Testes de Software, o certo e o errado

Existem muitas discussões sobre "o certo e o errado", principalmente em listas de discussão como a DFTestes e a oficial do BSTQB, mas a pergunta é: existe realmente o certo e o errado em Testes de software? Bom, apesar de ter sido membro do BSTQB TAG e defender, de certa forma, essa certificação, desafio alguém que diga que existe o certo e o errado, pelo menos para Testes de software. A inevitável resposta para essa pergunta é o bom e velho "depende".
Depende por quê? Vamos supor um projeto de software qualquer. Alguém se propõe a sugerir a melhor abordagem (ou estratégia) de Testes para o projeto? James Bach? Rex Black? James Whittaker? Dorothy Graham? LUGATI IT Services? Luiz Gustavo Schroeder Vieira (rs)? Cada um pode ter uma abordagem diferente, não existe a melhor ou a pior, nem a certa e nem a errada. E a minha abordagem de hoje, com certeza é diferente da abordagem de amanhã. Pois, de maneira geral, o contexto, cenário, pessoas, projetos, ferramentas, mudam o tempo todo. Inclusive estava lendo um post mais antigo meu e achei bastante curiosa a forma como eu pensava na época...
Há quem diga, creio que de forma bem despretensiosa, que o certo é seguir os padrões das certificações e modelos de mercado, tais como IEEE, TMMi, MPT.br e outros. Há quem diga, talvez com uma certa limitação, que o modelo certo é o modelo que ele aprendeu num curso da RSI, Interasys e outros. Há quem diga que, academicamente falando, o modelo mais apropriado é o proposto pelas metodologias RUP, ágil e outros. Há quem diga que, unilateralmente, que o correto é possuir um padrão oficial da empresa e segui-lo em todos os projetos. E também há quem diga que tudo isso que comentei até agora é uma grande bobagem.
Nessa história toda, quem sai perdendo infelizmente é a empresa. Fecha os olhos para o que o mundo tem a oferecer. Poderia investir em bons analistas ou consultores quando prefere pré-estabelecer critérios e os trata a ferro e fogo. O que acontece? Não costumam dizer que a gente colhe o que a gente planta? Então, projeto de desenvolvimento de software, sem um acompanhamento eficiente de profissionais capacitados em áreas específicas, tende ao fracasso.
Desenvolvimento de software não é brincadeira de criança (este assunto é para um próximo post), como eu costumo falar: tem que saber o que está fazendo. Existem motivos suficientes para equipes de testes de software tornarem o produto final mais BARATO. Sim, mais BARATO. Mais uma vez, e isso é cacoete de brasileiro: não se gasta com tecnologia, se INVESTE em tecnologia. Não se gasta com Testes de software, se INVESTE em Testes de software.
Como tornar o Teste de software lucrativo para a sua empresa?
1º - Dê importância a ele.
2º - Saiba REALMENTE o que está fazendo, ou contrate alguém que saiba. Existem muitos profissionais sérios que podem ajudar sua empresa.
3º - Utilize técnicas, estratégias, ferramentas e abordagens APROPRIADAS para o seu contexto.
4º - Não existe "estagiário expert em encontrar pêlo em casca de ovo", isso é mito.
5º - Cobre sua equipe de RESULTADOS: APRENDA COM AS MÉTRICAS e não simplesmente as utilize para mostrar ao seu chefe que sabe montar gráficos e reunir informações.
6º - Testes automatizados não resolvem o problema sozinho. Se utilizados incorretamente, podem se tornar um problema maior ainda.
7º - Crowdtesting é interessante, mas também não resolve o SEU problema.
8º - E por fim, para Testar software, tem que CONHECER Testes de software. E não somente ser especialista no negócio, não resolve nada.