Olá, cidadãos de Habrovsk!
Decidi escrever um artigo sobre o processo de interação entre nossos testadores e analistas e sobre os bônus que a empresa SuperJob recebe desse processo.
O trabalho dos testadores com requisitos consiste em três etapas: Revisão do TF, Cobertura do TF, Revisão do caso.
Revisão do FT
Os requisitos são mantidos pelos analistas no Enterprise Architect e, a partir daí, são copiados para o Confluence. Após escrever os requisitos, eles são enviados para revisão aos testadores.
Embora essa interação seja realizada pelo Planilhas Google, onde há:
- Nome do FT
- Link para FT
- Responsável pelo Analista FT
- Status de analistas
- Testador responsável
- Status dos testadores
O analista coloca o status "Em revisão" no parágrafo correspondente da tabela:
Nesse estágio, como parte do Confluence, são feitas perguntas sobre determinados pontos de requisitos, pois a funcionalidade permite adicionar comentários a partes arbitrárias do texto. Nos comentários, discussões estão em andamento, como resultado da atualização do FT.
Após os requisitos terem sido adicionados e atualizados, eles são transferidos para o desenvolvimento e teste.
Cobertura FT
Os casos de teste são escritos no TestRail; a arquitetura de armazenamento dos casos de teste repete completamente a arquitetura de armazenamento de requisitos. Isso é necessário para facilitar a pesquisa e, para não reinventar sua bicicleta, é mais fácil levá-la de um vizinho analista.
O teste cobre os requisitos - cada item de requisitos, cada oferta é coberta.
Cada item de requisitos é numerado; há um rastreamento de casos de teste para itens de requisitos. Separadamente, quero observar que, em cada caso, há uma versão do FT em que este caso foi escrito - os requisitos podem mudar e os pontos neles também, se você não levar em conta a versão do FT, não poderá encontrar os fins.
Desta forma:
- É fácil verificar a qualidade da cobertura do caso. Diante de meus olhos, não há uma folha de 50 casos e a mesma folha de FT por perto, mas você seleciona um ponto de requisitos e depois vê quais casos cobrem esse ponto específico;
- No caso de uma alteração nos requisitos, é possível ver imediatamente quais casos você precisa corrigir.
Os casos são escritos em três versões:
- Título de casos (a maioria deles). Quando o caso tem apenas um cabeçalho, pelo qual fica claro o que precisa ser feito. Eles são mais rápidos de escrever do que casos de teste detalhados e ao mesmo tempo cobertura transparente:
- Casos de teste. Um caso de teste detalhado com etapas em que existem muitas nuances no caso e todas elas não podem ser colocadas no cabeçalho;
- Casos, listas de verificação. Quando um caso consiste em uma lista de verificação para verificar alguma direção da funcionalidade. Para destacar esses casos, use no cabeçalho (casos):
Nas seções do FT, onde existem modelos, é criado o caso de teste "Reconciliação com o layout M ...". Serve simplesmente como um lembrete de que existe um layout e a implementação deve ser verificada com ele. Nesse caso, sem uma descrição interna - a lista de verificação para reconciliação com o layout que descrevemos nos regulamentos.
Revisão de Caso
Depois de escrever os casos, o status de "Revisão de casos" é colocado na tabela geral, isso é um sinal de que outro testador pode fazer esse teste e conduzir uma revisão de casos. Isso é necessário para que os casos sejam igualmente claros para todos os testadores e para percorrer os requisitos com uma nova aparência.
No caso de aprovação malsucedida da revisão, por exemplo, novas perguntas apareceram no TF ou a cobertura é insuficiente - o requisito é transferido para o status "Finalizar". Não há comentários suficientes no TestRail para descrever todos os seus desejos - enquanto isso acontece por escrito no Slack, o que não é muito conveniente para rastreamento.
Se a revisão for bem-sucedida, o FT está no status "Concluir".
Em casos raros, quando os requisitos foram atualizados após a gravação dos casos de teste, o FT é transferido para o status “Atualizado”. Além disso, o testador que cobre o FT assina atualizações na página Confluence. Se os requisitos mudaram muito, uma tarefa é criada para o testador atualizar casos.
Conclusão
O que nos dá essa abordagem?
- Primeiro, requisitos comprovados entram em desenvolvimento. Isso economiza tempo para os desenvolvedores, aos quais as ilogicalidades, deficiências e batentes do FT simplesmente não atingem;
- Em segundo lugar, os testadores estão se preparando para testar em paralelo com o desenvolvimento, portanto reduzimos o tempo necessário para liberar recursos. Os testadores podem abordar com calma e responsabilidade o processo de escrever casos, e não no formato “Ahhh, um recurso enorme caiu, você precisa derramar hoje à noite. Vamos testar mais rápido!
- Em terceiro lugar, este é um aumento na qualidade dos testes devido à revisão dos casos. Diga "Não!" um olhar borrado.
O que não gosta?
- Há um intervalo de tempo bastante grande entre gravar casos e executá-los em um recurso - embora os casos estejam prontos e possam ser verificados apenas, o testador, no entanto, fica fora de contexto;
- Como escrevi anteriormente - no TestRail, não há comentários suficientes, como no Confluence - você não pode simplesmente pegar e marcar o local do problema, deixando um comentário para ele.
Por enquanto é tudo. Obrigado pela atenção!
E como é o processo de trabalhar com seus requisitos?