É natural imaginar que o desenvolvedor deseja construir um software de qualidade e provar que ele funciona perfeitamente bem, livre de qualquer erro de implementação. A atividade de verificação é essencial para que este objetivo seja atingido. Porém engana-se quem pensa que o objetivo da verificação é provar a ausência de erros. Pelo contrário: o objetivo é encontrar erros e mostrar que o software não tem qualidade.
Trata-se de uma questão de postura. Aquele que realiza uma atividade com um objetivo em mente, termina a atividade bem sucedido no seu desejo. Portanto, mesmo que um software tenha problemas, se o testador iniciou seu trabalho com a mentalidade de confirmar que ele funciona, acabará por perder a chance de encontrar os defeitos. Reforço novamente: o objetivo dos testes é falhar. O objetivo da verificação é provar que o software precisa ser corrigido. Isto é verificar. Do contrário seria "uma demonstração e não uma verificação". [Mr.Slavchev https://mrslavchev.com/2018/03/30/hindsight-lessons-about-automation-layers-of-automation]
Tendo isto em mente - a mentalidade de expor o erro - é importante criar no time a cultura de verificação. Isto dificilmente é conseguido se o time que verifica é o mesmo que desenvolve. O time de verificação deve ter por objetivo quebrar o código e deve se sentir satisfeito quando consegue. Algumas normas de desenvolvimento de software exigem que atividades de verificação de software sejam realizadas por outras pessoas senão as que desenvolveram o software. Dá-se o nome de verificação com independência. Na área especial, a norma inclusive fala sobre IV&V (independent verification and validation), que é a verificação realizada por uma empresa diferente, especializada em verificação, que por não desenvolver o software, é imparcial quanto aos resultados dos testes, análises e revisões.
A independência por empresas ajuda o profissional que quer desenvolver um bom trabalho de verificação e não está condicionado a pressões de prazo que normalmente seriam compartilhadas entre as equipes de desenvolvimento e verificação, dentro de uma mesma empresa. Por exemplo, o desenvolvedor poderia atrasar a sua entrega para o verificador e este ter o seu tempo de trabalho reduzido, prejudicando a qualidade do seu trabalho, para cumprir uma meta conjunta de liberar uma versão de software em determinada data.
Outra característica do testador é ser insistente em sua desconfiança. Todo software de razoável qualidade aparenta à primeira vista funcionar. É necessário ser detalhista, metódico e sempre ter a esperança de que o erro alguma hora vai se revelar. "O trabalho do testador nunca termina. É necessário um pouco de paranóia. Dizem que o testador é aquele que olha para os dois lados quando atravessa uma rua de mão única." [Yogananda Jeppu - apresentação Testing Safety Critical Control Systems]
Comentários
Postar um comentário