terça-feira, setembro 22, 2009

O papel do analista de Testes dentro dos processos ágeis - Uma Introdução

Ainda há muitas dúvidas no mercado acerca do papel do analista de testes dentro de uma equipe trabalhando em um processo ágil. A definição de papéis no Scrum, por exemplo, posssui apenas três elementos: Product Owner, Scrum Master e time. Isso algumas vezes leva a confusões e a crenças de que não há lugar para um analista de testes especializado num time ágil.

Esse artigo é minha tentativa de introduzir e explicar o papel do analista de testes dentro de um projeto de desenvolvimento ágil e também a mudança paradigmática que um analista de testes "tradicional" (tradicional no sentido de uma pessoa acostumada a trabalhar em equipes de testes apartadas de equipes de desenvolvimento e utilizando um processo Waterfall) deve sofrer para se tornar um bom analista de testes "agilista".

Vamos então entender e elaborar a resposta à seguinte pergunta: como o processo de testes ágil é diferente do processo de testes tradicional (cascata) e qual o papel do analista de testes em cada modelo?

No processo cascata, os testes da aplicação acontecem no final do ciclo de desenvolvimento. Nesse período é onde temos o esforço mais concentrado dos testers. A grande realidade é que o papel do analista de testes nesse modelo é muito mais reativo e não pró-ativo. É claro que existe o famoso modelo em V. Além disso, o correto num processo cascata é que os analistas de testes planejem os casos de teste em paralelo com a fase de codificação. Mas, mesmo assim, o que ocorre na prática é que a equipe de testes vive separada da equipe de desenvolvimento, correndo em linhas paralelas que só se cruzam no momento da verdade da fase de testes do modelo cascata.

E como é então o processo de testes e o papel do analista de testes no desenvovimento ágil? Nesse modelo o analista de testes passa por uma grande transformação. Ele deixa de ser reativo para se tornar um papel fundamental na interação com os desenvolvedores, analistas de negócio e clientes. Para entender melhor como ocorre essa transformação precisamos de uma ajuda do quadrante de testes ágil, do livro de Lisa Crispin e Janet Gregory:


Temos então quatro grandes grupos de testes importantes:

Q1 - Testes que focam na arquitetura e suportam o time: São os testes unitários e de componentes. Estes são realizados e são de responsabilidade dos próprios desenvolvedores. O papel do analista de testes nesse quadrante é o de apoiar, suportar e mentorizar os desenvolvedores sempre que necessário. De preferência isso é feito fazendo "pairing" com o desenvolvedor no momento de elaborar os testes unitários automatizados.

Q2 - Testes que focam no negócio e suportam o time: São testes funcionais diferenciados, que idealmente utilizam a técnica de Behaviour-Driven Development e Acceptance Test-Driven Development. Isto é, são testes e cenários de exemplo realizados pelos testadores em conjunto com os clientes, usuários e analistas de negócio. Com base nesses exemplos e cenários os desenvolvedores terão melhores condições de desenvolver e entender os requisitos. Além disso, utilizando-se ferramentas adequadas (como o Fitnesse ou o Concordion, por exemplo), uma parte desses testes serão automatizados antes ou em paralelo com o desenvolvimento do cenário. Portanto, o foco desses testes não é encontrar o maior número de defeitos e sim ajudar clientes e desenvolvedores a se entender melhor.

Q3 - Testes que focam no negócio e criticam o produto: esses são o que chamo de testes "clássicos". Os testes de aceitação feitos na homologação do produto ou de suas partes, testes beta e testes exploratórios. São os testes feitos não com o objetivo de dizer que o software funciona mas, pelo contrário, de encontrar defeitos. Essa categoria às vezes é negligenciada por alguns agilistas mais radicais. Mas a verdade é que bons analistas de testes possuem técnicas para encontrar defeitos que poucos desenvolvedores conhecem (até porque o papel do desenvolvedor é construir e o do testador, neste quadrante, é o de destruir!).

Q4 - Testes que focam na arquitetura e criticam o produto: São os testes de performance, de carga e de segurança. Esses são de responsabilidade dos analistas de testes e costumam ser feitos quando pedaços da aplicação já estão prontas e, especialmente, antes da entrada de um release em produção.

Com a explicação do quadrante é que podemos entender melhor então a transformação crucial do testador num processo ágil. A existência dos quadrantes 1 e 2 no processo ágil (e que inexistem no processo cascata) modificam de maneira fundamental o perfil e o papel do analista de testes numa equipe ágil. Ele deixa de ser reativo para também ser pró-ativo. Ele deve estar dentro do time e não fora dele em uma equipe apartada. Ele alça novos rumos e se torna também um analista de negócios, ao ajudar os clientes a criarem cenários de testes que ajudam no entendimento dos requisitos e facilitam o processo de desenvolvimento da aplicação. A Lisa Crispin aborda isso em seu livro, mas não deixa tão clara assim essa mudança radical e transformadora do papel dos testers dentro de um projeto ágil. Por isso decidi escrever esse artigo para esclarecer ainda mais esse ponto e também para deixar essas informações para aqueles que não tiveram ainda a oportunidade de ler o livro dela.

Recomendo então a todos os analistas de testes: estudem bastante o processo ágil de testes, as novas técnicas de Behaviour Driven Development e as ferramentas automatizadas que as auxiliam. Assim você se tornará um recurso muito mais valioso para sua equipe e para o resultado final dos projetos.

23 Comentários:

At 11:07 AM, Blogger Ronaldo Cruz disse...

Olá Papo,

Sou analista de teste e aqui na empresa começamos a trabalhar com SCRUM a pouco tempo. Pelo que aprendi, o analista realmente tem de mudar a forma de trabalho. Ao invés de esperar pelas coisas, você tem de correr atrás, perguntar bastante e acima de tudo, ser bom negociador, porque alguns bugs ou incosistências encontradas são mais faceis na conversa do que "by book" 100%.
Mas está sendo uma otima experiência, você trabalha mais integrado e entende melhor o que tem de fazer.

Abraços,
Ronaldo Cruz
Analista de teste
ISTQB - CFTL

 
At 11:38 AM, Blogger Elias Nogueira disse...

Olá Papo!
Parabens pelo artigo! Expressa a realidade e postura que os Analistas devem tomar frente a processos ágeis. Eu penso só em uma coisa que tu não colocaste ai: a necessidade do Analista de Teste ser um pouco mais técnico. Em equipes ágeis sabemos que a equipe deve ser multidisciplinar (a profundidade disso varia) e que o Analista/Tester deve apoiar os desenvolvedores nas fases de testes unitários e integração. O problema que vejo é que muitos Analistas de Teste ainda fojem de código ou qualquer coisa relacionada (mesmo não tendo que programar) que nem diabo da cruz.

A qualidade técnica dos Analistas de Teste que o mercado vem formando tem deixado um pouco a desejar.
Creio que para a linha ágil que tu citou, um Arquiteto/Engenheiro de Teste já tem todos os skills necessários para imergir numa equipe ágil!

Abraços!
--
Elias Nogueira, CSTE
http://sembugs.blogspot.com

 
At 11:45 AM, Blogger José Papo, MSc disse...

Olá Elias,

É isso mesmo! Não abordei esse assunto porque iria fazer outro artigo exatamente sobre o tema de programação e testers :-) !

Mas é isso mesmo. Tester que não conhece programação e que não quer progredir aprendendo ferramentas automatizadas de testes com certeza acabará ficando para trás!


Abraços e obrigado!

 
At 12:06 PM, Blogger Gustavo Quezada disse...

Opa José,

Só para acrescentar mais uma frase muito legal que sempre falo para os Analistas de Teste que estão trabalhando em projetos SCRUM:

"O testador é “o cara que aprova”. Nada é considerado “pronto” em um Sprint até que ele diga que está."

Ótimo post!

Até+,
Quezada

 
At 1:06 PM, Blogger karla viana disse...

Este comentário foi removido pelo autor.

 
At 1:45 PM, Blogger karla viana disse...

Olá José,

Infelizmente em algumas literaturas deixam a desejar o papel do Analista de teste e de Negocio,pois acho que esses papeis devem trabalhar em conjunto com outros papeis que são essenciais.. sou analista de testes confesso que sou daquele tipo tradicional tenho aversão a codigo isso por conta de um modelo que separava os papeis e acho interessante seremos o apoio nas fases do processo..adorei a Ideia muito bom o artigo
José Gostaria que vc falasse do Analista de Requisitos no processo Agil!!

Parabéns,

Karla Viana
Analista de Testes

 
At 3:15 PM, Anonymous Anônimo disse...

OLá Paulo, parabens pelo seu post. Aproveitando... sou analista de teste ha dois anos e aprendi o modelo cascata. Estou agora em um projeto scrum e sinto um pouco de dificuldade para gerar o documento de teste. Nossos porjetos possuem UCs e os Casos de teste refletem o UC. o problema é que no scrum temos tarefas que podem ser parte de um UC ou afetar varias partes de varios UCs. Como você escreve teste no Scrum? "Um" documento de caso de teste por sprint ou o projeto do CT ainda se baseia no UC e os testes passam a ser parciais? ou seja, testamos o que atende a tarefa e o resto fica em branco.
Abracos a todos
LR

 
At 10:58 PM, Blogger Wilkner Anderson disse...

Olá blogueiro!

Seguinte: sou novo na profissão. Estou testando o sistema na empresa em que trabalho, portanto, tenho conhecimento de 'usuário'. No entanto, consigo simular bastante bug's! Trabalhamos com Scrum e vejo ser, realmente, uma metodologia muito interessante. Estou me aprofundando no assunto, estou cursando um técnico de web (que inclui programação) e gostando muito do que tenho visto. Bom, o blog foi adicionado no meus favoritos...estarei de olho nas novidades. Obrigado!

 
At 1:52 AM, Blogger Rafael Rosa Fu disse...

Salve,

Artigo bacana, sábado vamos ter um encontro do Guru-SP (Grupo de Usuários Ruby de SP) para falar sobre testes (mais informações no www.rubyinside.com.br), o Juan da Global Code deve estar lá e talvez fale sobre essa questão dos analistas de testes num ambiente ágil, ainda que de passagem. Só faço uma ressalva:

"Assim você se tornará um recurso muito mais valioso..."

Recurso? Péssimo termo. A maior parte das pessoas usa termos que condizem com suas formas de pensar e essa palavra diz muito sobre como enxergamos as pessoas numa organização. Acredito que seja apenas um deslize, mas achei importante dar esse toque.

Atenciosamente,
Rafael Rosa Fu
www.rafaelrosafu.com
www.rubyinside.com.br

 
At 9:11 AM, Blogger José Papo, MSc disse...

Olá Rafael, estou acostumado a usar a palavra recurso porque, além de ser engenheiro de software estudo muito finanças. E em finanças existe o termo técnico "resource" que significa "a person, asset, material, or capital which can be used to accomplish a goal". Isso não tem de maneira alguma relação com a forma como vejo as pessoas dentro de uma organização, isto é, como indivíduos singulares e importantes. Deixo o comentário para reforçar então essa definição e também minha filosofia alinhada com "Indívíduos são mais importantes que processos"

Abraços!

 
At 1:34 PM, Anonymous Wilson disse...

Papo,

Alguns itens sobre a parte onde você fala:

"A existência dos quadrantes 1 e 2 no processo ágil (e que inexistem no processo cascata) modificam de maneira fundamental o perfil e o papel do analista de testes numa equipe ágil. Ele deixa de ser reativo para também ser pró-ativo"

1 - Quem disse que teste unitário e de integração não é realizado em um projeto cascata?

2 - Você está dizendo que o analista de teste deve conduzir o teste unitário? Isso é meio difícil de acontecer né, até mesmo porque a melhor abordagem para testes unitários é utilizar TDD...

Abraços,

Wilson

 
At 1:41 PM, Blogger José Papo, MSc disse...

Wilson, creio que você não entendeu a essência do artigo. Testes unitários e integrados até são feitos em projetos cascata, porém na grande parte das vezes sem automação nenhuma e ainda sem o uso do próprio TDD (pois este fere o ciclo cascateiro de requisitos, design, código e depois teste). Outro ponto é que o quadrante mais importante é o que trata de Acceptance Test Driven Development. Este sim é a maior mudança de paradigma.

O ponto 2 que você também não entendeu e que está claro no artigo nesse trecho: "O papel do analista de testes nesse quadrante é o de apoiar, suportar e mentorizar os desenvolvedores sempre que necessário". Isso significa que não é o tester que conduz o teste unitário. Ele apóia e mentoriza o desenvolvedor. Essa inclusive é uma das principais dicas da Lisa Crispin em seu livro. O tester deve ajudar a melhorar a qualidade do projeto também ajudando os desenvolvedores a testarem seu código.

 
At 2:35 PM, Anonymous Wilson disse...

Papo,

me desculpa mas TDD não fere em nada o "ciclo cascateiro". TDD nada mais é do que uma técnica de testes-codificação / codificação-testes. Aliás, um projeto iterativo nada mais é do que um projeto que repete varias vezes o "ciclo cascateiro", dando ênfase em determinadas atividades de acordo com a iteração.

Abraços

 
At 4:16 PM, Blogger José Papo, MSc disse...

Olá Wilson, se você está fazendo "cascatinhas" dentro das iterações então provavelmente é porque vocÊ ainda não chegou no nível desejado de agilidade. No nível desejado a prática é de paralelismo das disciplinas e não a realização em cascata de cada uma delas. Veja a figura 3-1 desse link: http://www.ibm.com/developerworks/rational/library/may05/bittner-spence/. Lá fica claro o paralelismo das disciplinas.

Outro ponto: quando falo em cascata falo no modelo cascata ideal. Neste você obrigatoriamente precisa fazer o design antes do código e o teste unitário depois do código. Dentro dessa cascata ideal TDD não existe. Mas é claro que existem adaptações que podem ser feitas. E essas customizações podem até levar a um esquema "semi-cascata" que facilite o TDD. TDD não é uma mera técnica de testes-codificação. Se você um dia aplicar ou ver alguém aplicando TDD perceberá que ela é muito mais que isso. Ela é uma filosofia de
design de código. Inclusive alguns metodologistas recomendam dar o nome de Test-Driven Design para reforçar isso. O TDD ajuda a projetar o sistema para a testabilidade, o que por tabela o deixa mais modular. Essa é a grande vantagem do TDD.

 
At 4:19 PM, Blogger ViniciusAC disse...

As características do TDD contrastam bastante com as do desenvolvimento em cascata. Um exemplo disto é que no desenvolvimento em cascata a definição da arquitetura, seja do sistema, ou de uma parte dele, caso seja adotada a estratégia iterativa e em cascata, fica concentrada em algumas fases. Com TDD a arquitetura evolui junto com os testes, ou seja, em passos pequenos e de forma a atender apenas aos requisitos das funcionalidades que estão sendo implementadas. Cada conjunto de um ou mais testes reflete algo que necessariamente deve ser feito para atingir um objetivo bem definido – ou seja, um requisito – e só deve passar (ficar verde) se este objetivo(requisito) for alcançado. Como em TDD, código claro é lei, são comuns diversas refatorações que refinam o código e a arquitetura do sistema para torná-los cada vez mais claros(eu diria até belos) e eficazes.
Resumindo: Com TDD, o desenvolvedor é induzido a primeiro focar-se nos objetivos e refleti-los nos testes, e só depois pensar no código que alcançará estes objetivos. No desenvolvimento em cascata a regra é fazer o contrário.
TDD é em primeiro lugar Design, em segundo lugar aprendizado e documentação e em terceiro lugar verificação e prevenção de erros.
Encerro com um trecho do livro de Teles: “Escrevendo os testes primeiro, você se coloca no papel do usuário do seu código, ao invés de desenvolvedor. A partir desta perspectiva, você normalmente consegue obter um sentimento muito melhor sobre como uma interface será realmente utilizada e pode ver oportunidades para melhorar seu design (HUNT & THOMAS, 2003, p.115, tradução nossa)” [TELES, 2005]

 
At 4:41 PM, Blogger José Papo, MSc disse...

Isso aí, Vinicius!

Obrigado por reforçar minha mensagem ao wilson de que TDD é muito mais que uma técnica de testes unitários.

 
At 4:27 PM, Blogger Ronaldo Cruz disse...

Olá,

Vi que varias pessoas comentaram a respeito de que o analista de teste não programa ou coisa do tipo. Concordo que a grande maioria dos analistas odeia programar e não sou exceção. Também concordo que devemos sempre aprender e evoluir, mas pelo menos nos projetos em que trabalho, realmente não tenho tempo de auxiliar o pessoal de desenvolvimento. Os sprints possuem tarefas suficientes para ocupar o analista de teste de modo que realmente fica complicado ajudar os demais, assim como eles não conseguem me auxiliar em minhas atividades de teste. Bom, acho que isso é bastante relativo, depende da maneira na qual está sendo utilizado o modelo ágil e dos integrantes da equipe.

Abraços

 
At 11:07 AM, Blogger José Papo, MSc disse...

Olá Ronaldo, no livro da Lisa Crispin fica claro que o analista de testes deve ajudar os desenvolvedores em suas tarefas e, ainda mais, ajudar os stakeholders a definir os testes de aceitação para dirigir o desenvolvimento. Talvez no seu caso haja um número insuficiente de analistas de testes, ou talvez a equipe de desenvolvimento não esteja realizando um processo de test-driven development. Isso talvez acabe levando a uma sobrecarga nos testers. Talvez com essa ajuda pró-ativa e com o uso de práticas de TDD fique melhor, pois vocês teriam uma melhor qualidade do trabalho sendo realizado pelos desenvolvedores. Essa é a essência da mensagem que a Lisa Crispin quer passar sobre os fundamentos do "Agile Testing"

 
At 2:16 PM, Blogger Rafael Ribeiro Duque Estrada disse...

Parece que o post atingiu muitos analistas de teste. Não sei se concordo muito bem em tentar enquadrar os cargos existentes atualmente no mercado no SCRUM, o que acho é que toda a equipe é um time e somos "agilistas". Se alguém do time tem uma deficiências em programação não quer dizer que ela não irá programar, muito pelo contrário, provavelmente iremos fazer isso em par até essa pessoa conseguir caminhar sozinha. Assim como programação como tarefas de design ou até mesmo criação de modelo.
Eu acho que para trabalhar corretamente com SCRUM devemos ter essa mentalidade, não existe mais papeis definidos como temos no mercado dentro do time.
A pessoa que quiser trabalhar corretamente com SCRUM deve se enquadrar nesse perfil ou continuar empurrando com a barriga trabalhando em empresas que seguem o RUP ou waterfall.
Um exemplo, uma amiga trabalhou em um projeto e ela era Webdesigner antes de trabalhar com SCRUM e virar agilista, fazia a prototipação das telas para utilizacao na camada view da aplicação e não ficava parada ou pulava para a próxima estória, ela levantou o "bumbum" da cadeira e se ofereceu para ajudar nos testes unitários. Na 3o iteração ela já estava mechendo com o selenium e jUnit sozinha, lógico que não começou em par apredendo e mostrando interesse no framework, mesmo "não gostando" de programar (assim como a maioria das pessoas que não programam tem aversão).
Minha opinião pode parecer meio radical é, ou você se enquadra nesse mundo ou você irá usar o famoso SCRUMBUT que falam por ai ...

 
At 2:25 PM, Blogger Rafael Ribeiro Duque Estrada disse...

Acertando o post acima:
"lógico que COMEÇOU em par apredendo e mostrando interesse no framework, mesmo "não gostando" de programar (assim como a maioria das pessoas que não programam e tem aversão).
Minha opinião pode parecer meio radical, ou você se enquadra nesse mundo ou você irá usar o famoso SCRUMBUT que falam por ai ..."

 
At 2:30 PM, Blogger José Papo, MSc disse...

Olá Rafael,

Ser um tester é muito mais que um cargo. Além de ter um conhecimento profundo específico em técnicas de testes o analista de testes precisa de uma visão de mundo diferente de um programador. A função principal do tester é destruir o sistema e não construí-lo. É achar defeitos e não dizer que está tudo bem. No próprio livro da Lisa Crispin isso fica bem claro. A necessidade de um papel (e não cargo) que foque em testes ágeis é crucial. Mas é importante reforçar que isso não significa que o analista de testes será só tester no projeto. Ele focará a maior parte de seu tempo nessa atividade. Porém não significa que ele não tenha de ser pró-ativo e ajudar outros papéis quando necessário. Se isso fosse Scrumbut não teríamos tantos metodologistas comentando sobre esses aspectos em diversos blogs, artigos e livros. Recomendo a leitura do artigo do Scott Ambler que citei sobre especialistas generalistas. Esse para mim é um artigo que deixa claro como deve ser o perfil das pessoas dentro de uma equipe ágil. Não só generalista e não só especialista. Deve ter uma especialidade, que será seu foco, mas deve aprender sobre todas as outras áreas de conhecimento. Assim poderá apoiar os outros membros do time. A realidade de projetos é essa. Todos possuem um interesse mais forte por algum papel, seja ele programar, testar, analisar, gerenciar, administrar banco de dados, etc. Com o conceito de especialista generalista podemos potencializar a especialização de cada um e ainda ter a flexibilidade delas se auto-organizarem para ajudar em outros aspectos diferentes de sua especialidade.

 
At 8:02 PM, Anonymous José Eraldo disse...

Olá José!
Muito interessante e tem muito a ver com o tema em que estou postando, baseado em um estudo que fiz a algum tempo atrás.
Diariamente estou postando a respeito do tema Processo de Teste em Metodologia Ágil de Desenvolvimento. Estou detalhando os passos de como implementar e executar testes em métodos ágeis de desenvolvimento.

Acesse http://agiletestbr.blogspot.com.br/

Fico a disposição para dúvidas e criticas!

 
At 12:12 AM, Blogger Infinito Paralelo disse...

Olá José,

Primeiramente parabéns ao texto.
Eu entendi que o teste no processo ágil ocorre em paralelo com o desenvolvimento, porém uma parte do teste ficaria somente após a finalização da codificação. Então, acabariamos entrando um pouco no modelo cascata. Teria como explicar isso inclusive demonstrando como ficaria as atividades dentro de uma sprint?

Obrigado!

 

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas