QA, seja bem-vindo(a) ao princípio das coisas
O papel do(a) QA no fluxo de desenvolvimento de uma aplicação é amplo, de modo que testar a aplicação é uma parte importante, mas não se limita a isso.
Buscando contribuir com o Time e disseminar a perspectiva da Qualidade percebi a necessidade de ir além… Com estudos e a mentoria do Júlio de Lima, bem como a ajuda dos colegas do TSPI, compartilho com vocês neste artigo como a minha atuação ocorreu no princípio do ciclo de desenvolvimento do produto, a sua importância e os benefícios práticos que percebi.
Venham, vejam o que eu aprendi!
Meu contexto de trabalho era puxar atividades de cards liberados para teste no Jira. Havia um grande esforço e tempo voltados para essa atividade, com demandas às vezes acumuladas e não planejadas com prioridades maiores.
Como o foco estava em liberar testes, sem grande participação nas etapas iniciais de desenvolvimento, algumas tarefas chegavam no início da sprint sem os critérios de aceite bem definidos, sem sugestão de casos de teste e com pouco detalhamento do que deveria ser feito. Assim, era frequente que os testes fossem postergados para a sprint seguinte.
Eram necessários maiores esforço e tempo dispendidos na fase de planejamento, em vez da fase de execução. Assim, não era possível olhar outros aspectos do produto como desejado. Daí, surgiu a necessidade de se ter tarefas mais bem descritas, detalhadas, com os principais riscos já levantados antes mesmo do início do desenvolvimento.
Tudo bem Rafael, mas como você mapeou o que precisaria mudar?
Inicialmente criei um formulário bem simples com três perguntas para conhecer melhor a equipe e como se encontrava a Qualidade. As perguntas foram:
- O que é Qualidade para você?
- Como você entende meu papel como QA no ciclo de desenvolvimento do produto?
- Quais as maiores dores em relação aos testes e Qualidade?
Os resultados foram bastante interessantes:
As respostas para a pergunta 1 citaram entregas de valor e regras de negócio consideradas e mantidas; boa experiência do cliente com o produto; quantidade mínima de bugs, comportamentos incomuns e inconsistências; evitar a insatisfação do usuário final.
Para a resposta da pergunta 2, foi citado que o papel do QA envolve conhecimento sobre o produto, a garantia da conformidade dos processos e requisitos; o apoio ao time na identificação de inconsistências; contato constante com os desenvolvedores; entendimento de cada task, seu escopo e o que ela afeta; a ajuda na homologação das entregas.
Por fim, as maiores dores observadas nas respostas da pergunta 3 têm relação com deploys sem todos os testes necessários ou deploys sendo transferidos pra sprint seguinte. Também foi relatada a gestão de inconsistências e ritos não sendo seguidos da melhor forma.
Essas respostas ajudaram a entender que a equipe está em sintonia com a importância da Qualidade e como o papel do QA tem relevância no planejamento e nas entregas. Também foi possível identificar pontos de melhoria no processo que afetam a Qualidade do produto e o resultado do Time nas entregas.
Além do estudo das respostas do formulário, atuei na análise do ciclo de desenvolvimento do produto, que consistia em duas fases, de modo que o QA atuava somente na segunda. A primeira etapa começava na área de Produto e Design, a partir da ideação do produto. A segunda fase era composta pela criação de mapas mentais que indicavam pontos chave para a qualidade do produto como riscos, ferramentas, casos de teste, integrações, protótipos da área de UX. Observei que é interessante o acompanhamento do processo por parte do QA desde a primeira fase do projeto.
Com isso achei que já seria o suficiente? Ainda não!
Comecei então a marcar pequenas reuniões com pessoas chave — Product Manager, desenvolvedores e UX — para entender melhor o processo. Outro objetivo das reuniões foi analisar como eu poderia atuar, melhor aproveitando a visão de QA, as técnicas de teste, os checklists, a revisão de artefatos e os mapas mentais.
Essas primeiras mudanças em minha atuação, em comparação ao momento anterior já descrito, impactaram num maior tempo investido no planejamento e refinamento das tarefas, melhor aproveitando o tempo e o esforço nas fases de testes.
Beleza, e tudo isso trouxe algum benefício? Sim! Vejam logo abaixo:
- Maior participação nos processos iniciais, com reuniões e alinhamentos estimulados pelos integrantes do Time;
- Maior quantidade de riscos e pontos de atenção levantados antes da sprint se iniciar, com o objetivo de mitigar esses riscos durante as fases de desenvolvimento e testes;
- As tarefas se tornaram mais detalhadas e melhor descritas, com sugestão de casos de teste e critérios de pronto mais claros;
- Disseminação da Qualidade entre o time, que percebe que ela é responsabilidade de todos.
Bom demais! Então foi tranquilo e sem dificuldades passar por todo esse processo? Não!
Uma dificuldade que eu encontrei foi sair da zona de conforto e lidar com mudanças, uma vez que eu não estava acostumado a participar desses processos iniciais. Havia também o receio de não conseguir vender a ideia e a equipe não aceitar bem as alterações sugeridas. Por isso, a boa comunicação entre a equipe é fundamental ao expor o problema, ao levantar sugestões e ferramentas que dispomos para ajudar o Time na cultura da Qualidade.
Conclusão
Mudanças na minha atuação como QA desde o princípio dos processos trouxeram ótimos insights e benefícios para o produto, para a equipe e para mim, quem testa as aplicações. Como descrito, há diversos impactos positivos, de modo que incentivo vocês que tentem também participar mais das fases iniciais do ciclo de desenvolvimento do produto.
O time perceberá o valor destas mudanças e o processo será melhor para todos!
Agradeço o apoio nos insights e revisões de Zélia Gabriela, Paulo Oliveira, Ricardo Santos, Jonathan Santiago e Gabriel Santos.
Referências
1. http://tspi.juliodelima.com.br
2. Lessons Learned in Software Testing — Cem Kaner, James Bach, Bret Pettichord
