Garantia de qualidade: O que foi pedido é o que está sendo feito?

Após um ciclo de desenvolvimento, chega a hora de fazer a demonstração do incremento para o cliente. O time está ansioso para saber o feedback. Então, acontecem a apresentação e a entrega. Mas a resposta não é animadora: Não foi isso que eu pedi. O time se entreolha e pensa: “E agora?”.

Essa situação é um dos maiores medos dos times e do cliente, pois imagine trabalhar durante todo um período de desenvolvimento (por exemplo, durante uma sprint) em várias tarefas e na entrega o cliente fica descontente? Você perde praticamente todo o esforço e tempo investidos. Mas será que existe algo que você pode revisar e aprimorar no processo para alinhar melhor a expectativa com a realidade? Para garantir a entrega corresponda ao pedido? Sim, existe! Então, vamos ver abaixo uma das possíveis melhorias no processo de desenvolvimento que pode ajudar a sanar situações como essa.

Por que situações assim ocorrem?

Existem algumas variáveis que podem levar a situações de frustração no final de um ciclo de desenvolvimento, uma delas é quando o time de desenvolvimento não está alinhado com a área de negócio, pode ser por má comunicação, pode ser por falha na criação da documentação, pode ser porque cada área tem um entendimento sobre o objetivo, etc.

Sabendo disso, vamos identificar qual é o papel das profissionais envolvidos nessas áreas:

O Analista de Negócio (BA) é a pessoa responsável por entender o objetivo geral do produto e necessidades do negócio na visão dos stakeholders. Portanto, é quem irá descrever as especificidades que o negócio precisa e suas necessidades.

O Analista de Qualidade (QA) acompanha o processo de desenvolvimento para garantir que ele atenda exatamente ao que o cliente solicitou, preenchendo os requisitos fornecidos pelo BA.

Portanto, podemos dizer que eles são complementares. O QA precisa do BA para entender as regras e necessidades do negócio, e o BA precisa que o QA garanta o cumprimento dos requisitos identificados. Ao longo do de desenvolvimento, analistas de negócio e analistas de qualidade têm várias oportunidades para colaborarem em suas atividades, o que irá maximizar a sintonia entre as áreas e o valor obtido. Por outro lado, times que não entendem o valor desse trabalho colaborativo, e não o exercem, correm o risco de enfrentar essas situações de desencontro entre a expectativa e realidade, o que poderá gerar desgaste e prejuízos.

Sendo assim, como podemos atuar para que haja uma sinergia entre as áreas citadas?

A importância da boa qualidade das User Stories e Critérios de Aceite

O desenvolvimento de uma User Story começa antes da programação, quando ela ainda está sendo planejada e escrita. Para isso é necessário fazer um levantamento do que será necessário para atingir o objetivo daquela entrega. Portanto, a atenção e envolvimento para a criação de Requisitos e Critérios de Aceite devem estar muito bem apuradas entre o BA e o cliente, pois será através deles que as User Stories e Testes de Aceite serão feitos pelo QA.

Usando o exemplo simplificado, vamos entender um pouco melhor sobre esses termos e o que são eles:

Considerando a imagem acima, o fluxo consiste em: quanto melhor o BA entender as necessidades do negócio, melhor ele poderá escrever uma User Stories. Quanto mais bem escrita for uma User Stories, melhor será possível identificar os Critérios de Aceite para satisfazer o objetivo da User Stories. Por fim, quanto mais precisos forem os Critérios de Aceite, mais assertivos serão os Teste de Aceite criados.

Uma User Stories mal escrita, com margem para suposições ou interpretações ambíguas, vai impactar o Critério de Aceite. O que, por sua vez, irá impactar nos Testes de Aceite. E o que esses erros podem gerar?

O impacto dos erros

Quanto mais tarde você descobrir um erro, maior será seu impacto e, possivelmente, mais complicada será sua resolução. Erros que forem percebidos somente na criação do Teste de Aceite irão impactar tudo que foi feito antes. Portanto, critérios não alinhados resultarão na quebra de expectativa gerando:

• Risco e incerteza sobre o produto – Os stakeholders podem ter uma quebra de confiança sobre o Time e causar incerteza sobre a qualidade do desenvolvimento do produto. Dessa forma, um produto lançado sem a qualidade esperada pode manchar a reputação de uma empresa, além de outras consequências;
• Retrabalho – O time terá que revisitar as fases anteriores para identificar os erros e consertá-los;
• Consumo de tempo – O tempo gasto para o desenvolvimento e execução de testes inválidos agora será necessário novamente para consertá-lo;
• Aumento do custo do projeto – Tempo é dinheiro, todo o consumo de tempo citado acima irá impactar no custo do projeto.

Como evitar essas situações?

Segundo o ISTQB (International Software Testing Qualifications Board) é importante que as ambiguidades sobre o produto, objetivo, desenvolvimento sejam resolvidas e as suposições sejam esclarecidas para que os testes de aceite resultantes sejam válidos e sejam uma maneira significativa de determinar a prontidão do produto para a liberação.

Uma das técnicas usadas por Times Ágeis para criar User Stories colaborativamente e visando maior qualidade é a “INVEST”, criada por Mike Cohn. Esse acrônimo de palavras em inglês serve de guia para ajudar a escrever boas User Stories.

• (I)ndependent (Independente): User Stories devem ser independentes umas das outras, facilitando entrega e desenvolvimento, e evitando gargalos de dependência. Como, por exemplo: “Não posso fazer tal tarefa, porque preciso antes da finalização de outra”;
• (N)egociable (Negociável): User Stories não estão escritas em pedra. Elas são negociáveis entre as partes interessadas e podem ser mudadas ou reescritas antes de fazerem parte de uma iteração no intuito de entregar o maior valor possível e esperado;
• (V)aluable (Valiosa): Falando em valor, as User Stories devem sempre agregar valor ao usuário final;
• (E)stimable (Estimável): Deve ser possível estimar o tamanho de uma User Stories, para saber o tempo de desenvolvimento gasto, o que será afetado e assim ajudar no planejamento e priorização das User Stories;
• (S)mall (Pequenas): O tamanho das User Stories colabora com os itens acima. User Stories pequenas são mais objetivas, mais fáceis de fazer uma estimativa e de serem entregues, cabendo nas sprints;
• (T)estable (Testável): As User Stories precisam ser testáveis, através dos testes que podemos mensurar se a User Stories está atingindo sua definição de pronto.

Em resumo, a técnica INVEST é uma boa prática que auxilia na criação de boas User Stories, minimizando potenciais problemas que podem ocorrer por falta desse guia.

Dica final para garantir a qualidade do desenvolvimento

A cada fase do desenvolvimento, desde o planejamento até a entrega, atente-se a:

• Analisar os requisitos a fim de encontrar ambiguidade ou qualquer deficiência;
• Validar se os requisitos estão claros, de fácil entendimento e objetivos;
• Esclarecer dúvidas e suposições o quanto antes, registrando-as no documento;

Desse modo, quando a área de negócio e a área de qualidade trabalham em colaboração com propósito de garantir que ambas têm o mesmo entendimento sobre o objetivo e critério de aceite desde o começo do projeto, as chances de uma entrega ser bem-sucedida e ter satisfação do cliente são maiores.

Vanessa Pecorari é formada em Análise e Desenvolvimento de Sistema desde 2014. Se apaixonou pela área de qualidade em 2017 e viu um novo mundo de aprendizado se abrir com isso. Desde então procura conhecer mais sobre os conceitos, ferramentas e tecnologias dessa área.  Possui certificação CTFL, CTFL-AT e CTFL-AcT , além de PSM I na área de agilidade. Nas horas livres gosta de se afundar em cultura pop em streamings e se divertir com memes.