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.

testing-manifesto

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.

agile-testing-quadrant

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).

pyramid-testing

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

tdd

 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

bdd

 

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		 tdd-bdd

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:

tools-tests

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.

kpi-testes