Artigo no estilo Mentoring
Estes visam apoiar na customização do esforço de teste em um projeto. Neste artigo, serão discutidas estratégias para melhor especificação de casos e procedimentos de teste em projetos de software. Para isso, será utilizado um exemplo simples e comum de ser encontrado em sistemas de informação, um formulário de cadastro de venda de produtos online com diversas regras de negócio para validação dos dados preenchidos, e realizaremos a especificação dos casos e procedimentos de teste de forma a torná-la mais completa e objetiva, apoiando assim testes manuais e automáticos.
Qualquer profissional da área de teste de software possivelmente conhece e/ou já precisou especificar casos e/ou procedimentos de teste.
Segundo Craig e Jaskiel (2002), estes artefatos do processo de teste de software podem ser definidos da seguinte forma:
· Caso de Teste: descreve uma condição particular a ser testada e é composto por valores de entrada, restrições para a sua execução e um resultado ou comportamento esperado.
· Procedimento de Teste: é uma descrição dos passos necessários para executar um caso (ou um grupo de casos) de teste.
Aqueles com um pouco mais de experiência profissional devem perceber que uma das dificuldades enfrentadas na atividade de teste é a especificação dos casos e procedimentos de testes, não apenas pela dificuldade natural exigida pela tarefa, mas pelas variações de formato de descrição destes artefatos em diferentes locais.
Apesar de existir um padrão internacional para a especificação de casos e procedimentos de teste publicado no padrão IEEE-Std-829 (roteiro de documentos para a atividade de teste em geral, não apenas casos e procedimentos de teste, cuja versão mais atual foi publicado em 2008), este padrão em geral serve apenas como um roteiro e normalmente é customizado pelas empresas, em certas ocasiões de forma correta, porém em outras, de forma indevida.
Na verdade, o padrão IEEE-Std-829 foi proposto exatamente com o intuito de servir como base para que empresas de software pudessem definir o seu roteiro de documentos para as atividades de teste de software. Cada organização possui suas especificidades e isso precisa ser refletido no roteiro utilizado para documentar suas atividades de teste.
Assim, se um determinado formato funciona adequadamente para a empresa X, é por que ele contém o conjunto de informações necessárias para que os demais membros da equipe de teste desempenhem de forma satisfatória suas atividades. Contudo, não há garantia de que mesmo este formato funcionando adequadamente em uma empresa, ele possa ser utilizado de forma satisfatória por outra com características ou perfil diferentes. Maiores ou menores níveis de detalhamento na descrição podem ser necessários.
Apesar de não existir um padrão universal ou um consenso entre empresas de software no que diz respeito à especificação, um conjunto de boas práticas tem sido estabelecido ao longo dos anos e que, se consideradas, podem contribuir positivamente para que a especificação dos casos e procedimento de teste seja realizada de forma mais satisfatória. Neste contexto, satisfatória significaria poder ser utilizada por outros membros da equipe de teste (analistas de teste ou testadores, por exemplo) sem a necessidade de novas intervenções na especificação para que ela possa ser melhor compreendida.
Neste artigo, partiremos de um caso de uso simples para realizar a especificação de casos e procedimentos de teste para um formulário de compra online de produtos. Ao final, teremos uma especificação bem definida e que irá considerar várias das práticas que têm sido adotadas por equipes de teste de software.
Cenário utilizado
Para ilustrar o uso de
boas práticas na descrição de casos e procedimentos de teste, partiremos do caso
de uso Comprar Produto, apresentado
na Tabela ...
