Skip to main content

Elaboração do roteiro

O Roteiro de Testes é um documento para auxiliar o testador a validar se a tarefa (caso) em que ele irá começar a trabalhar atendeu as expectativas e se está condizente com aquilo que foi proposto ser feito. Idealmente o mesmo deverá ser montado em uma espécie de lista, com tópicos que deverão ser validados, facilitando para que o testador siga uma ordem e não se perca nos testes.

Para se montar um Roteiro de Testes, primeiramente deveremos ler o caso que começaremos a trabalhar e entender o que foi relatado, após isso, analisaremos o Script de Desenvolvimento para entender o que o desenvolvedor fez para corrigir o erro ou implementar a solicitação que foi feita. A partir disso teremos uma base de qual é a demanda (erro/solicitação) e o que será entregue (correção do erro/implementação no sistema).

Como cada tarefa (caso) é único, o roteiro de testes também deve ser. Para facilitar a montagem de um bom roteiro, deveremos seguir as etapas abaixo:

Qual o objetivo dos testes?

Como dito anteriormente, cada caso é único e portanto o objetivo dos testes também deve ser. Vamos supor que em um caso foi criado um novo relatório no sistema, o objetivo não deve ser simplesmente "Ver se o relatório está funcionando". Objetivos genéricos não "abrem nossa cabeça" sobre tudo o que precisaremos validar, como por exemplo, layout do relatório, facilidade no entendimento das informações, conferência dos dados, se o mesmo será compreensível ao usuário, etc.

Criação das tarefas/tópicos à serem validados

Com o objetivo principal dos testes em mente, passaremos a pensar em todos os passos que precisaremos validar para que possamos considerar o caso como "Testado". Ainda utilizando o exemplo da criação de um novo relatório no sistema, é difícil validarmos ele todo de uma vez se não o "quebrarmos" em pequenos "grupos", onde cada grupo é composto por algumas "tarefas" específicas e que irão nos dizer se o mesmo está aprovado ou não.

Exemplo:

1. Verificar criação/chamada da tela do relatório;
1.1. Verificar se no módulo XX, no menu "Relatórios > Emissão de Documentos" foi adicionada a opção "Teste novo relatório";
1.2. Verificar se a chamada do "Teste novo relatório" está sendo feita corretamente, se a tela está sendo aberta alinhada, layout da tela, etc.
1.3. Verificar se os botões da tela do relatório estão funcionando corretamente (minimizar, maximizar, fechar, etc.).
2. Validação dos campos;
2.1. Validar tab-order dos campos;
2.2. Validar preenchimento e validação dos campos (tamanho, código inválido, data inválida, campo vazio, etc);
2.3. Validar pesquisa dos campos pelo DLG, preenchendo manualmente ou pelo atalho ALT+F4;
2.4. Validar saída dos campos;

(...)

Esses tópicos deverão ser preenchidos até chegar a última etapa dos testes, que seria a visualização e validação das informações no relatório e cada um destes tópicos é um checkbox à ser assinalado se foi aprovado ou não, assim fica mais fácil de identificar tudo o que precisa ser validado e, caso tenham ajustes à serem feitos, onde exatamente está o problema.

Atenção: Em todos roteiros de teste deveremos considerar:

  • Analisar se o tratamento solicitado/proposto foi atendido e se está funcional;
  • Se o tratamento possui layout e usabilidade bem definida;
  • Identificar caminhos alternativos, como por exemplo parametrizações, configurações, tipo de cliente, atividade, etc., que possam ocasionar:
    - Erros no sistema;
    - Erros de integridade das informações no banco de dados;
    - Travamento no processo à ser executado pelo usuário;
    - Se as correções/solicitações realizadas poderão "quebrar", não atender ou impactar negativamente no uso do sistema pelos demais clientes.

Qual o resultado esperado em cada uma das tarefas para considerá-las "Aprovadas" ou "Reprovadas"?

Antes de iniciarmos de fato os testes é fundamental que tenhamos definido qual o resultado esperado em cada uma das tarefas que foram criadas, assim saberemos exatamente o que precisa ser validado e se poderemos considerá-la como "Aprovada".

Vamos tomar como exemplo o item "2.2. (Validar preenchimento e validação dos campos (tamanho, código inválido, data inválida, campo vazio, etc)" citado no exemplo anterior.
Se o campo que será validado for um campo do tipo "Data", por exemplo, será necessário verificar se o mesmo possui máscara, se está permitindo digitar datas inválidas (1/15/2020, 35,02/1999, 12/10/7, ...), entre outros. Cada tipo de campo possui validações específicas e por isso é importante que já saibamos o resultado esperado para cada uma das tarefas antes de iniciarmos os testes.

A estrutura do roteiro de testes deverá ser montada de acordo com o "Roteiro de testes padrão".