I think we need to re-think
Esta semana participei (como espectador e participante no chat enquanto a conversa acontecia) de um hangout with testers, no qual em dado momento falou-se sobre profissionais de tecnologia da informação que fazem dancinhas e ficam felizes ao encontrar bugs.
Isto vem gerando uma discussão nas listas de email sobre o assunto, as quais participo, e me fez lembrar que não existe esta contradição no livro Pride & Paradev, do Alister Scott. Algo como: O QA no mundo ágil deve fazer uma dancinha ao achar um bug? Não né. O cara já evolui para um nível onde esse tipo de discussão não faz sentido. É óbvio que não, é intrínseco, é parte do pensamento de um time maduro, não só em processos de engenharia de software, como a nível pessoal e profissional.
Com a tecnologia evoluída ao nível que está chegando, um número maior de pessoas e organizações tem a chance de entrar no mercado e entregar uma solução melhor que a sua, ou mesmo atender um mercado que você nem mesmo percebeu, portanto, falhar não deve ser o foco, e sim, acertar.
Devemos aprender com nossos erros, ir atrás dos benchmarks, e evoluírmos a cada dia, sempre com o foco na entrega de produtos os quais os clientes usam, facilita suas vidas, e se possível, os surpreende.
Como Alister Scott fala em seu livro, “Mas um testador não deveria nunca ser medido em quantos bugs ele cadastrou”. Este trecho do livro me fez lembrar uma pelestra do Klaus Wuestefeld, onde ele citou que, em um projeto no qual trabalhou, a ferramenta de bug track adotada foi um quadro físico do tamanho de um notebook pequeno, e que o número máximo de bugs que podia haver na aplicação, era o que coubesse em post-it’s físicos no quadro, o que restringia o número de bugs a um número muito pequeno, não focando no número de bugs como uma boa métrica. Além disso, fez o time então focar na qualidade de suas entregas. Nesta palestra, se falou em eXtreme Programming by the book, falou-se em pair programming 100% do tempo, em TDD, em integração contínua, e principalmente, em comprometimento.
Acredito que temos que evoluir, e fazermos a tal dancinha quando entregarmos de forma realmente ágil, produtos ou serviços aos nossos clientes os quais os deixem deslumbrados, no sentido de qualidade, rapidez de entrega, facilidade de uso, adaptações e práticas de desenvolvimento ágil de software (práticas atuais de sucesso).
That’s my point of view.
Tell me what do you think about it.
TALKING ABOUT TESTING 
“Mas um testador não deveria nunca ser medido em quantos bugs ele cadastrou” – e o que se recomenda para a pessoa que trabalha numa equipe em que ela é sim avaliada pelo número de bugs ?
“QA comemorando bug encontrado? E com dancinha?” – se esse mesmo QA participa de um projeto em que os desenvolvedores fazem de tudo pra minar os esforços de teste, inclusive apontando o dedo para o mesmo QA por que ele “não achou o bug antes de chegar em produção” ?
Contextos diferentes exigem atitudes diferentes. Concordo plenamente que um QA, num time ágil e maduro e numa empresa que respeite seu trabalho não deveria ter esse tipo de atitude. Mas levanto a bandeira de que, infelizmente, nem todo mundo vive numa realidade assim – a maioria se defende com as armas que tem =/
É utópico pedir para o QA ter uma atitude madura, advocar sobre práticas ágeis e tal e coisa, mas esquecer que as vezes o mesmo QA não tem poder político para ser um efetivo “agent of change”.
Creio que é muito mais do que isso. Na minha opinião, é uma questão de valores. Se eu não tenho os mesmos valores da empresa onde trabalho, por quê eu trabalho lá? A mudança vem da atitude de mudar, e se queremos ir atrás de nossos valores, devemos ser os agentes desta mudança.