Reflexão sobre o papel do QA no ciclo de desenvolvimento de software
Um estudo realizado em 2013 pela Cambridge University, descobriu que os desenvolvedores gastam em média metade do seu tempo de programação na correção de bugs. O fato mencionado eleva, portanto, os gastos em aproximadamente U$ 312 bilhões por ano, com tendências de aumentos progressivos. O Systems Sciences Institute da IBM mostrou que o preço da correção do bug depende exclusivamente de qual fase do ciclo de desenvolvimento ele é encontrado. Esse custo pode ser até 100 vezes mais caro quando encontrado em produção, na fase de manutenção (Figura 1).
Relembrando processos de desenvolvimento que utilizavam metodologias tradicionais, sabemos que a etapa de teste somente iniciava quando a fase de desenvolvimento era finalizada. Sendo assim, o analista de teste possuía um conhecimento limitado do sistema, visto que seu papel era exclusivamente preparar e executar casos de teste com foco nos requisitos documentados. Por isso, os bugs demoravam para ser encontrados.
Em virtude dos fatos mencionados, quanto custavam os bugs encontrados próximo ao lançamento ou até mesmo com o sistema já em produção?
Como podemos observar na tabela acima, uma falha na operação do sistema pode acarretar desde prejuízo financeiro para empresa como até mesmo catástrofes. Por isso, a preocupação com o desenvolvimento de sistemas com qualidade tem crescido gradativamente.
Contudo, o que é qualidade de software?
Na palestra “Como criar a tão falada cultura da qualidade” ministrada por Samanta Cecilia (referência em agile testing), ela disse:
“A qualidade é uma característica percebida, feita de expectativas do usuário (não é possível controlar)”
Por mais que tenhamos executado os testes e na nossa concepção o sistema esteja seguindo o escopo proposto, apenas o usuário poderá definir se o que foi entregue tem a qualidade esperada. Sendo assim, a experiência do usuário é um fator que deve ser considerado ao pensar em qualidade de software. Mas então, surge a dúvida: “como podemos pensar em qualidade dentro do ciclo de desenvolvimento de software?”.
Com o progresso constante do mercado foram surgindo novas tecnologias e metodologias ágeis, o que levaram, consequentemente, na evolução da área de qualidade. Assim, o papel do QA se tornou estratégico dentro do time de desenvolvimento, deixando de ser “bug hunter” (caçador de bugs) e ficando mais próximo tanto do time de negócio, quanto do time de desenvolvimento.
Pensando nesses fatores, onde começa e termina a real atuação do QA dentro do ciclo de desenvolvimento de software?
Sem deixar de preparar e executar testes, o QA pode participar desde a concepção até a entrega do produto, estando presente no processo completo de desenvolvimento de software e se tornado membro do time. Assim, ele tem conhecimento do sistema do início ao fim e está qualificado tecnicamente por ter noção de programação. Desse modo, podemos pensar nos seguintes tópicos:
- Contato com o PO e UX/UI: o conceito “esperar a documentação/telas ficarem prontas para iniciar o processo de desenvolvimento ou escrita dos casos de teste” é totalmente ultrapassada. O QA pode dar apoio total na validação e escrita da documentação analisando textos ambíguos, telas que não estão atualizadas e cenários alternativos não mapeados. Além disso, por ter conhecimento completo do sistema, durante esse contato, é possível relembrar regras que podem conflitar com as alterações que estão sendo propostas, questionar inserção de novas regra com relação ao comportamento do sistema, etc. Esse fato permite prevenir que alguns bugs possam ocorrer durante a fase de desenvolvimento.
- Planejamento: quando pensamos em metodologias ágeis o QA faz parte do time, portanto estando presente desde o início do processo é possível apoiar na estimativa justamente por ter uma visão maior do que será desenvolvido. Sendo presente, o QA pode questionar se o desenvolvedor está considerando todos os cenários que devem ser desenvolvidos e, assim, ser mais assertivo na pontuação das tasks que serão implementadas. Esse fato permite ter uma dimensão mais ampla das demandas que poderão ou não entrar na Sprint. Sem contar que essa atuação também ajuda a prevenir que possíveis bugs possam ocorrer, visto que estaremos validando todos os pontos que devem ser levados em consideração durante a implementação do sistema.
- Implementação/Testes: nesse ponto a fase de teste se tornou uma atividade que pode ser executada em paralelo ao desenvolvimento. Podemos realizar automação dos testes antes mesmo da implementação ser finalizada, executar testes do backend (API, banco de dados) sem a necessidade de uma interface. Apoiar o desenvolvedor realizar validação das funcionalidades e layout antes da versão ser liberada para “teste”. Realizar peer review de teste unitário e validar logs de bugs para pensarmos juntos nas possíveis soluções. Com isso, o foco parou de ser em “caçar e reportar bugs”, mas sim em prevenção.
Diante desses fatos, podemos pensar nos testes como uma atividade que irá ajudar na entrega de valor e não como uma fase.
Agora, se questionem:
- O QA do meu time tem sido participativo em todas as etapas do processo de desenvolvimento do projeto que estou atuando?
- No meu time, os QAs e Devs tem trabalhado juntos em prol da qualidade do produto?
- Todos os membros (PO, DEV, UX) do meu time interagem entre si?
- Pensamos na Experiência do Usuário como um fator de qualidade?
- Como QA, tenho questionado se os tipos e níveis de testes executados são aqueles que realmente irão agregar valor para o produto?
- Os bugs estão sendo encontrados apenas quando a versão do sistema é liberada ou atuamos na prevenção de bugs desde a concepção?
E aí? Chegaram na conclusão que a cultura de qualidade realmente é colocada em prática no seu projeto ou, apesar de atuar em um time ágil, o teste ainda é visto como uma fase?
Levando em consideração todas as reflexões aqui descritas, podemos concluir que o papel do QA vai além de “validar se o sistema está de acordo com os requisitos propostos”. Segundo Lisa Crispin e Janet Gregory no livro “Agile testing”, a qualidade de um produto é formada por vários componentes. Sendo assim, não basta executarmos testes de acordo com os requisitos propostos, precisamos pensar além. Precisamos levar em consideração características tais como, performance, segurança, acessibilidade, entre outras que vão de encontro com o contexto do projeto. Sendo membro do time e estando presente desde a concepção até a entrega, a garantia de qualidade se torna responsabilidade de todos. Assim, podemos prevenir que possíveis bugs aconteçam e pensar em tudo aquilo que realmente irá agregar valor para o projeto. A qualidade de software não se limita em apenas testar o sistema, mas sim em todas as decisões que podem (e devem) ser tomadas em conjunto ao time. É algo a se pensar e poderemos conversar sobre isso em uma outra postagem …
Referências
