APRENDER. PRATICAR. EVOLUIR.1. Definir o significado dos estados
Um requisito pode estar documentado, aprovado, implementado, testado e aceite em momentos diferentes. Num dashboard fictício, “verde” significa apenas que existe uma ligação a um teste. Essa definição é insuficiente para concluir que a release cumpre o requisito. Define estados e transições com os intervenientes: que evidência permite avançar, quem a revê e como se regista uma exceção? A política do exercício exige resultados aplicáveis à versão do requisito, build e ambiente selecionados, além da revisão prevista. É uma regra didática explícita, não um processo universal imposto pelo PMI. Preserva resultados anteriores para histórico, mas evita usá-los como se pertencessem à nova versão. O gestor de projeto precisa de conhecer a diferença entre trabalho realizado e cumprimento demonstrado para preparar uma decisão realista.
2. Medir requisitos, não multiplicar ligações
Considera quatro requisitos no âmbito. Três têm alguma evidência ligada, mas apenas um tem todos os controlos exigidos aprovados na versão e condições atuais. A cobertura de ligação é 3/4, ou 75%; a cobertura de suporte completo é 1/4, ou 25%. Dez execuções do mesmo teste não transformam um requisito em dez requisitos cobertos. Define o denominador antes de calcular e trata uma população vazia como não aplicável ou indeterminada, conforme a política acordada, sem inventar 100%. Mantém visíveis as lacunas por requisito e criticidade. Mesmo um indicador de 99% pode esconder o único controlo que bloqueia a decisão. Usa os totais para orientar a investigação e reporta separadamente critérios obrigatórios, resultados falhados, evidência antiga e revisão pendente.
3. Conservar a sequência de resultados
Um teste passou ontem e falhou hoje na mesma versão, build e ambiente. Escolher o resultado verde mais antigo para melhorar o dashboard elimina informação relevante. No modelo, a sequência mais recente para cada controlo aplicável determina o estado corrente; a regra de sequência faz parte do contrato do exercício. Um resultado sem revisão continua pendente mesmo que a execução tenha passado. Se existirem dois registos com a mesma identidade e sequência, o modelo rejeita a ambiguidade em vez de escolher arbitrariamente. Numa ferramenta real, confirma integridade, identidade do executor, ordenação e regras de substituição ou expiração da evidência. Os dados do laboratório não verificam esses controlos externos. Quando um teste muda, revê a relação entre a nova definição, o requisito e os resultados anteriores antes de os reutilizar.
4. Analisar impacto além do ticket inicial
Uma alteração no cut-off pode afetar a tabela de decisão, uma interface, testes, alertas, instruções operacionais e compromissos com consumidores. Segue relações para identificar candidatos a revisão, sem afirmar que todos sofrerão necessariamente alteração. Uma ligação indica uma dependência possível, não uma prova de defeito. Para cada candidato, confirma o tipo de impacto e a evidência necessária. Se uma regra partilhada muda, o consumidor que não está na equipa do projeto continua a merecer análise. Preserva a baseline anterior e a decisão que autorizou a mudança, com versão e âmbito. Num pedido urgente, usa a via de mudança aplicável e comunica o que ainda não foi demonstrado; urgência não transforma resultados antigos em testes atuais. Coordena a análise com o planeamento de release para que prazo e conteúdo sejam avaliados em conjunto.
5. Separar prontidão de realização de benefício
Uma release pode cumprir os critérios de entrega e ainda não realizar o benefício esperado. Se a automação prometia reduzir trabalho manual, mede volume, adoção, exceções e esforço transferido depois da entrada em serviço. Distingue horas libertadas de redução efetiva de despesa: sem mudança de utilização ou custo, capacidade disponível não é poupança financeira demonstrada. Regista a população e o período usados para comparar, incluindo alterações de procura que podem explicar diferenças. Antes da release, apresenta critérios cumpridos, lacunas e decisões pendentes à autoridade definida. Depois, atribui responsáveis e datas à medição do resultado. O exercício local ajuda a distinguir estados e calcular cobertura, mas não decide uma release real nem prova causalidade. Uma recomendação credível explica tanto a evidência favorável como os limites que ainda afetam a decisão.
Quatro requisitos: três com ligações e um com todos os controlos atuais suportados. Cobertura de ligação 75%; suporte completo 25%.
Armadilhas comuns
Contar execuções como requisitos; esconder uma falha recente com um sucesso antigo; confundir teste aprovado, decisão de release e benefício realizado.
Tópicos relacionados: Regras, combinações e exceções
Um estado deve indicar o que foi demonstrado, para que versão e sob que condições, deixando a decisão à autoridade prevista.
Referência: PMI-PBA Examination Content Outline · Five-domain ECO / verified 2026-10-01