Testes não substituem o levantamento de requisitos
No último post do Ronaldo sobre testes e o último podcast do pessoal do Stack Overflow, Thiago Arrais comentou:
Testes definitivamente são uma Boa Coisa™ (e eu, particularmente, não sei mais programar sem eles), mas é preciso lembrar que só são capazes de demonstrar a presença de defeitos, não a ausência deles
De fato, testes são direcionados. Eles apontam defeitos pontuais, em particular, as funcionalidades para os quais eles foram desenhados para testar.
Isso é um efeito desejado. Por mais que seja interessante ter testes para manter e evoluir sistemas legados — com os testes funcionando como uma rede de salva-guarda — eles sozinhos, não garantem adequação ao uso nem a ausência de defeitos.
É por isso que testes, mesmo sendo uma prática fundamental da engenharia de software, não é suficiente para sustentar todo o desenvolvimento. É necessário que, antes de se codificar freneticamente, seja feito um trabalho de compreensão do problema que será solucionado. Os requisitos do software precisam ser levantados e os critérios de aceite do mesmo precisam ser mapeados.
E é nesse momento que os testes podem ser potencializados, saindo de uma mera ferramenta de conformidade, para uma ferramenta de levantamento e captura de requisitos. Já até escrevi isso aqui antes. Mesmo em times ágeis, onde a mudança é bem vinda, ainda existe a necessidade de se capturar os requisitos e documentá-los de alguma forma. Testes são excelentes maneira de se fazer isso.
Se, mesmo usando testes como ferramenta de captura, muitos defeitos aparecerem, isso é um indicativo que ou o processo de compreensão do software desenvolvido está falho, e conseqüentemente os requisitos estão fracos e desconexos, ou o problem space possui complexidades não mapeadas, o que é fundamentalmente um problema técnico.
Mas isso é história para outro dia.