Introdução ao uso de testes exploratórios

O processo de teste software tem dois objetivos distintos: o de demonstrar aos desenvolvedores e ao cliente que o produto atende ao seu propósito, através da conformidade com os requisitos; e vasculhar o produto à procura de falhas ou defeitos, ou aspectos que não estão de acordo com as especificações. A meta do teste de software é convencer os desenvolvedores e clientes que o software é bom o suficiente para ser operacional.

O método clássico para o processo de testes de software se baseia no modelo em V, com o planejamento dos testes durante as fases iniciais do projeto e a execução dos testes nas fases posteriores do processo de desenvolvimento de software, conforme apresenta a Figura 1.

O planejamento para o teste ocorre de cima para baixo no modelo em V. Quando se obtêm as especificações de requisitos, já se inicia o planejamento do teste de aceitação. A partir do projeto de alto nível é planejado o teste de sistema, do projeto detalhado são concebidos os planos para testes de integração e finalmente no processo de codificação pode-se planejar os testes de unidade. Para a execução dos testes, a ordem é contrária à da criação dos planos, partindo dos testes de unidade até o teste de aceitação.

Todas as fases do modelo V tradicional são orientadas à geração de casos de testes baseados em scripts utilizando como base a documentação detalhada de requisitos. Os casos de testes baseados em scripts, em geral, contêm um passo a passo detalhado da execução de cada funcionalidade do software, com todas as variações de dados e resultados esperados para cada caso de teste especificado. Um exemplo simples de caso de teste é: o sistema deve apresentar como resultado esperado a mensagem “Cliente cadastrado” caso todos os dados inseridos do cliente estejam corretos. Uma variação “negativa” necessária para avaliar o comportamento é testar se o sistema apresenta, como resultado esperado, a mensagem “CPF inválido”, caso o CPF inserido do cliente esteja incorreto.

A geração de casos de testes baseados em scripts acrescenta um esforço considerável para os projetos de desenvolvimento de software, pois devem ser criados os scripts de testes exercitando todos os cenários possíveis de todas as funcionalidades existentes no software. Invariavelmente, em grandes projetos, são geradas centenas ou até milhares de casos de testes.

Um exemplo simples desse esforço é se analisarmos uma tela de cadastro complexa, com, aproximadamente, 20 regras de negócios, e que necessita de levantamento dos casos de testes pelo analista de testes. Serão dezenas de casos de teste apenas para exercitar essa tela minimamente. Considerando, como base, a técnica de classe de equivalência, deveremos ter um caso de teste para cobrir a entrada válida das regras de negócio e vinte casos de testes para exercitar as entradas inválidas das regras de negócios, totalizando 21 casos de testes apenas para essa tela.

Durante as fases de execução dos testes, no outro lado do modelo V, o testador fica restrito a testar com os dados sugeridos nos scripts e analisar os resultados esperados dos casos de testes conforme descrito. Essa rigidez no seguimento dos casos de testes diminui a criatividade e a capacidade de adaptação do testador, pois com o melhor entendimento do domínio do software, o testador teria melhor capacidade de variar os valores inseridos e, dessa forma, exercitar mais apuradamente as funcionalidades do software. Outro ponto importante trata da senioridade do testador obtida com o aprendizado de diversos projetos do domínio. Contudo, o testador fica “engessado”, executando scripts de testes pré-definidos sem poder colocar em prática a experiência adquirida." [...] continue lendo...