Habilidades de QA: o técnico e o comportamental que fazem diferença

· Algoritmos e guias, QA e automação, Qualidade de software

Neste guia, você vai ver quais habilidades técnicas e comportamentais realmente fazem diferença no dia a dia de quem trabalha com qualidade de software, por que cada uma importa, como praticar de forma concreta e, no final, um checklist de autoavaliação para descobrir onde investir o seu próximo mês de estudo.

Por que falar das duas coisas juntas

Trabalho com QA desde 2010 e uma coisa ficou clara ao longo desse tempo: ninguém é lembrado só por saber escrever um script de automação, nem só por ser simpático nas reuniões. A pessoa de QA que faz diferença é aquela que encontra o problema certo, entende o impacto dele e consegue fazer o time agir. Isso exige técnica para encontrar e comportamento para convencer. Uma sem a outra rende pouco.

Habilidades técnicas

Análise de requisitos e de risco

Antes de qualquer teste existe uma pergunta: o que pode dar errado e quanto isso custa? Ler uma história de usuário e apontar ambiguidades (“o que acontece se o campo vier vazio?”, “quem pode cancelar o pedido?”) é um dos trabalhos mais valiosos de QA, porque evita defeito antes de ele virar código. Pratique cruzando duas perguntas para cada funcionalidade: qual a chance de falhar e qual o estrago se falhar. O que for alto nas duas recebe mais atenção.

Técnicas de teste

Partição de equivalência, análise de valor limite, tabela de decisão, transição de estados e teste exploratório guiado por charters não são teoria de prova: são atalhos para cobrir mais com menos casos. Um campo de idade que aceita de um intervalo X a Y não precisa de cem testes; precisa dos limites, de um valor válido no meio e dos inválidos de cada lado. Para treinar, gere dados variados no gerador de massa de testes e documentos válidos e inválidos no validador de CPF.

HTTP e APIs

Boa parte das regras de negócio mora na API, não na tela. Entender métodos, códigos de status, cabeçalhos, autenticação e o formato do corpo permite testar mais cedo e isolar onde o problema está. Um teste simples já ensina muito:

curl -i -X POST https://appsquality.com.br/wp-json/aq-lab/v1/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username":"locked_user","password":"..."}'
# Pergunte: o status faz sentido? A mensagem de erro ajuda o cliente
# sem vazar detalhes internos?

A API de prática do Lab tem especificação OpenAPI e usuários como standard_user e locked_user, ótimos para treinar cenários positivos e negativos. Para ler as respostas, use o formatador de JSON, o comparador de JSON e o decodificador de JWT.

SQL

Saber consultar o banco permite confirmar se a tela mostra o que foi realmente gravado, preparar massa e investigar inconsistências. O básico já resolve muito: SELECT com WHERE, JOIN, GROUP BY e funções de agregação. Um exemplo de pergunta que vale ouro em produção ou homologação:

SELECT status, COUNT(*) AS total
FROM pedidos
WHERE criado_em >= CURRENT_DATE
GROUP BY status;

Git

Se o código de teste vive no repositório, você precisa de branch, commit, pull request, rebase ou merge e resolução de conflito sem pânico. Além disso, ler o diff de um pull request antes de testar mostra exatamente o que mudou e onde focar.

Lógica e uma linguagem de programação

Escolha uma linguagem que o seu time ou o mercado que você mira usa (JavaScript/TypeScript, Python ou Java são escolhas comuns) e vá fundo nela em vez de pular entre várias. Variáveis, condicionais, laços, funções, coleções, tratamento de erro e leitura de código alheio são a base. Expressões regulares também aparecem o tempo todo; treine no testador de regex.

Automação

Automação boa não é a que tem mais testes, é a que o time confia. Isso passa por escolher a camada certa (unidade, API ou interface), usar seletores estáveis, isolar dados e evitar esperas fixas. O Lab tem a mesma loja em vários fronts (HTML, React, Vue, legado e Shadow DOM) e uma página de elementos difíceis, perfeita para sentir na prática por que um seletor quebra e outro não.

Integração contínua (CI)

Teste que só roda na sua máquina ajuda pouco. Entender como um pipeline é disparado, como os testes rodam em paralelo, onde ficam relatórios e artefatos e como tratar testes instáveis faz a automação virar uma rede de segurança de verdade. Comece lendo o arquivo de pipeline do seu projeto e tentando explicar cada etapa.

Leitura de logs

Um bug report com o trecho certo do log, o horário e o identificador da requisição economiza horas de investigação. Aprenda a filtrar por nível, por correlação e por intervalo de tempo. O formatador de log e o conversor de timestamp ajudam a transformar uma parede de texto em uma linha do tempo legível.

Noções de segurança

QA não precisa ser especialista em pentest, mas deve desconfiar do óbvio: um usuário consegue ver dados de outro trocando um ID na URL? Mensagens de erro expõem detalhes internos? Um token expirado ainda funciona? O OWASP Top 10 é um documento de referência sobre os riscos mais críticos de segurança em aplicações web, e a versão mais recente publicada é a de 2025 (owasp.org/www-project-top-ten, consultado em 13/10/2026). Ler as categorias já muda a forma como você desenha cenários negativos.

Noções de acessibilidade

Navegar só pelo teclado, conferir se o foco é visível, se imagens têm texto alternativo, se campos têm rótulo e se o contraste é suficiente são verificações rápidas que qualquer QA pode incluir. A referência é a WCAG, do W3C: a WCAG 2.2 organiza suas diretrizes em quatro princípios (perceptível, operável, compreensível e robusto) e define critérios de sucesso testáveis nos níveis A, AA e AAA (w3.org/WAI/standards-guidelines/wcag, consultado em 13/10/2026).

Habilidades comportamentais

Comunicação

QA traduz o tempo todo: risco técnico para quem decide o negócio, comportamento do usuário para quem desenvolve. Adapte o nível de detalhe a quem ouve. Para a liderança, impacto e recomendação; para o time técnico, passos, evidência e hipótese.

Bug report claro

Um bom relato pode ser reproduzido por alguém que nunca viu a funcionalidade. Uma estrutura que funciona:

  • Título que diz o que falha e onde, sem adjetivos.
  • Ambiente e versão, usuário ou perfil usado.
  • Passos numerados e mínimos para reproduzir.
  • Resultado esperado e resultado obtido.
  • Evidências: print, vídeo, trecho de log, requisição e resposta.
  • Impacto para o usuário ou para o negócio.

Para mostrar a diferença entre o esperado e o obtido em textos longos, o comparador de textos deixa a evidência óbvia.

Negociação de prioridade

Nem todo bug vai ser corrigido agora, e tudo bem. Seu papel é garantir que a decisão seja consciente. Separe severidade (o quanto quebra) de prioridade (quando corrigir), apresente o risco com fatos e proponha alternativas: corrigir depois com uma mitigação, esconder atrás de uma flag, avisar o atendimento. Quem sai da conversa com um acordo claro ganha mais do que quem sai com razão.

Curiosidade

Perguntar “e se?” é o motor do teste exploratório. E se eu voltar no navegador no meio do pagamento? E se duas abas fizerem a mesma ação? Cultive isso reservando um tempo fixo da semana para explorar sem roteiro e anotando o que descobriu.

Pensamento crítico

Teste verde não é prova de qualidade, e um requisito escrito não é necessariamente o requisito certo. Questione evidências, inclusive as suas: o teste realmente valida o que diz validar? O dado de teste representa o mundo real? A conclusão vem de fatos ou de suposição?

Colaboração

Qualidade é responsabilidade do time, e QA é quem facilita isso. Participe do refinamento, faça pareamento com quem desenvolve, compartilhe cenários antes do código ficar pronto e celebre bugs encontrados cedo em vez de “pegar alguém no erro”. A relação de confiança faz as pessoas trazerem riscos até você.

Checklist de autoavaliação

Responda com honestidade “faço com segurança”, “faço com ajuda” ou “ainda não faço”. Os itens com “ainda não” são o seu plano de estudo.

  • Consigo apontar ambiguidades e riscos em uma história antes do desenvolvimento.
  • Aplico valor limite, partição e tabela de decisão sem consultar material.
  • Testo uma API com autenticação, cenários positivos e negativos, e explico os códigos de status.
  • Escrevo consultas SQL com JOIN e agregação para validar dados.
  • Uso Git no dia a dia: branch, pull request e resolução de conflito.
  • Leio e escrevo código em pelo menos uma linguagem com conforto.
  • Mantenho testes automatizados estáveis, com seletores e dados bem pensados.
  • Entendo o pipeline de CI do projeto e sei investigar uma falha nele.
  • Encontro nos logs o erro relacionado a um bug e anexo ao relato.
  • Incluo cenários básicos de segurança e acessibilidade nos meus testes.
  • Explico um risco técnico para alguém não técnico em poucas frases.
  • Meus bug reports são reproduzidos sem que me procurem para tirar dúvidas.
  • Negocio prioridade com fatos e saio com uma decisão registrada.
  • Reservo tempo para explorar e questiono minhas próprias conclusões.
  • Participo das conversas do time antes do código existir, não só depois.

Uma dica: escolha no máximo duas habilidades por ciclo de estudo, uma técnica e uma comportamental, e defina uma prática concreta para cada. Repita a autoavaliação depois de algumas semanas e compare.

Próximos passos