QA e testes

Porque é o único número que descreve se a garantia de qualidade está a funcionar. Testes executados mede actividade; cobertura mede intenção; defeitos encontrados mede o que se procurou. Defeitos que chegaram a produção mede o que falhou, que é a pergunta.

Medimos também a que fase o defeito pertencia. Um defeito de requisito encontrado em produção significa que o critério de aceitação estava errado, e nenhuma quantidade de testes o teria apanhado. Classificar por origem é o que distingue melhorar testes de melhorar o processo.

E o custo de cada escape, porque nem todos são iguais. Um defeito cosmético e um que corrompe dados não devem contar da mesma forma numa métrica agregada, e uma equipa avaliada por contagem aprende a dar prioridade ao que é fácil de encontrar.

Envolvida antes de o código existir, na definição dos critérios de aceitação. É aí que a garantia de qualidade tem mais valor e é onde é mais frequentemente ausente: uma equipa que recebe funcionalidade pronta para testar só pode encontrar defeitos de implementação, nunca de requisito.

Com acesso ao mesmo contexto que a equipa de desenvolvimento: pedidos de utilizadores, relatórios de incidente e métricas de utilização. Uma equipa de testes que não sabe que funcionalidade é a mais usada testa tudo com a mesma prioridade, que é o mesmo que não ter prioridade.

E sem uma fase de testes no fim. Testar no fim produz uma negociação sobre o que se corrige antes de sair, com a data já comprometida, e essa negociação perde-se sempre. Testar contínuo produz defeitos encontrados quando corrigi-los ainda é barato.

Em Portugal ou na Polónia, dentro do Espaço Económico Europeu, quando os testes correm sobre dados que se aproximam dos de produção. É o modelo que evita a questão de transferência internacional e o que propomos por defeito para produtos com utilizadores europeus.

Na rede global quando os ambientes de teste correm sobre dados sintéticos, que é o desenho que recomendamos independentemente da localização. Testar sobre dados reais de utilizadores é uma prática que continua a existir e que não tem defesa razoável.

O fuso importa menos aqui do que em quase todos os outros serviços, porque a maior parte do trabalho é assíncrona. O que importa é a sobreposição suficiente para uma reunião diária com a equipa de desenvolvimento, e meio dia chega.

Por risco e não por cobertura. Cobertura de código mede que linhas foram executadas e diz pouco sobre se o que importa funciona; risco combina probabilidade de falha com consequência, e é o que decide onde o esforço vale a pena.

As áreas de maior risco são identificáveis e quase sempre as mesmas: código alterado recentemente, integrações com sistemas de terceiros, fluxos que envolvem dinheiro, e funcionalidade que historicamente produziu incidentes. Um mapa destas quatro dimensões orienta melhor do que qualquer percentagem.

E revemos esse mapa com os incidentes reais. Uma área que produziu três incidentes em produção no último trimestre merece atenção independentemente do que a cobertura diga, e uma área estável há dois anos provavelmente não precisa da regressão exaustiva que continua a correr por inércia.