O Scrum, como sabemos, é uma abordagem Ágil para o desenvolvimento de software, focado na entrega de recursos que agregam valor aos negócios em ciclos pequenos de desenvolvimento de duas a quatro semanas. Os times de Scrum têm duas características bem definidas - são multifuncionais (ou seja, buscam conhecer a habilidade que for necessária para realizar o trabalho) e são auto-organizáveis (ou seja, é atribuição da própria equipe descobrir a melhor forma de realizar o trabalho).
Depois de trabalhar por volta de dois anos como analista de controle de qualidade (Quality Assurance ou QA) de um time de Scrum, aprendi que o Controle de Qualidade (QA) no Scrum é muito mais do que apenas escrever casos de teste e relatar defeitos de software ao time.
Diferentemente de um projeto Cascata tradicional, em que há forte dependência entre as atividades, o Scrum considera que as atividades de desenvolvimento devem ser realizadas conforme a demanda - de modo assíncrono. Essa quebra de paradigma levanta uma questão comum feita por muitos dos clientes, desenvolvedores e demais partes interessadas no negócio que são iniciantes nas metodologias ágeis - "Como engajar efetivamente os analistas de testes durante um sprint, uma vez que nada ainda foi construído?" Esse artigo objetiva explicar como o QA deve realizar os testes e qual a sua importância em um time de Scrum. Muito do que aprendi a respeito das funções e responsabilidades do QA no Scrum é compartilhado aqui.
Muito além de elaborar casos de teste
Em projetos Waterfall tradicionais, o QA é envolvido apenas no fim do projeto - quando toda a codificação está completa. Nesses projetos, geralmente o documento de requisitos e o código produzido são entregues ao QA, o qual é esperado que escreva e execute os casos de teste que verificarão se a aplicação está fazendo exatamente o que está determinado no documento de requisitos. Porém, no Scrum, ao QA não é esperado somente executar casos de teste e relatar os defeitos de software.
Em um time de Scrum, os analistas de QA participam de cerimônias e cumprem uma série de responsabilidades em conjunto com outros membros do time. São envolvidos desde o primeiro instante de um projeto e trabalham junto aos desenvolvedores e analistas de negócio. No Scrum, o QA não é um time à parte, que apenas testa a aplicação sendo construída. Ao contrário, é um time multifuncional em que os desenvolvedores, analistas de negócio e analistas de QA trabalham todos juntos.
Além de montar os casos de teste, os analistas de QA também podem ajudar o Product Owner (PO) a escrever os casos de teste de aceite, uma vez que desempenham o papel de representantes do PO. Por conta desse papel, os analistas de QA também podem ajudar a manter o time sempre progredindo, quando o PO não estiver disponível. Por fim, os QAs também podem interagir com o PO, fazendo questionamentos e criticando as premissas do projeto, para ajudar na elicitação dos requisitos de negócio.
Participação na estimativa das histórias
Normalmente, os analistas de controle de qualidade são muito bons em criar cenários de caso de teste, com base nos requisitos do usuário. Além disso, são excelentes em identificar e documentar cenários de caso de teste negativos e complexos. Na verdade, são geralmente melhores nesta última atividade que os desenvolvedores, que tendem a enfatizar mais o "caminho feliz" da história do usuário.
Incluir os testadores durante o Planejamento de Entregas e Iterações, no momento em que as histórias de usuário estão sendo estimadas, pode ajudar o time a pensar além do caminho feliz. Isso ajuda a elaboração de uma estimativa mais real, uma vez que ambos os caminhos - "feliz" e "infeliz" - são considerados. Fazer estimativas é uma tarefa árdua, e é uma boa prática ter a participação do time inteiro durante o levantamento dos prazos.
Ajudar a manter visíveis o objetivo e as metas
Uma vez que a equipe evolui o trabalho por meio de atividades de teste e estabilização, os analistas de QA devem tomar para si a responsabilidade de planejar, organizar e envolver o time inteiro nos testes, além de manter todos motivados da mesma forma que o Scrum Master (SM) o faz.
Considerando que poucos desenvolvedores apreciam fazer testes, os QAs, juntamente com o Scrum Master, devem fazer com que o objetivo e as metas de testes estejam visíveis a todos, além de de ajudar a manter a equipe motivada. Algumas vezes, essa postura facilita a criatividade quando os cenários de teste exigem ajuda dos desenvolvedores ou de outros membros do time. Por isso, tente tornar mais atraente a atividade de testes, fazendo uso de cenários e dados de teste divertidos, por exemplo. Faça o que for possível para ajudar a equipe a se entreter e colaborar com o trabalho de testar.
Ser parceiro dos clientes e desenvolvedores
Uma das principais responsabilidades do QA é registrar o resultado dos testes e dar ciência deles ao Product Owner. Os QAs trabalham juntamente com o Product Owner para ajudá-los a desenvolver critérios de aceite detalhados para as suas histórias de usuário. Baseados no conhecimento aprendido pelo time a cada sprint, os QAs conseguem também ajudar o Product Owner a modificar ou melhorar as histórias de usuários já existentes, com o objetivo de tornar os requisitos mais próximos da realidade.
Dependendo da ocasião, o analista de controle de qualidade pode ser solicitado a fazer o papel do Product Owner. Nessas situações, os QAs e os desenvolvedores devem sentar juntos e trabalhar em equipe, com o objetivo de melhorar a qualidade do projeto. Assim, os QAs conseguem se entrosar com os desenvolvedores na escrita dos casos de teste unitários e na discussão dos critérios de aceite.
Quanto maior o entrosamento, maior será a a compreensão dos requisitos. O aumento de clareza resultante desse trabalho conjunto reduzirá as questões e dúvidas que os desenvolvedores frequentemente encontram durante a fase de codificação. E produzirá, consequentemente, maior eficiência e economia de tempo tanto para os desenvolvedores como para os testadores.
O time inteiro deve estar preparado para se engajar nos testes, sempre que for requisitado e conforme as necessidades e a disponibilidade de cada integrante. Essa prática torna a equipe mais equilibrada e ajuda a dividir com todos a responsabilidade de concluir o trabalho, além de ajudar a obter a velocidade necessária para retornar os testes o quanto antes e, assim, melhorar a qualidade do produto.
Fornecer feedback rápido
O ciclo desenvolvimento-testes-correções que as equipes Cascata tradicionais repetem incessantemente acabam resultando em muito trabalho adicional e, não raramente, em desperdício de tempo da equipe. No Scrum, esse ciclo é muito mais simples, uma vez que os QAs e os desenvolvedores trabalham juntos durante todo o processo. Os desenvolvedores podem sempre consultar os QAs a respeito do critério de aceite ou do comportamento esperado de alguma funcionalidade, a partir da perspectiva do usuário. Isso acontece enquanto estão desenvolvendo, o que resulta em redução dos ciclos de testes e ajustes do produto.
Automatizar testes de regressão
É sempre dito que a automação é o melhor amigo do analista de testes, pois possibilita maior capacidade de repetição, consistência e melhor cobertura dos testes de cada funcionalidade do software. De certa forma, isso é verdadeiro em um projeto Scrum, com ciclos de sprint curtos, de duas a quatro semanas, pois o QA geralmente tem pouco tempo para testar a aplicação. Durante cada sprint de duas semanas, o QA deve desempenhar os testes completos dos novos recursos sendo incluídos durante o sprint, assim como deve desempenhar testes de regressão completos para todas as funcionalidades já implementadas. Como seria esperado, essa responsabilidade cresce significativamente a cada sprint, na mesma proporção que a automação dos testes reduz a pressão sofrida pelos QAs.
Testes automatizados retornam rapidamente resultados, quando os times implementam o processo de Integração Contínua (CI). Sempre que é necessário construir uma nova versão do produto, os testes automatizados podem ser executados, retornando os resultados imediatamente, tanto para indicar se os novos recursos estão funcionando corretamente, como para dizer se houve problemas em recursos que estavam funcionando em versões anteriores. Sem automação, o QA precisaria realizar esses testes manualmente - uma tarefa monótona e sujeita a erros. A automação dos testes é útil para detectar os defeitos o quanto antes, e para dar ao QA mais tempo para testar os casos limítrofes dos novos recursos sendo desenvolvidos. Por fim, a automação dos testes ajuda o QA a realizar os testes com muito mais eficiência e efetividade.
Participar na preparação para lançamentos e demonstrações
Ao final de cada sprint, a equipe deve realizar uma reunião de Revisão de Sprint em que as histórias do usuário finalizadas durante o sprint devem ser apresentadas ao Product Owner e às demais partes interessadas no produto. Essa reunião de Revisão de Sprint fornece uma dose saudável de prestação de contas ao time. E serve de motivação a todos para que seja finalizado o máximo possível de histórias do usuário.
Com ciclos pequenos de sprint de duas a quatro semanas, cada integrante do time deve se manter focado na realização de suas tarefas tendo em mente cumpri-las no prazo. Os desenvolvedores devem se ocupar com o desenvolvimento das histórias do usuário que lhes foram designadas e com a correção dos defeitos de software. Enquanto isso, o QA deve escrever os casos de testes, esclarecer as dúvidas dos Product Owners e automatizar os testes das histórias de sprint anteriores.
Usar ciclos pequenos de sprint significa que os desenvolvedores têm pouco tempo para explorar completamente as funcionalidades de suas histórias de usuários por si próprios. Como resultado, os desenvolvedores frequentemente consultam o QA para entender melhor as histórias do usuário, uma vez que ele é o único que detém o conhecimento completo das funcionalidades e conhece todos os requisitos e critérios de aceite.
Por fim, pode ser uma boa prática o QA realizar a demonstração do produto na reunião de Revisão de Sprint e expor perguntas vindas do negócio. Com isso é liberado tempo dos desenvolvedores para responder a eventuais questões técnicas que surgirem.
Analisar requisitos do usuário
Os QAs são os representantes dos POs no time do Scrum. Costumam entender muito bem os requisitos de negócio, de acordo com a perspectiva do usuário, uma vez que são frequentemente solicitados a responder sobre como o usuário final usaria a aplicação. O QA consegue retornar os resultados ao Product Owner de acordo com suas experiências em testes, e é capaz de ajudar o Product Owner a entender melhor a aplicação, do ponto de vista do usuário final.
Reforçar a definição de pronto
Ter uma clara Definição de Pronto ("Done") é muito importante para o time de Scrum. Uma Definição de Pronto é uma lista simples de critérios de finalização definidos pelo time - ou seja, tudo que deve estar finalizado (ou que deve ser verdade), para considerar que a história de usuário foi concluída. Essa lista geralmente inclui itens como escrever o código, realizar testes funcionais e de regressão, e obter a aprovação do Product Owner. Um exemplo bem simples de definição de pronto poderia conter:
- Código finalizado;
- Testes unitários concluídos;
- Testes funcionais e de interface de usuário finalizados;
- Aprovação do Product Owner.
Apesar de não ser o único responsável por definir a Definição de Pronto (DP), o QA é sempre o responsável por monitorar o trabalho sendo realizado pelo time, e de se certificar que cada história de usuário finalizada seja considerada como tal na DP. Um time de Scrum eficiente irá sempre revisar sua DP antes de iniciar cada história de usuário nova, para ter certeza que todos tenham o conhecimento do que deve ser feito.
Uma Definição de Pronto do time não é estática e pode evoluir, demandando mais tempo na medida em que o time de Scrum estiver evoluindo no trabalho. As DPs podem ser definidas tanto para os sprints como para os lançamentos de versões.
Sempre planejar os testes com estratégias de testes
Como não existe um líder de testes, ou mesmo uma equipe específica para testes no Scrum, construir um plano de testes ou seguir estratégias de testes específicas em um time de Scrum pode ser um problema. Segundo a filosofia do Scrum, deve ser preparada somente a documentação suficiente para apoiar as necessidades imediatas da equipe. Assim, o QA irá preparar apenas a documentação de alto nível suficiente para as estratégias de testes e para os planos de orientação da equipe. Por não existir líderes de QA no Scrum, é comum que o analista de QA decida as estratégias de teste.
Convergência das funções de QA e Analista de Negócio
Nos times de Scrum é comum ver as responsabilidades do QA e daqueles que fazem a análise de negócio começarem a convergir. O Analista de Negócio é comumente responsável por criar e manter o sprint e os backlogs do produto, analisar as histórias de usuário segundo a perspectiva do negócio, e definir a prioridade das solicitações do Product Owner nos backlogs.
O QA, por sua vez, fica responsável por definir e refinar os critérios de aceite para cada história de usuário, por testar as funcionalidades finalizadas em cada sprint a partir da perspectiva do usuário final, e por se certificar que todas as funcionalidades já existentes não deixaram de funcionar. Como o QA testa cada história de usuário e verifica se o critério de aceite definido foi atingido a partir da perspectiva do usuário final, o QA termina analisando as histórias de usuários segundo a perspectiva do negócio. Dessa forma, o QA e o analista de negócio compartilham várias responsabilidades, habilidades desejadas e objetivos gerais.
Normalmente, um time de Scrum obtém suas histórias de usuário e a predefinição do escopo de projeto do Product Owner no inicío do projeto. Contudo, no Scrum o time é incentivado a sugerir novas funcionalidades ou mudanças em funcionalidades existentes, sempre que isso resulte em melhorias à experiência dos usuários finais. O time também é incentivado a recomendar alterações na sequência ou ordem de prioridades das histórias de usuário no backlog, quando são descobertas dependências técnicas que implicariam uma ordem de implementação diferente para obter maior eficiência.
Considerando que tanto testadores como analistas acabam definindo os requisitos, analisando as histórias de usuário, definindo e clarificando os critérios de aceite, construindo os casos de teste de aceite, e trabalhando próximo aos clientes, pode-se notar claramente que as duas funções estão convergindo. Isso oferece vantagens - particularmente para times pequenos - mas também pode trazer problemas. A grande desvantagem é uma menor visibilidade para o testador e para o analista de negócio, pois eles só conseguiriam a devida atenção na equipe se houvesse um membro do time totalmente dedicado a cada responsabilidade.
Conclusões
Enquanto os QAs ainda escrevem testes e relatam defeitos de software, também assumem diversas outras funções e responsabilidades na equipe. São uma parte importante do time e estão envolvidos diretamente no projeto desde o primeiro instante. Trabalhar como uma analista de QA em um time de Scrum nos últimos dois anos foi uma experiência fantástica. Tive muitas oportunidades de aprendizado, e já assumi várias funções e responsabilidades, tais como analista de QA e representante do Product Owner. Também ajudei desenvolvedores a escrever casos de testes unitários, atuando como a consciência de qualidade da equipe, e mantendo o registro dos problemas e defeitos de software. Aprendizados importantes foram que é melhor fazer perguntas do que simplesmente seguir a documentação - e que tudo ao seu alcance deve ser feito para ajudar o time a ser bem sucedido.
Sobre a autora
Priyanka Hasija é consultora de testes na Xebia IT Architects. Na Xebia, ganhou experiência intensiva realizando testes manuais e trabalhando com ferramentas de automação de testes, tais como JMeter e Selenium. Mantém um blog ativo, onde escreveu uma série de posts sobre ferramentas de automação de testes, dentre elas JMeter, Selenium e soapUI, e também sobre Testes Exploratórios. Recentemente, Priyanka co-apresentou palestras de Agile na conferência Agile Tour-Hyderabad.