Módulo 6: SQL no dia a dia de QA

Validação de dados: achar quem quebra a regra

-- pedido que não foi cancelado mas está com valor zerado
SELECT id, status, valor_total
FROM pedidos
WHERE status <> 'cancelado'
  AND valor_total = 0;

A regra de negócio diz "todo pedido ativo tem valor". A query procura quem quebra isso. O trabalho de QA: rodar, achar as linhas, investigar por quê. Variações: WHERE quantidade <= 0 em itens_pedido; ou comparar o valor_total do pedido com SUM(quantidade * preco_unitario) dos itens via JOIN + GROUP BY + HAVING.

Métrica: taxa de aprovação por suite

SELECT suite,
       COUNT(*) AS total,
       SUM(CASE WHEN resultado = 'passou' THEN 1 ELSE 0 END) AS passaram,
       ROUND(
         100.0 * SUM(CASE WHEN resultado = 'passou' THEN 1 ELSE 0 END) / COUNT(*),
         1
       ) AS taxa_aprovacao_pct
FROM execucoes_teste
GROUP BY suite;

Junta o SUM(CASE...) (módulo 2) com GROUP BY (módulo 3). Pra cada suite: total, quantas passaram e a porcentagem. O 100.0 (com casa decimal) força divisão fracionária; com 100 inteiro o SQLite arredondaria pra 0.

Conferir escrita depois de um teste de API

-- logo depois do teste que criou um pedido pro cliente 42
SELECT *
FROM pedidos
WHERE cliente_id = 42
ORDER BY id DESC
LIMIT 1;

Depois de um teste de API que cria um pedido, você vai ao banco conferir: o pedido apareceu? O valor_total bate com o que a API recebeu? O status inicial é 'novo'? ORDER BY id DESC LIMIT 1 pega o registro mais recente.

Olhar de QA

Aqui está a habilidade que mais rende na carreira: achar, sozinho, a linha que viola a regra. Mas guarde duas cautelas. A primeira: zero linhas pode significar "está tudo certo" ou "a sua query está errada", então prove que a consulta funciona antes de concluir. A segunda: achar a linha torta é metade do trabalho; a outra metade é decidir se o defeito está no dado ou na regra que você assumiu. Às vezes ele está na especificação.