🧪 ATIVIDADE 09: QUALIDADE E TESTES DE SOFTWARE

📖 Fundamentação Teórica

Para realizar este laboratório com sucesso, certifique-se de ter compreendido os conceitos apresentados no:
👉 CAPÍTULO 09: FUNDAMENTOS DA MODELAGEM

Bem-vindo a mais uma etapa da sua jornada no curso de Gestão de TI / Desenvolvimento de Sistemas. Hoje vamos mergulhar em conceitos que conectam a teoria técnica diretamente com o padrão de excelência da qualidade, garantindo que o software seja robusto e confiável antes de chegar ao cliente final. 🛡️🧩


🎯 Objetivos de Aprendizagem do Laboratório

Ao final deste laboratório prático (estimativa: 4 horas presenciais / autoguiadas), você será capaz de:

  • Diferenciar Verificação (Estamos construindo o produto certo?) de Validação (Estamos construindo o produto corretamente?).
  • Redigir Casos de Teste (Test Cases) com passo a passo e resultados esperados.
  • Aplicar a técnica de Teste de Caixa Preta (Black-Box), focando em testes positivos e negativos.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, os desenvolvedores terminaram o "App de Rastreamento". No entanto, no primeiro dia de uso, um motorista tentou digitar o número da placa e o sistema travou porque ele usou letras minúsculas. O cliente tentou rastrear um pedido inexistente e o App exibiu uma tela de erro técnica (código 500) em vez de uma mensagem amigável.

O custo de imagem da empresa foi lá embaixo.

"Seu desafio como Analista de QA (Quality Assurance) é criar um Plano de Testes. Você deve antecipar o erro humano e criar roteiros que garantam que, mesmo que o usuário faça 'bobagem', o sistema se comporte de forma segura e elegante."


🧠 Fundamentos: A Teoria Traduzida

Testar software não é apenas "clicar para ver se funciona". É tentar provar que o sistema falha.

O Caso de Teste (Test Case)

Um caso de teste é um experimento científico controlado. Ele tem:

  1. Ação: O que eu faço? (Ex: Digito a senha errada).
  2. Resultado Esperado: O que deve acontecer? (Ex: Mensagem de erro "Senha inválida").

Testes Positivos vs Negativos

  • Positivo: O usuário faz tudo certo. (Ex: Login com dados corretos).
  • Negativo: O usuário faz tudo errado ou tenta "quebrar" o sistema. (Ex: Colocar letras no campo de 'Quantidade' ou deixar campos obrigatórios vazios).

📊 Visualizando a Lógica

Dica

Um bom QA não testa apenas o que o sistema faz, mas o que o sistema NÃO DEVE fazer.

```mermaid flowchart LR A[Entrada de Dados] --> B{Filtro de Teste} B -- "Dados Válidos" --> C[Sucesso] B -- "Dados Inválidos" --> D[Tratamento de Erro Amigável] ```

📖 Exemplo Guiado

Abaixo, veja como estruturar um Caso de Teste para o login da TecProExpress.

IDTítulo do TesteAção do UsuárioResultado Esperado
CT01Login VazioClica em 'Entrar' sem digitar nada.O sistema deve exibir "Campos Obrigatórios".
CT02Formato CPFDigita CPF sem pontos e traços.O sistema deve formatar e aceitar o login.

📊 A Pirâmide de Testes da Engenharia Profissional

flowchart TD
    subgraph P [Níveis de Cobertura e Esforço]
        direction BT
        E2E["Testes de Interface / Ponta a Ponta (E2E)<br/>(Lentos / Altamente Frágeis / Cobertura Focada)"]
        INT["Testes de Integração<br/>(Médio esforço / Valida comunicações entre APIs)"]
        UNI["Testes de Unidade (JUnit)<br/>(Ultra rápidos / Baratos / Cobertura massiva)"]
        UNI --> INT --> E2E
    end
    style UNI fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    style INT fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style E2E fill:#fffde7,stroke:#fbc02d,stroke-width:2px

🛠️ Estrutura do Roteiro de Teste

# CT03: Teste de Upload de Comprovante

**Objetivo:** Validar se o sistema aceita apenas imagens de comprovantes.
**Pré-condição:** Estar na tela de finalização de entrega.
**Passos:**
1. Clicar no botão "Anexar Foto".
2. Tentar selecionar um arquivo do tipo ".PDF".
3. Clicar em "Confirmar".

**Resultado Esperado:** O sistema deve bloquear a seleção do PDF e exibir o erro "Formato não permitido. Use JPG ou PNG".

🔍 Detalhamento do Processo:

  • Note que o roteiro é tão detalhado que qualquer pessoa (mesmo quem não conhece o sistema) conseguiria executá-lo. Isso permite a Reprodutibilidade do Erro.

🛠️ Prática Obrigatória 1: Tabela de Casos de Teste

Cenário: O projeto semestral da sua equipe.

  1. Escolha 3 Requisitos Funcionais da sua Atividade 03.
  2. Para cada requisito, crie 2 Casos de Teste (um positivo e um negativo).
  3. Organize-os em uma tabela contendo: ID, Título, Ação e Resultado Esperado.

🏁 Resultado Esperado (Para sua Referência)

Uma tabela com 6 roteiros de teste (3 pares) que cubram as funcionalidades críticas do seu sistema.


💻 Suíte de Testes Automatizados em Python (Pytest)

Para transformar sua tabela de casos de teste em asserções automatizadas executáveis via pytest:

# test_entregas_qa.py
import pytest

def calcular_frete(peso_kg: float, distancia_km: float) -> float:
    if peso_kg <= 0:
        raise ValueError("O peso do pacote deve ser estritamente positivo.")
    if distancia_km <= 0:
        raise ValueError("A distância percorrida deve ser maior que zero.")
    return 15.0 + (peso_kg * 1.5) + (distancia_km * 0.8)

# 1. Caso de Teste Positivo (Caminho Feliz)
def test_calcular_frete_sucesso():
    valor = calcular_frete(peso_kg=10.0, distancia_km=50.0)
    assert valor == 70.0, f"Esperado R$ 70.00, mas obteve R$ {valor}"

# 2. Caso de Teste Negativo (Entrada Inválida com Exceção)
def test_calcular_frete_peso_negativo():
    with pytest.raises(ValueError, match="estritamente positivo"):
        calcular_frete(peso_kg=-5.0, distancia_km=50.0)

🖥️ Saída Esperada no Terminal ao Executar pytest:

============================= test session starts =============================
platform win32 -- Python 3.11.2, pytest-9.1.1, pluggy-1.6.0
rootdir: D:\SourceCode\GitRepos\github.io\portal_mdbook
collected 2 items

test_entregas_qa.py ..                                                  [100%]

============================== 2 passed in 0.04s ==============================

🌐 Exemplo de Requisição cURL para Teste de Erro 422/400 (Swagger /docs)

# Teste Negativo: Enviando peso negativo para a API
curl -X POST "http://127.0.0.1:8000/api/v1/frete/calcular" \
     -H "Content-Type: application/json" \
     -d '{
       "peso_kg": -10.0,
       "distancia_km": 50.0
     }'

🔹 Resposta de Erro Tratada (HTTP 422 Unprocessable Entity):

{
  "detail": [
    {
      "loc": ["body", "peso_kg"],
      "msg": "ensure this value is greater than 0",
      "type": "value_error.number.not_gt"
    }
  ]
}

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus roteiros de teste:

  1. Salve o arquivo de documentação com o nome Atividade_09.md na pasta es-atv-09-testes/ do seu repositório GitHub.
  2. Certifique-se de fazer o commit e push para o repositório público.
  3. Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

Importante

Reflexão Profissional: O que é mais caro para uma empresa: encontrar um erro durante a fase de Requisitos (Atividade 03) ou encontrar esse mesmo erro depois que o software já foi entregue para 10.000 clientes? (Resposta: Depois da entrega. O custo de correção no mercado pode ser até 100x maior devido a recalls, suporte e perda de reputação). 🧠🛡️

---

📊 Rubrica Formativa de Avaliação

Critério de Avaliação Insuficiente (0% - 40%) Regular (41% - 70%) Excelente (71% - 100%)
Casos de Teste (Positivo & Negativo) Menos de 6 roteiros ou contendo apenas testes positivos óbvios. Cria 6 casos de teste mas sem clareza no resultado esperado. Tabela completa com 6 casos de teste (3 pares Positivo/Negativo) cobrindo ID, Título, Ação e Resultado Esperado.
Teste de Caixa Preta & Defesa do Sistema Omite o cenário de teste de validação de dados/caixa preta. Descreve o cenário negativo sem indicar a ação de defesa do sistema. Detalhamento impecável de teste de borda/caixa preta e comportamento defensivo da aplicação.
Entrega no GitHub Entrega fora da pasta `es-atv-09-testes/`. Arquivo entregue mas sem tabela organizada em Markdown. `Atividade_09.md` publicado com formatação limpa e validada.