SQL para QA se concentra em descobrir o que realmente aconteceu com os dados, em vez de otimização profunda de consultas ou trabalho de DBA. Quando interface e API discordam, o banco de dados geralmente fornece a evidência mais direta.
Mesmo o SQL básico melhora substancialmente os testes. Ele verifica se os registros foram criados, os status persistiram, as duplicatas apareceram, os relacionamentos estão corretos, os relatórios foram reconciliados ou os dados desapareceram após uma ação.
Por que QA precisa de SQL
No trabalho diário, o SQL geralmente atende a três objetivos:
- →Verifique o estado real dos dados após um cenário
- →Investigue defeitos mais rapidamente
- →Identificar se o problema está na interface, API, lógica ou nos dados
Muitos defeitos aparentes dos botões são, na verdade, problemas de estado dos dados.
- →Um registro aparece na interface, mas faltam linhas relacionadas
- →A API informa sucesso, mas uma atualização não foi salva
- →Um relatório usa dados errados
- →Novas tentativas criam duplicatas
- →Um filtro parece quebrado porque os dados armazenados já diferem das expectativas do produto
Sem SQL, essas investigações podem ser lentas e mal informadas.
O que aprender primeiro
QA não precisa inicialmente de toda a linguagem. Comece dominando alguns fundamentos.
- →SELECT recupera dados
- →WHERE filtra linhas
- →ORDER BY controla a ordenação
- →LIMIT evita a recuperação de linhas desnecessárias
- →COUNT mede quantidade
- →JOIN conecta dados entre tabelas
- →GROUP BY expõe agregados e duplicatas
- →IS NULL e IS NOT NULL verificam valores null
Eles cobrem uma grande parte das tarefas diárias de teste.
Entenda o propósito de cada construção, bem como sua sintaxe. Com tabelas de pedidos, usuários e pagamentos, SQL pode verificar o cenário completo em vez de apenas exibir linhas.
O que SQL oferece a QA
A maior força do SQL é a precisão.
A interface mostra informações selecionadas; uma API expõe a resposta de uma chamada. A inspeção direta dos dados pode responder:
- →O registro foi criado?
- →Quantos desses registros realmente existem?
- →Existem duplicatas?
- →Qual usuário possui a entidade?
- →O status correto foi salvo?
- →Existem registros órfãos?
- →O valor corresponde à interface?
- →A operação realmente mudou o registro ou apenas pareceu mudar?
Isso é particularmente útil para integrações, filas, novas tentativas, trabalhos em segundo plano, atualizações em massa e relacionamentos complexos entre entidades.
JOIN para QA
JOIN é especialmente valioso porque mostra como as entidades se relacionam, além de inspecionar tabelas individualmente.
- →Todo pedido tem um dono
- →Um pedido tem os itens de pedido necessários
- →Um pagamento pertence ao pedido correto
- →Um usuário tem o papel correto
- →Nenhum registro faz referência a objetos inexistentes
Muitas vezes, um registro existe, mas está vinculado incorretamente ou parte de sua cadeia de relacionamento está quebrada. JOIN torna esses defeitos mais fáceis de ver.
Erros comuns de SQL em QA
- →Confundindo NULL com um valor vazio
- →Ignorando linhas duplicadas introduzidas por JOIN
- →Inspecionando apenas a primeira linha conveniente
- →Executando gravações desnecessárias
A abordagem normal mais segura é ler primeiro e fazer alterações deliberadas apenas em um ambiente apropriado. SELECT é suficiente para a maioria das investigações.
Exemplo prático
Suponha que um usuário relate dois pedidos idênticos.
A interface fornece uma visão parcial e um endpoint de API mostra uma parte. SQL pode estabelecer muito mais:
- →Se realmente existem duas linhas de pedido
- →Se as chaves comerciais correspondem
- →Se eles foram criados ao mesmo tempo
- →Se ambos têm itens de pedido idênticos
- →Se uma nova tentativa criou a duplicata
- →Se há dois pagamentos ou apenas um
- →Se a duplicação é real ou se a interface mostra um registro duas vezes
Aqui o SQL se torna uma ferramenta QA prática, em vez de um extra técnico opcional.
Hábitos práticos para QA
- →Comece com um SELECT simples
- →Inspecione primeiro uma entidade e depois seus relacionamentos
- →Estabeleça sempre qual chave identifica os dados
- →Evite conclusões de uma linha quando um padrão mais amplo for importante
- →Trate as consultas de gravação com cuidado
- →Em caso de dúvida, compare as evidências SQL com o comportamento da API e da interface
SQL é especialmente poderoso como ponte entre as camadas do sistema.
Principais conclusões para QA
- →QA usa SQL para verificar a realidade dos dados em vez de programar um banco de dados.
- →SELECT básico, WHERE, JOIN, COUNT e GROUP BY suportam fortes investigações de defeitos.
- →Muitos defeitos do produto são problemas de estado dos dados.
- →Conectar UI, API e evidências de banco de dados é uma habilidade de teste valiosa.
- →SQL torna o diagnóstico mais preciso, rápido e metódico.
Leitura adicional
- →Nesta base de conhecimento: Teste de banco de dados
- →Nesta base de conhecimento: JSON e XML
- →Recurso externo: Tutorial de junções do PostgreSQL
Pratique em um conjunto de dados compartilhado: oito exercícios verificados
Use a folha de exercícios vinculada do QA Hub e sql-for-qa-fixture.sql, em vez de criar um segundo conjunto de dados. Ele contém quatro clientes fictícios e cinco pedidos, com valores inteiros em centavos. O passo a passo aqui usa SQLite 3; o recurso também descreve SQL portável, mas estas instruções não afirmam uma execução no PostgreSQL. Baixe os dois arquivos, abra um terminal nesse diretório e mantenha uma sessão aberta.
sqlite3 :memory:
-- At the SQLite prompt:
.read sql-for-qa-fixture.sql
SELECT COUNT(*) FROM qa_customers;
-- Expected: 4
SELECT COUNT(*) FROM qa_orders;
-- Expected: 5A fixture cria tabelas temporárias na sessão atual. Uma nova sessão :memory: começa vazia; repetir CREATE na mesma sessão sem reiniciar falha porque as tabelas já existem. Feche a sessão descartável e inicie outra para recomeçar. Não são necessárias conexões ou credenciais de produção.
Preveja as linhas antes de abrir a folha de respostas
Tarefa no recurso Resultado esperado
1 Pedidos pagos (101, 1, 1200), (103, 2, 700), (105, 3, 0)
2 Pedidos por cliente, incluindo zero (1, Ada, 2), (2, Boris, 2), (3, Chen, 1), (4, Dina, 0)
3 Receita paga por cliente (1, 1200), (2, 700), (3, 0), (4, 0)
4 Clientes sem pedidos (4, Dina)
5 E-mails duplicados não nulos (ada@example.invalid, 2)
6 Valor pago inválido segundo a regra do exercício (105, 0)
7 Pelo menos dois pedidos (1, 2), (2, 2)
8 E-mail ausente (4, Dina)Estes são os mesmos números de tarefa e resultados da planilha para download. O e-mail duplicado e o pedido pago com valor zero são exemplos inseridos deliberadamente. Se representam um defeito em um produto real depende dos requisitos. Não deduza regras de unicidade, valor positivo ou normalização apenas a partir de uma consulta.
A armadilha do LEFT JOIN: total correto com um cliente ausente
Compare estas duas consultas após carregar a massa de dados compartilhada. A regra do relatório é mostrar os quatro clientes, incluindo aqueles sem pedidos pagos. A primeira consulta coloca o filtro de pagamento no WHERE:
SELECT c.customer_id, COALESCE(SUM(o.amount_cents), 0) AS paid_cents
FROM qa_customers c
LEFT JOIN qa_orders o ON o.customer_id = c.customer_id
WHERE o.status = 'paid'
GROUP BY c.customer_id ORDER BY c.customer_id;Ela retorna (1,1200), (2,700), (3,0): Dina desaparece. A linha sem correspondência tem campos de pedido NULL, portanto a condição WHERE não a mantém. A soma ainda é 1900 centavos; por isso, verificar apenas o total geral não revela o defeito.
Coloque o filtro na condição de junção para preservar os clientes sem correspondência:
SELECT c.customer_id, COALESCE(SUM(o.amount_cents), 0) AS paid_cents
FROM qa_customers c
LEFT JOIN qa_orders o
ON o.customer_id = c.customer_id AND o.status = 'paid'
GROUP BY c.customer_id ORDER BY c.customer_id;Esperado: (1,1200), (2,700), (3,0), (4,0). Verifique os IDs exatos dos clientes e os valores. Para contar pedidos, use COUNT(o.order_id); COUNT(*) também conta a linha sem correspondência da junção externa. Verifique NULL com IS NULL, em vez de = NULL. A folha de respostas inclui esses casos com consultas executáveis.
Transforme uma divergência em evidência útil
Registre a versão da massa de dados, o dialeto SQL, a consulta, a regra do produto, as linhas esperadas e as obtidas. Ordene explicitamente antes de comparar resultados ordenados. Para resultados sem ordem, compare conjuntos ou multiconjuntos conforme a importância das duplicatas. Executar uma consulta com sucesso não prova que o resultado de negócio está correto.
Continuar aprendendo
Amplie as verificações para o comportamento do banco de dados
Relate uma divergência de dados com evidências
Baixe a massa de dados SQL compartilhada