Sua equipe já está utilizando limites de trabalho em progresso (WIP)? Se não,
que tal conversar com time e definir alguns limites iniciais para identificar gargalos e problemas de trabalho parado?
Seu time está mantendo as opções abertas? No que vocês estão se comprome-
tendo cedo de demais sem saber o porquê?
Você e seu time sabem o qual é o valor de negócio que está por trás de cada uma
das funcionalidades que estão desenvolvendo? Será que vocês podem ajudar o PO a
encontrar formas mais eficientes e baratas se conquistar o valor de negócio que está sendo perseguido?
66
Capítulo 4
Entregando Valor
Este é o segundo nível de fluência ágil, no qual os benefícios predominantes são a
alta produtividade e a melhoria na qualidade externa do produto.
É um momento oportuno para investimento nas capacidades técnicas da equipe
e, por isso, agora serão apresentadas algumas técnicas e práticas de engenharia utilizadas por equipes ágeis.
Equipes neste nível de fluência têm a habilidade de manter seus produtos sempre
(ou quase sempre) em um estado de pronto-para-entrega, permitindo assim que o
produto seja atualizado com a velocidade e frequência que o mercado exige.
Capacitar uma equipe para alcançar um alto nível de habilidade técnica requer
tempo, esforço e muita prática. Cursos, treinamentos, contratação de desenvolvedo-
res experientes para ensinar os menos experientes podem ser importantes para se
atingir esse objetivo [57].
O aprendizado de técnicas mais avançadas e o pagamento da dívida técnica cri-
ada pela falta de experiência e código legado podem reduzir a produtividade neste
momento. Mas apesar do alto investimento, uma equipe bem capacitada tecnica-
4.1. Testes Ágeis
Casa do Código
mente poderá criar produtos com menos defeitos, o que resultará em mais tempo
para produzir funcionalidades que realmente possam agregar valor.
Algumas práticas predominantes neste estágio são: programação em par, inte-
gração contínua, propriedade coletiva de código, e desenvolvimento orientado a tes-
tes (TDD).
A seguir faremos um rápido estudo sobre cada uma dessas práticas ágeis.
4.1
Testes Ágeis
Métodos ágeis defendem a ideia de que é preciso criar software de qualidade desde
o início, ao invés de assegurar a qualidade apenas no final do processo.
Novas funcionalidades serão entregues com alta frequência e não se pode permi-
tir que as alterações realizadas no software para criar as novas funcionalidades façam com que funcionalidades já existentes deixem
de funcionar. É para prevenir que isso aconteça que existem os testes de regressão que podem ser realizados manualmente
ou automatizados.
Além disso, deve-se prevenir defeitos a todo o momento, porque quanto antes
um defeito for detectado, mais rápido e barato será para resolvê-lo.
O que é mais barato: descobrir que uma alteração em uma parte do software
criou um defeito em outra através do feedback de um testes de unidade durante o
desenvolvimento e então resolver o problema na mesma hora, enquanto ainda se
está com as regras de negócio em mente; ou descobrir posteriormente que o defeito
existe porque não passou pela qualidade ou, ainda pior, descobrir que o problema
existe apenas quando o software já estiver em produção?
A resposta, claro, é muito óbvia: quanto mais cedo você descobrir que o pro-
blema existe, mais rápido e barato será para resolvê-lo. A mesma ideia é aplicada na Toyota para defeitos em carros.
Ao longo desta seção, estudaremos diversas técnicas e abordagens diferentes para
testes que, combinadas, podem ser úteis e importantes para o desenvolver software
com qualidade.
A pirâmide de testes, criada por Mike Cohn [20] é um modelo interessante que
além de defender que diferentes tipos de testes podem ser combinados, também su-
gere uma proporção dentre os diferentes tipos, como pode ser visto na figura 4.1:
68
Casa do Código
Capítulo 4. Entregando Valor
Figura 4.1: Pirâmide de Automação de Testes
Diferentes tipos de testes têm objetivos distintos e seu custo de automação e
tempo de execução também diferem.
Testes de Unidade, geralmente, são os mais rápidos se de automatizar e também
são rápidos de executar, por isso, eles estão na base da pirâmide e representam a
maior parte dos testes propostos pelo modelo.
Em seguida, temos os testes de integração (também chamados de testes de ser-
viço ou testes de API). Eles são mais completos e, geralmente, combinam diferentes
componentes que trabalham em conjunto para realizar em um determinado sistema.
São realizados diretamente na aplicação sem passar pela interface de usuário.
Em terceiro lugar, e no topo da pirâmide, temos os testes de ponta a ponta (tam-
bém chamados de interface de usuário, testes de sistema, ou testes de aceitação) que, como o nome sugere, testam a aplicação desde a interface do usuário, por isso são
os mais completos e, geralmente, são também os mais caros de se automatizar, e os
mais lentos para se executar.
É importante analisar os custos e benefícios de cada um dos tipos de testes pro-