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.

Quadrante Teste Agil

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 😉

2 Comentários »

Categorias deste post

Agile, Qualidade, Técnico, Time de desenvolvimento

O que é Agile Testing?

Primeiramente para entender Agile Testing temos que dar uma olhada no Manifesto Ágil
Em um grande resumo o manifesto coloca que temos entregas de valor em um curto espaço de tempo.

Muitas práticas são utilizadas por um time ágil referente a teste. Programadores utilizam TDD (Test Driven Development) para desenvolver código com uma maior qualidade. Com ele os programadores escrevem testes para um pequeno pedaço de uma funcionalidade no ciclo do TDD (falha na primeira vez, é refatorado até possuir o comportamento esperado. Sempre que é alterado ou melhorado passa por este processo).
Esta prática não é somente usada exclusivamente por equipes ágeis, mas como uma forma inteligente de pensar no design de software e agir de forma a prevenir os defeitos futuros.

Mas TDD não é teste. É uma maneira que temos de pensar no design do software e garantir que este, se alterado, continuará a funcionar. Se alguma inconsistência for encontrada frente a alguma modificação, facilmente com um conjunto de testes que asseguram o comportamento do software, podemos detectar e alterar/refatorar o ponto de inconsistência.

Alguns acham que TDD é aplicar Agile Testing, mas ele é muito mais que isso….

Times

Dentro de uma equipe ágil possuímos, basicamente, dois times:

Time do Cliente: todos que estão do lado do negócio no projeto (product owner, business experts, business analyts). Este time escreve histórias e funcionalidades que o time de desenvolvimento entrega.

Time de Desenvolvimento: todos que entregam código são parte integrante deste time, onde o papel de cada um por ser misto ou variado. Eles transformam todas as histórias do time do cliente em software.

Estes dois times trabalham próximos uma grande parte do tempo e se transformam em um único time com um objetivo em comum: entregar valor para a organização.

 

E o testador?

Falando do conceito de time para o Time do Cliente, os testadores são membros parciais do negócio, ajudando-os a descobrir requisitos e exemplos e também ajudando o time a expressar requisitos como testes.
Testadores também são parte do Time de Desenvolvimento advogando por qualidade à favor do cliente e ajudando o time a entregar o máximo de valor ao negócio.

Muitos times não possuem membros se intitulando testadores. Entretanto o time precisa de alguém que ajude o Time do Cliente a escrever histórias e características, a escrever testes para elas, garantir que elas estão atendendo as necessidades e, automatizar os testes de regressão (para termos um feedback rápido e contínuo sobre a qualidade/saúde do software).

O que é então Agile Testing?

Agile Testing é um conjunto de práticas, seguindo o Manifesto Ágil, que incorpora todas as técnicas de teste comumente utilizadas por profissionais de teste, tendo um grande foco em automação. A principal função é de criticar o produto, ou seja, constantemente garantir que o que está sendo especificado e desenvolvido realmente atende as necessidades do cliente e irá entregar valor ao negócio.

 

O que é um Testador Ágil?

Um Testador Ágil é aquele profissional que abraça as mudanças, colabora com pessoas técnicas e de negócio e entende o conceito de usar testes para documentar requisitos e guiar o desenvolvimento.
Ele tende a ter bons conhecimentos técnicos para colaborar com o time de desenvolvimento a automatizar os testes e também para explorar o sistema a procura de comportamentos, testes e problemas.

Ser um testador ágil está ligado muito mais a atitude e comportamento do que conhecimento técnico. Ele olha para o produto como um todo, com uma visão de usuário e/ou cliente, que é o fator mais importante. Assim ele consegue tanto interrogar o Time do Cliente quanto a requisitos e funcionalidades como guiar o desenvolvimento, através de testes, exemplos e ferramentas, para que o Time de Desenvolvimento tenha também a visão do valor que cada um destes itens tem para o produto final.

 

Sobre o autor:

Embora vários títulos já exercidos no mercado (Arquiteto de Teste, Engenheiro de Teste, Analista de Teste) Elias Nogueira é essencialmente um testador: alguém com uma grande curiosidade de como o software comporta através de diversas situações/contextos.

É consultor e instrutor em qualidade de software, blogueiro e palestrante já tendo trabalhado nas mais diferentes segmentos como bancos, telecos, governo, varejo, qualidade de dado e geoprocessamento. Elias também é instrutor associado na Adaptworks no curso de Agile Testing.
Acredita que a qualidade do software é dever de todos e, quando há um papel especifico para isso, que este deve saber sobre os dois mundos do desenvolvimento de software: técnico e negócio.

http://about.me/eliasnogueira
@eliasnogueira
http://sembugs.blogspot.com

4 Comentários »

Categorias deste post

Agile, Qualidade, Técnico, Time de desenvolvimento