O testador está morto!

Este foi o meu keynote de encerramento do Agile Floripa 2017 em 18/03/2017.

Título polêmico, mas vocês entenderão a lógica no final deste post.

Antes de iniciar a explicação, esta palestra foi baseada na apresentação chamada “The Tester is Dead” da Xebia cujo link pode ser encontrado no final do post, juntamente com o vídeo de apresentação. A visão da Xebia é muito comum ao que eu venho comentando com diversos testadores ao longo destes anos.

Testador 1.0

É aquele testador que, hoje, chamamos “do modelo tradicional” (frente as metodologias ágeis hoje).

O testador, no contexto de um time tradicional, trabalha em silos. Isso quer dizer que há barreiras físicas entre ele e os outros membros do time, geralmente separados entre desenvolvedores, analistas de negócio e testadores. A comunicação geralmente é feita através de documentos ou ferramentas de modo formal.

O processo de desenvolvimento, simplificado é: análise -> desenvolvimento -> testes

Os testes estão sempre na etapa final depois do desenvolvimento, geralmente você já deve ter vivenciado algo assim: o tempo que planejamos sempre será menor do que realmente teremos para testar. Assim a qualidade da aplicação é sempre um problema, e nós testadores levamos a culpa pelos testes estarem no final deste processo.

Ainda neste modelo temos as subdivisões de cargos de teste onde, geralmente, temos estas (que podem variar de acordo com cada empresa):

  • Gerente ou Líder de Testes
  • Analista de Testes
  • Automatizador de Testes
  • Testador

Ou seja, realmente estamos criando uma estrutura de testes onde a área de qualidade será a responsável por testes.

Por que? Porque nos organizamos como área criando subdivisões de cargos e tarefas.

Testador 2.0

Já não temos mais os silos (divisão de times). Trabalhamos agora como um time multidisciplinar (cada pessoa tem um papel específico no desenvolvimento de um software).

Geralmente estes testadores estão fortemente ligado a empresas que aplicam o Mindset Ágil. A qualidade e os testes são inseridas em todo o processo de desenvolvimento.

Ainda temos um testador responsável pelos testes dentro de uma equipe (muitos falam que não, mas o testador mesmo em um time ágil acaba sendo o responsável).

Para que o testador possa trabalhar em um time multidisciplinar focado nas entregas rápidas e frequentes é necessário elevar os seus skills, principalmente em termos de negócio e técnico.

Para isso uma das técnicas aplicadas é o chamado T-Shape. Um T-Shaped Tester precisa, além de conhecer profundamente o seu ramo de atuação (testes), outros conhecimentos que o time possui. Não, obrigatoriamente, o testador irá se aprofundar em todas as áreas de conhecimento. Este mapeamento é feito em conjunto e de acordo com a necessidade do time.

Este testador é uma evolução, obviamente, do Testador 1.0.

Existe um conceito chamado Testador 3.0 criado por Daniel Amorim que, na minha visão, é complementar ao T-Shaped Tester e mais aderente às necessidades de um time ágil.

O testador agora passa a ter especialidades para ajudar o seu time.

Estas dimensões são:

  • Negócio: testadores mais focados em análise de negócio
  • Técnica: testadores mais focados em automação de testes
  • DevOps: testadores mais focados em criação, suporte e testes de infraestrutura

A morte do testador! Bem vindo ao Teste 3.0

Com a junção do Testador 3.0 ao fato dos times se tornarem cada vez mais multidisciplinares, no sentido de executar tarefas diversas para uma entrega há a necessidade de não atribuir mais títulos específicos para os membros do time como programador, analista de requisitos, arquiteto, testador, ux, etc…

Todos no time agora são Engenheiros de Software, ou qualquer outra nomenclatura que o time deseja associar.

Qualquer pessoa do time pode pegar uma tarefa e desempenhar, de acordo com seus conhecimentos.

Por exemplo: uma pessoa que, antes era um testador, vê um bug na aplicação e sabe como corrigí-lo, pois aprendeu a programar. Ele vai pegar esta tarefa de correção e executar.

Para que isso seja possível um modelo de competências é aplicado: Agile Competence Fractal Mode

Ele é um fractal. Um fractal é uma forma geométrica que pode ser dividida em partes, cada uma semelhante ao objeto original. Essa fractal é baseado na Sequência de Fibonacci.

Nele dividimos cada fractal como uma competência.

Cada membro do time terá uma maior área de conhecimento Por exemplo, um programador terá a área de desenvolvimento como sendo a maior, um testador como sendo a teste, um analista de negócio como sendo análise e assim por diante. Mas é necessário preencher o conhecimento dos outro fractais. Nesta parte o time, em conjunto, analisa as competências necessárias que o time deve ter para a entrega e une isso ao conhecimento de cada pessoa.

Obviamente existirão competências que, em alguns casos, todos tenham que ter no mesmo patamar de conhecimento.

Podemos compor uma equipe onde, por exemplo, o mesmo patamar de conhecimento é referente a arquitetura.

A imagem acima mostra um time de engenheiros com diversos conhecimentos, mas todos pautados igualmente no conhecimento sobre arquitetura.

Lembre-se: isso é um conceito!

Todo conceito pode ser aplicado a risca, ser modificado ou mesmo não utilizado.

Lembre-se que o Teste 3.0 é um conceito que pode agregar valor no seu time e que, o fractal de conhecimento, pode ser feito de outra maneira aplicando alguma técnica de mapeamento de competências.

A maioria dos times hoje (datando esta data de publicação) estão na transição de Testador 1.0 para Testador 2.0

Alguns times que eu tenho vistos já estão aplicando o conceito de Testador 3.0.

De fato o testador, pelo conceito de Teste 3.0, irá morrer em termos de nomenclatura, mas não a sua essência: ter o principal foco no time como disseminador da importância do correto foco na qualidade e testes de uma aplicação. Assim ele consegue inserir o mindset de teste em todo o time, o que alguns chamam de “test infected”.

Referências

The Tester is dead, long live Testing! (inspiração da palestra)

[post] https://www.slideshare.net/JordannGross/the-tester-is-dead-long-live-testing-xebicon-2015

[vídeo] https://www.youtube.com/watch?v=Xqf0b7wmD7Q

Agile Tester 3.0 https://www.thoughtworks.com/insights/blog/agile-tester-30

Agile Competence Fractal Model https://www.nl.capgemini.com/blog/digital-customer-experience-blog/2013/05/de-agile-duizendpoot-competenties-tot-in-het-oneindige

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *