BT

Perigos da Separação entre o QA e a Equipe Ágil

Postado por Paulo Rebelo em 29 Abr 2011 |

Todos ganham quando há uma equipe ágil focada no produto e com o mesmo compromisso de entrega de valor de negócio. Ganha principalmente o cliente. Um dos piores males ocorre, entretanto, quando um dos membros não faz parte integral do time. Observei muitas situações em que o analista de qualidade estava em outra área, separada da equipe de desenvolvimento. E isso acontecia, perigosamente, em muitos projetos.

Consequências da separação

O problema começava na divisão por área do conhecimento. Outra questão era a aparente separação hierárquica: o analista de qualidade se preocupava mais em aferir e cobrar um processo de qualidade em si do que propriamente entregar, em conjunto com a equipe, um produto de qualidade que atendesse ao cliente.

Da forma que estava sendo feito, o processo de qualidade já interferia por si só em um dos princípios do manifesto ágil, pois desconsiderava as pessoas e a comunicação aberta. Focava, em vez disso, em impor um conjunto de regras e padrões burocráticos, que impediam o progresso produtivo e incremental. Já cheguei a presenciar o analista de qualidade dizendo que o contrato de QA (Quality Assurance) precisava ser seguido, mesmo que isso acontecesse em detrimento de toda a agilidade que a equipe estava realizando.

Essa situação tornou o projeto lento, muito formal e pernicioso para a equipe, causando conflitos incessantes entre o analista de qualidade e todos os demais. E quando se questionava o trabalho do profissional QA, ele respondia apenas que devia seguir o fluxo e o processo adotado.

Onde existem múltiplos "departamentos" trabalhando com objetivos antagônicos, o resultado é uma guerra entre essas divisões, com cada parte buscando ter mais poder que a outra, infelizmente.

A situação se agravava quando o analista de qualidade cobrava do ScrumMaster quanto ao posicionamento dos bugs da aplicação. Chegava a formalizar toda a comunicação por email, com a intenção de se "blindar" de eventuais problemas que surgissem no projeto.

Não é mais saudável, ágil e produtivo termos uma equipe única em prol de um objetivo comum?

Um problema comum

Michael Azoff tratou desse assunto em sua revisão dos últimos 10 anos do Agile, onde abordou o que evoluiu e regrediu neste período. Parece, portanto, que não é somente aqui no Brasil que ocorre o problema, e que existem de fato "gargalos" gerados pela separação dos times de QA e de desenvolvimento.

Ron Jeffries também aborda o assunto em seu artigo sobre Quality Assurance, no qual responde a questões de um gerente da área de qualidade sobre como o QA se "encaixa" no Extreme Programming. Jeffries recomenda que o o QA se concentre no planejamento e na execução de testes funcionais, apoiando o cliente na homologação das entregas do produto final. Sugere ainda que o gerente de qualidade realize um treinamento de XP e se integre ao time. Com isso, o time fica com um objetivo único: entregar um software que funcione e que satisfaça o cliente.

Enfim, em um cenário ágil, o analista de qualidade poderia cumprir com as seguintes responsabilidades: 

  • Integrar-se ao time, colaborando na prevenção de possíveis bugs, além de discutir com os desenvolvedores sobre as funcionalidades;
  • Validar funcionalmente as histórias de usuários (user stories), baseando-se nas expectativas do usuário e não a simplesmente na totalidade de bugs encontrados;
  • Realizar os testes de aceitação do usuário com o Product Owner;
  • Descrever os testes de aceitação, a fim de que os desenvolvedores ajudem a automatizá-los;
  • Escrever testes automatizados e integrá-los a uma ferramenta de integração contínua;
  • Ajudar a definir indicadores de qualidade e assegurar a qualidade do produto.

O que você acha?

Sobre o autor

Paulo Rebelo (@phfrebelo) trabalha em desenvolvimento de software há mais de 18 anos. Começou a carreira profissional com Mainframe IBM/3270, passando por várias tecnologias e linguagens (Assembler, Cobol, C/C++, Java, Ruby), e agora concentra-se no desenvolvimento para internet. Nos últimos cinco anos, vem se dedicando à gestão de projetos e pessoas, onde atuou na Sodexo como Coordenador Internet e ScrumMaster no UOL. Atualmente, trabalha na Abril como Gerente de Projetos, com foco em metodologias ágeis como Scrum, XP, Lean e Kanban. É Mestre em Engenharia de Software pelo IPT e Licenciado e Bacharel em Matemática.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

QA em equipes ágeis by Rogério Rondini

Eu vejo que a disciplina de QA tem tomado um rumo diferente dos seus reais objetivos. Não pretendo abrir nenhuma polêmica com o modelo CMMi, mas muitas empresas acreditam que apenas tendo uma certificação qualquer que seja o seu nível, já garante qualidade no desenvolvimento.

Você colocou muito bem o papel do analista de qualidade em um cenário ágil. Eu iria mais além; esse papel deve ser aplicado até mesmo em equipes "não-ágeis".
Integração Contínua, por exemplo, é uma prática que pode, e deve, ser adotada em qualquer processo de desenvolvimento. Inclusive, como forma de automatizar tarefas de revisão de código praticadas no CMMi; vide ferramentas como PMD e Checkstyle.

Para as empresas, não basta apenas dizer que tem QA ou que atende algum modelo de qualidade; é preciso por em prática, colaborando na prevenção de bugs, validando funcionalmente as histórias de usuários (ou casos de uso), realizar e descrevendo testes, acompanhando relatórios de ferramentas de integração contínua, etc.

QA em equipes ágeis by Rildo Santos

Penso o seguinte:
Não existe entrega de valor para o cliente se produto não tem qualidade. O QA tem fazer parte da equipe, pois, não tem como separar qualidade do produto. A distância de mentalidade e objetivos entre Analista de Qualidade e a equipe ágil aumenta as chances de conflito.
Acho que ponto a ser trabalhado é a "integração da equipe", pois, todos as pessoas devem ter um único objetivo, trabalhar juntas para entregar valor ao cliente.
Coaching e/ou mentoring podem ajudar na solução de conflitos.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT