Glossário · Fundamentos de testes
Matriz de rastreabilidade de requisitos
Em inglês: Requirements traceability matrix
Também chamado de: RTM, matriz de rastreabilidade, rastreabilidade de requisitos, traceability matrix
Definição
Tabela que relaciona cada requisito aos casos de teste que o verificam e aos seus resultados, deixando visíveis as lacunas de cobertura e o impacto das mudanças.
Uma matriz de rastreabilidade de requisitos (RTM, requirements traceability matrix) liga os requisitos aos testes que os cobrem e, muitas vezes, também aos resultados de execução e aos defeitos. Ela responde rapidamente a duas perguntas: todo requisito está testado? E, se este requisito mudar, quais testes precisam ser atualizados? É obrigatória em domínios regulados, como dispositivos médicos, aviação e finanças, e útil em qualquer lugar em que a cobertura precise ser demonstrada.
Exemplo
| Requisito | Descrição | Casos de teste | Status | Defeitos |
|---|---|---|---|---|
| AUTH-01 | O usuário consegue fazer login com credenciais válidas | TC-101, TC-102 | Aprovado | nenhum |
| AUTH-02 | A conta é bloqueada após 5 tentativas com falha | TC-103, TC-104, TC-105 | Reprovado | BUG-311 |
| AUTH-03 | O link de redefinição de senha expira após 30 minutos | (nenhum) | Não coberto | n/a |
Como ler: o AUTH-03 não tem testes, o que é uma lacuna de cobertura. O AUTH-02 está coberto, mas falhando, então é um risco para o release ligado a um bug específico.
Forward, backward e bidirecional
- Rastreabilidade forward (para frente): do requisito para os testes. Comprova que todo requisito é verificado.
- Rastreabilidade backward (para trás): do teste para o requisito. Mostra testes que não verificam nada que alguém tenha pedido, que podem estar obsoletos ou revelar um requisito faltando.
- Bidirecional: as duas direções, que é o que a maioria dos auditores espera.
RTM vs cobertura de código
Uma RTM mede a cobertura de requisitos: se cada necessidade declarada tem um teste. A cobertura de código mede quais linhas ou branches foram executados durante os testes. Você pode ter 100% de cobertura de requisitos com pouca cobertura de código, e o contrário também. Elas respondem a perguntas diferentes e funcionam melhor juntas.
Mantendo a matriz sustentável
Uma planilha mantida à mão fica desatualizada rapidamente. A maioria dos times gera a rastreabilidade a partir das próprias ferramentas: casos de teste marcados com IDs de histórias na ferramenta de gestão de testes, ou testes automatizados anotados com a chave do requisito (por exemplo uma tag como @AUTH-02 no título de testes Playwright ou uma @Tag do JUnit), e depois um relatório cruza essas informações. A matriz só é tão boa quanto a disciplina de marcar cada novo teste.