Assim como o Manifesto Ágil que declara valores e princípios essenciais para o desenvolvimento de aplicações e o ciclo de vida ágil, The Testing Manifesto é o manifesto voltado a práticas de testes durante o ciclo de vida, propondo alguns valores a todo o time (e não somente a testers):
- Testing throughout OVER testing at the end: o retrabalho aumenta exponencialmente quando tentamos corrigir bugs posteriormente em qualquer ciclo de vida. É por isso que testamos desde o início e frequentemente.
- Preventing bugs OVER finding bugs: “built-in quality”. O foco é criar aplicações com qualidade desde o início, pensando no sistema em produção e manutenção.
- Testing understanding OVER checking functionality: o senso de propriedade compartilhada resulta em maior qualidade. Precisamos checar o entendimento do time no que está sendo construído. O pair programming, code reviews, entre outros, podem ajudar a coletar feedbacks.
- Building the system OVER breaking the system: o “built-in quality” é uma abordagem proativa e através de CI/CD, testes automatizados, monitoramento inteligente, etc. tornamos a qualidade integrada mais alcançável.
- Team responsibility for quality OVER tester responsibility: o time é responsável pela qualidade do produto que está sendo criado.
A cultura de testes é imprescindível para o time para alcançar a qualidade integrada. Além das práticas de desenvolvimento orientado a testes (que será abordado mais adiante neste artigo), algumas intersecções entre o The Testing Manifesto e o ciclo de vida ágil podem ser observados:
- Iterative cycles and incremental: os times trabalham com ciclos iterativos e incrementais, o que previne testar o sistema somente no fim e consequentemente encontrar os bugs na fase final.
- Testing in all development process: desde a criação de um Work Item (descrevendo os planos de testes associados e critérios de aceitação), as práticas de desenvolvimento orientado a testes (TDD), entre outros, garantem o time em alinhamento com o que está sendo construído desde o início.
- Cross functional teams / Squads: a responsabilidade é de todos pela qualidade e não somente QA.
Agile Testing Quadrants
O Agile Testing Quadrants exibe a visão em quatro quadrantes dos testes durante todo o ciclo de desenvolvimento. Enquanto os dois quadrantes abaixo são relacionados a technology facing por não ter interação com o usuário (interface), os dois quadrantes acima são business facing, pois há interação do usuário. Também há a representação de cada quadrante se os testes são manuais, automáticos ou ferramentas.
- Quadrante 1 (Q1): TDD (Test Driven Development) é a principal técnica. Não é visível aos usuários. Geralmente está no processo de CI (Continuous Integration). Também inclui qualidade de código (SonarQube, etc.)
- Quadrante 2 (Q2): BDD (Behavior Driven Development) é a principal técnica. Está mais relacionado a qualidade externa da aplicação e está visível aos usuários. Também inclui testes funcionais automatizados (serviços, API e webservices) e record playback.
- Quadrante 3 (Q3): assegura que as necessidades do usuário foram atingidas, por exemplo com UAT (user acceptance testing), testes exploratório e de usabilidade. O usuário é envolvido na execução.
- Quadrante 4 (Q4): avaliação técnica. Sugere a execução dos testes de segurança, carga e performance.
Symbio Test Automation
Na comparação entre o ciclo tradicional (find bugs) e ágil (prevent bugs), podemos ver que enquanto os testes unitários representam a maior parte do esforço em ciclos ágeis, os testes manuais em UI (User Interface) compreendem o maior esforço em ciclos tradicionais. Segundo o Symbio Test Automation, cerca de 70% dos testes são unitários, 20% correspondem a testes de API, Integrações e Componente, e por fim 10% são dedicados a testes GUI (graphical user interface).
TDD x BDD
Vemos no quadro abaixo uma comparação bem resumida de TDD – prática de escrever os testes antes do desenvolvimento e BDD que especifica os cenários de funcionamento para a aplicação e os testes são desenvolvidos com base nesses cenários.
TDD (Test Driven Development)
|
BDD (Behavior Driven Development)
|
TDD 1. Escrevemos um Teste que inicialmente não passa (Red) 2. Adicionamos uma nova funcionalidade do sistema 3. Fazemos o Teste passar (Green) 4. Refatoramos o código da nova funcionalidade (Refactoring) 5. Escrevemos o próximo Teste |
![]() |
Ferramentas
Após toda a explicação teórica (acima) e compreensão da aplicabilidade dos testes durante o ciclo de vida do desenvolvimento, vale discutir com sua equipe o planejamento das ferramentas que serão utilizadas na organização. Abaixo, compartilho uma visão de onde pode ser utilizada cada tipo de ferramenta:
KPIs
E por fim, como podemos acompanhar o resultado dos testes durante as iterações? Veja que o Dashboard abaixo apresenta alguns KPIs como code coverage (cobertura de teste unitário na aplicação) e test results (em relação aos planos de teste).
Como explicado na figura dos quadrantes (acima neste post), os testes devem ocorrer desde o início do ciclo de vida, por exemplo, criando e validando os testes unitários no processo de CI. As releases podem ser validadas pelos usuários após serem promovidas (a um ambiente de homolog por exemplo). A execução dos testes de segurança, carga e performance acontecem por sugestão no ambiente de QA.