DoD e DoR na garantia da qualidade de Software
Definition of Ready (DoR) para Testes de Software
A DoR para testes de software estabelece os critérios que uma tarefa deve cumprir antes de ser considerada pronta para iniciar os testes.
Exemplo de DoR para Testes de Software
Requisitos claros e documentados
Todos os requisitos funcionais e não funcionais devem estar claramente definidos e documentados.
Os critérios de aceitação devem ter sido especificados e aprovados pelo Product Owner.
Dados de teste disponíveis
Os dados de teste identificados como necessários estão prontos e disponíveis.
Os cenários de teste foram todos identificados e estão correctamente definidos.
Design dos testes completo
Todos os casos de teste identificados estão escritos e revistos.
O plano de testes está aprovado.
Ambiente de teste preparado
O ambiente de teste está configurado e operacional.
O acesso a todos os dados necessários para realizar os testes está garantido.
Dependências resolvidas
Todas as dependências externas, como APIs ou serviços de terceiros, estão disponíveis e a funcionar correctamente.
Aprovação do Product Owner
O Product Owner aprova que a tarefa está pronta para iniciar a fase de testes.
Definition of Done (DoD) para Testes de Software
A DoD para testes de software define os critérios que uma tarefa deve cumprir para ser considerada concluída após os testes.
Exemplo de DoD para Testes de Software
Execução completa dos testes
Todos os casos de teste foram executados.
Todos os critérios de aceitação foram verificados e validados.
Sem registo de defeitos críticos ou bloqueantes
Garantia da não existência de defeitos críticos ou bloqueantes abertos.
Defeitos menores registrados e prioritizados para correção futura.
Testes de regressão concluídos
Os testes de regressão foram executados com sucesso, a fim de garantir que as novas mudanças não afetaram as funcionalidades existentes (e em correcto funcionamento).
Documentação actualizada
Relatórios de teste devem ser criados e correctamente arquivados.
A documentação deve ser actualizada para refletir as mudanças e resultados dos testes.
Feedback do Product Owner
O Product Owner reviu e aceitou os resultados dos testes.
Preparação para produção
A equipa de desenvolvimento está pronta para implantar o novo branch no ambiente de produção (se aplicável).
Exemplos Práticos
Exemplo 1: Testes de uma Nova Funcionalidade de Login
DoR:
Requisitos para a funcionalidade de login estão claramente documentados.
O ambiente de teste está configurado e com acesso à base de dados de autenticação.
Todos os cenários de teste (login com sucesso, login sem sucesso, bloqueio de conta) estão identificados.
Casos de teste estão escritos e revistos.
Dados de teste, incluindo as várias contas/perfis de utilizador, estão disponíveis.
A aprovação do Product Owner foi conseguida.
DoD:
Todos os casos de teste para a funcionalidade de login foram executados.
Todos os critérios de aceitação, como os tempos de resposta e as mensagens de erro identificadas, foram verificados.
Não existem defeitos críticos ou bloqueantes no sistema de login.
Os testes de regressão confirmaram que outras funcionalidades de autenticação não foram afectadas pela nova funcionalidade de Login.
Os relatórios de teste documentam todos os resultados e estão armazenados no repositório de testes, sendo acessíveis por todos os membros da equipa.
a documentação do sistema de login foi correctamente actualizada.
O Product Owner reviu e aceitou os resultados.
A equipa está pronta para implantar a funcionalidade no ambiente de produção.
Exemplo 2: Testes de Desempenho de um Sistema de e-Commerce (vendas online)
DoR:
Os requisitos de desempenho (por exemplo, executar 1000 transações por segundo) estão correctamente documentados.
O ambiente de teste de desempenho está configurado com dados de transações reais (que podem ou não estar anonimizados).
Todas as dependências, como os serviços de pagamento, estão disponíveis.
Todos os scripts de teste de desempenho foram escritos e revistos.
Todo o trabalho foi aprovado pelo Product Owner.
DoD:
Todos os testes de desempenho foram executados e atingiram as metas de desempenho previamente definidas.
Nenhum defeito crítico ou bloqueador foi identificado durante os testes de desempenho.
Os relatórios de desempenho foram criados e devidamente analisados.
A documentação de desempenho foi atualizada em conformidade.
O Product Owner reviu e aceitou os resultados dos testes de desempenho.
A preparação para a implantação dos testes no ambiente de produção foi concluída.
Portanto, a Definition of Ready (DoR) e a Definition of Done (DoD) são essenciais para garantir que as tarefas de teste de software são iniciadas e concluídas com qualidade e eficiência.
Enquanto a DoR prepara as tarefas para serem testadas, a DoD assegura que os testes são concluídos de acordo com os critérios de qualidade estabelecidos.
Implementar estas práticas ajuda a equipa a evitar ambiguidades, a melhorar a eficiência e a garantir uma entrega de software de qualidade.
