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.

Avalie esse artigo

Relevância
Estilo/Redação

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 mensagens 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 mensagens dessa discussão

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

Receber mensagens dessa discussão

2 Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.