Quando os requisitos de um projeto mudam "on the fly" e você não tem os meios de monitorar a implementação de cada requisito individual por recurso ou módulo, surge a pergunta: como analisar a cobertura? Uma das ferramentas que nossa equipe de controle de qualidade usa nesses projetos é a matriz de rastreabilidade.
No momento, usamos matrizes há mais de 2,5 anos. Durante esse período, pudemos avaliar as vantagens dessa ferramenta e adaptá-la ao nosso projeto.
O que é uma matriz de rastreabilidade?
Por definição, a matriz de rastreabilidade é uma tabela bidimensional que contém a correspondência dos requisitos funcionais do produto (requisitos funcionais) e os casos de teste preparados (casos de teste).
Na interseção da linha e coluna correspondentes, uma marca é colocada indicando que esse requisito é coberto por este caso de teste.
Assim, a tabela fornece uma exibição visual de dois parâmetros:
- a presença no sistema de requisitos ainda não cobertos (se o requisito não tiver interseção com casos de teste (condição suficiente);
- Há testes excessivos no sistema - se os requisitos tiverem várias interseções (uma condição necessária).
Em nosso projeto, usamos matrizes de rastreabilidade não apenas para avaliar a cobertura, mas também para determinar o relacionamento entre tarefas de desenvolvimento, requisitos e artefatos de teste.
Portanto, a matriz tem a forma de uma tabela, cada linha contendo:
- número e descrição da tarefa de desenvolvimento da tarefa rastreadora;
- bloco lógico ao qual a tarefa pertence (opcional);
- requisitos atômicos ou critérios de aceitação;
- prioridade;
- número e descrição do artefato de teste correspondente.
Como usamos o rastreador de tarefas Jira, Zephyr by Jira para documentação de teste e o sistema de gerenciamento de requisitos Confluence, todas as entidades são sincronizadas e essa rastreabilidade nos permite:
- visualizar o estado atual da implementação;
- dividir os requisitos em mais atômicos e estruturá-los;
- monitorar se existem requisitos para os quais o desenvolvimento ainda não está planejado (passo de implementação);
- monitorar se o requisito está atualmente implementado;
- monitorar se o requisito é coberto por um caso de teste (pulando o teste);
- Visualize a priorização de requisitos.
Opções de relacionamento na matriz de rastreabilidade
Os requisitos de ligação e os casos de teste podem ser:
- 1 a 1 (requisito atômico, que é coberto por um caso de teste, este caso de teste cobre apenas esse requisito);
- 1 a n (um requisito coberto por vários casos de teste, esses casos de teste cobrem apenas esse requisito);
- n a n (um requisito coberto por vários casos de teste, esses casos de teste cobrem este e outros requisitos).
Em relação ao último ponto, quero observar que
- Quando um requisito da matriz de rastreabilidade é coberto por vários testes, isso pode indicar redundância de teste. Nesse caso, é necessário analisar o quão atômico é o requisito.
- se, ao executar todos os casos de teste, garantirmos a abrangência da cobertura, e os próprios casos de teste não se duplicarem, isso não será um teste excessivo.
Temos casos no projeto em que um requisito é coberto por vários testes e um teste pode cobrir vários requisitos (conexões “1 a n” e “n a n”).
Especificidade da estimativa de cobertura usando matrizes de rastreabilidade
Se usarmos a métrica “proporção do número de requisitos para o número de artefatos de teste” para avaliar a cobertura, os relacionamentos na matriz devem ser “1 para 1” e os requisitos devem ser decompostos ao máximo.
Um exemplo Temos um requisito não atômico: "O usuário deve poder modificar e formatar a carta em um editor de texto". Obviamente, um caso de teste não será suficiente, mas se apenas um artefato estiver vinculado na matriz, visualmente haverá uma ideia de que o requisito é coberto.
Portanto, é melhor:
- divida esse requisito na matriz em funções atômicas separadas de um editor de texto;
- escreva um critério de aceitação para cada função;
- crie um artefato de teste para cada critério;
- se vários requisitos atômicos puderem ser cobertos por uma lista de verificação, não será possível fazer fragmentação excessiva, economizando recursos.
Com a falta de recursos para decomposição máxima, é possível usar requisitos não atômicos, mas para cobrir cada um deles, é necessário criar vários artefatos de teste.
Nesse caso, casos de teste e listas de verificação para cada requisito não atômico são compilados por vez, ou seja, cada requisito na matriz é completamente coberto por artefatos ou não é coberto.
Ao compilar as matrizes, é recomendável seguir a recomendação de que a decomposição de cada requisito em uma única matriz seja aproximadamente igual, ou seja, uma tabela não deve conter requisitos, alguns dos quais requerem 5 casos de teste e parte - um caso de teste.
A pontuação de cobertura neste caso é calculada separadamente para cada matriz.
Como a documentação do nosso projeto pode ter uma aparência diferente para cada recurso, e mesmo a descrição de um recurso pode conter UML, diagramas, diagramas de casos e transições de usuário e o projeto contém mais de 40 funcionalidades de volume, decidimos desenvolver uma matriz separada para cada módulo ou recurso, para que Não perca nenhuma das vantagens desta ferramenta.
A pontuação da cobertura também é calculada separadamente para cada módulo ou recurso.
Com essa abordagem, podemos usar a métrica descrita acima: “o número de requisitos para o número de artefatos de teste”. Mesmo se tivermos conexões 1 a n, n a n, temos vários componentes, cada um dos quais pode ser usado em vários módulos. Os requisitos e critérios de aceitação são descritos em cada matriz e um artefato de teste é usado.
Nossas matrizes também são armazenadas no sistema de gerenciamento de requisitos do Confluence - cada matriz está localizada com a estrutura como uma página filha do recurso para o qual foi desenvolvido. Além disso, todas as matrizes são coletadas em uma página por conveniência na avaliação da cobertura de todo o aplicativo.
Criando e mantendo uma matriz
A criação de uma matriz está incluída em nosso fluxo de trabalho em tarefas de análise.
Quando recebemos informações sobre um novo recurso, o analista de nossa equipe cria uma tarefa no rastreador de tarefas e, junto com o proprietário do produto, trabalha como parte dessa tarefa por parte do cliente. No processo de coleta e estruturação de requisitos, toda a equipe realiza uma revisão e faz perguntas adicionais. Quando os requisitos são formulados, documentados e confirmados pelo cliente, o líder da equipe de desenvolvimento cria tarefas para o desenvolvimento desse recurso, e a equipe de teste pode começar a criar uma matriz de rastreamento.
E aqui podemos distinguir os seguintes estágios de compilação da Matriz de Rastreabilidade:
- No início, os requisitos são decompostos e priorizados pelo controle de qualidade e / ou comando do proprietário do produto. O resultado desta etapa é uma lista estruturada e priorizada de todos os requisitos para essa funcionalidade.
- O segundo estágio será a comunicação com a equipe de desenvolvimento e a atribuição de tarefas das tarefas do rastreador para o desenvolvimento na matriz dos requisitos relevantes. Como resultado, podemos rastrear a rastreabilidade dos requisitos e tarefas de desenvolvimento.
- O terceiro estágio é o desenvolvimento de casos de teste e listas de verificação.
Essa etapa é realizada antes do teste ou durante o teste de uma tarefa específica.
Se a funcionalidade for nova e a interface mudar, poderá haver casos em que as etapas sejam melhor descritas imediatamente antes de testar a tarefa.
Se a funcionalidade de implementação for semelhante a um dos recursos existentes, poderemos começar a descrever casos de teste com etapas imediatamente após a revisão e decomposição dos requisitos. - Etapa 4 - preenchendo a matriz com casos de teste.
Com base nos resultados de todo o processo, obtemos tarefas de desenvolvimento, casos de teste para testes e uma matriz de rastreabilidade que os combina e requisitos.
A tarefa de desenvolver requisitos está sendo encerrada. - Etapa 5 - mantendo a matriz no estado atual. Alterações devem ser feitas em quaisquer modificações nos requisitos. Você também deve levar em consideração os relacionamentos de integração entre duas matrizes que descrevem recursos ou módulos diferentes e, ao alterar um, verifique se é necessário editar o segundo.
Dificuldades no trabalho com a matriz de rastreabilidade
- Actualização
A matriz será útil apenas com a condição de que seja sempre atualizada. Em nosso projeto com requisitos que mudam frequentemente, a atualização levou muito tempo, mas se a matriz não for atualizada, ela se torna não apenas inútil, mas também confusa.
Como decidir :
Solucionou parcialmente o problema com uma mudança frequente nos requisitos e transferiu o estágio de criação da matriz para o momento em que os requisitos já foram revisados pela equipe e confirmados pelo cliente.
A equipe decidiu que o analista atualizaria os requisitos não apenas na página com a descrição dos recursos, mas também os encontraria e os atualizaria na matriz, destacando em uma cor diferente. Isso ajudou toda a equipe a não perder as alterações, e a equipe de controle de qualidade em particular - para ver quais casos de teste precisam ser atualizados. - Recursos temporários
O projeto pode ter uma liberação urgente e trabalhar com novos requisitos ao mesmo tempo, e todos os recursos de controle de qualidade são enviados para teste e não funcionam com os requisitos. Assim, a dívida aumenta de acordo com a documentação do teste.
Como decidir :
Se todos os especialistas em controle de qualidade estiverem ocupados testando tarefas prioritárias, transferiremos a criação de uma matriz para um recurso específico. Na medida do possível, ele é transferido para o momento de testar a primeira tarefa desse recurso e, nesse caso, a matriz é preenchida com casos de teste como tarefas de teste nas quais o recurso é implementado.
O especialista em controle de qualidade dedica tempo à avaliação não apenas para escrever os casos de teste, mas também para desenvolver a matriz. - Eficiência
Se o projeto for pequeno e todos os requisitos forem estruturados na forma de um ToR estruturado, e casos de teste forem criados para cada requisito de uma só vez, a matriz de rastreabilidade em nosso formulário duplicará apenas as informações e será um desperdício de recursos.
Portanto, você precisa usar a matriz padrão descrita na definição para avaliar a cobertura.
Amenidades
- A matriz permite monitorar a implementação de requisitos, rastrear que todos os requisitos sejam desenvolvidos e testados e nada está faltando.
- A matriz ajuda a equipe de controle de qualidade a rastrear se há dívidas na documentação de teste e quais requisitos específicos ainda não são cobertos pelos casos de teste.
- A ferramenta é usada pelo analista e pela equipe de controle de qualidade para monitorar os requisitos alterados.
- No projeto, as matrizes de rastreabilidade começaram a ser usadas não apenas por nós, mas também pelo proprietário do produto por parte do cliente. Portanto, eles se certificaram de que todos os requisitos estejam lá e estejam corretos e rastreados usando a matriz, que já foi implementada. As matrizes nos permitiram tornar o processo de desenvolvimento e teste um pouco transparente.