RESUMO EM CONSTRUÇÃO
QA (Quality Assurance ou Garantia da Qualidade) é conjunto de processos e práticas para prevenir defeitos (bugs) e garantir que software atenda padrões de qualidade esperados (requisitos do sistema, critérios de aceitação, normas e modelos de qualidade, padrões técnicos e boas práticas, contratos e SLAs, definição de pronto - Definition of Done), em todas fases do desenvolvimento. Profissionais de QA identificam falhas, otimizam processos e asseguram que software seja robusto e confiável, atuando de forma preventiva.
No cotidiano, QA participa da análise de requisitos, validando regras de negócio, identificando ambiguidades e antecipando cenários de erro. Durante desenvolvimento, QA valida se features estão conforme esperado e, após entrega, contribui para estabilidade do sistema em produção. Em times ágeis, QA trabalha integradamente com desenvolvedores, POs e designers.
Testes manuais são executados por pessoa, seguindo cenários definidos ou explorando sistema de forma livre. São essenciais em testes exploratórios, validação visual, usabilidade e testes iniciais de novas funcionalidades. Testes automatizados utilizam ferramentas e scripts para executar cenários repetitivos de forma rápida e confiável. Em ambiente de produção, são usados para validar regressões, fluxos críticos e integrações sempre que nova versão é entregue. Testes repetitivos, regressões, fluxos críticos e cenários que precisam ser executados com frequência são fortes candidatos à automação. Testes exploratórios, validações visuais e funcionalidades em constante mudança geralmente são melhores executados de forma manual, especialmente em fases iniciais do desenvolvimento. Automação permite execuções rápidas, redução de erros humanos, maior cobertura de testes e integração com pipelines de CI/CD, possibilitando validar aplicação inteira a cada deploy.
Teste manual, cenário Login de usuário:
Abrir aplicação no navegador
Informar e-mail válido e senha válida
Clicar em Entrar
Verificar se sistema redireciona para página inicial e exibe nome do usuário
Teste automatizado, cenário Login de usuário (exemplo em pseudocódigo Python):
def test_senha_com_tamanho_minimo():
senha = "123456"
resultado = validar_senha(senha)
assert resultado is True
Loja online aplica 10% de desconto para compras acima de R$ 100,00. Função responsável por calcular valor final da compra.
Regra de negócio:
Valor a menor ou igual a 100 = não aplica desconto
Valor maior que 100 = aplica 10% de desconto
Teste unitário (exemplo prático)
def test_calcular_desconto():
assert calcular_desconto(80) == 80
assert calcular_desconto(100) == 100
assert calcular_desconto(200) == 180
Sistema de e-commerce possui API de Pedidos, que cria pedidos, e API de Pagamentos, que processa pagamentos. Quando pedido é criado, API de Pedidos chama API de Pagamentos para cobrar cliente.
Regra de negócio:
Se pagamento for aprovado, pedido fica com status "PAGO"
Se pagamento falhar, pedido fica com status "RECUSADO"
def test_criar_pedido_com_pagamento_aprovado(client):
response = client.post("/api/pedidos/", json={
"produto_id": 1,
"quantidade": 2,
"cartao": "4111111111111111"
})
assert response.status_code == 201
assert response.json()["status"] == "PAGO"
Sistema: E-commerce web
Objetivo do sistema: permitir que usuário compre produto do início ao fim.
Critério de aceitação:
Usuário consegue comprar produto com sucesso
Pagamento é aprovado
Pedido aparece no histórico do usuário
Teste de sistema (exemplo prático)
Fluxo executado:
Usuário acessa site
Realiza login
Adiciona produto ao carrinho
Finaliza compra
Sistema processa pagamento
Pedido é confirmado e exibido no histórico
Validações:
Tela de confirmação exibida
Status do pedido: "Confirmado"
Pagamento registrado no sistema
Pedido visível no histórico
Sistema: Sistema escolar online
Regra de negócio (definida pelo cliente):
Apenas alunos autenticados podem visualizar suas próprias notas
Notas devem corresponder ao aluno logado
Teste de aceitação (exemplo prático):
Cenário: Aluno acessa suas notas após login
Dado que aluno possui cadastro ativo no sistema
Quando aluno realiza login com usuário e senha válidos
E acessa opção "Minhas Notas"
Sistema exibe apenas notas daquele aluno da sessão
Testes funcionais verificam se funcionalidades do sistema funcionam conforme esperado, como login, cadastro, busca e envio de formulários. Testes não funcionais avaliam características como desempenho, segurança, usabilidade e compatibilidade, inclui testar quantos usuários simultâneos o sistema suporta ou se dados sensíveis estão protegidos adequadamente.
TESTE FUNCIONAL:
Sistema: Aplicativo bancário
Cenário: Pix entre contas
Usuário realiza login
Informa Pix de destino e valor de R$ 500,00
Confirma Pix
Resultado esperado:
Valor é debitado da conta de origem
Valor é creditado na conta de destino
Sistema exibe mensagem de sucesso
TESTE NÃO FUNCIONAL:
Sistema: API bancária
Cenário: Tempo de resposta da API de Pix
Realizar 1.000 requisições simultâneas de Pix
Medir tempo de resposta
Resultado esperado:
95% das requisições respondem em até 2 segundos
Nenhuma requisição retorna erro 5xx
Pirâmide de testes é modelo de distribuição dos tipos de testes (E2E Tests, Service Tests, Unit Tests). Na base estão testes unitários, em maior quantidade e com execução rápida. No meio, testes de integração. No topo, testes de sistema e End-to-End, em menor quantidade, sendo mais lentos e complexos. Pirâmide ajuda reduzir custos, acelerar feedbacks e manter estabilidade do desenvolvimento do sistema.
Artefatos de QA são documentos e registros utilizados para planejar, executar e acompanhar testes, garantindo rastreabilidade, organização e comunicação entre time.
1. Plano de Testes: documento que define o que será testado, como, quando e por quem. Exemplo:
Plano descrevendo que:
Testes unitários serão feitos com pytest
Testes de integração cobrem APIs de pedidos e pagamentos
Ambiente de homologação será usado antes da produção
2. Casos de Teste: descrição passo a passo de como validar funcionalidade. Exemplo:
Caso de teste: Login com senha válida
Entrada: e-mail e senha corretos
Ação: clicar em "Entrar"
Resultado esperado: redirecionamento para dashboard
3. Cenários de Teste: visão mais alto nível, focada no fluxo. Exemplo:
Cenário: Compra de produto com pagamento aprovado
4. Relatório de Bugs (Defect Report): registro formal de erro encontrado. Exemplo:
Título: Erro ao finalizar pagamento com cartão
Ambiente: Homologação
Resultado esperado: pagamento aprovado
Resultado obtido: erro 500
5. Checklist de Testes: lista rápida para validação básica. Exemplo:
Login funciona
API retorna status 200
Campos obrigatórios validados
6. Relatório de Execução de Testes: mostra status dos testes executados. Exemplo:
Total de testes: 120
Passaram: 110
Falharam: 10
7. Matriz de Rastreabilidade: relaciona requisitos aos testes. Exemplo:
Requisito RF-01: Caso de Teste CT-05
8. Evidências de Teste: comprovação da execução do teste. Exemplo:
Screenshot da tela de confirmação
Log de execução de teste automatizado
Casos de teste descrevem passo a passo como validar funcionalidade, incluindo pré-condições, dados de entrada, ações e resultados esperados. Exemplo: descrever todo fluxo de login de usuário, desde inserção de credenciais até acesso ao sistema.
Caso de Teste Completo - Login de Usuário
ID: CT-AUTH-LOGIN-001
Título: Login com credenciais válidas
Módulo: Autenticação
Tipo de teste: Funcional / Sistema
Prioridade: Alta
Autor: QA Team
Data: 15/01/2026
Objetivo: validar se o usuário consegue acessar sistema, informando credenciais válidas, conforme regras de negócio definidas.
Pré-condições:
Usuário cadastrado e ativo no sistema
Usuário não está logado
Sistema disponível
Navegador Google Chrome atualizado
Ambiente: Homologação
Dados de teste (campo, valor):
E-mail: usuario@exemplo.com
Senha: Senha@123
Passos de execução:
Acessar URL do sistema
Clicar na opção Login
Informar e-mail no campo correspondente
Informar senha no campo correspondente
Clicar no botão Entrar
Resultado esperado:
Sistema valida credenciais
Usuário é autenticado com sucesso
Redirecionamento para página inicial
Nome do usuário exibido no topo da tela
Token de sessão criado
Resultado obtido: (Preenchido durante a execução)
Status: (Aprovado / Reprovado)
Evidências: Screenshot da tela inicial após login
Log da requisição de autenticação
Observações:
Caso de teste pode ser reutilizado para automação
Base para cenários negativos (senha inválida, usuário inativo)
Checklists são listas simples de verificações que devem ser realizadas durante teste. Muito usados em testes exploratórios, revisões rápidas ou validações antes de entrega em produção.
Checklist de Testes - Liberação para Produção
Sistema: Plataforma Web de E-commerce
Módulo: Autenticação e Compra
Ambiente: Homologação
Responsável: QA
Data: 15/01/2026
1. Autenticação:
[] Login com credenciais válidas
[] Bloqueio após tentativas inválidas
[] Logout funcionando corretamente
[] Sessão expira após tempo de inatividade
2. Funcionalidades principais:
[] Listagem de produtos carregando corretamente
[] Produto pode ser adicionado ao carrinho
[] Atualização de quantidade no carrinho
[] Finalização de compra com sucesso
3. Pagamentos:
[] Pagamento aprovado atualiza status do pedido
[] Pagamento recusado exibe mensagem adequada
[] Nenhum pagamento duplicado gerado
4. Validações de campos:
[] Campos obrigatórios validados
[] Mensagens de erro claras para usuário
[] Dados inválidos não são aceitos
5. Segurança:
[] URLs protegidas exigem autenticação
[] Dados sensíveis não expostos em tela ou logs
[] HTTPS ativo
6. Performance básica:
[] Páginas principais carregam em até 3 segundos
[] API responde sem erros 5xx
7. Experiência do usuário:
[] Layout consistente em telas principais
[] Botões e links funcionam corretamente
[] Mensagens de sucesso e erro visíveis
8. Evidências:
[] Screenshots coletados
[] Logs salvos, se aplicável
Status final:
[] Apto para produção
[] Não apto para produção
Relatórios de bugs registram defeitos encontrados durante testes. Contém descrição clara do problema, passos para reprodução, resultado esperado, resultado obtido e evidências, como screenshots ou logs.
Relatório de Bug:
ID: BUG-PAG-014
Título: Erro 500 ao finalizar pagamento com cartão de crédito
Projeto: E-commerce Web
Módulo: Pagamentos
Tipo: Defeito funcional
Severidade: Alta
Prioridade: Alta
Status: Aberto
Responsável: Time de Desenvolvimento
Reportado por: QA
Data: 15/01/2026
Ambiente:
Ambiente: Homologação
Navegador: Google Chrome 120
Sistema Operacional: Windows 11
Descrição do problema:
Ao tentar finalizar compra utilizando cartão de crédito válido, sistema retorna erro interno (HTTP 500) e não conclui pagamento.
Pré-condições:
Usuário autenticado no sistema
Produto adicionado ao carrinho
Cartão de crédito válido disponível para teste
Passos para reprodução:
Acessar sistema
Realizar login com usuário válido
Adicionar produto ao carrinho
Clicar em Finalizar compra
Selecionar pagamento via cartão de crédito
Informar dados válidos do cartão
Confirmar pagamento
Resultado esperado:
Pagamento processado com sucesso
Pedido criado com status "Pago"
Tela de confirmação exibida ao usuário
Resultado obtido:
Sistema retorna erro HTTP 500
Tela genérica de erro exibida
Pedido não é criado
Evidências:
Screenshot da tela de erro
Log da API de pagamento mostrando exceção
Request e response da requisição (HTTP 500)
Impacto:
Usuários não conseguem finalizar compras utilizando cartão de crédito, bloqueando vendas.
Observações:
Erro ocorre de forma consistente ao usar cartão Visa em ambiente de homologação.
Documento SRS (Software Requirements Specification) descreve, de forma detalhada e estruturada, o que sistema deve fazer, quais suas restrições, regras de negócio, e requisitos funcionais e não funcionais. Requisitos funcionais descrevem o que o sistema faz (features). Exemplo: RF-01 Aluno deve realizar login com e-mail e senha. Requisitos não funcionais descrevem como sistema deve se comportar (ambiente, especificações técnicas e ferramentas). Exemplo: Sistema deve responder em até 2 segundos, Dados do aluno devem ser protegidos por autenticação JWT. Requisitos funcionais geram testes funcionais e requisitos não funcionais geram testes não funcionais. Exemplo de SRS.
História de Usuário:
Como aluno,
Quero acessar minhas notas
Para acompanhar meu desempenho escolar.
Informações extraídas pelo QA:
Apenas alunos autenticados acessam notas
Notas são individuais
Existe tela específica de consulta
Impacto direto nos testes:
Criar teste para acesso com login válido
Criar teste para acesso sem login (bloqueio)
Criar teste para tentativa de acesso a notas de outro aluno
Documento SRS:
SRS Requisitos Funcionais:
RF-01: Sistema deve permitir que aluno autenticado visualize suas notas
RF-02: Sistema deve garantir que aluno visualize apenas suas próprias notas
RF-03: Acesso às notas deve ser restrito a usuários autenticados
SRS Requisitos Não Funcionais:
RNF-01: Tempo de resposta da tela de notas deve ser inferior a 2 segundos
RNF-02: Informações exibidas devem estar protegidas por autenticação.
O que QA extrai do SRS:
Login é obrigatório
Existe controle de permissão
Há requisito de desempenho
Há requisito de segurança
Impacto direto nos testes
Teste de acesso com login válido
Teste de acesso sem login (bloqueio)
Teste de tentativa de acesso a dados de outro aluno
Teste de tempo de resposta da funcionalidade
Documentos funcionais:
Funcionalidade: Consulta de Notas
Aluno deve acessar sistema utilizando login e senha.
Após autenticação, aluno poderá acessar o menu "Minhas Notas".
Sistema deve exibir apenas notas do aluno autenticado.
Notas devem ser exibidas por disciplina e período letivo.
Aluno não poderá editar ou excluir notas.
O que o QA identifica na leitura:
Fluxo principal de acesso
Regra de permissão
Restrições de edição
Organização das informações
Impacto direto nos testes
Teste de login obrigatório
Teste de acesso ao menu "Minhas Notas"
Teste de exibição correta por disciplina
Teste garantindo que campos são somente leitura
Reuniões com PO / Cliente (baseadas no SRS):
Dúvida do QA:
"No RF-01, o sistema deve mostrar notas parciais ou apenas notas finais?"
Resposta do cliente:
"O sistema deve exibir notas parciais e finais, separadas por disciplina."
Ajuste no SRS:
Inclusão de novo requisito: RF-04 - Sistema deve exibir notas parciais e finais separadamente
Impacto nos testes:
Novo cenário de consulta por disciplina
Casos de teste para notas parciais e finais
Sistema: Sistema Escolar Web
Funcionalidade: Consulta de notas e faltas
Fase do projeto: Início do desenvolvimento
Participantes:
QA
PO (representando cliente)
Coordenador pedagógico (stakeholder)
Objetivo da entrevista:
Entender regras de negócio, permissões e exceções relacionadas à visualização de notas e faltas dos alunos.
Perguntas do QA (com raciocínio real):
QA: "Quem pode acessar as notas no sistema?"
Stakeholder: "Apenas alunos e responsáveis."
Insight: existe mais de um perfil - novos cenários de permissão.
QA: "O aluno consegue ver notas de outros alunos?"
Stakeholder: "Não, somente as próprias notas."
Insight: requisito claro de segurança e autorização.
QA: "As notas são parciais ou apenas finais?"
Stakeholder: "As duas. Durante o semestre são parciais, no final ficam consolidadas."
Insight: necessidade de testes por tipo de nota.
QA: "O responsável vê as mesmas informações que o aluno?"
Stakeholder: "Sim, mas não pode ver dados pessoais do aluno."
Insight: regra específica por perfil.
QA: "Existe algum período em que as notas ficam indisponíveis?"
Stakeholder: "Sim, durante o fechamento do semestre."
Insight: cenário de indisponibilidade - testes negativos.
Informações consolidadas após a entrevista
Requisitos funcionais levantados:
Alunos veem apenas suas notas
Responsáveis veem notas do aluno vinculado
Notas parciais e finais devem ser exibidas
Acesso bloqueado durante fechamento do semestre
Requisitos não funcionais:
Controle de acesso por perfil
Mensagem clara quando notas estiverem indisponíveis
Impacto direto no design de testes:
Cenários criados a partir da entrevista
Aluno acessa notas durante o semestre
Aluno acessa notas após fechamento
Responsável acessa notas do aluno
Tentativa de acesso indevido a notas de outro aluno
Registro da entrevista (artefato real de QA)
Ata de reunião / Registro de entrevista:
Data
Participantes
Perguntas realizadas
Decisões tomadas
Ações pendentes
Conclusão prática
Sistema: Sistema Escolar Web
Funcionalidade em refinamento: Consulta de notas
Sprint: Planejamento da Sprint 5
Participantes:
Product Owner (PO)
QA
Desenvolvedor Backend
Desenvolvedor Frontend
Scrum Master
Objetivo da reunião:
Detalhar requisitos
Quebrar a funcionalidade em cenários testáveis
Definir critérios de aceite claros
Identificar riscos antes do desenvolvimento
Simulação real da reunião:
PO apresenta a funcionalidade
PO: "O aluno precisa acessar suas notas pelo sistema."
QA inicia o refinamento com perguntas
QA: "O aluno pode ver notas de períodos anteriores?"
PO: "Sim, através de um filtro por período."
Impacto: necessidade de testes de filtro.
QA: "Se o aluno não tiver notas lançadas, o que o sistema deve mostrar?"
PO: "Uma mensagem informando que não há notas disponíveis."
Impacto: cenário negativo e validação de mensagem.
QA: "Durante o fechamento do semestre, as notas ficam disponíveis?"
PO: "Não, o acesso deve ser bloqueado temporariamente."
Impacto: novo cenário de exceção.
Desenvolvedor complementa:
Dev: "O backend vai retornar status 403 quando o acesso estiver bloqueado."
Impacto: QA define validação de status e mensagem.
Definição de critérios de aceite (resultado do grooming):
Aluno autenticado acessa suas notas
Aluno pode filtrar por período
Sistema exibe mensagem quando não houver notas
Acesso bloqueado durante fechamento do semestre
Mensagem clara para o usuário
Resultado prático da reunião:
Cenários criados
Consulta de notas com período atual
Consulta de notas com período anterior
Consulta sem notas cadastradas
Tentativa de acesso durante bloqueio
Ajustes na documentação:
Documento funcional atualizado
Critérios de aceite formalizados
Itens prontos para virar casos de teste
Artefatos gerados:
Ata de refinamento
Lista de cenários
Critérios de aceite
Pendências técnicas
Conclusão prática
Sistema: Sistema de Gestão de Clínicas
Módulo analisado: Agendamento de consultas
Objetivo: Entender como recepcionistas realmente trabalham no dia a dia
Shadowing (na prática): Profissional (QA/Analista) acompanha, sem interferência usuário no ambiente real, observando:
Ações
Atalhos
Dificuldades
Gambiarras
Comportamentos não documentados
Usuário observado:
Recepcionista da clínica
Situação 1 - Agendamento comum
Recepcionista recebe ligação.
Observação do QA:
Abre sistema
Não usa botão "Novo Agendamento"
Vai direto na agenda do médico e clica no horário
Insight: fluxo real é diferente do fluxo desenhado.
Situação 2 - Cliente atrasado
Paciente chega atrasado.
Observação do QA:
Recepcionista apaga agendamento antigo
Cria outro manualmente
Não usa opção "Reagendar"
Insight: Funcionalidade existe, mas não é intuitiva.
Situação 3 - Falha do sistema
Sistema demora para carregar.
Observação do QA:
Recepcionista anota nome do paciente em papel
Lança no sistema depois
Insight crítico: sistema precisa suportar operação posterior (offline ou rascunho).
Perguntas feitas após observação:
QA: "Por que você não usa o botão de reagendamento?"
Usuária: "É muito demorado, prefiro apagar e refazer."
Confirma problema de usabilidade.
Problemas identificados (que ninguém tinha contado):
Fluxo real ≠ fluxo projetado
Funcionalidades pouco usadas
Dependência de papel em caso de lentidão
Risco de perda de informação
Resultados práticos do shadowing:
Requisitos descobertos:
Agendamento direto pelo calendário
Reagendamento em menos cliques
Salvamento temporário (rascunho)
Melhor feedback de carregamento
Impacto para QA:
Criação de casos de teste baseados no uso real
Testes de usabilidade
Testes de performance percebida
Testes de recuperação de falha
Artefatos gerados:
Relatório de observação
Lista de problemas reais
Sugestões de melhoria
Novos cenários de teste
Conclusão prática
Sistema: Portal Escolar Online
Objetivo: Permitir que alunos consultem notas, faltas, calendário acadêmico e avisos
Fase do projeto: Levantamento e refinamento de requisitos
Técnica utilizada: Questionário
Público-alvo: Alunos e professores da escola
Muitos usuários
Pouco tempo para entrevistas individuais
Necessidade de dados quantitativos + qualitativos
Questionário com objetivo de melhorar Portal Escolar Online.
Seção 1 - Perfil do Usuário
1. Qual é o seu perfil?
() Aluno
() Professor
() Coordenador
2. Com que frequência você acessa o portal escolar atualmente?
() Todos os dias
() 2 a 3 vezes por semana
() Raramente
() Nunca
Seção 2 - Uso Atual do Sistema
3. Quais funcionalidades você mais utiliza?
(Marque todas que se aplicam)
[] Consulta de notas
[] Consulta de faltas
[] Calendário acadêmico
[] Avisos da escola
[] Não utilizo o sistema
4. Em qual dispositivo você mais acessa o portal?
() Computador
() Celular
() Tablet
Seção 3 - Problemas e Dores (requisitos não funcionais)
5. Você já teve dificuldades para acessar suas notas?
() Sim
() Não
Se sim, quais?
✏️ Campo aberto
6. Avalie a velocidade do sistema:
() Muito lenta
() Lenta
() Adequada
() Rápida
7. O sistema costuma apresentar erros ou instabilidade?
() Frequentemente
() Às vezes
() Raramente
() Nunca
Seção 4 - Expectativas e Requisitos Funcionais
8. Quais funcionalidades você considera essenciais?
(Marque até 3)
[] Ver notas por disciplina
[] Histórico de notas anteriores
[] Detalhamento de avaliações
[] Exportar boletim em PDF
[] Notificações de novas notas
9. Você gostaria de receber notificações quando novas notas forem lançadas?
() Sim, por e-mail
() Sim, pelo aplicativo
() Não
Seção 5 - Segurança e Privacidade
10. Você acredita que suas informações estão seguras no portal?
() Sim
() Não
() Não sei
11. Quem você acredita que pode visualizar suas notas?
(Marque todas que achar correto)
[] Apenas o aluno
[] Professores
[] Coordenação
[] Outros alunos (resposta importante para validação de regra de negócio)
Seção 6 - Pergunta Aberta (ouro do levantamento)
12. Na sua opinião, o que poderia melhorar no portal escolar?
Campo aberto
Análise dos Resultados
Após coletar respostas, time de QA / Produto percebe:
- Muitos alunos querem notificação de novas notas
- Reclamações sobre lentidão em horários de pico
- Dúvidas sobre quem pode visualizar notas (requisito de segurança)
- Forte uso via dispositivos móveis
Transformando Questionário em Requisitos e Testes
RF-01: O sistema deve permitir a visualização de notas por disciplina
RF-02: O sistema deve enviar notificações quando novas notas forem lançadas
RNF-01: O sistema deve responder em até 3 segundos em horários de pico
RNF-02: Um aluno não pode visualizar notas de outros alunos
Empresa desenvolvendosistema escolar online para alunos e professores, com foco em consulta de notas, faltas e boletins.
Contexto do trabalho (dia a dia):
Antes de definir requisitos finais, QA e PO decidem analisar sistemas já consolidados no mercado para evitar retrabalho e alinhar produto às expectativas reais dos usuários.
Sistemas analisados (benchmark):
Google Classroom
Sistema Escolar Estadual já utilizado por outras escolas
Plataforma privada de gestão escolar (ex.: Sponte ou similar)
Atividades realizadas:
QA cria lista de funcionalidades-chave:
Login e recuperação de senha
Visualização de notas por disciplina
Histórico de boletins
Controle de faltas
Acesso por perfil (aluno, professor, coordenador)
QA navega nos sistemas benchmark e observa:
Como notas são apresentadas (tabela, gráfico, média final)
Se aluno consegue ver apenas suas próprias informações
Se há exportação de boletim em PDF
Como funciona filtro por período letivo
QA registra boas práticas encontradas:
Uso de cores para indicar aprovação/reprovação
Exibição clara do professor responsável pela disciplina
Histórico separado por ano letivo
Resultado prático gerado (requisito refinado):
"Sistema deve permitir que aluno visualize suas notas organizadas por ano letivo, com indicação visual de aprovação ou reprovação, semelhante ao padrão encontrado em sistemas escolares amplamente utilizados."
Valor para QA e testes:
Ajuda a criar cenários de teste mais realistas
Reduz risco de requisitos incompletos
Garante que sistema siga padrões já aceitos pelo mercado
Facilita validações de usabilidade e experiência do usuário
Equipe está desenvolvendo sistema escolar e precisa validar como será tela de consulta de notas do aluno antes de iniciar desenvolvimento.
Contexto do trabalho (dia a dia):
PO cria protótipo de baixa fidelidade (wireframe) no Figma para representar tela de "Minhas Notas". QA, desenvolvedores e grupo de alunos participam da validação.
O que protótipo contém:
Campo para seleção do ano letivo
Lista de disciplinas
Nota parcial, nota final e média
Indicador visual de aprovação/reprovação
Botão "Exportar boletim em PDF"
Atividades realizadas:
PO apresenta protótipo aos alunos e professores
Usuários navegam no protótipo simulando o uso real
QA observa dúvidas e dificuldades dos usuários
Feedback coletado:
Alunos pedem para visualizar faltas junto das notas
Professores solicitam identificação clara do peso das avaliações
Usuários confundem nota parcial com nota final
Ajustes feitos antes do desenvolvimento:
Inclusão da coluna "Faltas"
Diferenciação visual entre nota parcial e final
Tooltip explicativo sobre cálculo da média
Resultado prático para QA:
Requisitos ficaram mais claros e completos
Casos de teste puderam ser escritos antes do código existir
Redução de retrabalho e defeitos em produção
QA analisa critérios que dizem quando funcionalidade está pronta (done).
Dado que o aluno esteja autenticado
Quando acessar a tela "Minhas Notas"
Então sistema deve exibir apenas suas notas
E não permitir acesso a notas de outros alunos
Impacto direto nos testes:
Cada critério vira, no mínimo, um caso de teste:
Teste positivo: aluno vê suas notas
Teste negativo: aluno tenta ver notas de outro aluno
QA questiona pontos não claros ou riscos do requisito.
"Aluno pode acessar notas sem login?"
"Aluno pode ver notas de anos anteriores?"
"Existe perfil de responsável com acesso às notas?"
Respostas e impacto nos testes:
Sem login - acesso bloqueado - teste de segurança
Anos anteriores - filtro por período - teste de filtro
Perfil responsável - novos cenários de permissão
Técnicas para organizar, estrategicamente, informações dos testes.
(Etapa 1) Análise e elicitação de requisitos visa coletar e analisar requisitos de software para verificar alinhamento com objetivos de negócios e necessidades técnicas. Compõe das seguintes etapas:
Produto: Sistema Web de Pedidos para Cafeteria
Objetivo de negócio: permitir que clientes realizem pedidos online e que cafeteria gerencie pedidos de forma eficiente.
Stakeholders:
Product Owner (PO)
Desenvolvedores
QA Analyst
1. Revisão dos Requisitos Funcionais e Não Funcionais:
Requisitos Funcionais (RF):
RF01: cliente deve conseguir realizar pedido selecionando produtos do cardápio.
RF02: sistema deve calcular automaticamente valor total do pedido.
RF03: atendente deve visualizar pedidos em tempo real.
RF04: cliente deve receber confirmação do pedido.
Requisitos Não Funcionais (RNF):
RNF01: sistema deve responder em até 2 segundos para ações principais.
RNF02: sistema deve estar disponível 99% do tempo.
RNF03: sistema deve funcionar nos navegadores Chrome e Firefox.
Atuação prática do QA: QA analisa requisitos e levanta pontos como:
RF01 não define: Quantidade máxima de itens? É permitido pedido vazio?
RF02: Como tratar valores decimais? Regras de arredondamento?
RF04: Confirmação via tela? E-mail? Ambos?
2. Priorização de Áreas de Alto Risco e Funcionalidades Críticas
Funcionalidade - Impacto no Negócio - Probabilidade de Falha - Risco
Realizar pedido - Alto - Alto - Alto
Cálculo de valores - Alto - Médio - Alto
Visualização pelo atendente - Médio - Médio - Médio
Confirmação do pedido - Médio - Baixo - Baixo
Testes mais profundos e antecipados em:
Fluxo de criação de pedido
Cálculo de preço
Automatizar testes do cálculo do pedido
Executar testes exploratórios no fluxo principal
3. Mapeamento das Condições de Teste com os Objetivos do Projeto
Objetivo de Negócio: Permitir que clientes realizem pedidos online sem erros e com rapidez.
Condições de Teste Criadas pelo QA:
Objetivo do Projeto - Requisito - Condição de Teste
Pedido sem falhas - RF01 - Validar criação de pedido com itens válidos
Pedido sem falhas - RF01 - Validar bloqueio de pedido sem itens
Valor correto - RF02 - Validar soma correta com múltiplos produtos
Valor correto - RF02 - Validar arredondamento de valores
Rapidez - RNF01 - Validar resposta em até 2s
Compatibilidade - RNF03 - Validar fluxo completo no Chrome e Firefox
Resultado Gerado pelo QA (Entregáveis Reais):
Checklist de requisitos validados
Lista de dúvidas e gaps de requisitos
Mapa de risco por funcionalidade
Condições de teste ligadas aos objetivos de negócio
Base sólida para criação dos casos de teste
(Etapa 2) Identificação do Test Scenario ocorre após requisitos definidos com precisão, onde testers dividem aplicação em modelos lógicos. Compõe das seguintes fases:
Contexto do Projeto - Sistema web de pedidos para uma cafeteria, composto por:
Frontend web
Backend com API REST
Banco de dados relacional
Serviço externo de notificação de pedidos
Objetivo do QA nesta etapa: Identificar cenários de teste macro, antes de detalhar casos de teste.
1. Identificação das Interações e Fluxos de Trabalho do Usuário:
Fluxo principal (happy path):
Usuário acessa sistema
Usuário visualiza cardápio
Usuário adiciona produtos ao pedido
Usuário altera quantidades
Usuário visualiza valor total atualizado
Usuário finaliza pedido
Sistema exibe confirmação do pedido
Fluxos alternativos:
Usuário remove item do pedido
Usuário tenta finalizar pedido sem itens
Usuário abandona pedido antes da finalização
Usuário tenta adicionar produto indisponível
2. Definição dos Test Scenarios Baseados nos Fluxos:
Test Scenarios de Usuário:
Criar pedido com um item válido
Criar pedido com múltiplos itens válidos
Atualizar quantidade de item no pedido
Remover item do pedido antes da finalização
Tentar finalizar pedido sem itens
Cancelar pedido durante o fluxo
Esses cenários representam modelos lógicos da aplicação, não casos de teste ainda.
3. Verificação das Condições de Entrada:
Condições de Entrada Válidas:
Produto existente no cardápio
Quantidade maior que zero
Sessão de usuário ativa
API respondendo com status de sucesso
Dados enviados no formato esperado
Condições de Entrada Inválidas:
Produto inexistente
Quantidade zero ou negativa
Finalização de pedido sem itens
Payload com dados inválidos
Sessão expirada
4. Avaliação dos Pontos de Integração:
Integração com APIs:
Frontend (API de produtos)
Frontend (API de pedidos)
Validação de códigos HTTP
Validação de mensagens de erro retornadas
Integração com Banco de Dados:
Persistência correta do pedido após finalização
Registro correto dos itens e valores
Consistência entre pedido e itens
Rollback em caso de erro durante a gravação
Integração com Sistemas Externos:
Envio de confirmação do pedido
Comportamento do sistema em caso de falha do serviço externo
Garantia de não duplicação de pedidos
5. Resultado Final do Trabalho do QA:
Ao final da identificação de test scenarios, QA entrega:
Lista estruturada de test scenarios
Mapeamento de fluxos críticos
Identificação clara de entradas válidas e inválidas
Pontos de integração mapeados
Base sólida para criação de casos de teste manuais e automatizados
(Etapa 2b / 3) Test Plan é documento de planejamento dos testes, com descrição das atividades e necessidades para realização dos mesmos. Etapas para construção de Test Plan:
Test Plan - Sistema de Gestão de Cafés (Web)
1. Introdução:
Este documento descreve Plano de Testes para sistema Sistema de Gestão de Cafés, aplicação web utilizada para cadastro, listagem, edição e exclusão de cafés, além de consulta pública dos dados. Objetivo deste Test Plan é definir escopo, estratégia, recursos, cronograma, riscos e artefatos relacionados às atividades de teste, garantindo que sistema atenda aos requisitos funcionais e não funcionais estabelecidos.
2. Escopo dos Testes:
2.1 Em Escopo - Serão testadas as seguintes funcionalidades:
Cadastro de cafés
Listagem de cafés
Consulta pública de cafés
Atualização de dados de cafés
Exclusão de cafés
Validações de campos obrigatórios
Regras de negócio descritas nos requisitos
Respostas da API REST
Compatibilidade básica com navegadores modernos
2.2 Fora do Escopo - Não serão cobertos neste ciclo:
Testes de carga e stress
Testes de segurança avançados (pentest)
Testes em dispositivos móveis físicos
Integrações com sistemas externos inexistentes no momento
3. Tipos de Testes e Estratégia:
3.1 Tipos de Testes - Serão aplicados tipos de testes:
Testes Funcionais
Testes de Regressão
Testes Exploratórios
Testes de API
Testes de Usabilidade básicos
Testes Manuais e Automatizados
3.2 Estratégia de Testes:
Testes manuais serão priorizados no início do projeto, durante validação de requisitos.
Testes automatizados serão aplicados para fluxos críticos (CRUD).
Testes de regressão serão executados a cada nova entrega.
Testes exploratórios serão realizados ao final de cada ciclo.
4. Estágios e Ciclos de Teste:
Ciclo 1: Testes funcionais iniciais (cadastro e listagem)
Ciclo 2: Testes de atualização, exclusão e validações
Ciclo 3: Testes de regressão
Ciclo 4: Testes exploratórios e validação final
5. Recursos Tecnológicos:
5.1 Ambiente:
Ambiente de desenvolvimento (DEV)
Banco de dados de testes
API REST disponível via endpoint de homologação
5.2 Tecnologias e Ferramentas:
Navegadores: Chrome, Firefox
Ferramenta de testes de API: Postman
Automação: Selenium / Cypress (exemplo)
Gerenciamento de testes: Planilha ou ferramenta de gestão (ex: Jira, TestRail)
Versionamento: Git
6. Recursos Humanos - Papel (quantidade):
QA Analyst (1)
Desenvolvedor (2)
Product Owner (1)
Responsabilidades do QA:
Criação do Test Plan
Elaboração de casos de teste
Execução dos testes
Registro e acompanhamento de defeitos
Reexecução de testes após correções
7. Cronograma de Testes - Atividade (duração estimada em dias):
Análise de requisitos (1)
Criação do Test Plan (1)
Criação dos casos de teste (2)
Execução dos testes (3)
Reteste e regressão (2)
OBS: Cronograma considera tempo adicional para investigação de bugs, reporte, acompanhamento e validação das correções.
8. Riscos:
Mudanças frequentes nos requisitos
Atraso na entrega das funcionalidades
Ambiente de testes instável
Falta de dados consistentes para testes
Dependência de correções do time de desenvolvimento
9. Restrições:
Prazo limitado para execução dos testes
Apenas 1 QA disponível
Não haverá testes automatizados completos neste ciclo
Testes realizados apenas em ambiente web
10. Artefatos Gerados:
Plano de Testes (Test Plan)
Casos de Teste Manuais
Scripts de Testes Automatizados (parciais)
Relatórios de Execução de Testes
Relatórios de Defeitos (Bugs)
11. Referências:
Documento de Requisitos do Sistema
Histórias de Usuário
Critérios de Aceite
Documentação da API
Padrões internos de QA
(Etapa 4) Test Case são conjuntos de ações utilizadas para testar cenários com baseado em requisito. Cenários de Testes definem "O que" deve ser testado, enquanto os Casos de Testes definem "Como". Compõe das seguintes etapas:
Contexto do Projeto: Sistema web de pedidos para cafeteria, onde cliente pode montar e finalizar pedidos online.
Caso de Teste 1: Nome / Test Scenario
TC-TS01-001 - Finalizar pedido com um item válido
Este cenário valida se usuário consegue concluir pedido corretamente quando todas condições estão válidas.
Pré-condição:
Sistema disponível
Usuário com acesso à aplicação
Produto cadastrado e disponível no cardápio
API de pedidos em funcionamento
Passos:
Acessar sistema web de pedidos
Visualizar cardápio
Selecionar produto disponível
Adicionar produto ao pedido
Clicar no botão "Finalizar pedido"
Resultado Esperado:
Sistema deve calcular corretamente valor do pedido
Pedido deve ser salvo com sucesso no banco de dados
Sistema deve exibir mensagem de confirmação do pedido
Resultado: N/T (Não testado)
Nível de Prioridade: Alta
Caso de Teste 2: Nome / Test Scenario
TC-TS01-002 - Finalizar pedido com múltiplos itens
Pré-condição:
Sistema disponível
Usuário com acesso à aplicação
Dois ou mais produtos disponíveis no cardápio
API de pedidos ativa
Passos:
Acessar sistema
Adicionar 2 produtos diferentes ao pedido
Alterar quantidade de 1 dos produtos
Conferir valor total do pedido
Finalizar pedido
Resultado Esperado:
Valor total deve refletir corretamente itens e quantidades
Pedido deve ser persistido corretamente
Confirmação do pedido deve ser exibida
Resultado: N/T (Não testado)
Nível de Prioridade: Alta
Caso de Teste 3 (Entrada Inválida): Nome / Test Scenario
TC-TS01-003 - Tentar finalizar pedido sem itens
Pré-condição:
Sistema disponível
Usuário com acesso à aplicação
Carrinho vazio
Passos:
Acessar sistema
Não adicionar nenhum produto
Clicar em "Finalizar pedido"
Resultado Esperado:
Sistema deve impedir finalização do pedido
Mensagem de erro informando que pedido não pode estar vazio
Resultado: N/T (Não testado)
Nível de Prioridade: Alta
(Etapa 5) Test Data mal gerenciados podem levar a cobertura de teste incompleta ou a falsos positivos. Um projeto eficaz de Test Data inclui:
Contexto do Projeto: Sistema web de pedidos para cafeteria, onde clientes realizam pedidos informando:
Produto
Quantidade
Dados do cliente (nome e telefone)
Objetivo do QA: Garantir que diferentes tipos de dados cubram cenários positivos, negativos, limites e variações críticas.
1. Dados Válidos - Testes Positivos:
Esses dados validam comportamento esperado do sistema em condições normais de uso.
Exemplo de Test Data Válido:
Produto: Café Expresso
Quantidade: 1
Nome do cliente: João Silva
Telefone: 11987654321
Objetivo do Teste:
Pedido deve ser criado com sucesso
Valor calculado corretamente
Confirmação exibida ao usuário
Uso real: Executar fluxos principais (happy path) e regressão.
2. Dados Inválidos - Testes Negativos:
Esses dados validam se sistema bloqueia entradas incorretas e exibe mensagens adequadas.
Exemplos de Test Data Inválido:
Produto inexistente
Quantidade: 0
Quantidade: -3
Nome do cliente vazio
Telefone com caracteres alfanuméricos
Objetivo do Teste:
Sistema deve impedir a criação do pedido
Mensagens de erro devem ser claras e corretas
Nenhum dado inválido deve ser persistido no banco
Uso real: Evitar falsos positivos e bugs críticos em produção.
3. Dados de Limite - Boundary Value Analysis:
Esses dados validam comportamento do sistema nos limites inferior e superior.
Regras de Negócio (Exemplo):
Quantidade mínima permitida: 1
Quantidade máxima permitida: 10 itens por produto
Test Data de Limite:
Quantidade = 1 (limite inferior válido)
Quantidade = 10 (limite superior válido)
Quantidade = 0 (abaixo do limite)
Quantidade = 11 (acima do limite)
Objetivo do Teste:
Garantir que limites sejam respeitados
Evitar erros de cálculo ou quebra do sistema
Uso real: Esses dados normalmente pegam bugs que passam em testes básicos.
4. Variações de Dados - Desempenho e Segurança:
Variações para Desempenho:
Pedido com 1 item
Pedido com 10 itens
Pedido com múltiplos produtos e quantidades máximas
Execução simultânea de múltiplos pedidos
Objetivo:
Verificar tempo de resposta
Garantir estabilidade sob carga moderada
Variações para Segurança:
Nome do cliente com script HTML
Nome com SQL Injection básico
Campos com strings extremamente longas
Envio de payload malformado via API
Objetivo:
Garantir sanitização de dados
Evitar falhas de segurança comuns
Prevenir persistência de dados maliciosos
Uso real: Mesmo quando não há time de segurança, o QA cobre o básico.
(Etapa 6) Test Environment controlado é essencial para testes confiáveis. Isso envolve:
Contexto do Projeto: Sistema web de pedidos para cafeteria, composto por:
Frontend web
Backend com API REST
Banco de dados relacional
Serviço externo de notificação
Objetivo do QA: Garantir que testes sejam executados em um ambiente estável, previsível e rastreável, evitando falsos resultados.
1. Configuração de Ambientes Separados:
Ambientes Definidos no Projeto:
Desenvolvimento (DEV)
Utilizado pelos desenvolvedores para implementação e testes locais.
Teste (QA)
Ambiente exclusivo para execução de testes funcionais, regressão e automação.
Homologação (HML)
Ambiente próximo de produção, usado para validação final e aceite do negócio.
Produção (PROD)
Ambiente real, utilizado pelos clientes finais.
Prática real de QA: validar se ambiente de teste está isolado e não depende de dados ou serviços de produção.
2. Definição de Dependências de Hardware, Software e Terceiros:
Dependências de Hardware:
Servidor com capacidade mínima definida
Estações de teste com acesso à internet
Dispositivos para testes básicos de compatibilidade (desktop)
Dependências de Software:
Sistema operacional Linux no servidor
Navegadores Chrome e Firefox em versões estáveis
Banco de dados PostgreSQL
Backend rodando com Java ou Python
Frontend acessível via navegador
Dependências de Terceiros:
Serviço externo de envio de notificações
Gateway de mensagens (mockado em QA)
Serviço de autenticação (quando aplicável)
Ação real do QA: Solicitar mock ou stub de serviços externos para evitar instabilidade nos testes.
3. Implantação da Versão Correta do Software:
Controle de Versão:
Identificação da versão testada: v1.3.0
Commit ou tag associada à versão
Registro da versão nos relatórios de teste
Atividade do QA:
Confirmar que build implantado é mais recente
Validar se ambiente foi atualizado corretamente
Evitar testar versões desatualizadas ou parciais
4. Configuração de Frameworks de Automação:
Ferramentas Utilizadas:
Framework de automação web (ex: Selenium ou Cypress)
Framework de testes de API
Gerenciador de dependências
Pipeline de CI para execução automática
Configuração no Ambiente de Teste:
URLs apontando para ambiente QA
Dados de teste específicos
Execução de testes automatizados a cada novo deploy
Geração de relatórios automáticos
Visão prática: QA valida que testes automatizados não apontam para DEV ou PROD por engano.
5. Boas Práticas Aplicadas pelo QA:
Ambientes claramente documentados
Controle de acesso por perfil
Base de dados exclusiva para testes
Reset ou seed de dados antes da execução
Registro de instabilidades do ambiente
Comunicação constante com DevOps
(Etapa 7) Test Execution iniciados após configuração dos ambientes e frameworks. Compõe as seguintes atividades:
Contexto do Projeto: Sistema web de pedidos para cafeteria, com:
Ambiente de teste (QA) configurado
Framework de automação funcional e de API disponível
Casos de teste documentados e versionados
Objetivo do QA nesta fase: Executar testes de forma eficiente, confiável e rastreável, analisando resultados e identificando falhas reais.
1. Revisão dos Casos de Teste:
Antes de iniciar execução, QA realiza revisão rápida dos casos de teste.
Atividades realizadas:
Verificar se casos de teste estão alinhados aos requisitos atualizados
Validar se pré-condições estão claras e possíveis de serem atendidas
Conferir se passos estão objetivos e sem ambiguidades
Garantir que resultado esperado esteja mensurável
Exemplo real:
Caso de teste menciona botão "Finalizar"
QA valida se nome do botão ainda existe na interface
Caso contrário, teste é ajustado antes da execução
2. Remoção de Casos de Teste Duplicados:
Durante revisão, QA identifica redundâncias.
2 casos testam:
Finalização de pedido com 1 item válido
Finalização de pedido com item único válido
Ação do QA:
Manter apenas 1 caso bem descrito
Ajustar cobertura para evitar sobreposição
Atualizar matriz de rastreabilidade
3. Preparação para Execução dos Testes:
Checklist antes de executar:
Ambiente QA disponível e estável
Versão correta do sistema implantada
Base de dados preparada com massa de teste
Ferramentas de teste acessíveis
Scripts automatizados apontando para o ambiente correto
4. Execução de Casos de Teste Manuais:
Execução prática:
QA executa casos de teste por prioridade
Fluxos críticos executados primeiro
Resultados registrados caso a caso
Exemplo de registro:
Resultado: Pass
Evidência: print da tela de confirmação do pedido
Observações: execução dentro do tempo esperado
5. Execução de Scripts de Teste Automatizados:
Execução:
Scripts de regressão são disparados
Testes de API e UI executados
Logs e relatórios gerados automaticamente
Análise dos Resultados:
Testes aprovados confirmados
Falhas analisadas individualmente
Identificação de falhas reais vs problemas de ambiente
Exemplo real:
Teste falhou por timeout
QA verifica instabilidade do ambiente
Caso não seja bug, teste é marcado como bloqueado
6. Análise e Consolidação dos Resultados:
Atividades finais do QA:
Consolidar quantidade de testes executados
Avaliar taxa de aprovação e falhas
Registrar defeitos encontrados
Comunicar status ao time
Exemplo de status:
Total de testes: 45
Pass: 38
Fail: 5
Blocked: 2
Pairwise Testing (all-pairs testing) é método de teste de software que examina todas combinações possíveis de pares de parâmetros de entrada. Essa abordagem é particularmente útil quando o teste exaustivo é impraticável devido ao grande número de casos de teste potenciais. Compõe das seguintes etapas:
Matrizes ortogonais são conceito matemático usado em testes de pares para projetar experimentos ou casos de teste de forma sistemática e eficiente. Ferramentas para Paiwise Testing são PICT (Pairwise Independent Combinatorial Testing), Hexawise, Testersdesk, ACTS (Automated Combinatorial Testing for Software) e AllPairs.
Teste de combinações de funcionalidades
Cenário: Site simples de e-commerce
Objetivo: validar combinações de funcionalidades utilizando pairwise testing (teste em pares)
Funcionalidades consideradas:
Métodos de Pagamento: Cartão de Crédito, PayPal, Transferência Bancária
Métodos de Envio: Padrão, Expresso, Noturno
Tipos de Cliente: Novo, Recorrente, Visitante
Abordagem:
Utilização do pairwise testing para garantir que todas as combinações possíveis em pares entre as funcionalidades sejam testadas
Redução da quantidade total de casos de teste, mantendo uma boa cobertura de testes
Exemplos de casos de teste gerados:
Caso de Teste 1
Método de Pagamento: Cartão de Crédito
Método de Envio: Padrão
Tipo de Cliente: Novo
Caso de Teste 2
Método de Pagamento: Cartão de Crédito
Método de Envio: Expresso
Tipo de Cliente: Recorrente
Caso de Teste 3
Método de Pagamento: Cartão de Crédito
Método de Envio: Noturno
Tipo de Cliente: Visitante
Caso de Teste 4
Método de Pagamento: PayPal
Método de Envio: Padrão
Tipo de Cliente: Recorrente
Caso de Teste 5
Método de Pagamento: PayPal
Método de Envio: Expresso
Tipo de Cliente: Visitante
Caso de Teste 6
Método de Pagamento: PayPal
Método de Envio: Noturno
Tipo de Cliente: Novo
Caso de Teste 7
Método de Pagamento: Transferência Bancária
Método de Envio: Padrão
Tipo de Cliente: Visitante
Caso de Teste 8
Método de Pagamento: Transferência Bancária
Método de Envio: Expresso
Tipo de Cliente: Novo
Caso de Teste 9
Método de Pagamento: Transferência Bancária
Método de Envio: Noturno
Tipo de Cliente: Recorrente
Model-Based Testing (MBT) é abordagem de teste via uso de modelos. Ao contrário do teste tradicional, que envolve análise minuciosa de cada detalhe intrincado, teste baseado em modelos adota abordagem geral. Permite que você se concentre nas funcionalidades principais sem se perder em detalhes insignificantes. Diagramas utilizados, conforme nível de abstração:
Modelo do SUT (System Under Test) é diagrama de atividades simplificado, que define quais ações podem ser realizadas, em qual ordem, e quais passos devem preceder ou podem seguir outros.
Aplicação sob teste (AUT) simula tela de máquina de café, permitindo:
Escolher bebida
Ajustar açúcar e leite
Finalizar preparo
Casos de teste iniciais:
1º caso de teste: Preparo de espresso, sem adicionais
2º caso de teste: Preparo de latte, e Ajuste de leite e açúcar
Cada caso de teste corresponde a 1 caminho no diagrama de atividades
Durante execução:
Squish assume controle da AUT
Reproduz passos na ordem definida pelo modelo
Cada passo possui 1 implementação, escrita em linguagem de programação
@mbt.step("Click on Macchiato")
def step():
mouseClick(waitForObject(names.macchiato_button))
test.vp("VP_macchiato")
# -------- Ajustando leite e açúcar --------
@mbt.step("Set milk")
def step():
mousePress(waitForObject(names.milk_slider_handle))
slider = waitForObject(names.coffee_sugarSlider_Slider)
x = builtins.int(slider.width * random.random())
y = builtins.int(slider.height * 0.5)
mouseMove(slider, x, y)
mouseRelease()
snooze(0.5)
Adicionando novo passo ao modelo MBT:
Identificado que faltava no modelo funcionalidade de voltar para tela anterior e escolher outra bebida
Etapas realizadas no Squish IDE:
Add Step Mode
Criação do novo passo: "Go back"
Connect Steps Mode
Conexão do novo passo aos demais no diagrama
Generate missing steps implementations
Geração automática do esqueleto do passo
Implementação real do passo
Substituição do código vazio por ação concreta:
@mbt.step("Go back")
def step():
mouseClick(waitForObject(names.back_button))
Black-box testing (teste de caixa-preta) é técnica de teste de software onde tester avalia funcionalidade do sistema sem conhecer estrutura interna do código. Objetivo é verificar se software atende aos requisitos especificados, testando entradas e saídas sem considerar implementação interna. Técnicas black-box:
Um sistema de cadastro de usuários possui campo idade, com seguinte regra de negócio:
Idade aceita deve estar entre 18 e 65 anos
Valores fora desse intervalo não são permitidos
Campo é obrigatório
Sistema exibe mensagem de erro para valores inválidos
Tester não conhece código interno, apenas requisitos funcionais.
Partições de equivalência identificadas:
Tester divide entradas possíveis em grupos (partições) que devem ter mesmo comportamento do sistema
Partições válidas:
Idade entre 18 e 65 (Exemplo: 25, 40, 60)
Partições inválidas:
Idade menor que 18 (Exemplo: 10, 15, 17)
Idade maior que 65 (Exemplo: 66, 80, 100)
Campo vazio ou nulo (Exemplo: não informar idade)
Valor não numérico (Exemplo: "abc", "@#", "vinte")
Casos de teste derivados (black-box):
Caso de Teste - Entrada (Idade) - Partição - Resultado Esperado
CT01 - 25 - Válida - Cadastro realizado com sucesso
CT02 - 17 - Inválida (<18) - Mensagem de erro exibida
CT03 - 70 - Inválida (>65) - Mensagem de erro exibida
CT04 - (vazio) - Inválida (obrigatório) - Mensagem de campo obrigatório
CT05 - "abc" - Inválida (não numérico) - Mensagem de erro exibida
Um sistema de e-commerce aplica desconto no pedido de acordo com três condições:
Cliente é VIP?
Valor da compra é maior ou igual a R$ 200?
Cupom de desconto é válido?
Regras de negócio:
Desconto só é aplicado se:
Cliente for VIP OU Valor da compra maior ou igual a R$ 200 E cupom precisa ser válido
Caso contrário, nenhum desconto é aplicado
Condições:
Condição - Descrição
C1 - Cliente é VIP
C2 - Valor da compra maior ou igual a R$ 200
C3 - Cupom válido
Ações:
Ação - Descrição
A1 - Aplicar desconto
A2 - Não aplicar desconto
Tabela de decisão:
Regra - Cliente VIP (C1) - Compra maior ou igual a R$ 200 (C2) - Cupom válido (C3) - Ação
R1 - Sim - Sim - Sim - Aplicar desconto
R2 - Sim - Não - Sim - Aplicar desconto
R3 - Não - Sim - Sim - Aplicar desconto
R4 - Não - Não - Sim - Não aplicar desconto
R5 - Sim - Sim - Não - Não aplicar desconto
R6 - Sim - Não - Não - Não aplicar desconto
R7 - Não - Sim - Não - Não aplicar desconto
R8 - Não - Não - Não - Não aplicar desconto
Casos de teste derivados:
Caso de Teste - VIP - Valor da Compra - Cupom - Resultado Esperado
CT01 - Sim - R$ 250 - Válido - Desconto aplicado
CT02 - Sim - R$ 150 - Válido - Desconto aplicado
CT03 - Não - R$ 300 - Válido - Desconto aplicado
CT04 - Não - R$ 100 - Válido - Sem desconto
CT05 - Sim - R$ 220 - Inválido - Sem desconto
CT06 - Não - R$ 210 - Inválido - Sem desconto
CT07 - Sim - R$ 80 - Inválido - Sem desconto
CT08 - Não - R$ 50 - Inválido - Sem desconto
Sistema de transferência bancária possui seguinte regra:
Valor mínimo para transferência: R$ 10,00
Valor máximo para transferência: R$ 5.000,00
Valor deve estar dentro desse intervalo, inclusive
Valores fora do intervalo devem ser rejeitados
Tester avalia apenas entradas e saídas, sem conhecer implementação interna (teste de caixa-preta)
Limites identificados:
Limite inferior: Valor mínimo permitido: R$ 10,00
Limite superior: Valor máximo permitido: R$ 5.000,00
Valores de teste escolhidos: Para cada limite, o QA testa:
Valor abaixo do limite
Valor exato do limite
Valor acima do limite
Casos de teste (valores limite):
Caso de Teste - Valor da Transferência - Tipo de Valor - Resultado Esperado
CT01 - R$ 9,99 - Abaixo do limite inferior - Transferência recusada
CT02 - R$ 10,00 - Limite inferior - Transferência realizada
CT03 - R$ 10,01 - Acima do limite inferior - Transferência realizada
CT04 - R$ 4.999,99 - Abaixo do limite superior - Transferência realizada
CT05 - R$ 5.000,00 - Limite superior - Transferência realizada
CT06 - R$ 5.000,01 - Acima do limite superior - Transferência recusada
Aplicativo de delivery de comida permite que usuário:
Faça login
Busque restaurantes
Selecione produtos
Finalize pedido
QA testa sistema a partir da interação real do usuário, seguindo fluxo do negócio
Caso de uso: Realizar pedido de comida
Ator: Cliente
Objetivo: Permitir que cliente realize pedido com sucesso
Pré-condições:
Usuário cadastrado no sistema
Usuário autenticado (login realizado)
App com conexão à internet
Fluxo principal (cenário feliz):
Usuário acessa aplicativo
Usuário realiza login com credenciais válidas
Usuário pesquisa restaurante
Usuário seleciona restaurante disponível
Usuário adiciona produtos ao carrinho
Usuário acessa carrinho
Usuário escolhe forma de pagamento
Usuário confirma pedido
Sistema processa pagamento
Sistema exibe confirmação do pedido
Resultado esperado:
Pedido realizado com sucesso
Número do pedido exibido ao usuário
Fluxos alternativos (cenários):
Cenário alternativo 1 - Pagamento recusado
No passo 9, pagamento falha
Sistema exibe mensagem de erro
Pedido não é confirmado
Cenário alternativo 2 - Restaurante indisponível
No passo 4, restaurante fica indisponível
Sistema informa indisponibilidade
Usuário retorna à lista de restaurantes
Cenário alternativo 3 - Carrinho vazio
Usuário tenta confirmar pedido sem itens
Sistema bloqueia ação
Mensagem de aviso exibida
Casos de teste derivados do caso de uso:
Caso de Teste - Cenário - Resultado Esperado
CT01 - Fluxo principal completo - Pedido realizado com sucesso
CT02 - Pagamento recusado - Pedido não confirmado
CT03 - Restaurante indisponível - Pedido não iniciado
CT04 - Carrinho vazio - Mensagem de erro exibida
Sistema de pedidos online possui pedido que muda de estado conforme ações do usuário e do sistema.
Estados possíveis do pedido:
Novo
Pago
Em preparo
Enviado
Entregue
Cancelado
Transições permitidas:
Estado Atual - Ação - Próximo Estado
Novo - Confirmar pagamento - Pago
Pago - Iniciar preparo - Em preparo
Em preparo - Enviar pedido - Enviado
Enviado - Confirmar entrega - Entregue
Novo - Cancelar pedido - Cancelado
Pago - Cancelar pedido - Cancelado
Transições não permitidas (exemplos):
Enviado - Pago
Entregue - Em preparo
Cancelado - Qualquer outro estado
Casos de teste baseados em transições:
Caso de Teste 1 - Fluxo válido completo
Criar pedido (estado: Novo):
Confirmar pagamento - Pago
Iniciar preparo - Em preparo
Enviar pedido - Enviado
Confirmar entrega - Entregue
Resultado esperado: Pedido entregue com sucesso
Caso de Teste 2 - Cancelamento antes do pagamento
Criar pedido (estado: Novo):
Cancelar pedido - Cancelado
Resultado esperado: Pedido cancelado corretamente
Caso de Teste 3 - Cancelamento após pagamento
Criar pedido (estado: Novo):
Confirmar pagamento - Pago
Cancelar pedido - Cancelado
Resultado esperado: Pedido cancelado e reembolso iniciado
Caso de Teste 4 - Transição inválida
Criar pedido (estado: Novo)
Tentar confirmar entrega
Resultado esperado:
Sistema bloqueia a ação
Mensagem de erro exibida
Tabela de transições (resumo):
Estado Inicial - Ação - Estado Final - Válido?
Novo - Confirmar pagamento - Pago - Sim
Pago - Enviar pedido - Enviado - Não
Cancelado - Iniciar preparo - Em preparo - Não
Enviado - Confirmar entrega - Entregue - Sim
Experience-based testing AQUI...
White-Box testing AQUI...
Bug Report é relatório apresentando informações detalhadas sobre erro (bug). Dados serão cadastrados em planilhas ou ferramentas de gerenciamento de falhas, como Jira, Mantis, Testlink, etc. Compõe das seguintes etapas:
EXEMPLO DE BUG REPORT AQUI...
Elaborado por Mateus Schwede
ubsocial.github.io