Introdução do Quadrante de Teste Ágil

Uma pergunta muito comum, quase sempre vinda de um profissional de testes, dento da linha ágil é: como vou testar no Scrum?
Essa pergunta geralmente é feita por falta de conhecimento em agilidade, e a resposta é que não existe fórmulas, padrões ou receitas de bolo de testar utilizando Scrum , XP, Kaban ou qualquer prática ágil para desenvolver um software.

Muitos tem sede de ter um processo, uma fórmula para trabalhar com testes em agilidade, mas isso é mais fácil do que imaginamos…
Mas antes vamos conceituar um pouco o porque disso.

Conceituação no modelo tradicional

No modelo que podemos chamar de tradicional temos duas abordagens distintas com algumas dimensões, além de separação clara de papéis e atividades. Enquanto parte dos profissionais de análise de negócio, arquitetura e gestão trabalhavam no desenvolvimento dos requisitos, o testador criava uma série de documentos para verificar se os requisitos estavam de acordo com o que foi pedido, mas muita coisa era perdida e o foco era (ou ainda é em algumas empresas) em pesadas documentações e checklists.
O Modelo V de Testes foi um guia por muito tempo neste ponto, trazendo quatro níveis e chamando estas etapas de Verificação: requisitos, análise, arquitetura e codificação (este compartilhado com o próximo grupo de nível).
Neste ponto os testadores também criavam os casos de teste, quando o time já estava na fase “codificação”

Quando chegava a fase em que um grupo de funcionalidades já estava apta a ser testada entramos na fase de validação, que consiste nos níveis: unidade, integração, teste a aceitação. Neste ponto começam os testes como conhecemos no modelo tradicional.

O Modelo V de testes foi utilizado por muitos como um guia para entender estes níveis e o que poderíamos fazer em cada um, e esta é a forma correta de utilizá-lo, mas remetendo sempre a termos testes no final do processo.

E como isso funciona dentro do Ágil?

O Quadrante de Teste Ágil

Já sabemos pelo post anterior o que é Agile Testing. Agora iremos aprender qual o guia que temos quando utilizamos práticas ágeis no projeto e queremos aplicar alguma abordagem ou técnica de teste.

O Quadrante de Teste Ágil foi criado por Brian Marick que introduziu uma série de termos para diferentes categorias de teste para alcançar diferentes propósitos através de um diagrama.

Este diagrama, dividido em quatro quadrantes reflete diferentes razões de teste. Nele já uma matriz dividindo testes que suportam o time e criticam o produto, que é dividido em foco no negócio ou foco em tecnologia.

Vale lembra desde agora que o quadrante é um guia, e não um processo!

Testes que suportam o time

Podemos dizer que os testes que suportam o time são os que ajudam os desenvolvedores, não somente testers, enquanto o produto é desenvolvido. Estes testes são mais voltados a qualidade e entendimento dos requisitos e arquitetura do que em testes como conhecemos de forma funcional.

Quadrante 1

Representa, basicamente, a principal prática de desenvolvimento ágil:  TDD – Test Driven Development.
Dentro deste quadrante temos duas práticas: teste de unidade, que valida uma pequena parte da aplicação como objetos e/ou métodos, e testes de componente que valida partes maiores da aplicação como um grupo de classes que provê o mesmo serviço. São usualmente desenvolvidos com ferramentas xUnit e medem a qualidade interna do produto.
Ao utilizar a técnica de TDD o programador pode desenvolver uma funcionalidade sem se preocupar em posteriormente alterar qualquer parte da aplicação, ajudando assim a tomar melhor decisões de arquitetura e design.
Não são destinados ao cliente, pois o cliente não irá entender os aspectos internos do desenvolvimento e não devem ser negociáveis com o cliente, pois a qualidade do código deve sempre existir e não ser negligenciada. Os testes desenvolvidos usualmente executados dentro de uma abordagem de Integração Contínua para prover um rápido feedback da qualidade do código.

Quadrante 2

Este quadrante também suporta o time de desenvolvimento, continua guiando o desenvolvimento, mas de uma maneira mais alto-nível focando mais em testes que o cliente entenda, onde este define a qualidade externa de que ele precisa.
Aqui o cliente define exemplos que serão usados para um entendimento maior do funcionamento da aplicação, e são escritos de forma com que o cliente ou papéis ligados a negócio entendam. Todo o teste executado aqui tem um foco no funcionamento do produto e alguns deles podem até mesmo ter uma pequena duplicação com alguns testes criados no Quadrante 1.
Testes testes focados no negócio também podem ser automatizados e, usualmente, a técnica de BDD – Behavior Driven Development é utilizada na escrita e execução automatizada destes exemplos.

Neste quadrante também podemos utilizar de pessoas com conhecimentos em UX para que, através de mockups e wireframes, o cliente possa validar a interface gráfica antes que o time comece a desenvolver esta camada.

Testes que criticam o produto

O termo “criticam” aqui não é apenas de forma destrutiva, mas também relacionados a melhoria. O foco é saber como iremos aprender a melhorar o produto, escrevendo, se necessário, mais critérios e exemplos.

Quadrante 3

As vezes mesmo criando diversos mecanismos para assegurar que estamos atendendo a necessidade do cliente através de critérios e/ou exemplos, pode acontecer de não atendermos realmente aquele desejo, ou mesmo o teste unitário e o teste através do BDD podem não ter um real valor.
Neste quadrante iremos realmente criticar o produto e executa-lo como um usuário real usando nosso conhecimento e intuição na utilização da aplicação. O cliente pode executar este tipo de tarefa, usualmente chamada de UAT – User Acceptance Testing, dando um feedback mais preciso, aceitando a funcionalidade, analisando possíveis novas funcionalidades. Esta ação pode ser também um dos critérios de DoD – Definition of Done de uma funcionalidade.
O ponto central deste quadrante, além do UAT, são os testes exploratórios. Utilizando esta técnica qualquer membro do time é capaz de, simultaneamente, aprender sobre a aplicação e executar mais testes, usando o feedback do último teste para a execução dos próximos e também é capaz de extrair novos critérios, sempre observando o comportamento da aplicação.

Quadrante 4

Os testes neste quadrante são os mais técnicos e criticam o produto em termos de performance, carga e segurança.
Nos dias de hoje negligenciar aspectos como performance podem tirar a vantagem competitiva de um cliente. Geralmente já conhecemos aspectos relacionados a performance e segurança quando refinamos algumas User Stories.
As técnicas aplicadas a performance, carga e segurança vão desde os níveis mais baixos (como um profiling de código) como a utilização de ferramentas que simulam diversos usuários simultaneamente.

Bom, agora você já sabe, conceitualmente, um pouco deste guia para iniciarmos atividades de teste de software dentro de uma equipe ágil. Vale ressaltar que todas as técnicas de teste e abordagens podem ser utilizadas, pois o quadrante é um guia e não um padrão 😉