Teste Independente e dos Envolvidos ou Teste do Cliente

Engana-se quem acha ultrapassado tudo no Processo Unificado. O "Teste Independente e dos Envolvidos" é um exemplo de prática antiga, mas bem útil e eficiente, semelhante ao "Teste do Cliente" do XP.

Ela não tem nada haver com aquele paradigma tradicional de testadores num modelo cascata-homologador. É aquele grupo de pessoas, geralmente com conhecimento similares ao de um usuário final avançado (sabem instalar, configurar e operar), obedecendo um plano de trabalho que diz como manualmente verificar todas as funcionalidades do sistema, após o desenvolvimento do sistema. 

Tanto investimento e esforço e os defeitos continuam reaparecendo. E começam as disputas de quem falha mais: desenvolvedores x testadores independentes.

A independência não é de ambiente, como se repetir os testes dos desenvolvedores em outro ambiente, separado das máquinas usadas por eles, ou compensar o tempo deles executando seus testes (mesmo de forma manual!), fosse a grande vantagem. Não! A independência é de foco. 

O contato maior dos desenvolvedores é o código, as funções, os módulos, estrutura de dados, fluxos de controle etc. Ora, é natural ter uma preocupação voltada para entradas e saídas de requisitos funcionais e não-funcionais e não para situações, necessidades e problemas do dia-a-dia de quem opera, vende, distribui e está envolvido no retorno ao cliente do sistema. O inverso também é bastante complicado!

Por isso, a coisa fica pior quando aquele plano é construído pelos desenvolvedores. Independente de quem faz o plano, é preciso pelo menos ter consciência do quanto é esperado: se feito por desenvolvedores não espere abranger situações de uso comum dos clientes; se feito por clientes, não espere capturar detalhes de funcionamento dependentes de plataforma.

Muitas são as vantagens dos testes: melhora a confiança, a sanidade do código e a produtividade (Kent Beck). Entretanto, eles podem ser uma armadilha para o desenvolvedor quando se procura associar 100% de testes passados com ausência total de bugs, apesar do número bem reduzido de falhas em produção. Para um desenvolvedor, a regra é 100% ou nada, todavia para um foco bem restrito e diferente daquela dos testadores independentes. 

A recomendação é manter o pacote de testes visível e atualizável por ambos tipos de testadores, de modo a promover um conhecimento holístico da qualidade do software, com segregação colaborativa de funções.

A motivação de um teste feito manualmente por alguém próximo do usuário final para ser semelhante ao ambiente de uso do cliente não agrega nenhum valor. Só a o sentimento de ter algo similar ao do cliente e só. Automatize, integre continuamente e construa testes unitários, de integração, de sistema, de desenvolvedor ou independentes o quanto puder.