De que se trata o artigo:
Este artigo apresenta algumas abordagens para geração de casos de teste caixa preta. Neste sentido, são apresentadas as abordagens: random sampling, pairwise testing e N-wise testing.
Em que situação o tema útil:
A discussão deste tema é importante para todos aqueles que trabalham com o planejamento e execução de casos de teste em seu dia a dia. Isto por que o artigo apresenta alternativas para geração de casos de testes considerando cenários onde não tenhamos acesso ao código fonte da aplicação (teste caixa preta).
Resumo DevMan:
Ao testarmos qualquer software, sempre teremos duas variáveis importantes a serem gerenciadas: custo e benefício da atividade de teste. Como veremos ao longo deste artigo, uma sempre será limitada pela outra. Além disso, ao testarmos aplicações muito complexas, os custos do teste podem crescer rapidamente, podendo eliminar parte de seus benefícios oferecidos. Neste sentido, as técnicas que serão apresentadas aqui auxiliam na geração automatizada de cenários de teste (desde que apoiadas por ferramentas, claro), reduzindo desta forma os custos associados às atividades de teste (planejamento e execução).
Este artigo foi baseado no artigo “Test Smarter, Not Harder” de autoria de Scott Sehlhorst.
Imagine que estejamos desenvolvendo uma página web de compras de notebooks cujo foco seja a customização do notebook para compra. Caso você não consiga imaginar quais funcionalidades estariam presentes em uma aplicação web desta natureza, você pode ver como funciona o site de compras de notebook da Dell.
De uma forma bem resumida, existem algumas questões pré-definidas que permitem a configuração de um conjunto de itens em um notebook. Para cada questão, um conjunto de escolhas deve ser efetuado pelo usuário. Apenas para ilustrar, vamos considerar que existem 11 questões de customização e que para cada uma o usuário pode fazer um número diferente de escolhas conforme os dados (2, 2, 2, 2, 2, 3, 2, 2, 3, 4, 7). Considerando este cenário, o número total de possíveis combinações que levam a diferentes notebooks é dado pelo produto de todas as escolhas possíveis, que neste cenário totalizam 32.256 possibilidades. Perceba que se incrementássemos um pouco a quantidade de escolhas possíveis em cada questão ou aumentássemos um pouco o número de questões, chegaríamos facilmente a mais de 1 milhão de combinações possíveis.
Considerando este cenário, criar uma suíte de testes que percorra ao menos uma vez cada uma das combinações de dados possíveis pode ser bastante desafiador. Perceba que até mesmo se automatizássemos a geração dos casos de teste, ainda assim sua execução poderia ser altamente custosa. Neste sentido, poderíamos pensar também na execução automática dos casos de teste. Com isso, teríamos resolvido o problema da geração e da execução dos casos de teste.
Focando agora um pouco nossa discussão na questão da execução dos casos de teste, teríamos duas opções:
· Desenvolver um sistema baseado em regras para executar todas as combinações possíveis, ou;
· Adquirir uma ferramenta de testes disponível no mercado.
Entretanto, as duas soluções não são, na prática, tão simples assim de serem realizadas. Primeiro por que definir todas as regras de execução e validação dos casos de teste não seria trivial. Segundo por que, uma vez desenvolvidas as regras, sua manutenção poderia ser altamente custosa. Terceiro por que normalmente as ferramentas que apóiam este tipo de teste tendem a ser genéricas, o que traria como consequência um esforço muito alto de customização.
Perceba que, com isto em mente, fica fácil perceber que os custos de execução também seriam altíssimos. Aliado a isso, como na maioria das vezes não temos tantos recursos assim para a execução das atividades de teste, devemos sempre ter em mente que esta atividade deve ser considerada sob limitações de esforço, tempo e custo, o que inviabiliza na grande maioria das vezes a execução de testes de forma exaustiva ou que se proponham a testar todos os cenários possíveis do software.
Não podemos evitar a execução dos testes
Existem algumas situação onde o custo da qualidade excede o custo da não qualidade. Estas situações ocorrem quando a infraestrutura necessária, o tempo de desenvolvimento de teste e os custos de manutenção dos testes excedem o custo de ter um defeito inserido no software.
A partir de agora, as técnicas descritas neste artigo apresentarão alternativas que podemos fazer uso para reduzir o custo da qualidade. Certamente fazer uso delas é melhor do que simplesmente não testar o software por conta dos altos custos do planejamento e execução dos testes.
Normalmente, pessoas que não possuem conhecimento sobre a complexidade em se planejar e executar testes ou desconhecem as limitações das ferramentas de automação de testes tendem a solicitar que o software seja testado completamente (com 100% de cobertura).
Talvez você já tenha escutado, nos projetos em que participou, coisas do tipo: “Eu preciso que o teste tenha 100% de cobertura! Nossa política é tolerância 0. Produtos com má qualidade não fazem parte de meu trabalho!”
O ponto de discussão aqui é justamente a falta de preocupação com o uso do “100% de cobertura” e a falta de um critério mais bem definido para se identificar taxas de defeito aceitáveis no software. Você pode até não gostar, mas defeitos quase sempre estarão presentes no software.
Não existe uma fórmula secreta para atingirmos a qualidade total em um sistema de software. Para lidarmos com isso, muitas vezes fazemos uso de estatísticas, níveis de confiança, planejamento de riscos... Como engenheiros, conseguimos entender a complexidade envolvida na tentativa de assegurar a qualidade do software. Entretanto, como tornar isso claro para aqueles que não possuem este conhecimento técnico?
Do ponto de vista lógico, questionamentos como o seguinte fazem até sentido: “Nós temos um conjunto de ferramentas para execução de testes automatizados. Agora basta definir as entradas e observar se o software se comportará adequadamente ou não!”. Entretanto, na realidade não é bem assim. Testar é uma atividade complexa e que precisa ser executada dentro de restrições existentes. Sendo assim, precisamos trabalhar no sentido de maximizarmos o nível de cobertura dos testes ao mesmo tempo em que fazemos isso dentro de limitações de recursos pré-estabelecidos. É justamente sobre isso que vamos falar a partir da próxima seção.
...
