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.