Um portfólio de QA forte tem 4 peças: um plano de teste real, bug reports exemplares, uma suíte automatizada rodando (hoje possível sem código) e um caso documentado de raciocínio de risco. Recrutadores gastam 90 segundos por candidato — o portfólio de QA existe para tornar esses segundos inescapáveis. Currículo diz “atenção a detalhes”; portfólio prova.

Na área de QA, quase ninguém tem portfólio — o que o torna desproporcionalmente eficaz. Dev júnior sem GitHub é exceção; QA júnior com evidência pública de trabalho é raridade que passa na frente da fila. O contexto do cargo está em Analista de QA: o que faz.

As 4 peças do portfólio de QA, em ordem de impacto

1. Uma suíte de testes automatizada, viva

A peça de maior impacto — e a que mais mudou. Antes exigia código; hoje não.

Escolha um site público conhecido (um e-commerce, um SaaS com trial) e automatize 8–10 fluxos críticos — use nossa lista de fluxos E2E essenciais como roteiro. Duas rotas: com código (Playwright + GitHub Actions, se você mira SDET) ou sem código (plataforma com IA como a TestBooster.ai, escrevendo os testes em português — captura de tela dos testes verdes + descrição dos fluxos no seu documento).

O que o avaliador procura: escolha inteligente de fluxos (risco, não facilidade), verificações explícitas e pelo menos um caso de erro por fluxo.

2. Três bug reports exemplares

Encontre bugs reais (sites públicos têm aos montes) e documente cada um como profissional: título específico, passos numerados reproduzíveis, resultado esperado vs obtido, evidência (vídeo/screenshot), severidade justificada. Um único bug report impecável comunica mais senioridade que dez certificados.

3. Um plano de teste de verdade

Pegue uma feature conhecida (o checkout de um app famoso, o upload de um serviço de nuvem) e escreva o plano: escopo, riscos priorizados, o que automatizar vs explorar, massa de dados, critérios de saída. 2–3 páginas. É a peça que demonstra estratégia — o que separa pleno de júnior.

4. Um caso de raciocínio: “o bug que eu procuraria”

A peça-assinatura, que quase ninguém tem: escolha um incidente público famoso (um app fora do ar, uma cobrança duplicada noticiada) e escreva uma página: que teste teria pegado isso? Em que camada? Por que provavelmente não existia? Mostra exatamente o que entrevistas tentam extrair — como você pensa.

Onde publicar o portfólio de QA

Simples e sem atrito: um Notion ou GitHub README como índice, com as 4 peças linkadas; PDF de uma página como cartão de visita para anexar em candidaturas; o link fixado no LinkedIn. Evite site pessoal elaborado — o conteúdo importa, o frame não.

Os erros que queimam candidatos

Portfólio de cursos (lista de certificados sem trabalho aplicado — certificado é complemento, não peça); projetos clonados de tutorial (o avaliador reconhece o mesmo to-do list app da internet inteira); bug reports de bugs triviais (typo em rodapé comunica olhar raso — cace bugs de fluxo e de estado); e suíte automatizada quebrada (se o badge do CI está vermelho no dia da entrevista, era melhor não ter badge).

Do portfólio para a entrevista

Portfólio gera a conversa; a conversa é outra prova. Prepare-se para defender cada decisão (“por que automatizou esses fluxos e não outros?”) — as perguntas típicas estão em entrevista para SDET: 25 perguntas, e a maioria vale para vagas de QA também.

Perguntas frequentes

O que colocar num portfólio de QA?

Quatro peças: suíte automatizada de um produto real, bug reports exemplares, um plano de teste e uma análise de raciocínio de risco. Qualidade sobre quantidade — quatro peças fortes vencem vinte medianas.

Preciso saber programar para ter portfólio de automação?

Não. Plataformas no-code com IA permitem montar e manter uma suíte real escrevendo os testes em português. Se sua meta é SDET, aí sim inclua a rota com código.

Quanto tempo leva para montar?

De 3 a 6 semanas dedicando 5–8 horas semanais. A suíte automatizada é a peça mais longa; os bug reports, o retorno mais rápido.