BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Perigos da Separação entre o QA e a Equipe Ágil

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

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

Conteúdo educacional

BT