Olá pessoal!
Dia 11 de Maio de 2013, na Unicamp, eu apresentei no DevCamp uma palestra sobre "O papel do testador em uma equipe ágil.
Vídeo
No site da Infoq BR é possível ver o vídeo da apresentação pelo link abaixo. Também é possível fazer o download do áudio da palestra em .mp3http://www.infoq.com/br/presentations/testador-equipe-agil
Apresentação!
Abaixo segue um resumo do que comentei.
Hoje muitas empresas falam, quando sobre desenvolvimento ágil, muito de Scrum (e isso é bom ou ruim). Em teste de software temos um grand problema: além dos testadores não serem técnicos (muitos poucos são), eles querem aplicar em um contexto ágil (ou quase), as técnicas utilizadas em um modelo burocrátivo/engessado sempre pensando a fase de criação e, posteriormente, execução é um sprint separado do de desenvolvimento (não colaboram).Testadores também não gostam de programar. Muitos foram para a área de teste por esse "benefício". Muitos são programadores que não deram certo ou pessoas querendo uma porta de entrada em TI ou para algum outro cargo, como um Analista de Requisitos/Negócio. Estou falando alguma mentira?
Emfim, em um mundo não tão distante o testador quer continuar acomodado e ainda discute itens básicos e, as vezes, nem condizentes como onde ele pode obter simulados da certificação XYZ ou como escrever um caso de teste.
Neste momento começamos a discutir sobre Agile Testing, que vale muito a pena salientar que Agile Testing é nada mais que seguir as práticas ágeis em primeiro lugar. Claro que existem técnicas, algumas já amplamente usadas, e outras novas, mas em um primeiro momento Agile Testing é uma prática que segue a "linha" ágil. Sempre falo que, para aprender Agile Testing, é necessário primeiro o testador dar um passo para trás e aprender o que é realmente ágil e nem ler sobre Scrum.
Em seguida comento algo que, em algumas empresas é sempre nítido, mas em outras nem acontece: O testador tem que interagir com todos! Desenvolvedor, cliente e analistas entendendo a visão do cliente (onde ele quer chegar) e a complexidade de viabilizar essa visão (como ajudar ela a chegar no objetivo).
O testador tem que estar inserido junto ao time e deve ajudar o cliente a entender onde ele precisa chegar, através de perguntas e transformando o entendimento em algo que possa ser entendido e testável por todos.
E o que o testador fará enquanto os desenvolvedores estão criando código?
Várias coisas! Entre elas, pairing, ajudando os desenvolvedores nos testes unitários (a ter mais testes/cenários) e principalmente automatizam (existem muitas outras coisas que o testador pode fazer)! Sim, automatizam sem ter uma interface gráfica. E isso é possível adotando práticas como BDD e ATDD para que tenhamos boa parte dos testes já automatizados.
E, obviamente, um testador ágil tem que conhecer sobre o Quadrante Ágil (ou quadrantes de Bryan Merick). É essencial que ele conheça os quatro quadrantes e as atividades recomendadas em cada quadrante.
Para entender quando podemos automatizar, é interessante falar sobre a Pirâmide de Automação de Testes, onde a base da pirâmide (e o mais barato) são os testes unitários. Claro que não iremos desenvolver os testes unitários (mas se soubermos, nada contra), mas apoiaremos os desenvolvedores a criar uma gama de testes unitários que façam sentido para o negócio (e aqui aquele testador que adora testar limites, pode fazer aqui, e não na interface gráfica...)
Após seguimos pelos serviços, onde ainda sem interface gráfica conseguiremos testar a integração do sistema e, através de Fixtures ou BDD, viabilizar estes testes.
Por último, na automação, temos a interface gráfica. Esta mais cara e demorada. Mas é um ponto os testadores tradicionais começam por conhecerem ferramentas de automação e entenderem que é importante testar o que o usuário irá utilizar.
Mas não podemos somente falar em automação... em ágil também fazemos testes manuais, mas estes devem ser mais "inteligentes". Essa inteligência pode ser a utilização de uma técnica chamada SBT - Session Based Testing, por exemplo.
E como ficam os defeitos? Reportamos em uma ferramenta de bugtracker, faremos uma parada para todos os devs corrigirem defetos?
A resposta sempre é depende!
Mas vamos pensar em algo lógico: estamos trabalhando (falando) de agilidade, certo? O que é mais ágil: reportar um defeito em um ferramenta ou parar ao lado do desenvolvedor, mostrar o bugs e ajudá-lo a criar um teste automatizado para que aquilo não ocorra?
No final existe uma série de fatores de sucesso, mas o principal, sempre é COLABORACÃO!!!
