Aproveitando uma quest�o levantada � algum tempo no LinkedIn por mim e pegando uma carona no post da Marta, resolvi dar a minha contribui��o em rela��o a discuss�o sobre o papel do Analista de Teste em um time de Scrum.
Como todos devem saber a mais ou menos um ano a Globo.com adotou SCRUM como metodologia de desenvolvimento �gil, sendo assim �reas e especialistas que integravam um determinado n�cleo e seguiam mais Waterfalls, passaram a ser membro de um time multidisciplinar integrando equipes �geis.
Mas isso j� foi falado, vamos ao assunto do post…
Para resumir, tudo mudou e n�s como Homologadores e Analistas de testes , ca�mos de paraquedas nos times de SCRUM. A princ�pio , como � da natureza humana, resistimos a mudan�a e por diversas vezes achamos que n�o era o melhor modelo de se trabalhar com testes. De um lado t�nhamos os desenvolvedores , com a postura natural de rep�dio e medo. E do outro lado est�vamos n�s, estudando o terreno totalmente acanhados.Passou…
Como enxergo o quadro hoje
Ap�s 3 meses integrando de fato um time SCRUM, as coisas ficaram muito mais claras. N�o existe uma receita de bolo em rela��o ao papel de atua��o de um analista de teste em seus times. Os profissionais tem experi�ncias e skills diferentes e os times possuem suas peculiaridades. Cabe ao profissional se adequar a estas particularidades , identificando e atuando como agente agregador sempre.
Hoje, atuo no time levando todo o meu conhecimento de testes e a principio, sem muitas dificuldades, evangelizando sobre a import�ncia dos mesmos. No meu caso, foi e est� sendo mais f�cil, pois o time � receptivo a ideia de teste. Mas mesmo assim, estamos sempre buscando a melhoria e sempre h� algo a se explicar.
A quebra de Paradigma
No come�o � natural desenvolverdores pedindo para Homolgar isso ou aquilo. Com o tempo vou explicando a cada um que o dever de uma entrega com qualidade e sem bugs � do time todo. N�o bato mais o martelo para nada. Tudo � negoci�vel e decidido pelo time.
O Comportamento a adotar
Al�m da evangeliza��o � importante entendermos o trabalho realizado por cada um no time, entender a especialidade de cada membro do time � muito importante.
Sendo assim estaremos entendendo mais ainda o nosso papel.
Documenta��o, tipos e estrat�gias testes
Finalmente vem a quest�o do trabalho em s�. Como e quando devo realizar este ou aquele tipo de teste? Qual a estrat�gia devo adotar? Que documentos devo gerar? Mais uma vez eu digo, tudo isso depender� do time.
Caber� a voc� encontrar a melhor formula. Cuidado com modismos! Automatize os testes avaliando a necessidade. Documente apenas o que realmente for relevante, documenta��o que ningu�m l� n�o serve para nada e demanda um tempo que voc� poderia estar gastando com outra atividade. Monitore o time (no bom sentido), gerando m�tricas e analisando estes dados.E se voc� souber fazer qualquer outra coisa como imlpementar Html ou cortar imagens pode fazer tamb�m, desde que as tarefas espec�ficas de testes j� tenham sido feitas ou estejam esperando por outras. Assim voc� estar� atingindo o principal objetivo, agregar valor ao time com o seus conhecimentos de testes.
#1 written by Maria Martha janeiro 26th, 2009 at 18:40
Isso mesmo, Rey
Nao ha formulas. Cada time vai trabalhar de um jeito e nós precisamos criar mecanismos para nos adequarmos a ele.
Bjs
#2 written by janeiro 28th, 2009 at 10:42
Opa reynaldo, bacana o post, gostaria de deixar a minha colaboração. Realmente cada time tem suas maneira de trabalhar e temos que nos adequar a isso (quando digo nós são “todos” e não somente os “testers”)… Porém lembro que times são compostos de “pessoas” e cada uma delas tem um pensamento e modo de agir. Na minha opnião o mas complexo é lidar com o lado “sentimental” da equipe, como agir, como se impor, quando rir, quando brincar, quando falar sério!! O scrum facilita a comunicação verbal (cliente + Time Scum = produto OK e conforme os requisitos) é nisso que na minha opnião ele ganha de qualquer outra metodologia. Outro ponto que gera discussões é: MEU DEUS agora todos devem saber: Programar JAVA, python, entender do vignette, saber designer, arquitetura de informação, quality assurance, etc … Calma gente, ajudar em outra especialidade é muito bacana porém cada um “gosta” de uma determinada prática… Uns fazem faculdade de desenho, outros de desenvolvimento! Acredito que impor as pessoas a fazerem o que elas não gostam, possa acontecer algo muito pior que é a desmotivação.
PS.: não que eu sou contra a estudar isso é fundamental, mas a imposição não sou a favor!
abraços.