.png)
Técnicas de Testes de Software - 1
Esta seqüência de artigos tem o objetivo de demonstrar algumas técnicas de testes simples, contribuindo para homologadores/analistas de testes em início de experiência. Espero que contribua.
____________________________________
Por Fernando Palma, Setembro de 2009
____________________________________
Por Fernando Palma, Setembro de 2009
Técnica de teste para telas de pesquisa
Ao validar uma tela de pesquisa, o homologador deve fazer os seguintes testes:
☺ Testar todas as combinações existentes dos campos para garantir que a tela funciona. Para uma busca com “a” campos, existirão 2ª combinações.
Ex: 3 filtros são dispostos em uma pesquisa. Portanto, então seriam 8 combinações.
A melhor técnica para alcançar este fim, é utilização de números binários, como demonstrado a seguir:
Ex: Imaginemos uma tela com os campos: Nome, Cidade e Estado.
Nome | Cidade | Estado |
0 | 0 | 0 |
0 | 0 | 1 |
0 | 1 | 0 |
0 | 1 | 1 |
1 | 0 | 0 |
1 | 0 | 1 |
1 | 1 | 0 |
1 | 1 | 1 |
*Considerando “0” o campo não preenchido e “1” o campo preenchido.
Como a tabela demonstra, 8 combinações de busca são realizadas.
Mas estes não são todos os testes, pois para cada campo preenchido, o desenvolvedor deve testá-lo preenchendo uma vez com parâmetros que retorne(m) registros(s) e outra vez com parâmetros que não retorne registro. Então, seriam na verdade 2 (ª + 1) à 2 elevado a “a” mais 1 combinações diferentes. No exemplo acima, seriam 16 combinações, na verdade.
Obs: Considerando que “R” represente um parâmetro que retorne registro(s) e “N” um parâmetro que não retorne nenhum registro.
Nome | Cidade | Estado |
0 | 0 | 0 |
0 | 0 | 1 (R/N) |
0 | 1 (R/N) | 0 |
0 | 1 (R/N) | 1 (R/N) |
1 (R/N) | 0 | 0 |
1 (R/N) | 0 | 1 (R/N) |
1 (R/N) | 1 (R/N) | 0 |
1 (R/N) | 1 (R/N) | 1 (R/N) |
O interessante desta técnica é imaginar uma tela com diversos filtros. 6, 8, 15 filtros de pesquisa. Representariam estes valores elevado ao cubo, quando traduzido em testes. Três conclusões podem ser tiradas, portanto:
1- O gerente responsável pelo projeto de software deve definir o nível de qualidade que é requerido para o sistema. Baseado nesta especificação, ou melhor: neste requisito de qualidade, o analista de testes/homologador executa a metade, um terço, ou até 1% das combinações existentes.
2- Quando parte das combinações são executadas, cabe ao Analista de Testes definir quais delas serão escolhidas, por representarem maior risco de falhas.
3- Ao receber os requisitos do sistema, no inicio do projeto, o Analista de Testes deve prevenir com estimativas de quantidade de testes que serão gerados. Esta colaboração é importante para que haja um balanceamento eficaz diante de escolhas, como esta: "quantos filtros existirão na tela?". Nem sempre o que é fácil de implementar é fácil de testar. Por isso, muitos analistas de testes já utilizam o conceito denominado "pontos de testes" para os requisitos de teste, que equivale aos "pontos de função" dos requisitos de sistema.
Aguardem outras técnicas, em breve.
Olá Fernando!
ResponderExcluirSou iniciante na atividade de testes... Ainda tenho que utilizar a imaginação para os teste pois onde trabalho além de não ter a cultura de testes não há também documentação de qualquer gênero. Artigos como este me ajudarão muito.