0% acharam este documento útil (0 voto)
6 visualizações3 páginas

Casos de Testes No Formato BDD

O documento aborda a técnica BDD (Behavior Driven Development), que facilita a comunicação entre membros da equipe através de uma linguagem comum. Ele descreve a estrutura Dado-Quando-Então para escrever casos de teste, ilustrando com exemplos de login válidos e inválidos. Além disso, lista validações essenciais que os sistemas devem atender durante os testes.

Enviado por

marivalen1108
Direitos autorais
© All Rights Reserved
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato PDF, TXT ou leia on-line no Scribd
0% acharam este documento útil (0 voto)
6 visualizações3 páginas

Casos de Testes No Formato BDD

O documento aborda a técnica BDD (Behavior Driven Development), que facilita a comunicação entre membros da equipe através de uma linguagem comum. Ele descreve a estrutura Dado-Quando-Então para escrever casos de teste, ilustrando com exemplos de login válidos e inválidos. Além disso, lista validações essenciais que os sistemas devem atender durante os testes.

Enviado por

marivalen1108
Direitos autorais
© All Rights Reserved
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato PDF, TXT ou leia on-line no Scribd

Casos de Testes no formato BDD

BDD (Behavior Driven Development) criado por Dan North, em 2003, é uma técnica
utilizada para integrar regras de negócios e linguagem de programação,
caracterizando-se por um vocabulário bem específico e pequeno, que minimiza as
dificuldades de comunicação e possibilita todos os membros do time utilizarem uma
mesma linguagem para realizar o trabalho.

Como escrever casos de teste em BDD?

Ao escrever um cenário em BDD é quase regra que deve-se utilizar uma estrutura
conhecida como Dado-Quando-Então ou em inglês Given-When-Then, ao se valer
desta estrutura de escrita os cenários ficarão bem claros, com um principio, uma
ação e um resultado.

Veja como estas palavras chaves devem ser utilizadas:

●​ Dado: Define as pré-condições verdadeiras para executar o seu teste


●​ Quando: Define a ação que será executada
●​ Então: Seguindo a ação descrita no QUANDO define o resultado esperado
para o seu teste
●​ E: adiciona uma sentença positiva no Dado, no Quando ou no Então.

Exemplo:​
Cenário 1: Login com credenciais válidas

Dado que o usuário está na página de login quando o usuário insere o e-mail
"usuario@[Link]" e a senha "123456" e clica no botão "Entrar" então o sistema
deve redirecionar o usuário para o dashboard e exibir a mensagem "Bem-vindo!"

Cenário 1: Login com credenciais inválidas

Dado que o usuário está na página de login quando o usuário insere o e-mail
"usuario@[Link]" errado e/ou a senha errada e clica no botão "Entrar" então o
sistema deve emitir uma mensagem de alerta: “ Usuário ou senha inválidos” e não
fazer o login até que o usuário digite corretamente e-mail e senha válidos.
Ao escrever um caso de teste, o analista de qualidade deve se atentar para as
seguintes validações que o sistema precisa atender:

●​ Todos os campos obrigatórios precisam ser validados;


●​ Erros precisam ser retornados em um formato padronizado;
●​ Dados inválidos precisam retornar o status HTTP adequado;
●​ Verificar permissões adequadas;
●​ A resposta precisa ser entregue dentro de um tempo aceitável (ex.: menos de
500ms para a maioria dos casos);
●​ Os endpoints precisam seguir os padrões RESTful (se aplicável), incluindo:
Uso correto de métodos HTTP (GET, POST, PUT, DELETE);
●​ Uso adequado de códigos de status HTTP (ex.: 200, 201, 404, 500);URLs e
nomes de parâmetros precisam ser consistentes e descritivos;
●​ Todos os endpoints precisam estar documentados. A documentação de API
precisa incluir exemplos de requisições e respostas;
●​ Para toda história precisa ter testes unitários;
●​ As telas precisam ser responsivas.
●​ Testar nos browsers: Chrome, Firefox, Edge.

Você também pode gostar