Tive a ideia de fazer uma série de posts sobre questões contraditórias relacionadas à teste de software, visto minha recente leitura do livro “Pride And Paradev – A collection of agile software testing contratictions“, de Alister Scott.
Meu plano é abordar um par de contradições por post semanal, os quais serão reflexões próprias e específicas sobre cada assunto, e ao mesmo tempo não ser uma leitura cansativa.
Bora começar então?
Times ágeis precisam mesmo de testadores de software?
Interessante contradição no blog de um tester, não?
Times ágeis não precisam de testadores de software
Em minha opinião este modelo pode muito bem ser atingido por times bastante maduros e com um processo bem definido de desenvolvimento de software, onde exista monitoria constante de falhas em ambiente de produção, e onde hajam canais de fácil acesso para o reporte de inconsistencias no sistema.
Um ponto legal abordado no livro é a questão de o software em desenvolvimento poder ser disponibilizado primeiramente em uma versão beta (mesmo com alguns bugs), e então após o feedback e possíveis correções de bugs, liberado em produção para o restante dos usuários.
Além disso, já que todos os envolvidos no processo de teste são técnicos o bastante (desenvolvedores), testes podem ser realizados de forma automatizada, ajudando na detecção rápida de falhas provenientes de novas funcionalidades ou correções de defeitos, e provendo certa segurança aos desenvolvedores de software, que podem dormir tranquilos, quando após seus commits, todos os testes que rodam automaticamente ficarem como a parte de fora da melancia (verdes).
Times ágeis definitivamente precisam de testadores de software
Testadores de software provém uma perspectiva única de questionamento, a qual é crítica para se encontrar problemas antes de ir à produção. Mesmo com sólidos testes automatizados, nada pode substituir os olhos e o julgamento humano (frase traduzida do livro).
Isto vai muito de encontro com o que penso, pois creio que a perspectiva do testador, ainda mais a de um testador com sólidos conhecimentos e grande entendimento sobre as áreas de negócio, é insubstituível, porém, mesmo estes com o papel de testers, devem focar em automação de testes, já que testes de regressão sem automação de testes tornam-se inviáveis quando se fala em agilidade.
E você? o que pensa a respeito desta contradição? Deixa um comentário aí!
Na próxima semana vou falar sobre: “Testadores de software ágeis precisam de habilidades técnicas?”
Pensamento do livro:
Your role as an agile software tester
“Do not worry about holding high position; worry rather about playing your proper role”. ~Confucius
TALKING ABOUT TESTING 
Boa reflexão inicial !
Na minha humilde opinião, um Testador (ou “uma pessoa da equipe criticando seu software”, seja ele qual título tenha) é importante para o desenvolvimento de um produto quando ele se torna complexo o bastante para não ser mais explicado numa frase simples.
Para uma startup que ainda não tem um produto maduro o suficiente e estão correndo atrás de um produto/nicho-de-clientes, eu acho que essa ação de “crítica do produto” pode ser realizada pelo próprio desenvolvedor/analista/dono-da-empresa.
Todo time ágil precisa de pessoas com habilidades de teste. O “Testador” na minha visão deve ser visto como um papel dentro de um projeto e não como um cargo.
Ou melhor, pode ser visto como um papel dentro da execução de uma determinada funcionalidade. Ou seja, nada me impede de ser o desenvolvedor de uma funcionalidade e em outro momento ser o responsável por ser o testador de outra.
Ao longo do tempo, algumas pessoas vão querer focar mais neste processo e outras menos, e pode até acontecer de você ter desenvolvedores que se focam mais em processos de automação e validação do que foi implementado ao invés de serem os desenvolvedores principais das funcionalidades. Eles podem seguir pareando com a equipe ajudando no desenvolvimento mas não são mais puxadores de novas funcionalidades como de repente já foram um dia.