Há 9 anos, trabalho na área de Qualidade de Software. Durante essa jornada, participei de mais de 15 projetos diferentes e percebi como o Analista de Qualidade de Software é importante no ciclo de desenvolvimento. 

Antes, deixe-me explicar o que é o ciclo de desenvolvimento de software. Este é um processo que envolve diversas etapas sequenciais ou iterativas para produzir um software de qualidade que atenda às necessidades do usuário e esteja dentro do prazo e do orçamento estabelecidos. A Engenharia de Software define como ciclo básico as etapas de requisitos, projeto, implementação, testes e manutenção. 

Levando em consideração essas etapas, quando você, leitor, acha que o Analista de Qualidade de Software deveria entrar?  

Mas, antes, deixe-me explicar quem é esse profissional caso você não esteja familiarizado. O Analista de Qualidade de Software é responsável por garantir que um produto esteja em conformidade com os requisitos de qualidade estabelecidos, realizando testes no software para garantir essa qualidade. 

Agora que você já sabe o que é o ciclo de vida do desenvolvimento de software e quem é o Analista de Qualidade, consegue responder à pergunta que fiz acima?  

Se você respondeu que o Analista de Qualidade deve estar envolvido desde o início do ciclo de desenvolvimento de software, parabéns! Agora, com essa descoberta, podemos falar um pouco sobre a abordagem de Shift-Left-Testing, onde o processo de teste é movido para a esquerda no ciclo de vida do desenvolvimento de software.  

Isso significa que os testes são realizados mais cedo no processo, permitindo a correção de defeitos com um custo muito menor. Os testes nessa abordagem não podem ser realizados apenas no final do processo de desenvolvimento, quando há uma publicação de toda uma funcionalidade desenvolvida. Myers, em 1979, em seu livro “The Art of Software” (A Arte de Teste de Software), dizia que quanto mais cedo descobrimos e corrigimos o erro, menor é seu custo para o projeto. Esse custo em correção de bugs cresce 10 vezes para cada estágio em que o projeto de software avança. 

Você deve estar se perguntando: “Como é possível encontrar defeitos logo nas fases iniciais do desenvolvimento de software, como a fase de arquitetura, análise e especificação?”. Bem, a resposta está no Analista de Qualidade de Software, que possui uma visão analítica e de usuário que, ao participar de todas essas fases com a equipe, pode iniciar vários planejamentos, reduzindo, assim, o risco de bugs. 

O Analista de Qualidade pode revisar os requisitos, garantindo que estes estejam claros, completos, consistentes e testáveis, permitindo que os desenvolvedores os implementem corretamente. Além disso, pode contribuir para definir critérios de aceitação, identificar riscos associados a cada requisito e planejar a cobertura de testes baseada em riscos. 

Ele também pode definir métricas que serão usadas para garantir a qualidade do software, como a taxa de defeitos encontrados. Além disso, o Shift-Left-Testing promove uma cultura de qualidade em toda a equipe de desenvolvimento de software, ao invés de colocar a responsabilidade exclusivamente no Analista de Qualidade ou em uma equipe de teste separada. 

Na fase de escrita das histórias, o Analista de Qualidade pode planejar e escrever cenários de testes que serão utilizados como insumos para o desenvolvimento. É importante destacar a fala de Myers de que casos de teste mal planejados não agregam em nada. 

“A good test case is a test case that has a high probability of detecting na undiscovered error, not a test case that show that the program works correctly.” 

“O caso de teste tem que ser para encontrar defeito, e não mostrar que o programa funciona.” 

Quanto mais rápido tivermos acesso às histórias e podermos discutir junto com o Product Owner sobre esses cenários de testes, já estaremos prevenindo falhas que poderiam vir a acontecer no software. Outro ponto importante é que, quando duas ou mais pessoas conversam sobre determinado assunto, a chance de ocorrer um equívoco é menor do que quando uma pessoa trabalha sozinha. Portanto, a parceria nessa fase inicial entre o Analista de Qualidade, o Product Owner, o UX e os próprios desenvolvedores é muito importante para entregar um produto de qualidade ao usuário final. 

Quando observamos a pirâmide de testes criada por Mike Cohn no livro “Succeeding with Agile”, onde deveríamos ter mais testes de unidade, depois testes de integração e, por último, testes funcionais, e olhando para a abordagem do Shift-Left-Testing, vemos vários conjuntos de testes escritos de forma saudável, rápida e sustentável. 

Podemos testar um sistema de ponta a ponta, mas com a abordagem correta em cada fase, podemos dar ênfase aos testes de acordo com a necessidade do produto. Se o Analista de Qualidade estiver envolvido desde o início, esse tipo de abordagem é possível. Porém, quando o Analista de Qualidade de Software só aparece na fase final do ciclo de desenvolvimento, a coisa fica feia, meu amigo! É como se fosse um dia ensolarado: todos felizes e sorridentes; você vê alguém com um sorvete de casquinha de chocolate e começa a salivar… Mas, de repente, PLOFT, o sorvete cai de cabeça pra baixo! É o que acontece quando os testes ficam só para a última hora. 

Infelizmente, na prática, é comum a pirâmide de testes ser composta por muitos testes funcionais end-to-end, complexos e demorados, e com poucos Analistas de Qualidade para testar todas as funcionalidades e cobrir o que precisa ser coberto. Isso leva a testes realizados às pressas para que o software entre em produção, especialmente quando o projeto está atrasado. E, muitas vezes, nem há tempo para escrever cenários de testes, recorrendo ao famoso “testa aí, vai clicando e usando o sistema”, sem planejamento, sem estratégia, sem cobertura adequada.  

Dessa maneira não é possível testar o back, as integrações ou fazer os testes unitários. Isso fica para depois e depois e depois, e esse dia nunca chega. Resultado: bugs e mais bugs em produção. Porque, sejamos honestos, o usuário final é ótimo em achar erros, falhas e regras que ninguém pensou no início. 

Então, fica a dica: se você é QA, coloque a mão na massa e se envolva em tudo! E se você é PO, UX ou desenvolvedor, venha junto e faça parte da Cultura de Qualidade. Vamos entregar produtos de verdade e com mais qualidade!