Olá pessoal!
Hoje vamos conhecer uma ferramenta que pode ajudar os times de testes ágeis durante projetos ou manutenções de aplicações.
Primeiramente, vamos entender a diferença entre os modelos 'tradicional' e 'ágil'.
No modelo tradicional os testes são realizados ao final da versão, onde somente ao final de todo o projeto é que os analistas de teste irão conhecer o produto final e irão estudar os requisitos a partir das especificações. Nesse modelo caso o analista de teste encontre um problema no software, a demanda retornará para todo o fluxo e, consequentemente, impactará no prazo de entrega final, aumentando-se o custo do projeto.
No modelo ágil os testes estão focados no negócio, onde os testes serão realizados ao longo do ciclo de vida do projeto, durante todas as fases. Os analistas de teste terão um papel mais dinâmico
e crítico dentro do projeto, podendo contribuir ativamente na qualidade do produto, pois eles terão uma visão de todo o projeto.
Sendo assim, o Quadrante de Teste Ágil, criado por Brian Marick, sugeriu uma série de técnicas de testes para diferentes categorias e com objetivo de alcançar diferentes propósitos através de um quadrante. É importante enfatizar que o quadrante é um guia e não um processo.
TESTES QUE SUPORTAM O TIME
São os testes que suportam o time e ajudam os desenvolvedores, não somente os testadores, 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. Validam a qualidade interna do código fonte.
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/deseja.
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 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 de cenários.
Neste quadrante também podemos utilizar de pessoas com conhecimentos em UX (User Experience) 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 de aceite 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 valor real.
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, explorar 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/negócio. 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 uma inspeção de código) como a utilização de ferramentas que simulam diversos usuários simultaneamente ou transações por segundos.
O quadrante visa apoiar os times de testes ágeis como um guia. É fundamental o entendimento do time e principalmente a capacidade técnica de “perceber” quais técnicas e práticas serão adotadas durante o desenvolvimento/testes da aplicação, sempre buscando agregar valor a aplicação/entrega, e principalmente atender a expectativa do cliente.
Fonte: https://quaslati.wordpress.com/2015/11/05/o-quadrante-magico-dos-testes/
Até mais!
