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) Tests are written before the code Improve code design Created to work with unit test Executed in CI process Facilitates regression Refactoring mitigates risk Red – Green – Refactor

BDD (Behavior Driven Development) TDD Derivation Support the questions: Where to start? What to test and what not to test? What to test at each step? Helps understanding why a test fails Ubiquitous language and live documentation.  Understanding the requirements

 

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.