segunda-feira, 30 de junho de 2008

Guia Completo para Certificações em Teste de Software

 Estou postando a introção dada pelo Fábio no final do poste tem um link que leva para a página do testexpert com todas as certifição.


por  Fábio Martinho Campos

A crescente evolução do mercado faz com que os profissionais, cada vez mais, se atualizem através de programas de certificação profissional e por outro lado as empresas buscam por profissionais capacitados e qualificados.

Por muito tempo ainda as Certificações em T.I. serão um caso polêmico. Isso porque alguns não acreditam na real validade da certificação, achando que qualquer um que estudar poderá tirar a certificação sem experiência comprovada e que na verdade a certificação não comprova realmente a capacidade de um profissional resolver determinado cenário. Por outro lado, alguns acreditam que a certificação é essencial para completar a formação profissional, fazendo com que a pessoa se atualize constantemente, tornando também o profissional mais valorizado perante o mercado de trabalho.

O caso é que, atualmente, as Certificações em T.I. ainda fazem a diferença em entrevistas de emprego. Empresas preferem dar mais credibilidade para o profissional certificado do que o não-certificado. Isso depende da política de contratação de cada empresa e não serve de regra para todas.

Poderá ser que, com o tempo, as Certificações em T.I perderão seu valor, pois muitos profissionais também terão essas mesmas certificações. Para isso, terá que se criar um diferencial no futuro, a exceção da certificação, para se valorizar profissionalmente através de cursos de pós-graduação, mestrados, doutorados, especializações, etc.

O mais importante é viver "O Hoje" se preparando e se capacitando para que "No Amanhã" nós possamos manter nosso nível de profissionalismo e grau de especialização avançados para então continuarmos "vivos" no mercado de trabalho.

Para tanto, esse artigo tem o objetivo de guiar e ajudar profissionais de Qualidade e Teste de Software a escolher a melhor certificação e a que mais se encaixa na realidade de cada profissional. Há muito tempo pesquiso sobre as certificações em Qualidade e Teste de Software e tomei a iniciativa de agrupar todas elas em um único espaço, possibilitando a todos conhecer as mais diversas certificações existentes atualmente. Espero com isso, estar contribuindo para toda a comunidade brasileira de Qualidade e Teste de Software, de forma a possibilitar que os profissionais cada vez mais busquem alternativas de aprendizado e capacitação pessoal e profissional.


clique aqui "testexpert"para visualizar as possiveis certificações com Material de apoio para a certificação, Valor, Número de Questões, Duração, Formato e a Pontuação Mínima para Aprovação

sexta-feira, 27 de junho de 2008

Verificação, Validação e Teste de Software


O artigo [1], escrito em 1982, apresenta diversos conceitos e técnicas sobre verificação, validação e teste de software. Segundo os autores deste artigo, a qualidade de software é adquirida com a aplicação de técnicas de verificação e validação durante todo o processo de desenvolvimento de um software. São necessárias diversas técnicas para definir e medir a qualidade do software, como também é importante verificar a qualidade do processo de teste adotado. Quanto antes for aplicado um processo de teste no ciclo de desenvolvimento de um sistema, menos será o custo para corrigir os defeitos encontrados. Para isso o ideal é que haja um processo de teste independente, porém que seja altamente integrado ao processo de desenvolvimento.

Os casos de teste devem ser criados tendo o cuidado de verificar se todos os requisitos levantados foram abordados, pois sua finalidade é garantir que o software está fazendo o que ele deve fazer. As técnicas de teste de unidade e de cobertura geralmente são utilizadas na fase de codificação. As técnicas gerais descritas no artigo [1] foram “walk-through”, inspeções, revisões, prova de corretude e simulação. As técnicas de “walk-through” e inspeções verificam também as especificações a fim de detectar problemas até mesmo na fase de design. Os tipos de teste são divididos em testes de caixa-branca e caixa-preta. Para minimizar o número de entradas para os casos de teste, é necessário extrair algumas características do domínio, as quais irão representar o domínio como um todo, isso pode ser feito com a técnica de análise do valor limite.

Outra questão apresentada no artigo [1] foi com relação à qualidade dos casos de teste criados. Para verificar esta qualidade existem técnicas de análise estatística, análise de mutação, análise estática, análise de fluxo e análise dinâmica. A técnica de análise estatística utiliza testes de cobertura, que determinam o percentual de abrangência dos casos de teste ao executar o programa no momento do teste. Na técnica de mutação são gerados programas mutantes, onde neles são introduzidos diferentes defeitos, com a intenção de verificar se os casos de teste executados conseguem detectar tais falhas previamente conhecidas.

O artigo [2], foca na importância da aplicação de teste de software durante todo o desenvolvimento do sistema. No entanto, a prática de testes nas indústrias de software ainda é imatura. Além disso, as ferramentas que poderiam auxiliar com testes automáticos, ainda não estão prontas para determinados tipos de sistemas. Outra problemática é que o custo para garantir que o sistema está de acordo com a especificação é muito alto e fica mais alto ainda quanto mais tarde os testes forem realizados. O que impossibilita para uma melhor qualidade do sistema é a falta de formalização das especificações. Segundo Dijkstra, o teste pode ser usado para mostrar a presença de erros, mas nunca para mostrar que eles não existem. Foram apresentadas as definições para os termos debug, verificação, teste, validação e defeito. Uma coisa é importante, quanto mais riscos aquele sistema apresentar para a sociedade, mais tem que se investir na sua qualidade.

Crítica:

O que pude perceber com relação ao artigo [1] é que apesar de ele ter sido escrito há 25 anos atrás, ele aborda assuntos e técnicas bem atuais referentes a testes de software. É interessante perceber que muitas das técnicas apresentadas no artigo não passam de modelos matemáticos, mas que atualmente muitas delas são bastante utilizadas e outras são aplicadas através de ferramentas automáticas. Isso indica que este artigo contribuiu bastante para a evolução da área de teste de software.

Concordo com o que foi apresentado no artigo [2] no que diz respeito às dificuldades enfrentadas pelas empresas de software com relação ao processo de teste. Com relação ao custo, ele é alto se adotar técnicas de qualidade e mais alto ainda se não adotar, existe uma preocupação por parte das empresas no que diz respeito à melhor forma de adotar estas técnicas, de modo que minimize os custos [3].

Referências:

[1] ADRION, W. R; BRANSTAD, M. A and CHERNIAVSKY, J. C. Validation, Verification and Testing of Computer Software, published at ACM, p. 159-192, New York, 1982.

[2] HAILPERN, B. and SANTHANAM, P. Software debugging, testing, and verification at http://www.research.ibm.com/journal/sj/411/hailpern.html, wrote at 2002, accessed at Mar/08.

[3] WIKIPEDIA – Software Testing at http://en.wikipedia.org/wiki/Software_testing, accessed at Mar/08.


fonte: Grupo de testadores de software

quinta-feira, 26 de junho de 2008

Automação e Gerenciamento de Testes

Aumentando a Produtividade com as Principais Soluções Open Source e Gratuitas

por Cristiano Caetano

Desenvolver software de qualidade não é mais um requinte para poucos, transformou-se num fator de competitividade num mercado cada vez mais exigente. O filósofo Nietzsche, no século passado, alertava: "Com o aumento da competição, a qualidade se torna mera propaganda. Vence aquele que melhor engana". Essa receita é muito simples e fácil de seguir, todavia, quem tomar esse tipo de postura estará fadado ao fracasso. Nos dias de hoje, a qualidade tornou-se requisito imprescindível para garantir a sobrevida de um software no mercado.

Podemos concluir que as empresas mais competitivas são as empresas que trabalham sob a ótica da melhoria contínua dos processos para aumentar a qualidade do processo de desenvolvimento e, conseqüentemente, aumentar a qualidade do produto final. Neste contexto, devemos destacar adoção crescente de ferramentas para dar suporte ao processo de melhoria contínua. Estas ferramentas servem para dar suporte a todas as atividades relacionadas ao ciclo de vida de desenvolvimento de software: da concepção à implantação.

Na tentativa de dar suporte as pessoas interessadas nesse assunto, eu escrevi o livro "Automação e Gerenciamento de Testes: Aumentando a Produtividade com as Principais Soluções Open Source e Gratuitas". A proposta deste livro é apresentar as ferramentas Open Source e gratuitas essenciais para a gestão e automação de testes de software, sem no entanto, esgotar o assunto. O livro tem o propósito de apresentar um catálogo das melhores opções disponíveis atualmente e os seus principais recursos. O objetivo principal deste livro é fornecer informações e subsídios a fim de que o leitor seja capaz de utilizar os conhecimentos adquiridos para aprofundar-se no assunto e escolher a solução que melhor atenda a sua necessidade.

A organização das ferramentas do livro segue a filosofia apresentada pelo "Guide to the CSTE Common Body of Knowledge" do QAI que diz o seguinte: apesar de não existir uma categorização amplamente difundida das ferramentas de teste, a experiência tem mostrado que elas são normalmente agrupadas em 8 áreas distintas:
  1. Ferramentas de automação de testes de regressão;
  2. Ferramentas para gestão de defeitos;
  3. Ferramentas para testes de Performance/Stress;
  4. Ferramentas manuais;
  5. Ferramentas de rastreabilidade;
  6. Ferramentas de cobertura de código;
  7. Ferramentas para gestão de testes;
  8. Ferramentas de apoio à execução dos testes.


Dessa forma, a figura abaixo apresenta a relevância de cada tipo de ferramenta apresentada neste livro em relação às fases de um ciclo de vida de desenvolvimento de software:


clique na imagem para ampliar

Figura 1: Relevância de cada tipo de ferramenta apresentada neste livro em relação às fases de um ciclo de vida de desenvolvimento de software.

Além da apresentação das ferramentas agrupadas por áreas, o livro também aborda os seguintes temas:
  • Ferramentas Open Source Similares;
  • Ferramentas Comerciais Similares;
  • Repositórios de Ferramentas Open Source;
  • Ferramentas de Apoio;
  • Referências sobre Teste de Software;
  • Bibliografia Recomendada.

Por mais abrangente que sejam as categorias e ferramentas apresentadas neste livro, seria ingênuo pensar que ele ofereceria soluções que atendessem a necessidade de todos os leitores, afinal, muitos de vocês devem precisar de soluções específicas para a realização de testes de diversos tipos e nas mais diversas plataformas. Pensando neste cenário, fiz uma pesquisa extensa a fim de trazer para o leitor uma lista detalhada com os maiores e melhores repositórios de ferramentas Open Source do mundo. Assim, você poderá pesquisar a solução que se enquadre na sua necessidade no momento que você quiser.

O escopo do livro foi definido tendo em mente as ferramentas realmente essenciais; outro ponto que pesou muito foi o tamanho das comunidades apoiando e suportando estas ferramentas. Ferramentas com grandes comunidades e liberações freqüentes foram privilegiadas em relação às outras. De qualquer forma, me sinto na obrigação de compartilhar com o restante da comunidade de testes brasileira, a listagem das melhores ferramentas com base na pesquisa realizada para a criação do livro. As ferramentas são agrupadas por área e estão listadas na Tabela 1. Sinta-se à vontade para procurar uma ferramenta que atenda as suas necessidades. Não obstante, como o mundo Open Source evolui numa velocidade incrível, foi criado um MindMap dinâmico que será atualizado freqüentemente com as melhores opções disponíveis em cada área. O MindMap está disponível gratuitamente no seguinte endereço:

http://www.mindomo.com/view?m=d1535d37f8b0aa6df765a1db90bfa317


clique na imagem para ampliar


Você achou essas informações úteis? Suporte o autor, compre o livro. Este livro será unicamente comercializado por meio eletrônico (e-book). Esta foi uma decisão pessoal do autor para viabilizar a venda do livro por um preço justo a fim de permitir que todas as pessoas interessadas possam compra-lo. Para comprar o livro, ler a resenha, o sumário e um preview de várias páginas visite o seguinte endereço:

http://www.linhadecodigo.com.br/EBook.aspx?id=2951




fonte: TestExpert

terça-feira, 24 de junho de 2008

A qualidade da Wikipédia

No desenvolvimento de software, a qualidade do produto está diretamente relacionada à qualidade do processo de desenvolvimento, desta forma, é comum que a busca por um software de maior qualidade passe necessariamente por uma melhoria no processo de desenvolvimento.

Rodney Brooks, diretor do Laboratório de Inteligência Artificial e Ciência da Computação do MIT, define qualidade como a conformidade aos requisitos. Essa definição exige determinar dois pontos:
I) o que se entende por conformidade; e
II) como são especificados - e por quem - os requisitos.

esse trecho foi retirado do wikipedia(a Enciclopédia livre) desta página http://pt.wikipedia.org/wiki/Qualidade_de_software

A enciclopédia sem fins lucrativos, é gerida e operada pela Wikimedia Foundation. Está disponível em 257 idiomas ou dialetos com um total de 7,5 milhões de artigos, dos quais 2,1 milhões de artigos são referentes à versão em língua inglesa (dados de 11 de Dezembro de 2007) e 406 915 artigos na versão em língua portuguesa (dados de 23 de Junho de 2008). O número total de páginas ronda os 24 milhões e inclui imagens, páginas de usuários, páginas de discussão, categorias, predefinições, páginas de gestão dos projectos, etc. A versão alemã distribui-se também em DVD-ROM. Propõem-se, ainda, as idéias na versão anglófona, além de uma edição impressa.

Desde seu início, a Wikipédia tem aumentado firmemente sua popularidade, e seu sucesso tem feito surgir outros projetos irmãos. Segundo o Alexa, a wikipédia está entre os quinze websites mais visitados no mundo. A popularidade também deve-se ao fato de muitas das páginas terem sido ou copiadas ou "forkiadas". Nas palavras do co-fundador Jimmy Wales, a Wikipédia é "um esforço para criar e distribuir uma enciclopédia livre e em diversos idiomas da mais elevada qualidade possível a cada pessoa do planeta, em sua própria língua".

 Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!

…e também a pen drives, card drives, camisetas geeks, livros e mais! O BR-Linux e o Efetividade lançaram uma campanha para ajudar a Wikimedia Foundation e outros mantenedores de projetos que usamos no dia-a-dia on-line. Se você puder doar diretamente, ou contribuir de outra forma, são sempre melhores opções. Mas se não puder, veja as regras da promoção e participe - quanto mais divulgação, maior será a doação do BR-Linux e do Efetividade, e você ainda concorre a diversos brindes!

Conhecendo o BadBoy - parte 2

Por Elias Nogueira

Nesse post iremos aprender a utilizar as ferramentas Data Source e FormPopulator do BadBoy e aplicar um exemplo.
Primeiro explicarei brevemente como funciona cada uma destas ferramentas no BadBoy e depois faremos um exemplo pratico.
No final do post existe uma video-aula mostrando como foi criado o scrip. Você também pode visualizar os scripts diretamente no Youtube pelo link http://br.youtube.com/sembugs

Data Source


Muitas vezes precisamos interagir com um banco de dados ou efetuar consultas para verificar resultados dos nossos testes manuais. O BadBoy traz esta ferramenta para que possamos carregar dados de um banco de dados através de uma conexão ODBC do Windows. Inserimos um Data Source no script arrastando e soltando ele da aba Tools até o ponto que desejamos. Um ponto importante é colocarmos o Data Source ligado a um step sem qualquer outro item no step. Existem alguns requisitos que devem ser atendidos para a correta utilização do Data Source:
  • Todos os valores para todas as variáveis devem aparecer um uma única tabela
  • O nome das colunas deve ser idênticos as das variáveis
  • Se existiram dados repetidos em uma coluna, crie uma coluna de identificação com um numero seqüencial

Quando adicionamos um Data Source podemos ter a conexão ODBC criada ou simplesmente criá-la pela própria interface do BadBoy. A janela de propriedades do Data Source apresenta quatro itens importantes:
  • DataSource: é nele que selecionamos ou criamos a conexão ODBC. No momento que você insere o Data Source (item) é apresentada a tela para criar ou selecionar a conexão ODBC. Se você necessitar alterar a conexão clique no botão Change..
  • Load from Table: Selecione a tabela ou planilha apresentada pela conexão ODBC. É desta tabela que os dados serão carregados
  • Load Using SQL: Se necessitarmos carregar parte dos dados de uma tabela podemos escrever um comando em SQL para carregar estes dados
  • Map Columns to Variables: Se marcado como Automatic o BadBoy pressupõe que o nome das colunas da tabela e das variáveis são idênticas. Com Custom nos selecionamos somente as colunas que desejarmos.

clique na imagem para ampliar

A utilização correta do Data Source para efetuarmos loops no script tem de estar ligada a um step. Para isso devemos entrar nas propriedades do step e marcar o item Repeat for each value of variable e informar a variável. Note que já devemos ter a variável criada. Outro item a ser levado em consideração é que toda a ação na pagina que dependa do loop deve Ester contida neste step.


clique na imagem para ampliar

Form Populator

Em praticamente todas as paginas web que necessitam que o usuário entre com dados nele são utilizados um elemento HTML chamado Form. O Form HTML consiste em caixas de entrada de dados e um botão de submissão destes dados.

O BadBoy trabalha muito bem com esse elemento HTML através do Form Populator. Ele basicamente verifica se existe algum elemento Form na pagina e pega todos os dados dele, trazendo a informação consigo para poder popular com dados.
Não precisamos utilizar o Form Populator para a maioria dos scripts criados, uma vez que os dados já são transmitidos por parâmetros no request (requisição). Utilizamos ele em casos que não conseguimos, de forma fácil, entrar com dados em um formulário.


clique na imagem para ampliar

Para inserir um Form Populator devemos inseri-lo abaixo da requisição que contem o Form. Podemos clicar sobre cada informação carregada pelo Form e inserir um dado ou atribuir a ele uma variável, como mostra a figura acima. Na propriedade do Form podemos informar o elemento Form alvo e se o método é Populate ou Clear, ou seja, inserir valores ou limpar o Form.

Exemplo de utilização do Data Source e Form Populator


Agora veremos um exemplo pratico de como utilizar estas duas ferramentas. Nosse exemplo será sobre o site de demonstração da ferramenta TestLink, onde criaremos um script que efetua o login com dois usuários, um de cada vez, e no momento do login verificarmos se o usuário que entrou no sistema é o correto. Primeiro teremos que criar um banco de dados no MS Access com duas colunas: login e password e inserir os valores abaixo. A vídeo-aula mostra como criar o banco.

clique na tabela para ampliar


Agora é necessário criar uma conexão ODBC com qualquer nome, vamos escolher “BanocBadBoy”. A video-aula mostra como criar a conexão ODBC. Depois do banco e a conexão ODBC criada vamos partir para a criação do script:

  1. Abra o BadBoy e no primeiro step arraste e solte o item Data Source para ele. Será apresentada a tela para selecionarmos ou criarmos a conexão ODBC. Como já criamos selecionamos a conexão criada (BancoBadBoy ou o nome escolhido por você)
  2. Após selecione a tabela criada segundo a estrutura que falamos acima.Feche a janela de propriedades do Data Source.
  3. Agora insira um step e digite o seguinte endereço na barra de URL: http://testlink.org/demo/login.php. Será criada uma requisição para a página.
  4. Arraste a ferramenta Form Populator para baixo da requisição criada. Será apresentada sua tela de propriedades. Feche a janela. O Form Populator deve apresentar os campos de login e password abaixo dela.
  5. Insira o usuário admin e senha testlink para autenticação no TestLink. Sera criada uma nova requisição.
  6. Seleciona o texto “Role :: [ admin ]” e clique no botão Easy Assertion. Isso servirá depois para validarmos o usuário.
  7. Depois da asserção criada efetue um logoff no sistema.
  8. Agora vá até a requisição abaixo do Form Populate e crie duas variáveis para os parâmetros de login e password clicando com o botão direito sobre cada uma e selecionando Add as variable
  9. Entre nas propriedades do Check da Assertion criada. Dentro do texto do Check substitua “admin” por “${login}”.
  10. Em cada item do Form Populator insira a variável correspondente digitando o nome dela para cada um.
  11. Agora entre nas propriedades do Data Source, selecione o item Custom no painel Map columns to variables e deixe marcado os dois itens: login e password.
  12. Agora basta fazem a repetição do step que contem todas as ações na pagina. Fazemos isso abrindo a janela de propriedades do step e selecionando o item For each value of variable com o valor login.
Fazendo isso dizemos que o step vai ser executado novamente para cada valor de login diferente no banco de dados.

Agora é só executar o script, na primeira iteração ele ira preencher os dados com o usuário admin e verificar pela Assertion se o nome do usuário é igual ao mostrado na tela. Depois do logoff o valor de login é alterado e o step é executado novamente.

Como criar o banco com MS Access

http://www.youtube.com/watch?v=-ziBFucFpx0

Como criar a conexão ODBC no Vista (semelhando no Windows XP)
http://www.youtube.com/watch?v=FSViJnNLJZk

Como criar o script de exemplo
http://www.youtube.com/watch?v=l_KAqTa1DRA

Conhecendo o BadBoy - parte 1

Por Elias Nogueira

BadBoy <http://www.badboy.com.au/>.

BadBoy é uma ferramenta desenvolvida em C++ (sim, não vai funcionar no linux,
infelizmente) que grava todas ações que você faz em uma página web
(java, php, ruby, etc...). Ele é capaz de gravar, como uma macro, tudo o que você faz na página web como requests, parâmetros, alert, respostar, etc.. Com
ele você pode alterar parâmetros das páginas que você está testando,
efetuar asserções por texto (simples ou html), cor, javascript, etc... Veremos
então, nesta primeira parte, a estrutura básica do BadBoy e suas
principais ferramentas (pelo menos as mais fáceis de utilizar. Segue a tela principal do BadBoy (numeração em vermelho)


clique na imagem para ampliar


  1. Barra de ferramentas
Aqui encontramos todos os botões para as principais ações no Badboy, veromos
com detalhes cada uma das ações asseguir e nos outros tutoriais.

     2.  Barra da URL
Aqui digitamos o endereço de entrada que iremos gravar o script e onde
aparecerão as demais url's enquanto vamos navegando nas paginas.

     3.  Estrutura do Script
Aqui é apresentada a principal estrutura de script do BadBoy com a estrutura de

  • Suites:  
   Organiza seu script da mesma forma de um test, mas com a diferença de
ter apenas uma suite (não nesessário, pois o suite e test possuem quase
as mesmas funcionalidade).
  • Tests:   
   Organiza o seu script como um teste, podendo transforma-lo em um
template (que tambem será apresentado mais tarde). Você pode organizar
o Tests como um TestCase ou como partes agrupadas de teste no seu script
  • Steps:  
   Organiza o seu script como passos para execução de determinada ação ou
grupo de ação. Um step pode virar uma Thread, pode repetir N vezes,
pode ser monitorada e ser transformada em test.

Uma estrutura básica com um script é apresentada abaixo:


clique na imagem para ampliar



Tools


Tools apresenta uma série de ferramentas para auxilia-lo na gravação, execução e visualização do seu script.

Summary:
Apresenta todos os dados referente a execução do seu script (nro de
execuções, falhas, sucessos, tempo medio de execução, etc...)

Variebles:
apresenta todas as variaveis que podem ser utilizadas no script para substituir um determinado parâmetro.

Graph:
Apresentação do gráfico contendo o tepo medio da execução de cada step do script.

Toos:
Uma série de ferramentas que podem ser adicionadas no seu script para ajuda-lo a obter o sucesso da execução do seu script.

Checkers:
Série de analisadores que podem ser inseridos para efetuar alguma verificação na página.

References:
itens que podem ser adicionados como requirements ou defeacts para
ajudar você a visualizar o que precisa see verificado ou ajuda-lo em
algum decisão dentro da ferramenta, a fins ilustrativos.


Visualizador da página


É aqui será exibida a página enquanto você grava sua execução. Você
interege com a pagina neste painel, onde também pode aplicar os
checkers.

Como Gravar um Script no BadBoy

Os passos para a gravação de um script é bem fácil

     1.  Abra o BadBoy. Ele já estará em mode de gravação, que pode ser visualizado
pelo botão Record pressionado na barra de ferramentas 
     2.  Digite a URL na barra de endereço. O BadBoy Automaticamente criará a o request com todos os parâmetros da página requisitada.
     3.   Começe a interagir ocm a página no painel de visualização da página. Todas as
ações na página serão adicionadas na estrutura do script do BadBoy.



 

Este e outros posts sobre Teste e Qualidade você encontra no blog SemBugs:
http://sembugs.blogspot.com

segunda-feira, 23 de junho de 2008

Casos de Testes

Finalidade

A finalidade do Caso de Teste é identificar e comunicar formalmente as condições específicas detalhadas que serão validadas para permitir a avaliação de determinados aspectos dos Itens do Teste-alvo. Os Casos de Teste podem ser motivados por vários fatores, mas normalmente incluirão um subconjunto dos Requisitos (Casos de Uso, características de desempenho etc.) e dos riscos envolvidos no projeto.

O Caso de Teste é usado basicamente:

* para enumerar um número adequado de testes específicos para garantir a abrangência da avaliação.
* para identificar e considerar Scripts de Teste e geradores, de forma manual e automatizada.
* para fornecer um esquema para a implementação de Scripts de Teste e geradores, fornecendo uma descrição dos pontos-chave de observação e controle e qualquer pós ou precondição.

Ocorrência

As primeiras sugestões de Casos de Teste podem ser identificadas logo na Fase de Iniciação, sendo identificadas subseqüentemente em cada iteração durante o restante do ciclo de vida do projeto. É normal que os Casos de Teste sejam definidos em detalhes de acordo com o trabalho de implementação programado para eles, geralmente iniciando na primeira iteração, na Fase de Elaboração.

Responsabilidade

O Analista de Teste é basicamente responsável por esse artefato. As responsabilidades incluem:

  • Identificação e definição de cada Caso de Teste e aprovação de todas as mudanças subseqüentes em cada um deles.
  • Certeza de que as mudanças serão comunicadas aosresponsáveis afetados.
  • Certeza de que tenham sido identificados Casos de Teste suficientes para permitir uma avaliação satisfatória dos Itens de Teste-alvo.
  • Certeza de que há detalhes suficientes para implementar e conduzir o teste.
  • Gerenciamento e manutenção de relacionamentos de rastreabilidade apropriados.
  • Gerenciamento do escopo apropriado dos Casos de Teste em uma iteração específica.

Adaptação

Em determinados domínios e culturas de teste, os Casos de Teste são considerados artefatos opcionais, enquanto em outros, eles são altamente formalizados e obrigatórios. Assim sendo, o conteúdo e o formato dos Casos de Teste podem necessitar de modificação para atender às necessidades de cada organização ou projeto específico.

Quando esses casos de teste são registrados (de maneira formal ou informal), dois estilos principais são seguidos:

  • O primeiro consiste em uma estrutura de documento de texto padrão Em geral, várias instâncias ou variações de Casos de Teste são especificadas em um único documento e agrupadas pela finalidade ou pelo objetivo geral dos testes.
  • O segundo estilo usa um determinado formato de tabela ou banco de dados. As instâncias de Casos de Uso são especificadas em cada linha, com colunas que facilitam a classificação e a filtragem por diferentes critérios.

É necessário que haja algum tipo de avaliação contínua dos casos de teste para verificar andamento, eficácia etc. Considere uma cobertura de teste baseada em requisitos, em que cada Caso de Teste pesquise pelo menos uma idéia de teste e um requisito de sistema, que representa um subconjunto dos requisitos do Produto.

Conforme mencionado anteriormente, é comum que várias instâncias ou variações de Casos de Teste sejam especificadas em um único documento e normalmente estejam agrupadas pela finalidade ou pelo objetivo geral dos testes. Elas podem ser concebidas como várias condições de execução descritas em um único documento, uma para cada instância exclusiva de Caso de Teste.

modelo:

Clique na tabela para ampliar



Clique na tabela para ampliar

A Disciplina de Teste

O teste enfatiza principalmente a avaliação da qualidade do produto, realizada através de várias práticas centrais:

  • Localizar e documentar defeitos na qualidade do software.
  • Avisar de forma geral sobre a qualidade observada no software.
  • Validar as suposições feitas nas especificações de design e requisito através de demonstração concreta.
  • Validar as funções do software conforme projetadas.
  • Verificar se os requisitos foram implementados de forma adequada.

O Teste tem como principal finalidade localizar e expor os pontos fracos do software

A realização de testes de software tem por finalidade imprimir qualidade ao produto gerado. Porém, o que é Qualidade?

As Metodologias Ágeis definem qualidade da seguinte forma:

"...as características que demonstram haver produzido um produto que atinge ou excede os requisitos estabelecidos - conforme avaliado por métricas e critérios acordados - e que é produzido por um processo também acordado."

Documente os seus Testes

Esse documento descreve 8 sugestões de documentação:

  • Plano de Teste: Apresenta o planejamento para execução do teste, incluindo a abrangência, abordagem, recursos e cronograma das atividades de teste.

A tarefa de especificação de testes é coberta por 3 documentos:
  • Especificação de Projeto de Teste: Refina a abordagem apresentada no Plano de Teste e identifica as funcionalidades e características a serem testadas pelo projeto e por seus testes associados.
  • Especificação de Caso de Teste: Define os casos de teste, incluindo dados de entrada, resultados esperados, ações e condições gerais para a execução do teste.
  • Especificação de Procedimento de Teste: Especifica os passos para executar um conjunto de casos de teste.

Os relatórios de teste são cobertos por 4 documentos:
  • Diário de Teste: Apresenta registros cronológicos dos detalhes relevantes relacionados com a execução dos testes.
  • Relatório de Incidente de Teste: Documenta qualquer evento que ocorra durante a atividade de teste e que requeira análise posterior.
  • Relatório-Resumo de Teste: Apresenta de forma resumida os resultados das atividades de teste associadas com uma ou mais especificações de projeto de teste e provê avaliações baseadas nesses resultados.
  • Relatório de Encaminhamento de Item de Teste: Identifica os itens encaminhados para teste no caso de equipes distintas serem responsáveis pelas tarefas de desenvolvimento e de teste.
Estes são apenas os "resumos" de cada item.

Você não precisa utilizar todos estes itens necessariamente. O ideal é você utilizar o que mais se adequar a sua necessidade.

Para saber mais sobre esta norma e sobre o assunto visite estes links
http://www.ruleworks.co.uk/testguide/IEEE-std-829-1998.htm
http://www.ieee.org.br/
http://www.ieee.org/portal/site

Fonte: Sem Bugs

sexta-feira, 20 de junho de 2008

Técnicas de Teste Funcional (Caixa Preta)

O Teste Caixa Preta é executado tomando como base os requisitos e as funcionalidades do software. A Técnica de Teste funcional é feita para assegurar que os requisitos do software e as especificações foram atendidos.

O Processo normalmente envolve a criação de cenários de testes para o uso na avaliação das funcionalidades da aplicação, validando se o que foi especificado foi implementado corretamente. Os tipos de testes utilizados na execução da técnica funcional são apresentados na tabela a seguir:


Clique na tabela para ampliar

Na prática é quase impossível testar todas as possibilidades de formas alternativas de entrada de dados, bem como testar as diversas possibilidades e condições criadas pela lógica do programador. Os testes de caixa preta cobrem as funcionalidades, mas nem sempre cobrem todo o código do programa. Erros de requisitos descobertos apenas quando o software já está em produção estão entre aqueles defeitos mais caros de serem corrigidos. Dessa forma, as técnicas mais modernas de teste de software sugerem que os defeitos sejam buscados também nas fases iniciais de desenvolvimento do software e que os testes se repitam por todo ciclo de vida do processo de desenvolvimento.

Técnicas de Teste

Atualmente existem muitas maneiras de se testar um software. Mesmo assim, existem as técnicas que sempre foram muito utilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje têm grande valia para os sistemas orientados a objeto. Apesar de os
paradigmas de desenvolvimento serem completamente diferentes, o objetivo principal destas técnicas continua a ser o mesmo: encontrar falhas no software. Abaixo estão descritas as três técnicas mais conhecidas.

Caixa-Branca

Técnica de teste, também chamada de Teste Estrutural, que avalia o comportamento interno do componente de software. Essa técnica trabalha diretamente sobre o código-fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste
de ciclos e teste de caminhos lógicos. Os aspectos avaliados nesta técnica de teste dependerão da complexidade e da tecnologia que determinarem a construção do componente de software, cabendo portanto avaliação de mais aspectos que os citados anteriormente. O testador tem
acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas e componentes. Este tipo de teste é desenvolvido analisando-se o código fonte e elaborando-se casos de teste que cubram todas as possibilidades do componente de software.

Dessa maneira, todas as variações originadas por estruturas de condições são testadas. Um exemplo bem prático desta técnica de teste é o uso da ferramenta livre JUnit para desenvolvimento de classes de teste (test cases) para testar classes ou métodos desenvolvidos em Java .

Também se enquadram nessa técnica testes manuais ou testes efetuados com apoio de ferramentas para verificação de aderência a boas práticas de codificação reconhecidas pelo mercado de software. A aderência a padrões e boas práticas visa principalmente a diminuição da
possibilidade de erros de codificação e a busca de utilização de comandos que gerem a melhor performance de execução possível. Apesar de muitos desenvolvedores alegarem que não há ganhos perceptíveis com essa técnica de teste aplicada sobre unidades de software, devemos lembrar que, no ambiente produtivo, cada programa pode vir a ser executado milhares ou milhões de vezes em intervalos de tempo pequenos. É na realidade de produção que a soma dos aparentes pequenos tempos de execução e consumo de memória de cada programa poderá levar o software a deixar de atender aos objetivos esperados. A técnica de teste de Caixa-Branca é recomendada para as fases de Teste da Unidade e Teste da Integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que por sua vez conhecem bem o
código-fonte produzido.

Caixa-Preta

Técnica de teste, também chamado de Teste Funcional, em que o componente de software a ser testado é abordado como se fosse uma caixa-preta, ou seja, não se considera o comportamento interno do mesmo. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido.

O componente de software a ser testado pode ser um método, uma função interna, um programa, um componente, um conjunto de programas e/ou componentes ou mesmo uma funcionalidade. A técnica de teste de Caixa-Preta é aplicável a todas as fases de teste - fase de teste de unidade (ou teste unitário), fase de teste de integração, fase de teste de sistema e fase de teste de aceitação.

A aplicação de técnicas de teste leva o testador a produzir um conjunto de casos de teste (ou situações de teste). A aplicação combinada de outra técnica - Técnica de Particionamento de Equivalência (ou uso de Classes de Equivalência) permite avaliar se a quantidade de
casos de teste produzida é coerente. A partir das classes de equivalência identificadas, o testador irá construir casos de teste que atuem nos limites superiores e inferiores destas classes, de forma que um número mínimo de casos de teste permita a maior cobertura de teste possível.

Outras Técnicas

Outras técnicas de teste podem e devem ser utilizadas de acordo com necessidades de negócio ou restrições tecnológicas. Destacam-se as seguintes técnicas: Teste de Performance, Teste de Usabilidade, Teste de Carga, Teste de Stress, Teste de Confiabilidade e Teste de Recuperação.

Alguns autores chegam a definir uma técnica de Teste Caixa Cinza, que seria um mesclado do uso das técnicas de Caixa Preta e Caixa Branca, mas, como toda execução de trabalho relacionado à atividade de teste utilizará simultaneamente mais de uma técnica de teste, é recomendável que se fixem os conceitos primários de cada técnica.

Metodologias de desenvolvimento e Testes

Um desenvolvimento organizado de software tem como premissa uma metodologia de trabalho. Esta deve ter como base conceitos que visem a construção de um produto de software de forma eficaz. Dentro desta metodologia estão definidos os passos necessários para chegar ao produto final esperado. Esse é o campo de estudos da Qualidade de Software , uma sub-área da Engenharia de Software .

Assim, quando se segue uma metodologia para o desenvolvimento de um produto de software espera-se um produto final que melhor agrade tanto aos clientes quanto ao próprio fornecedor, ou seja, a empresa de desenvolvimento.

Observando este aspecto, não faz sentido iniciar a construção de um produto de software sem ter uma metodologia de trabalho bem solidificada e que seja do conhecimento de todos os envolvidos no processo. Porém, além de uma crescente demanda por softwares de qualidade, as empresas de desenvolvimento de software sofrem cada vez mais pressão por parte dos clientes para que o produto seja entregue num curto período de tempo. Este fato pode fazer com que uma sólida
metodologia de trabalho acabe por se desequilibrar.

Independentemente da metodologia de trabalho empregada no desenvolvimento de um software, para que se obtenha um produto final com um certo nível de qualidade é imprescindível a melhoria dos processos de engenharia de software.

Uma maneira viável para se assegurar a melhoria de tais processos seria tomar como base modelos sugeridos por entidades internacionais respeitadas no assunto. Dentro de uma gama de modelos, sejam eles para situações e ambientes específicos ou para soluções genéricas, existem alguns que são mais utilizados e tidos como eficientes, como por exemplo os SW-CMM , SE-CMM , ISO 15504 e o mais conhecido CMMI .

Outro fator com grande influência sobre a qualidade do software a ser produzido é o que diz respeito aos testes que serão executados sobre tal produto. Todas as metodologias de desenvolvimento de software têm uma disciplina dedicada aos testes. Atualmente esta é uma tarefa indispensável, porém muitas vezes efetuada de maneira ineficiente, seja pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pela falta de recursos humanos e financeiros.

O Teste de Software

O teste do software é um processo realizado pelo testador de software que permeia outros processos da Engenharia de Software e envolve ações que vão do levantamento de requisitos (necessidades) até a execução do teste propriamente dito. O objetivo, por paradoxal que pareça, é encontrar defeitos nos produtos, para que estes possam ser corrigidos pela equipe de programadores, antes da entrega final. A maioria das pessoas pensa que o teste de software serve para demonstrar o correto funcionamento de um programa, quando na verdade ele é
utilizado como um processo da engenharia de software para encontrar defeitos.


O processo de teste de software é voltado para o alcance de um nível de qualidade de produto, que durante o processo de desenvolvimento de software muda conforme avanço das  atividadades - requisitos, protótipos, modelo de dados lógico, modelo de dados físico,
código-fonte, módulos funcionais e finalmente um sistema.

O conceito de teste de software pode ser compreendido através de uma visão intuitiva ou mesmo de uma maneira formal. Existem atualmente várias definições para esse conceito. De uma forma simples, testar um software significa verificar através de uma execução controlada se o seu comportamento corre de acordo com o especificado. O objetivo principal desta tarefa é encontrar o número máximo de erros dispondo do mínimo de esforço, ou seja, mostrar aos que desenvolvem se os resultados estão ou não de acordo com os padrões estabelecidos.

Nem pode-se garantir que todos os programas funcionariam corretamente, sem a presença de erros humanos, visto que os mesmos muitas vezes possuem um grande número de estados com fórmulas, atividades e algoritmos complexas. O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumentam ainda mais a complexidade.

Falhas podem ser originadas por diversos motivos, como os listados abaixo:

         • A especificação pode estar errada ou incompleta.

         • A especificação pode conter requisitos impossíveis de serem implementados, devido à limitações de hardware ou software.

         • Talvez a base de dados esteja organizada de forma que não seja permitido distinguir os tipos de usuário.

         • Pode ser que haja um erro no algoritmo de controle dos usuários

         • Pode ser que haja erros no código, o algoritmo pode estar implementado de forma errada ou incompleta.

Portanto, uma falha é o resultado de um ou mais defeitos em algum aspecto do sistema.

O teste de software pode ser visto como uma parcela do processo de qualidade de software. A qualidade da aplicação pode, e normalmente, varia significativamente de sistema para sistema mas os atributos qualitativos previstos na norma ISO 9126 que são: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.