em que momento o teste deve comecar e o “tester” se envolver?

é bom ouvirmos falar cada vez mais em teste unitários. os testes unitários na grande maioria das vezes é de responsabilidade do desenvolvedor. isto é bom. o quanto antes no desenvolvimento começamos a testar a aplicação ou código, mais provável acharmos bug e bem possivelmente aumentarmos a qualidade.

também temos ouvido falar mais em times de testes. com menos freqüência do que de unit testes e na maioria das vezes mais funcional do que técnico. mas, o fato de começar ter mais times de testes especializados mostra uma preocupação com o aumento da qualidade. este time de teste é o responsável por definir um plano de teste, automatizar parte destes testes e executá-los. os bugs encontrados são logados e passado para os desenvolvedores corrigi-los. isto é o que acontece em praticamente todos os casos. o time de teste é envolvido no final do processo. depois que a funcionalidade já está especificada e desenvolvida. é claro que eles entram em contato com a especificação mais cedo. porém normalmente eles focam em definir os testes. se o objetivo do time de teste é melhorar a qualidade do produto, o resultado seria ainda melhor e mais produtivo se os responsáveis pelos testes se envolvessem com os responsáveis pela especificação desde o início do processo. Isto ajudaria a identificar possíveis problemas na experiência do usuários, nos textos das mensagens e assim por diante. Isto seria identificado bem cedo no processo e não nas véspera de se fazer o release. o mesmo se dá em relação ao desenvolvedores. O envolvimento do teste neste processo pode ajudar a garantir a testabilidade do design. eles também poderiam trabalhar pro-ativamente com o time de desenvolvimento dando sugestões de como melhorar a cobertura dos testes unitários ou a sua manutenção. Isto poderia ser feito por simplesmente envolver o “tester” no processo de “code review” dos testes unitários. estão são apenas algumas maneiras que o envolvimento real do time de testes desde o início do processo traria benefícios para o produto.

dois posts colaboram com esta idéia. este primeiro é de um arquiteto de de testes da microsoft. ele fala somente sobre este envolvimento desde o início. o segundo, é de um dos nomes mais reconhecidos atualmente na área de teste em times ágeis. ela fala um pouco sobre um exercício que ela faz em seu treinamento. é interessante ver como a comunicação simplificada e o envolvimento de todo o time contribui para a agilidade e melhoria do produto.