Tipos de Testes
Durante o desenvolvimento de software, existem diferentes tipos de testes que ajudam a garantir a qualidade do sistema. Na Comp Júnior, você utilizará principalmente os testes abaixo no dia a dia.
Teste Funcional
Os Testes Funcionais são uma técnica de teste de “caixa-preta” que foca em validar o que o sistema faz, comparando o comportamento real da aplicação com os requisitos de negócio esperados.
Em vez de analisar o código-fonte (como nos testes unitários), o QA interage com a interface ou com a API simulando as ações de um usuário real. O objetivo é garantir que cada funcionalidade — desde um simples clique em um botão até um cálculo complexo de nota em um simulado — entregue o resultado correto.
Pergunta principal:
“Isso está funcionando como deveria?”
Exemplo:
- Cadastro cria usuário?
- Botão realiza a ação correta?
Teste de API
O teste de API valida a camada de integração do sistema (Back-end), garantindo que os dados e as regras de negócio funcionem corretamente, mesmo sem a interface visual (Front-end).
O que o QA deve validar:
- Status Codes: O servidor responde com o código HTTP correto? (ex:
201para criado,403para negado). - Contrato e Schema: O JSON de resposta tem todos os campos e tipos de dados (String, Number) esperados?
- Payload (Corpo): Os dados retornados são exatamente o que foi solicitado ou processado?
- Tratamento de Erros: O sistema é resiliente a dados inválidos, nulos ou malformatados?
Exemplos de Status Codes
| Ação | Status | Validação do QA |
|---|---|---|
| Login Válido | 200 OK | Deve retornar o Token de acesso. |
| Senha Errada | 401 Unauthorized | Mensagem de erro clara e segura. |
| Dado Duplicado | 409 Conflict | Impedir e-mail repetido, por exemplo. |
| Campo Vazio | 400 Bad Request | O Back-end deve travar o processamento. |
| Erro de Código | 500 Internal Error | Falha crítica que precisa de correção imediata. |
Checklist Rápido
- A URL e o método (GET, POST, etc) estão corretos?
- O Header de autenticação foi enviado?
- O JSON segue a documentação do projeto?
Teste de Regressão
O Teste de Regressão consiste em testar novamente funcionalidades que já estavam estáveis após uma nova alteração, correção de bug ou atualização de ambiente. O objetivo é garantir que o novo código não gerou “efeitos colaterais” indesejados em partes do sistema que não deveriam ter sido afetadas.
Pergunta-chave:
“Essa mudança quebrou outra parte do sistema?”
Por que ele é vital na Comp?
Em nossos projetos, é comum que uma alteração em uma função global ou no Banco de Dados afete telas distantes. O teste de regressão é a nossa rede de segurança para evitar que o sistema “ande para trás”.
Quando aplicar no dia a dia?
- Após correções de bugs: Garantir que o conserto de um erro não criou um novo problema em outro lugar.
- Novas funcionalidades: Verificar se o que você acabou de implementar é compatível com o que já existia.
- Refatoração: Quando o desenvolvedor limpa o código sem mudar a função, o QA deve garantir que o comportamento final continua idêntico.
Exemplo Prático de Regressão
Imagine que a equipe de desenvolvimento alterou a lógica de “Esqueci minha senha”:
- Você testa a nova função de recuperação de senha (Teste Funcional).
- Em seguida, você tenta fazer o Login Comum e o Cadastro (Teste de Regressão).
- Se o login parar de funcionar por causa da mudança na recuperação, temos uma regressão.
Checklist de Regressão Manual
- Identifiquei quais áreas do sistema podem ter sido afetadas?
- O fluxo principal (Caminho Feliz) continua funcionando sem erros?
- Testei as funcionalidades vizinhas à que foi alterada?
Resumo
Na prática, ao testar uma tarefa, você deve sempre:
- Ver se funciona (funcional)- Testar com dados corretos (positivo)- Testar com dados errados (negativo)- Ver se não quebrou outras partes (regressão)