Menu

Como os testadores estão envolvidos nas técnicas de TDD, BDD e ATDD

how testers are involved tdd

Experimente Nosso Instrumento Para Eliminar Problemas

Visão geral das técnicas TDD, BDD e ATDD:

TDD, BDD e ATDD são os termos que revolucionaram o mundo do testador em Agile e também ganharam impulso. Mudança na mentalidade dos testadores também requer aprender novas habilidades e, mais importante, mudar a atitude e a maneira de trabalhar.

Ao contrário de trabalhar isoladamente, os testadores precisam colaborar e trabalhar em conjunto com os programadores, o que significa

  • Compartilhando os casos de teste
  • Participar da redação dos critérios de aceitação das histórias
  • Fornecendo feedback contínuo para as partes interessadas
  • Colaborando para resolver os defeitos no prazo.
  • Fornecer sugestões e contribuições para melhorar a qualidade dos resultados
  • Automação

Testadores envolvidos no Agile

Antes de entrar na discussão sobre o envolvimento de um testador nessas práticas, vamos primeiro tentar entender os conceitos por trás desses termos:

O que você aprenderá:

Desenvolvimento Orientado a Testes

Considere a abordagem tradicional de desenvolvimento de software onde o código é escrito primeiro e depois testado. O desenvolvimento orientado a testes ou TDD é uma abordagem que é exatamente o REVERSO do desenvolvimento tradicional. Nessa abordagem, o teste é feito primeiro e, em seguida, o código é escrito.

Confuso?!!

Como testar um software que ainda não foi desenvolvido?

Sim!! Isso é desenvolvimento orientado a testes ou TDD.

O TDD funciona em pequenos incrementos onde:

  • O teste é escrito primeiro
  • O teste é executado - que irá falhar (por razões óbvias)
  • O código é escrito (ou refatorado) apenas para fazer o caso de teste passar
  • O teste é executado novamente
  • Se o teste for bem-sucedido, passe para o próximo teste ELSE reescreva / modifique o código para fazer o teste passar

Deixe-me tentar explicar por meio de um fluxograma:

Fluxograma TDD

Agora, temos que entender o fato de que TDD não fala sobre os testes que os testadores fazem. Em vez disso, essa abordagem realmente fala sobre os testes que os programadores fazem.

Sim!! Você adivinhou certo !! É o teste de unidade.

O teste que é escrito primeiro não é o teste que os testadores escrevem, mas é o teste de unidade que os programadores escrevem. Então, eu reformularia as etapas como:

  • O teste UNIT é escrito primeiro
  • O teste UNIT é executado - que irá falhar (por razões óbvias)
  • O código é escrito (ou refatorado) apenas para fazer o teste passar
  • O teste UNIT é executado novamente
  • Se o teste for aprovado, vá para o próximo teste ELSE reescrever / modificar o código para fazer o teste passar

Agora, a questão que se coloca aqui é - se TDD é trabalho de um programador, qual é o papel do testador nesta abordagem?

Bem, tendo dito que TDD é trabalho de um programador, isso não significa que os testadores não estejam envolvidos nele. Os testadores podem colaborar compartilhando os cenários de teste que consistem em:

O que quero dizer é - os testadores devem participar na definição dos cenários de teste de unidade e colaborar com os programadores para implementá-los. Os testadores devem fornecer seus comentários sobre os resultados do teste.

Se quisermos implementar TDD, os testadores precisam atualizar seus conjuntos de habilidades. Eles precisam ser mais técnicos e se concentrar em melhorar suas habilidades analíticas e lógicas.

Os testadores também devem se esforçar para entender o jargão técnico que os programadores usam e, se possível, devem ter uma visão geral do código. De forma semelhante, os programadores têm que entrar no lugar do testador e tentar criar cenários mais sofisticados que tornarão o teste de unidade mais robusto e sólido.

Tanto os programadores quanto os testadores precisam se colocar no lugar uns dos outros, ao contrário da velha abordagem tradicional em que os programadores não davam muito peso aos testes de unidade porque confiavam nos testadores para encontrar bugs e defeitos, e os testadores não queriam se dar ao luxo em aprender as coisas técnicas porque pensam que seu trabalho termina depois de encontrar os defeitos.

Desenvolvimento baseado em comportamento

O Behavior Driven Development ou BDD é uma extensão do Test Driven Development.

O BDD, como o nome sugere, ilustra os métodos de desenvolvimento de um recurso com base em seu comportamento. O comportamento é explicado basicamente em termos de exemplos em uma linguagem muito simples que pode ser entendida por todos da equipe que são responsáveis ​​pelo desenvolvimento.

Alguns dos principais recursos do BDD são os seguintes:

  • A linguagem usada para definir o comportamento é muito simples e em um único formato no qual pode ser entendido por todos - técnicos e não técnicos envolvidos na implementação
  • Fornece uma plataforma que permite aos três amigos (programador, testador e PO / BA) colaborar e entender o requisito. Determina um modelo comum para documentá-lo
  • Esta técnica / abordagem discute o comportamento final do sistema ou como o sistema deve se comportar e NÃO fala sobre como o sistema deve ser projetado ou implementado
  • Enfatiza os dois aspectos da qualidade:
    • Conheça o requerimento
    • Apto para uso

Por que BDD?

Bem, sabemos que consertar um defeito / erro no estágio posterior de qualquer ciclo de desenvolvimento é bastante caro. A correção dos defeitos de produção não afeta apenas o código, mas também o design e seus requisitos. Quando fazemos o RCA (análise de causa raiz) de qualquer defeito, na maioria das vezes, concluímos que o defeito realmente se resume a requisitos mal compreendidos.

Basicamente, isso ocorre porque todos têm aptidões diferentes para entender os requisitos. Assim, técnicos e não técnicos podem interpretar o mesmo requisito de forma diferente, o que pode levar a uma entrega incorreta. Portanto, é fundamental que todos na equipe de desenvolvimento entendam o MESMO requisito e o interpretem da MESMA maneira.

Precisamos ter certeza de que todos os esforços de desenvolvimento são direcionados e focados no cumprimento dos requisitos. Para evitar qualquer tipo de defeito de “falha de requisito”, toda a equipe de desenvolvimento deve alinhá-los para entender o requisito que é adequado para uso.

A abordagem BDD permite que a equipe de desenvolvimento faça isso: -

  • Definição de uma abordagem padrão para definir o requisito em inglês simples
  • Fornecimento de exemplos de definição que explicam os requisitos
  • Fornece uma interface / plataforma que permite aos técnicos (programadores / testadores) e não técnicos (PO / BA / Cliente) colaborar e se reunir e estar na mesma página para compreender e implementar os requisitos

Como implementar o BDD?

Existem muitas ferramentas disponíveis no mercado para a implementação de BDD. Estou citando alguns aqui:

  • Pepino
  • Ginástica
  • Concordion
  • JBehave
  • Spec Flow

Exemplo:

Vamos tentar entender o BDD com um exemplo. No meu caso, estou usando pepino (pepino):

Considere um caso simples em que queremos permitir que apenas usuários autenticados entrem no site XYZ.

O arquivo Gherkin (arquivo de recurso) seria o seguinte:

Recurso: Portal de registro de teste

Esboço do cenário: Usuário válido conectado

Dado: O cliente abre o portal de registro

Quando: o usuário insere o nome de usuário como “” e a senha como “”

Então: o cliente deve ser capaz de visualizar o formulário.

Exemplos :

| usuário | senha |

| user1 | pwd1 |

| user2 | pwd2 |

Podemos ver como um determinado requisito é documentado usando um inglês simples. Os três amigos podem trabalhar juntos para projetar os arquivos de recursos e dados de teste específicos podem ser documentados na seção de exemplo. O BDD fornece um meio para reunir programadores, testadores e negócios em uma mesa e estabelecer um entendimento comum dos recursos a serem implementados.

A abordagem BDD economiza esforços e custos e verifica se há algum defeito após a implantação da produção, visto que a colaboração dos clientes e desenvolvedores foi durante todo o ciclo de desenvolvimento do recurso.

As equipes de desenvolvimento podem utilizar esses arquivos de recursos e convertê-los em programas executáveis ​​para testar um determinado recurso.

Quão?

Bem, você precisa aprender Pepino / Fitnesse para isso !!

Desenvolvimento baseado em teste de aceitação

Aceitação Test Driven Development ou ATDD é uma técnica onde toda a equipe colabora para definir os critérios de aceitação de um épico / história antes que a implementação realmente comece. Esses testes de aceitação são suportados por exemplos adequados e outras informações necessárias.

Na maioria das vezes, BDD e ATDD são usados ​​alternadamente. A abordagem ATDD também pode ser implementada usando o formato Dado-Quando-Então, assim como escrevemos recursos na abordagem BDD.

Vamos tentar resumir rapidamente as diferenças entre as 3 abordagens:

  • O TDD é mais técnico e escrito na mesma linguagem em que o recurso foi implementado. Se o recurso for implementado em Java, escrevemos JUnit casos de teste . Considerando que BDD e ATDD são escritos em inglês simples
  • A abordagem TDD se concentra na implementação de um recurso. Enquanto o BDD se concentra no comportamento do recurso e o ATDD se concentra na captura dos requisitos
  • Para implementar o TDD, precisamos ter conhecimento técnico. Considerando que BDD e ATDD não requerem nenhum conhecimento técnico. A beleza do BDD / ATDD está no fato de que tanto técnicos, quanto não técnicos, podem participar do desenvolvimento do recurso
  • Como o TDD é evoluído, ele dá margem para um bom design e se concentra no aspecto de qualidade de “Atendimento aos Requisitos”; enquanto o BDD / ATDD se concentra no 2WLaspecto da qualidade que é “apto para uso”

Todas essas técnicas falam basicamente sobre a abordagem “teste primeiro”, ao contrário da abordagem “teste último” usada nas metodologias de desenvolvimento tradicionais.

Como os testes são escritos primeiro, os testadores desempenham um papel muito importante. Os testadores não precisam apenas ter um vasto domínio e conhecimento de negócios, mas também devem possuir boas habilidades técnicas para que possam agregar valor ao brainstorming durante as discussões do 3 amigos.

Com os conceitos de CI (Integração Contínua) e CD (Entrega Contínua), os testadores precisam colaborar bem com os programadores e contribuir igualmente para a área de desenvolvimento e operações.

como abrir arquivos .jnlp no Windows 10

Deixe-me resumir esta discussão com a famosa Test Pyramid in Agile:

Pirâmide de teste em Agile

A camada mais baixa dessa pirâmide é composta pela camada de teste de unidade. Esta camada é a camada de base; portanto, é imperioso que esta camada seja sólida como uma rocha. A maioria dos testes deve ser inserida nessa camada. Esta camada mais baixa concentra-se apenas em TDD.

No Ágil mundo, a ênfase é colocada em tornar esta camada da pirâmide mais forte e robusta e é enfatizado que a maioria dos testes é realizada nesta camada.

As ferramentas usadas nesta camada de uma pirâmide são todas as ferramentas Xunit.

A camada intermediária da pirâmide é a camada de serviço, explicando os testes de nível de serviço. Essa camada atua como uma ponte entre a interface de usuário do aplicativo e a unidade / componente de nível inferior. Essa camada é composta principalmente de APIs que aceitam solicitações da IU e enviam de volta a resposta. A abordagem BDD e TTDD é ativa nesta camada da pirâmide.

As ferramentas usadas na camada intermediária da pirâmide são - Fitnesse, Cucumber e Robot Framework .

A camada superior da pirâmide é a IU real, o que mostra que essa camada deve conter o menor número de testes, ou, devo dizer, o esforço de teste nessa camada específica deve ser mínimo. A maioria dos testes do recurso deve ter sido concluída quando alcançamos a camada superior da pirâmide.

As ferramentas usadas na camada superior são - Selênio , QTP e RFT.

Uma vez que trabalhamos em pequenos incrementos em Scrum (chamados Sprints), a implementação manual de todas essas abordagens não é viável. Essas abordagens requerem intervenção automatizada. A automação, neste caso, é muito crítica.

Na verdade, essas abordagens são executadas por meio da automação. Ao final de cada sprint, novos recursos são adicionados, por isso é importante que o recurso implementado anteriormente funcione conforme o esperado; conseqüentemente, Automação torna-se o HERÓI aqui.

Conclusão

Ao final do artigo, você deve ter aprendido sobre como os testadores estão envolvidos nas técnicas de TDD, BDD e ATDD.

Na terceira parte da série, focalizarei minha discussão sobre automação em um mundo Agile.

Sobre o autor: Este artigo é do autor do STH Shilpa. Ela trabalha na área de teste de software há mais de 10 anos em áreas como publicidade na Internet, banco de investimento e telecomunicações.

Continue observando este espaço para muito mais atualizações.

Leitura recomendada

^