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, a apresentação e entrega são feitas. 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? Todo o esforço feito e tempo gasto são praticamente perdidos. Será que existe algo que pode ser revisto e aprimorado no processo com o intuito de estreitar a relação entre expectativa e realidade? Entre o que foi pedido e o que será entregue? 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 ocorrerem?
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, é quem irá descrever as especificidades que o negócio precisa e suas necessidades.
O Analista de Qualidade (QA) é quem irá acompanhar o processo de desenvolvimento a fim de garantir que o mesmo se comporte tal qual o cliente solicitou, preenchendo os requisitos que foram fornecidos pelo BA.
Logo, 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 que os requisitos identificados sejam cumpridos. 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. 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 melhor uma User Stories for escrita, 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.
Se uma User Stories for mal escrita dando margem para suposições ou interpretações ambíguas, isso irá impactar o Critério de Aceite que, por sua vez, irá impactar nos Testes de Aceite. E o que esses erros podem gerar?
O impacto dos erros
É sabido que quanto mais tarde um erro é descoberto, maior será seu impacto e, possivelmente, mais complicada será sua resolução, o mesmo vale nessa situaçã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. Um produto lançado sem a qualidade esperada pode manchar a reputação de uma empresa, além de outras consequências;
• Muito retrabalho – O time terá que revisitar as fases anteriores para identificar os erros e consertar o que foi feito erroneamente;
• Consumo de tempo – Todo o tempo que foi gasto para o desenvolvimento e execução de testes inválidos, agora será gasto 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 de outras User Stories, o que torna sua entrega e desenvolvimento mais fáceis, podendo evitar gargalos de dependência como “Não posso fazer tal tarefa, porque preciso que outra seja finalizada antes”;
• (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 conseguem ser mais objetivas, mais fáceis de serem estimadas e 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.
A técnica INVEST é dada como 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 neles;
• Analisar se os requisitos estão claros, de fácil entendimento e objetivos;
• Dúvidas e suposições devem ser esclarecidas o quanto antes e registradas 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.