“Durante o processo de desenvolvimento de software sabemos que teste de software é uma forma essencial para garantir a qualidade do produto, através da antecipação de inconsistências que podem ser encontrados por usuários finais do produto que é desenvolvido.

Contudo, o papel da pessoa responsável por disseminar a qualidade não é somente por executar testes e detectar discrepâncias entre o que era esperado e o estado atual. Essa pessoa também se envolve nas atividades para garantir a qualidade no processo como um todo, incluindo papéis e tarefas bem definidos e também qualidade nos artefatos gerados.

Dentre os diversos artefatos gerados durante um projeto de desenvolvimento de software, temos plano de projeto, requisitos, códigos, casos de testes, entre outros. Os casos de testes são descritos e definidos de acordo com o produto que está sendo desenvolvido, e são artefatos escritos por um ser humano, logo, podem estar sujeitos à inconsistências tais como: erros ortográficos, erros gramaticais, estrutura de escrita, ambiguidade de informações, duplicidade de dados, ou até mesmo descrição incompleta de requisitos.

Um caso de teste é um algoritmo ou procedimento, no qual o testador deve seguir com o intuito de validar se o produto em desenvolvimento está de acordo com os requisitos definidos, e como consequência pode antecipar as possíveis inconsistências das quais o produto é suscetível..

• Título: sumário descrevendo o objetivo do caso de teste;
• Data de criação: o registro de quando o caso de teste foi criado;
• Autor: responsável pela criação do caso de teste;
• Procedimentos: passos a serem seguidos de maneira sequencial com o intuito de validar o que está sendo testado;
• Resultado esperado: feedback para quem segue os procedimentos com a intenção de mostrar qual é o comportamento esperado a partir da ação (passos) executada,
• Status: identificar se o caso de teste já foi executado (passou, falhou ou foi bloqueado), ou se ainda será executado.

Atualmente, a ISO/IEC/IEEE 29119–3 descreve um padrão de como os artefatos produzidos pela atividade de teste de software podem ser definidos.

É importante salientar que dependendo da quantidade de pessoas envolvidas na escrita dos casos de testes, cada pessoa tem formas diferentes de se expressar, o que pode ser gerados diferentes entendimentos de como o caso de teste deve ser escrito. Agora, imagine um cenário que a pessoa que escreveu o caso de teste não é a mesma que executa o caso de teste, e a pessoa que está executando o caso de teste não tem o mesmo entendimento de quem escreveu. Com isso, algumas consequências podem acontecer, como:

• Possíveis inconsistências (falhas) escapadas;
• Possíveis inconsitências reportadas de maneira indevida;
• Falta de entendimento do requisito;
• Comprometimento da qualidade do produto que é entregue;
• Falta de segurança por parte dos stakeholders envolvidos (Product Owner, Cliente, Usuários, entre outros) quanto a qualidade do produto.

Como podemos observar, vários problemas podem acontecer quando o caso de teste não fornece a informação e dados adequados para assegurar a qualidade do produto desenvolvido. Por isso, a comunicação através da escrita do caso de teste precisa ser bem efetiva e clara para evitar os problemas mencionados ou até mesmo outros que venham a acontecer.

Uma estratégia que pode mitigar os riscos mencionados é através da realização de uma revisão do caso de teste. O processo de revisão pode ser realizado de diversas maneiras (revisão por pares, revisão formal, revisão informal, revisão por inspeção, e muitas outras técnicas existentes)…

Essa técnica de processo de revisão é através de checklists, que pode ser utilizada com intuito de revisar um artefato conhecido como documento de requisitos, mas também podemos adaptá-la para a escrita de casos de testes, pois a validação dos requisitos acontece através da execução de casos de testes. Com base nisso, há itens que podem ajudar na revisão dos casos de testes, como no checklist a seguir:

• Verificar se ortografia e gramática estão de acordo com as regras do idioma no qual o caso de teste está sendo desenvolvido;
• Verificar se as pré-condições do caso de teste foram expostas de maneira clara;
• Verificar se as ações (passos/procedimentos) levam aos resultados esperados pelo caso de teste;
• Verificar se não existem informações ambíguas, duplicadas ou incompletas nas pré-condições, passos e resultados esperados;
• Verificar se o caso de teste atende ao requisito que está sendo validado.

Esse checklist … foi adaptado para ser utilizado como uma estratégia de revisão de casos de teste. Através do processo de revisão de um caso de teste, espera-se que:

• Aconteça uma comunicação única por todos os stakeholders que interagem no processo de criação e execução de testes;
• Evite o registro de inconsistências indevidas ou até falhas escapadas;
• Melhor cobertura dos requisitos de acordo com o objetivo de casos de testes,
• Mitigação dos riscos no qual o projeto está suscetível.

…Teste de software não é somente testar para antecipar inconsistências, mas também somos responsáveis por garantir a qualidade dos artefatos gerados pela atividade de teste. Dessa forma, através de boas práticas de escrita de casos de testes (revisão por checklist), podemos melhorar a comunicação entre quem executa e quem escreve casos de teste, além de entendermos os requisitos, evitarmos falhas e melhorarmos a confiança do cliente quanto ao trabalho que fazemos em teste de software.”

Para quem deseja se aprofundar e conhecer mais sobre a Norma, indicamos o curso DPTS que é ministrado por Emerson Rios autor dos livros: Teste de software (2006), Base de conhecimento em teste de software (2007) e Documentação em projeto de teste de software (2020).

Fonte: Medium