Para metodologia ágil e o teste ágil – Parte 1 clique aqui

Métodos Ágeis de Teste:

Desenvolvimento Orientado por Comportamento (BDD) – Muitos já ouviram falar

• Desenvolvimento Orientado a Testes (TDD). Por exemplo, desenvolvedores utilizam TDD para escrever testes unitários antes da implementação do sistema, testando os componentes individualmente, o teste BDD é baseado no mesmo princípio, mas ao contrário dos testes unitários, o BDD visa testar elementos a nível de negócio. Ao invés de focar os testes em unidades técnicas como faz o TDD, o BDD atua sobre o requisito baseado no comportamento que o usuário espera do sistema. Testes de comportamento podem ser feitos a qualquer momento: antes, durante ou posterior ao desenvolvimento, no entanto o “desenvolvimento orientado por comportamento” ocorre quando os testes são escritos antes da codificação. Os testes BDD são criados em linguagem natural, a sintax Gherkin. Essa sintax foi criada especificamente para a descrição de comportamentos e por isso é tão adequada para descrever o negócio. Abaixo temos um exemplo:

1. Cenário: Paula quer fazer um saque no caixa automático. Dado que Paula tem 1000 reais em sua conta corrente e seu cartão é válido e o caixa automático tem dinheiro suficiente
2. Quando a correntista solicita 100 reais
3. Então o caixa automático deve prover 100 reais e o saldo da conta deve ser 900 reais e o cartão deve ser retornado ao correntista

Repare que no BDD o teste é segmentado em três partes distintas:

1. Contexto – Estado inicial Evento
2. O que o usuário faz Resultado
3. Resultado esperado do sistema

Especificações baseadas nessa abordagem guiam os desenvolvedores, testadores e donos de produto através das funcionalidades. Funções de teste são automatizadas para determinar completude e o refinamento de código é feito até que os resultados esperados sejam alcançados. O processo é parecido com a abordagem TDD exceto que no BDD todo o time participa (desenvolvedores, testadores e área de negócio). Vale ressaltar que os desenvolvedores fazem os ajustes visando não adicionar nenhuma funcionalidade extra.

• Desenvolvimento Orientados a Testes de Aceitação (ATDD) – Assim como o teste BDD, o desenvolvimento orientado a testes de aceitação (ATDD) também propõe que os testes sejam criados antes da codificação para que o código, uma vez escrito, passe pelos testes previamente elaborados. Diferentemente dos testes TDD visto mais acima, nos quais os testes são, tipicamente, testes de unidades técnicas , no ATDD os testes são de voltados a cumprir os critérios de aceitação dos usuários.

A ideia por trás do ATDD é de que a percepção do usuário em relação ao produto é tão importante quanto a percepção de funcionalidade e esse entendimento deve ser a força motriz para a realização e adoção do produto. Para concretizar essa ideia, o ATDD coleta input dos clientes/usuários, utiliza esse input para desenvolver critérios de aceitação, traduz esses critérios em testes de aceitação manuais ou automatizados, para depois, desenvolver código que confronte esses testes. Como o TDD e o BDD, o desenvolvimento orientado a testes de aceitação ou ATDD, é uma metodologia orientada a teste e não orientada a requisitos.

Assim como as metodologias TDD e BDD a metodologia ATDD diminui os riscos de que os desenvolvedores tenham de interpretar como produto será utilizado e vai além, pois busca na origem (usuário) como deve ser o produto, minimizando a necessidade de redesenhar as funcionalidades em nova release.

• Teste Exploratório – O teste exploratório é essencialmente um tipo de teste funcional também relevante para execução em ambientes ágeis. É um importante tipo de teste no qual os testadores perpassam pelo código fonte para testar organizadamente de forma “caótica”. Nessa abordagem, testadores não seguem sequencias determinadas de teste, mas sim utilizam o software visando “quebrar ou derrubar” o aplicativo. Testadores documentam os defeitos normalmente, mas nem sempre detalha o quê ou como a aplicação foi testada.

O teste exploratório não é orientado a scripts, mas sim busca desenvolver testes que melhor se encaixem a cada tipo ou particularidade de aplicação. Por não seguir uma abordagem movida a scripts, o teste exploratório comumente simula como o usuário interagiria com o software na realidade.

Usualmente, o teste exploratório segue quatro princípios chave básicos:

• Planejamento de teste paralelo, test design e execução,
• Específico, porém flexível,
• Alinhado para investigar oportunidades em potencial e
• Troca de conhecimento.

O teste exploratório faz uso de abordagem investigativa, de pensamento crítico e de aprendizado contínuo.

• Teste Baseado em Sessão – O teste baseado em sessão utiliza elementos do teste exploratório, porém é mais estruturado. Nele o teste é conduzido durante períodos de tempo pré-determinados em sessões ininterruptas e com propósito é pré-definido.

Cada uma das sessões de teste deve ser adequadamente reportada. Nos testes baseado em sessão, assim como nos testes exploratórios, a simulação da experiência do usuário e o uso da criatividade são mantidos.

As sessões de teste são finalizadas com uma espécie de checklist que cobre as seguintes questões: O que aconteceu? (passado), o que foi alcançado? (resultados), houveram impedimentos? (obstáculos), o que ainda precisa ser feito? (perspectivas) e o qual a percepção do testador? (pensamentos)

Continuação da síntese de um dos artigos de 2017 da vice-presidente de estratégia de produto da QASymphony, Elise Carmichael – “Metologia Ágil: O Guia Completo para entender o Teste Ágil” publicado no QASymphonyBlog (https://www.qasymphony.com/blog/).