Há espaço para testadores no mundo ágil?

O pensamento de muitas empresas

Ágil, uma palavra que cada vez mais vem se tornando uma buzzword e cada vez mais tem feito empresas a se intitularem ágil pelo simples fato ou de ser mainstream ou por uma série de "benefícios" como o mito de ágil não tem documentação.

O pensamento inicial de algumas empresas, ao adotarem a metodologia ágil como parte do desenvolvimento do seu produto acredita que apenas dois papéis são necessários: o do product owner e os desenvolvedores.
Como um dos princípios da agilidade é a entrega frequente de valor e a rápida resposta a mudanças, porque iriamos ter agora uma área de testes com testadores que fazem a validação do software no final do desenvolvimento? Esse é um dos pensamentos de muitas empresas que "migram" dos moldes de desenvolvimento tradicional (cascata) para o ágil.
Logo não se tem mais testadores, porque temos um ciclo mais curto para uma entrega e com testadores no projeto só iríamos aumentar este tempo.

E como temos desenvolvedores no projeto, eles apenas precisam adotar TDD - Test Driven Development, que já estarão testando e fazendo com que o software fique livre dos defetos!

Observação: vale lembrar também que, muitas empresas de forma errônea, tomam como premissa que um período de tempo para a entrega de algum valor (funcionalidade ou requisito) tem 4 semanas (que é derivado do Scrum) e planejam o desenvolvimento (e somente o desenvolvimento) em 4 semanas.

Mas vamos pensar uma coisa: onde no manifesto ágil é dito que não precisamos de documentação ou que precisaremos "cortar" qualquer atividade do processo de desenvolvimento? Em lugar nenhum!!!

Uma pequena lembrança

Ágil está mais para uma filosofia do que um conjunto de práticas/regras/processos.
Quando adotamos tal filosofia o time pode (e deve) estudar qual(is) método(s) de desenvolvimento irá adotar e entender qual(s) pode(m) ou não funcionar no contexto da organização.

A realidade em um time ágil

Um time ágil bem estruturado (leia-se time como o time do lado do cliente e o time de desenvolvimento) todos estão envolvidos e colabora em todas as fases: planejamento, desenvolvimento, testes e retrospectiva. Logo podemos concluir que alguém testa, não é verdade? Não necessariamente precisamos de um testador, mas que alguém na equipe tenha tal papel fixo ou esporadicamente (seja ele por um curto ou logo período de tempo).

A transição de testes cascata para interativo-incremental

No modelo cascata, ainda amplamente utilizado quando temos uma setorização de times (analistas, desenvolvedores, testadores), temos testes ao final do desenvolvimento de uma release, onde o testador recebe uma especificação e cria casos de teste enquanto o time de desenvolvimento está desenvolvendo uma série de funcionalidades. O final do desenvolvimento desta release os testadores já estão com os casos de teste prontos e só precisam de tempo para testar e reportar bugs/inconsistências segundo a especificação que foi recebida.
Esse modelo como muito tempo, porque sempre há bugs/inconsistências, onde o time de desenvolvimento que já está trabalhando em outras atividades, tem que parar e corrigir um problema, virando assim ciclos longos de correção.

No modelo ágil cada iteração se torna um processo paralelo no que diz respeito a desenvolvimento e testes. Enquanto o desenvolvimento de uma funcionalidade é realizado há formas e maneiras de testar o que está sendo desenvolvido, onde conseguimos um rápido feedback e, caso ocorra alguma inconsistência, uma correção na própria iteração.
Todas as tarefas de teste manual existentes no modelo cascata agora tornam-se automatizáveis em diversos níveis do desenvolvimento. A automação traz uma velocidade ainda maior no feedback quando a próxima iteração começa, onde o testador agora, ao invés de executar todos os testes manuais das funcionalidades existentes na iteração anterior, executa a batera de testes automatizados criada anteriormente, ou nem se preocupa em executar se a equipe utiliza a prática e integração contínua.

Então, precisamos de testadores?

Sim! Sabemos que o testador tem a tendência de pertencer aos dois times: cliente e desenvolvimento e ajuda o cliente a entender o que ele precisa expressando seus desejos em testes e os desenvolvedores a entender o que precisa ser entregue de valor.

Não é atoa que grandes empresas como Microsoft, Google, Apple, Yahoo!, Twitter, Facebook, Amazon e diversas outras que utilizam práticas ágeis possuem posições de testadores expressadas de diversas maneiras: QA Engineer, Software Engineer in Test, QA Automation Engineer, Test Engineer, etc...

Nos próximos post vamos falar dos skills que um testador precisa ter para trabalhar em uma equipe/time ágil.