--- title: "Python para QA: Como Montar um Portfólio de Automação de Testes em 2026 | Python Brasil" url: "https://python.dev.br/blog/python-qa-automacao-testes-carreira/" markdown_url: "https://python.dev.br/blog/python-qa-automacao-testes-carreira.MD" description: "Veja como usar Python para criar um portfólio de QA com pytest, Playwright, APIs, dados e CI. Guia prático para vagas júnior e transição de carreira." date: "2026-05-24" author: "Equipe Python Brasil" --- # Python para QA: Como Montar um Portfólio de Automação de Testes em 2026 | Python Brasil Veja como usar Python para criar um portfólio de QA com pytest, Playwright, APIs, dados e CI. Guia prático para vagas júnior e transição de carreira. Python é uma das melhores portas de entrada para quem quer trabalhar com QA, automação de testes e qualidade de software em 2026. A linguagem é simples de ler, tem um ecossistema maduro para testes de API, web, dados e linha de comando, e aparece com frequência em vagas brasileiras que pedem Selenium, Playwright, pytest, CI/CD, SQL, Docker e alguma noção de produto. O problema é que muita gente aprende a escrever um teste isolado, mas não consegue transformar isso em um portfólio convincente. Para uma vaga júnior ou uma transição de carreira, o recrutador não precisa ver uma arquitetura gigantesca. Ele precisa ver que você entende o fluxo básico de qualidade: identificar risco, automatizar o que faz sentido, rodar os testes de forma reproduzível, explicar falhas e documentar limites. Neste guia, você vai ver como montar um portfólio de automação de testes com Python sem cair em projetos genéricos. A ideia é complementar o tutorial de [testes unitários em Python](/blog/testes-unitarios-python/), o guia de [testes com pytest](/guias/testes-com-pytest/) e o conteúdo sobre [Playwright com Python](/guias/playwright-python-testes-e2e/) com uma visão de carreira: quais projetos criar, como organizar o GitHub e como conectar cada entrega às vagas reais. ## Por que Python funciona tão bem para QA Python encaixa bem em QA porque permite testar diferentes camadas do produto com poucas ferramentas. Com `pytest`, você escreve testes unitários, testes de integração, fixtures, parametrização e relatórios. Com `requests` ou `httpx`, testa APIs. Com Playwright ou Selenium, automatiza fluxos web reais. Com pandas, valida arquivos CSV, planilhas, relatórios e bases exportadas por sistemas internos. Essa versatilidade importa no mercado brasileiro porque muitas vagas de QA não são puramente “testador manual” nem puramente “engenheiro de automação sênior”. Várias empresas procuram pessoas capazes de transitar entre análise de requisito, teste exploratório, automação de regressão, validação de dados e comunicação com desenvolvimento. Python ajuda justamente por ser legível para perfis técnicos e não técnicos. Outro ponto forte é a curva de aprendizado. Para começar, você não precisa dominar metaclasses, concorrência avançada ou frameworks web completos. Precisa entender funções, listas, dicionários, arquivos, ambiente virtual, instalação de pacotes e organização de projeto. Se ainda está consolidando essa base, comece pelo guia de [como começar com Python](/blog/como-comecar-com-python/) e depois avance para automação. ## O que um portfólio de QA precisa provar Um bom portfólio de QA com Python deve provar cinco coisas: 1. Você sabe escolher o tipo certo de teste para cada risco. 2. Você consegue escrever testes legíveis e manter dados de teste organizados. 3. Você sabe rodar a suíte localmente com comandos simples. 4. Você entende o resultado do teste e sabe explicar falhas. 5. Você documenta instalação, execução, escopo e limitações. Isso é mais valioso do que ter cinquenta testes frágeis gravados por uma ferramenta visual. Recrutadores técnicos percebem quando um projeto só reproduz cliques sem critério. Prefira uma suíte menor, mas com intenção clara: validar login, autorização, cálculo de preço, contrato de API, regras de formulário, geração de relatório ou consistência de dados. ## Projeto 1: testes de API com pytest O primeiro projeto recomendado é uma suíte de testes para uma API pública ou uma API simples criada por você. Pode ser uma API de tarefas, biblioteca, catálogo de produtos, busca de CEP ou consulta de dados públicos. O objetivo não é criar o backend mais sofisticado do mundo; é mostrar que você sabe validar contrato, status code, payload e regras de erro. Uma estrutura simples já funciona: ```text qa-api-python/ ├── README.md ├── pyproject.toml ├── tests/ │ ├── test_health.py │ ├── test_produtos.py │ └── test_erros.py └── data/ └── produtos_validos.json ``` No README, explique quais cenários são cobertos: resposta saudável, criação com dados válidos, validação de campo obrigatório, busca inexistente e erro esperado. Inclua o comando de execução, por exemplo `pytest -v`, e um print textual do resultado. Se usar uma API externa, documente limites de uso e evite depender de dados instáveis. Esse projeto conversa bem com vagas que pedem API REST, backend básico, Postman, pytest e automação. Para reforçar a base técnica, estude também [APIs REST com FastAPI](/blog/apis-rest-com-fastapi/) e [Python e APIs: consumindo dados](/blog/python-e-apis-consumindo-dados/). ## Projeto 2: testes end-to-end com Playwright O segundo projeto deve demonstrar automação de navegador, mas com escopo controlado. Escolha uma aplicação de demonstração, um site seu ou um fluxo público que permita testes responsáveis. Evite automatizar sites de banco, governo, e-commerce real ou sistemas com captcha. O foco é qualidade técnica, não burlar proteções. Bons cenários para portfólio incluem: 1. formulário de contato com validação de campos; 2. login em aplicação local de demonstração; 3. filtro e busca em uma lista de produtos fictícia; 4. fluxo de carrinho em ambiente de teste; 5. verificação de acessibilidade básica em páginas críticas. Com Playwright, você pode mostrar uso de seletores estáveis, espera automática, fixtures de navegador e execução headless. Evite depender de `time.sleep()`. Quando um teste falhar, a saída deve ajudar a entender o motivo. Se possível, configure captura de screenshot ou trace apenas em falha, sem encher o repositório de arquivos pesados. Esse projeto deve apontar para o guia de [Playwright com Python](/guias/playwright-python-testes-e2e/) e, se você quiser comparar ferramentas, para o conteúdo de [Selenium com Python](/blog/python-e-selenium-automacao-web/). A mensagem para recrutadores é clara: você sabe testar fluxos reais no navegador, mas entende estabilidade e manutenção. ## Projeto 3: validação de dados e relatórios Muitas vagas de QA, dados e operações no Brasil envolvem validar arquivos, planilhas, integrações e relatórios. Por isso, um projeto de validação de dados pode diferenciar seu portfólio de quem só mostra testes de interface. Você pode criar um script que lê um CSV de vendas fictícias, valida colunas obrigatórias, tipos, datas, valores negativos, duplicidades e regras de negócio. Depois, gere um relatório simples com os erros encontrados. Esse projeto mostra Python prático para problemas de empresa: conferência de arquivo antes de importação, validação de relatório financeiro interno, limpeza de dados para BI ou auditoria de integração. Use dados fictícios e deixe isso explícito. Não publique base real de cliente, planilha de trabalho ou informação pessoal. Se o tema envolver dados sensíveis, trate tudo como exemplo didático. Para aprofundar, veja [Python para automação de planilhas](/blog/python-para-automacao-de-planilhas/) e [trabalhando com JSON em Python](/blog/trabalhando-com-json-python/). ## Como organizar o GitHub para parecer profissional O GitHub do portfólio precisa facilitar a vida de quem avalia. Cada projeto deve ter nome claro, README objetivo e comandos reproduzíveis. Um recrutador técnico não deve precisar adivinhar como rodar. Inclua no README: 1. objetivo do projeto; 2. tecnologias usadas; 3. cenários de teste cobertos; 4. como instalar dependências; 5. como rodar os testes; 6. exemplo de saída esperada; 7. limitações conhecidas; 8. próximos passos realistas. Evite frases vagas como “projeto para treinar Python”. Prefira algo como “suíte de testes automatizados para validar contrato de API de catálogo, cobrindo sucesso, erro de validação e recurso inexistente”. Essa descrição mostra intenção profissional. Também vale configurar CI com GitHub Actions ou Gitea Actions para rodar `pytest` a cada push. Mesmo uma configuração simples já comunica maturidade: você entende que teste automatizado precisa rodar sem depender da sua máquina. Para vagas júnior, isso pode ser um diferencial forte. ## Como falar desse portfólio no currículo No currículo, não liste apenas “pytest, Selenium, Playwright”. Conecte ferramenta a evidência. Por exemplo: > Desenvolvi suíte de testes em Python com pytest para API REST, cobrindo status code, payload, erros de validação e cenários negativos. Configurei execução local e documentação no README. Ou: > Automatizei fluxo web de login e busca com Playwright Python, usando seletores estáveis, fixtures e captura de evidência em falhas. Esse tipo de frase é melhor do que uma lista enorme de tecnologias. Se você ainda está ajustando o currículo, use o guia de [currículo Python para vaga júnior](/carreira/curriculo-python-vaga-junior/) e conecte seus projetos ao roteiro de [projetos de portfólio Python](/carreira/projetos-portfolio-python/). ## Erros comuns em projetos de QA iniciante O primeiro erro é automatizar tudo pela interface. Teste end-to-end é útil, mas costuma ser mais lento e frágil. Para muitos cenários, teste de API ou teste de função é mais simples e confiável. Um bom portfólio mostra que você entende essa diferença. O segundo erro é usar dados mágicos sem explicação. Se o teste depende do produto com ID 123, explique de onde ele vem ou crie o dado durante o teste. Quanto mais previsível for a massa de teste, melhor. O terceiro erro é ignorar cenários negativos. Empresas não querem apenas saber se o caminho feliz funciona. Elas querem evitar regressões quando usuário envia campo vazio, token inválido, arquivo mal formatado ou quantidade negativa. O quarto erro é publicar segredo. Nunca coloque token, senha, cookie, chave de API ou credencial em repositório público. Use variáveis de ambiente e um `.env.example` sem valores reais. ## Roteiro de quatro semanas Se você está começando, um plano realista é: 1. Semana 1: revisar Python básico, ambiente virtual, pytest e Git. 2. Semana 2: criar projeto de testes de API com README e cenários negativos. 3. Semana 3: criar projeto Playwright pequeno com fluxo web estável. 4. Semana 4: adicionar CI, revisar README, fixar projetos no GitHub e adaptar currículo. Depois disso, acompanhe as [vagas Python](/vagas/) e observe quais palavras aparecem: QA, automação, pytest, Selenium, Playwright, API, SQL, Docker, CI/CD. Ajuste seus projetos aos requisitos mais frequentes, sem inventar experiência que você não tem. Para ampliar a busca de oportunidades de entrada em tecnologia, o eu.dev.br também pode ajudar a comparar vagas júnior além do ecossistema Python. ## Conclusão Python para QA é uma escolha prática porque une legibilidade, ferramentas maduras e aplicação direta em problemas reais de empresas. Um portfólio forte não precisa ter dezenas de repositórios. Precisa ter dois ou três projetos bem acabados, com testes que fazem sentido, documentação clara e evidência de execução. Comece pequeno: uma API, um fluxo web e uma validação de dados. Escreva README como se outra pessoa fosse rodar o projeto sem falar com você. Mostre decisões, limites e próximos passos. Esse cuidado comunica o que toda empresa procura em uma pessoa júnior: base técnica, organização, responsabilidade e capacidade de aprender entregando.