O “Quadrante Mágico” dos testes.

Uma ferramenta muito boa para apoiar/direcionar o time de testes ágeis é o “quadrante dos testes ágeis”.

A exemplo dos modelos tradicionais de testes, o modelo ágil possui técnicas e “práticas” a serem adotadas pelos times de testes ágeis. É fundamental salientar que uma das características de times ágeis, é o grau de maturidade, mas muitas vezes os princípios ágeis são confundidos com “não seguir métodos e práticas”. Mas isto é assunto para outro momento.

Antes de falarmos do “ágil“, é necessário resgatar o “tradicional“.

Conceituação no modelo tradicional

No modelo tradicional temos duas abordagens na qualidade de software Verificação e Validação, além da separação clara de papéis e responsabilidades. Enquanto parte dos profissionais de análise de sistemas, arquitetura e gestão trabalham no desenvolvimento dos requisitos e software, o testador cria um conjunto artefatos de testes (plano de testes, casos de testes, checklists, etc.) para verificar a aderência do software em relação aos requisitos, e a relação dos requisitos em relação ao solicitado pelo cliente.

O Modelo V é um modelo conceitual de Engenharia de Sistemas/Desenvolvimento de Produto visto como melhoria ao problema de reatividade do modelo cascata. Ele permite que, durante a integração de um sistema em seus diversos níveis, os testes sejam feitos contra os próprios requisitos do componente/interface que está sendo testado, em contraste com modelos anteriores onde o componente era testado contra a especificação do componente/interface.

No momento que um grupo de requisitos/funcionalidades estão aptas a serem 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, ou seja, o momento do testador encontrar defeitos na aplicação, ou como alguns gostam de dizer “quebrar a aplicação”.

E como isso funciona dentro do Ágil?

O Quadrante de Teste Ágil

A ideia é compartilhar uma ferramenta/prática para testes ágeis em projetos ou manutenções de aplicações.

O Quadrante de Teste Ágil foi criado por Brian Marick que 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.

Quadrante Teste Agil

Este quadrante é dividido em quatro partes e reflete diferentes objetivos de testes. Nele já uma matriz dividindo testes que suportam o time e criticam o produto, e divididos em foco no negócio ou foco em tecnologia.

É importante salientar 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.

Anúncios
Sobre

Engajado, responsável e colaborativo! MBA em Gerênciamento de Projetos! Algumas certificações: PSC, CSM, CTAL-TM, Empreendedor, Desing Thinking e Lean Startups. Mais de 15 anos atuando com Qualidade de Software, Governança de TI (Processos e Contratos) e Gerenciamento de Projetos e Transformação Ágil.

Publicado em Qualidade de Software

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Digite seu endereço de email para acompanhar esse blog e receber notificações de novos posts por email.

Junte-se a 516 outros seguidores

Follow Rodrigo Murari Severo on WordPress.com
Blogs que sigo
Samuel Lucas

Experiências e aprendizados

Márcio Habigzang Brufatto

Desenvolvedor, Palestrante e Aprendiz

Rodrigo Murari Severo

Entrega é Eficiência, Qualidade é Eficácia...

Jorge Horácio "Kotick" Audy

Compartilhar Agile, dia-a-dia no ambiente selvagem da Savana SCRUM

Samuel Lucas

Experiências e aprendizados

Márcio Habigzang Brufatto

Desenvolvedor, Palestrante e Aprendiz

Rodrigo Murari Severo

Entrega é Eficiência, Qualidade é Eficácia...

Jorge Horácio "Kotick" Audy

Compartilhar Agile, dia-a-dia no ambiente selvagem da Savana SCRUM

%d blogueiros gostam disto: