Análise de um app real com olhar crítico de QA. Objetivo: treinar a percepção de falhas antes de qualquer teste formal.

• 1. Abra qualquer app de delivery no seu celular. Navegue por 5 minutos como usuário normal.
• 2. Agora navegue novamente fazendo perguntas: "E se o endereço estiver errado?", "E se o cartão recusar?", "E se a internet cair no momento do pagamento?"
• 3. Liste pelo menos 10 perguntas "E se..." e classifique cada uma: Dados | Fluxo | Visual | Performance.
• 4. Para 3 das perguntas, escreva o que o app deveria fazer (comportamento esperado) vs. o que pode estar acontecendo de errado.

Analise a distribuição de testes de um projeto open source real e compare com a pirâmide ideal.

• 1. Acesse github.com/gothinkster/realworld, este é um projeto com o mesmo app feito em várias tecnologias.
• 2. Escolha uma implementação (ex: React, Vue ou Angular) e abra a pasta de testes. Conte os arquivos por tipo.
• 3. Desenhe a pirâmide atual do projeto. Depois desenhe a ideal. O que está diferente?
• 4. Escreva 2 recomendações práticas para melhorar a estratégia de testes desse projeto.

Analise um projeto real (ou o Sauce Demo) e identifique onde cada tipo de teste se encaixa na pirâmide.

• 1. Desenhe a pirâmide em papel: base (unitários), meio (integração), topo (E2E). Para o Sauce Demo, liste 3 exemplos concretos de teste para cada camada.
• 2. Identifique se a distribuição atual está invertida: muitos E2E e poucos unitários. Quais são os sintomas de uma pirâmide invertida no dia a dia?
• 3. Proponha uma redistribuição: quais testes E2E existentes poderiam ser substituídos por testes de integração ou unitários sem perder cobertura de risco?

Aplique partição de equivalência em cima de um formulário real sem nenhum conhecimento do código.

• 1. Acesse The Internet / Login. Antes de clicar em qualquer coisa, defina suas partições: credenciais válidas, usuário inválido, senha inválida, ambos inválidos, campos vazios, espaços em branco.
• 2. Para cada partição escreva um caso de teste: ID | Entrada | Resultado Esperado. Credenciais válidas: tomsmith / SuperSecretPassword!.
• 3. Execute todos os casos e preencha: Resultado Obtido | Status (Passou/Falhou).
• 4. Algum resultado surpreendeu você? Registre como observação ou bug.

Entenda o que um relatório de cobertura diz, e o que ele não diz.

• 1. Clone o repositório RealWorld (qualquer implementação frontend). Rode os testes existentes e gere o relatório de cobertura com npm test -- --coverage.
• 2. Abra o relatório HTML em coverage/lcov-report/index.html. Identifique: qual arquivo tem menor cobertura? Quais linhas não estão cobertas?
• 3. Para uma função com cobertura abaixo de 60%, mapeie os caminhos possíveis (if/else, ternários) sem executar o código. Quantos testes seriam necessários para cobrir todos os caminhos?
• 4. Escreva pelo menos 1 teste novo que cubra um caminho descoberto. A cobertura subiu?

Use DevTools para verificar o que acontece por trás da interface durante um fluxo de autenticação.

• 1. Acesse OrangeHRM Demo. Abra o DevTools (F12) antes de logar. Vá na aba Network e ative a opção "Preserve log".
• 2. Faça login com Admin / admin123. Na aba Network, encontre a requisição de autenticação. Quais headers foram enviados? Qual o status code da resposta?
• 3. Vá em Application → Cookies. Quais cookies foram criados após o login? Têm as flags HttpOnly e Secure?
• 4. Faça logout e verifique: os cookies foram removidos? Copie a URL de uma página autenticada e tente acessar sem estar logado. O sistema redireciona corretamente?

Identifique os dois tipos num sistema real e execute pelo menos um de cada.

• 1. Liste 10 cenários de teste para o Sauce Demo. Para cada um, classifique: funcional ou não-funcional. Se não-funcional, especifique o subtipo (performance, compatibilidade, usabilidade, segurança).
• 2. Execute 3 testes funcionais documentando resultado em tabela.
• 3. Execute 1 teste não-funcional básico: abra o Lighthouse no DevTools (aba Lighthouse), rode um relatório de Performance na página de produtos do Sauce Demo. Qual o score? Qual a métrica mais crítica?
• 4. Compare: como a forma de documentar um resultado funcional difere de um não-funcional?

Defina e execute as três suítes para o Sauce Demo, entendendo o propósito de cada uma.

• 1. Smoke: defina 5 testes que verificam se o Sauce Demo está "vivo". Critério: se qualquer um falhar, você bloqueia o QA e pede um novo build. Execute e documente.
• 2. Sanity: simule que um dev corrigiu o bug "produto adicionado ao carrinho some após atualizar a página". Quais 4 a 6 testes você executaria para validar essa correção sem testar tudo? Monte e execute a suíte.
• 3. Regressão: liste os 15 testes mais importantes do Sauce Demo. Organize em ordem de prioridade. Essa é sua suíte de regressão completa.
• 4. Para cada suíte, documente: quantos testes, tempo estimado de execução, quando você a executaria (a cada build? a cada release? após cada bugfix?).

Execute uma sessão de teste exploratório estruturado usando a técnica de charter.

• 1. Defina um charter (missão) para sua sessão: "Explorar o fluxo de checkout do Sauce Demo em busca de comportamentos inesperados em cenários de borda". Defina um tempo: 25 minutos.
• 2. Durante a sessão, tome notas contínuas: o que testou, o que encontrou, perguntas que surgiram, bugs ou estranhezas. Use a estrutura SBTM (Session-Based Test Management).
• 3. Tente cenários que um script nunca cobriria: adicionar 99 unidades do mesmo produto, remover todos os itens no meio do checkout, voltar ao passo anterior com o botão do browser, digitar XSS simples nos campos de texto.
• 4. Ao final, escreva um relatório de sessão: o que você testou, o que encontrou, cobertura estimada, sugestões de testes adicionais.

Para cada nível da pirâmide, identifique e documente um bug real ou hipotético com precisão.

• 1. Unitário: pense numa função de cálculo de desconto, calcularDesconto(preco, percentual). Quais casos de teste unitários cobririam essa função? Escreva pelo menos 5 (incluindo valores negativos, zero, percentual acima de 100).
• 2. Integração: simule um cenário onde o serviço de carrinho chama o serviço de estoque. Quais testes de integração verificariam que a comunicação entre os dois está correta? Liste pelo menos 3 cenários.
• 3. Sistema: execute o fluxo completo de compra no Sauce Demo do login ao "Thank you for your order". Documente cada passo e resultado : isso é um teste de sistema.
• 4. UAT: escreva 3 critérios de aceite de negócio para o fluxo de checkout, como um usuário final os descreveria (sem linguagem técnica). Como esses critérios diferem dos testes de sistema que você escreveu no passo 3?

O OrangeHRM (opensource-demo.orangehrmlive.com, login: Admin/admin123) é um sistema de RH para prática. Escreva casos de teste profissionais para o módulo de login.

• 1. Acesse o sistema e explore o fluxo de login por 10 minutos. Anote tudo que pode ser testado.
• 2. Crie uma planilha com colunas: ID | Título | Pré-condição | Passos | Dado de Entrada | Resultado Esperado.
• 3. Escreva 10 casos: pelo menos 3 positivos (deve funcionar) e 5 negativos (deve rejeitar ou dar erro).
• 4. Execute todos os casos e preencha: Resultado Obtido e Status (✅ Passou / ❌ Falhou / ⚠️ Bloqueado).

Domine as 3 abas do DevTools mais usadas no dia a dia do QA web.

• 1. Network: Abra reqres.in com F12. Clique em "GET /api/users". Anote: status code, tempo de resposta e 3 campos do JSON retornado.
• 2. Console: Em qualquer site, abra o Console e veja se há erros (ícones vermelhos). Tente digitar document.title e pressione Enter. O que retornou?
• 3. Elements: Clique direito em qualquer botão Inspecionar. Encontre o seletor CSS da cor de fundo. Dê duplo clique no valor da cor e mude para outra, veja a mudança em tempo real.
• 4. Documente o que você descobriu nos 3 passos. Essas são as habilidades que vão impressionar no seu próximo processo seletivo.

Use DevTools para ir além do visual e entender a causa raiz.

• 1. No Sauce Demo, abra DevTools (F12) e a aba Network. Faça login e identifique a requisição de autenticação: endpoint, método, payload e status code.
• 2. Adicione um produto ao carrinho observando Network. Existe chamada de API para atualizar o carrinho ou é tudo no frontend? O que isso implica para os testes?
• 3. Use a aba Console para verificar erros JavaScript durante a navegação. Documente cada erro: mensagem, arquivo, linha e qual ação o dispara.

Verifique o comportamento em diferentes browsers e documente inconsistências.

• 1. Execute o fluxo completo de compra no Chrome, Firefox e Edge. Registre qualquer diferença visual ou comportamental.
• 2. Use o modo responsivo do DevTools para simular iPhone 12, iPad e 1920px. Verifique: menu acessível, botões clicáveis, texto legível.
• 3. Classifique cada diferença: bug real (comportamento incorreto) ou variação aceitável (renderização diferente mas funcional). Escreva bug report só para bugs reais.

Monte um mini-sprint de 1 hora no Trello simulando seu papel como QA.

• 1. Crie um board gratuito no Trello com 5 colunas: Backlog | Em Desenvolvimento | Pronto para QA | Em QA | Concluído.
• 2. Crie 5 cards de user stories para um app de lista de tarefas. Cada card deve ter: a story, os critérios de aceitação (mínimo 3, no formato Given/When/Then) e a estimativa em pontos (1, 2, 3 ou 5).
• 3. Mova 2 stories para "Pronto para QA". Para cada uma, escreva os casos de teste no próprio card.
• 4. Execute os casos manualmente (simule o comportamento esperado) e mova para "Concluído" com o resultado documentado.

Compare como o QA atua em Waterfall versus Ágil usando um cenário concreto.

• 1. Para um sistema de login simples, escreva a sequência de atividades do QA em Waterfall: quando recebe os requisitos, quando testa, quando reporta bugs, quando aprova.
• 2. Repita para Scrum: em quais cerimônias o QA participa? O que faz no refinamento, na planning, durante a sprint e na review?
• 3. Identifique um bug de requisito descoberto tarde no Waterfall e trace como teria sido pego mais cedo no Ágil. Qual foi o custo da descoberta tardia?

Compare o papel do QA nas duas metodologias com um cenário concreto.

• 1. Para um sistema de login, escreva a sequência de atividades do QA em Waterfall: quando recebe requisitos, quando testa, quando reporta e quando aprova.
• 2. Repita para Scrum: em quais cerimônias o QA participa? O que faz no refinamento, planning, durante a sprint e na review?
• 3. Identifique um bug de requisito descoberto tarde no Waterfall e trace como teria sido capturado mais cedo no Ágil. Calcule o custo da descoberta tardia.

Aplique as duas técnicas combinadas para um campo de senha com regras: 8-20 chars, pelo menos 1 número, 1 letra maiúscula.

• 1. Primeiro, defina as partições: (a) válida, (b) muito curta, (c) muito longa, (d) sem número, (e) sem maiúscula.
• 2. Depois, para a regra de comprimento, liste os 6 valores limite: 7, 8, 9, 19, 20, 21.
• 3. Monte uma tabela com colunas: Valor | Partição | É Limite? | Resultado Esperado. Mínimo 10 linhas.
• 4. Implemente a função validatePassword(pwd) em JS e escreva testes Jest para cada linha da tabela.

Use tabela de decisão para mapear todas as combinações de uma regra de negócio e derivar casos de teste.

• 1. Regra: desconto aplicado se o cliente tem conta há mais de 1 ano E o carrinho tem mais de R$200. Monte a tabela com todas as combinações (2 condições = 4 linhas). Para cada linha, escreva o resultado esperado.
• 2. Para cada linha da tabela, escreva um caso de teste com: dados de entrada, ação e resultado esperado. Verifique que cada combinação está coberta.
• 3. Adicione uma terceira condição: cliente premium tem 10% adicional. Quantas linhas a tabela passa a ter? Quais novos casos surgem?

Use tabela de decisão para cobrir todas as combinações de uma regra complexa.

• 1. Regra: desconto se conta há mais de 1 ano E carrinho acima de R$200. Monte a tabela com as 4 combinações. Para cada linha, escreva resultado esperado.
• 2. Para cada linha da tabela, escreva um caso de teste com: dado de entrada, ação e resultado esperado.
• 3. Adicione uma terceira condição: cliente premium ganha 10% extra. Quantas linhas a tabela passa a ter? Quais casos novos surgem?

Crie um repositório profissional que vai funcionar como portfólio de QA.

• 1. Crie o repositório no GitHub: nome "qa-portfolio", público, com README, .gitignore para Node.js e licença MIT.
• 2. Clone localmente: git clone https://github.com/SEU_USUARIO/qa-portfolio.git.
• 3. Crie a estrutura de pastas: manual-tests/, test-plans/, automation/. Adicione um arquivo README em cada pasta explicando o que vai ter ali.
• 4. Faça commits com mensagens descritivas: git commit -m "feat: add login test cases for OrangeHRM". Faça push e veja no GitHub.

Pratique o fluxo completo de branch, PR e code review com olhar de QA.

• 1. Em um repositório pessoal no GitHub, crie a branch feature/login-page a partir da main. Adicione um arquivo de caso de teste em Markdown.
• 2. Abra um Pull Request para a main. Escreva uma descrição clara: o que muda, por que muda e como testar. Adicione uma checklist de critérios de aceite.
• 3. Revise seu próprio PR após 30 minutos. Encontre pelo menos uma melhoria. Solicite review de um colega e aplique o feedback antes de mergear.

Pratique o ciclo completo de branch, PR e review.

• 1. Num repositório GitHub pessoal, crie a branch feature/login-test. Adicione um arquivo de caso de teste em Markdown.
• 2. Abra um PR com descrição clara: o que muda, por que muda, como testar. Inclua checklist de critérios de aceite.
• 3. Revise seu próprio PR após 30 min. Encontre uma melhoria, aplique e mergeie. Documente o aprendizado.

Conduza uma sessão de teste exploratório no demoqa.com com charter definido.

• 1. Escreva seu charter antes de começar: "Explorar o Practice Form (demoqa.com/automation-practice-form) focando em validações de campos por 30 minutos, testando dados incomuns e limites."
• 2. Configure um timer de 30 minutos. Durante a sessão, anote em tempo real: o que você testou e qualquer comportamento inesperado.
• 3. Experimente inputs extremos: nome com 500 caracteres, e-mail sem @, data de nascimento no futuro, upload de arquivo .exe, campos com emojis e caracteres especiais (ç, ñ, 中文).
• 4. Ao final, escreva o relatório da sessão: resumo do que cobriu, lista de bugs encontrados com evidência (screenshot), e 2 sugestões de próximas sessões.

Aplique heurísticas de teste para guiar uma sessão exploratória estruturada.

• 1. Escolha 3 heurísticas do modelo SFDPOT (Structure, Function, Data, Platform, Operations, Time) e aplique cada uma no Sauce Demo por 10 minutos. Documente o que testou e o que encontrou.
• 2. Aplique a heurística Goldilocks em pelo menos 2 campos: valores muito pequenos, muito grandes e no limite certo. O sistema se comporta de forma previsível nos três casos?
• 3. Escreva um Session Test Report ao final: missão, duração, área coberta, bugs encontrados e perguntas que surgiram e ainda precisam de investigação.

Aplique heurísticas para estruturar uma exploração com mais cobertura.

• 1. Escolha 3 heurísticas do SFDPOT e aplique cada uma no Sauce Demo por 10 minutos. Documente o que testou e o que encontrou.
• 2. Aplique Goldilocks em 2 campos: valores muito pequenos, muito grandes e no limite. O sistema se comporta previsivelmente?
• 3. Escreva um Session Test Report: missão, duração, área coberta, bugs encontrados e perguntas que surgiram.

Explore o demoqa.com/automation-practice-form por 20 minutos e documente 3 bugs no padrão profissional.

• 1. Explore o formulário buscando comportamentos inesperados. Use Loom para gravar a tela.
• 2. Para cada bug encontrado, crie um card no Jira com: Título no padrão "[Módulo] Descrição do problema", Passos numerados, Resultado Obtido, Resultado Esperado, Screenshot/vídeo como evidência.
• 3. Classifique cada bug: Severidade (impacto técnico) e Prioridade (urgência de negócio). Escreva a justificativa.
• 4. Peça a alguém testar os seus reports, se não conseguirem reproduzir, melhore os passos até que qualquer pessoa consiga.

Pratique abertura, acompanhamento e fechamento de bugs.

• 1. Crie um projeto gratuito no Jira ou Azure DevOps. Configure colunas: Aberto, Em Análise, Em Correção, Em Reteste, Fechado.
• 2. Abra 3 bugs do Sauce Demo com título, severidade, prioridade, steps, resultado atual e esperado. Mova cada um pelo fluxo completo.
• 3. Crie um filtro que mostre bugs Abertos de severidade Alta ou Crítica, ordenados por data de criação. Salve como favorito para acompanhamento diário.

Analise os dados dos bugs para produzir um relatório de qualidade.

• 1. Com os bugs do exercício anterior, produza um relatório: total por severidade, taxa de bugs reabertos e tempo médio entre abertura e fechamento.
• 2. Identifique o módulo com mais bugs. O que isso indica sobre a área de maior risco? Como isso influencia a próxima sessão exploratória?
• 3. Apresente o relatório em 3 parágrafos para um PO não técnico: o que está bem, o que preocupa e qual ação você recomenda. Evite jargões.

Execute os três tipos com k6 contra uma API pública e compare os resultados.

• 1. Performance baseline escreva um script k6 que faz GET https://reqres.in/api/users com 1 VU por 30 segundos. Anote p50, p95, p99 e throughput. Esse é seu baseline.
• 2. Carga suba para 50 VUs simultâneos por 2 minutos (carga realista). Os percentis se mantiveram? Adicione um threshold: p95 < 800ms. O teste passou?
• 3. Estresse rampa de 0 a 300 VUs em 3 minutos. Observe o ponto onde a taxa de erros começa a subir. Documente: em quantos VUs o sistema começou a degradar?
• 4. Compare os três relatórios. Qual a diferença entre o comportamento do sistema nos três cenários? O que cada tipo de teste revelou que o outro não revelaria?

Explore vulnerabilidades reais no OWASP Juice Shop de forma ética e documentada.

• 1. Acesse OWASP Juice Shop. Complete o desafio de SQL Injection no login: use ' OR 1=1-- no campo de email. O que aconteceu? Qual item do OWASP Top 10 isso representa?
• 2. Tente um desafio de XSS: encontre um campo que reflita input do usuário sem sanitização. Injete <script>alert('xss')</script>. Funcionou?
• 3. Instale a extensão OWASP ZAP ou use o Burp Suite Community. Execute um scan passivo na URL do Juice Shop. Quais vulnerabilidades foram identificadas automaticamente?
• 4. Para cada vulnerabilidade encontrada, documente: tipo (OWASP category), severidade (crítica/alta/média/baixa), como explorar, como mitigar.

Execute uma auditoria de acessibilidade combinando ferramentas automáticas e testes manuais.

• 1. Instale a extensão axe DevTools no Chrome. Execute na página de produtos do Sauce Demo. Liste todas as violações encontradas com nível WCAG (A, AA ou AAA) e impacto (critical/serious/moderate/minor).
• 2. Navegue pelo fluxo completo de compra usando APENAS o teclado (Tab para navegar, Enter para clicar, Esc para fechar). Em quais pontos o foco desapareceu ou ficou preso?
• 3. Ative o leitor de tela do sistema (NVDA no Windows, VoiceOver no Mac com Cmd+F5). Tente completar o login. As instruções do leitor de tela fazem sentido? Os botões têm labels descritivos?
• 4. Monte um relatório: violações automáticas (axe) + problemas manuais (teclado + leitor de tela). Priorize as 3 correções mais urgentes com justificativa de impacto para o usuário.

Avalie o Sauce Demo pelas heurísticas de Nielsen e teste em múltiplos contextos.

• 1. Leia as 10 Heurísticas de Nielsen. Para cada uma, identifique um elemento do Sauce Demo que viola ou respeita a heurística. Monte uma tabela com: Heurística | Elemento | Violação/Conformidade | Evidência (screenshot).
• 2. Acesse o Sauce Demo no Chrome, Firefox e Safari (ou use o modo de simulação de dispositivos do DevTools para Edge e Samsung Internet). Há diferenças visuais ou funcionais entre os browsers?
• 3. No DevTools do Chrome, ative o modo responsivo (Ctrl+Shift+M). Teste nas dimensões: 375x667 (iPhone SE), 768x1024 (iPad), 1440x900 (desktop). O layout quebrou em alguma resolução?
• 4. Compile os achados em um relatório de usabilidade: violações de heurística (prioridade alta/média/baixa) + problemas de compatibilidade encontrados.

Use o Stryker para descobrir lacunas na sua suíte de testes JavaScript.

• 1. Crie um projeto JavaScript simples com uma função calcularDesconto(preco, percentual) e pelo menos 3 testes Jest para ela. Execute os testes, todos devem passar.
• 2. Instale o Stryker: npm init stryker. Execute npx stryker run. Anote o mutation score inicial e o relatório HTML gerado.
• 3. Abra o relatório e encontre os mutantes sobreviventes. Para cada um, entenda: qual mudança foi feita no código? Por que seus testes não pegaram?
• 4. Escreva testes adicionais para matar os mutantes sobreviventes. Execute o Stryker novamente. O score deve ter subido. Documente: quais testes você adicionou e por quê.

Implemente um contrato básico entre dois serviços usando Pact JS.

• 1. Crie dois projetos Node.js: consumer-app (faz GET /users) e provider-app (serve GET /users). No consumer, instale @pact-foundation/pact.
• 2. No consumer, escreva um teste Pact que define o contrato: "quando chamar GET /users, espero status 200 e um array com objetos que tenham id (number) e name (string)". Execute, o Pact gera um arquivo JSON de contrato.
• 3. No provider, use o Pact para verificar que sua API satisfaz o contrato gerado. Execute a verificação, deve passar.
• 4. Quebre o contrato intencionalmente: mude o campo name para nome no provider. Execute a verificação novamente. O que aconteceu? Como isso previne bugs em produção?

Planeje experimentos de chaos para um sistema real e simule o mais simples localmente.

• 1. Para um sistema que você conhece (ou o Sauce Demo como referência), liste 5 falhas que poderiam acontecer em produção: serviço de pagamento fora do ar, banco de dados lento, CDN inacessível, timeout na API de CEP, disco cheio no servidor.
• 2. Para cada falha, defina o experimento: Hipótese | Como simular | O que o sistema deveria fazer | Como medir.
• 3. Simule latência de rede localmente: use as Chrome DevTools (Network → Throttling → Custom) para simular uma conexão 3G lenta no Sauce Demo. O sistema se comporta bem? Há timeouts, spinners sem fim, ou a UI quebra?
• 4. Documente o resultado: o sistema foi resiliente? O que deveria ser implementado para melhorar a resiliência (retry, fallback, graceful degradation)?

Aplique shift-left numa história de usuário real, identificando ambiguidades antes que virem código.

• 1. Pegue esta história de usuário: "Como cliente, quero filtrar produtos por categoria para encontrar o que procuro mais rapidamente." Antes de escrever qualquer teste, liste todas as perguntas que você faria ao PO/dev. Mínimo: 8 perguntas.
• 2. Reescreva os critérios de aceite no formato Given/When/Then. Escreva pelo menos 5 cenários cobrindo: filtro com resultados, filtro sem resultados, múltiplos filtros simultâneos, limpar filtros, filtro após busca.
• 3. No Sauce Demo, execute o filtro de produtos manualmente. Ele atende aos critérios que você definiu? Encontrou ambiguidades que não estavam nos critérios originais?
• 4. Compare a história original com seus critérios de aceite. Quantas ambiguidades você identificou? O que teria acontecido se o dev tivesse implementado sem essas perguntas?

Configure uma feature flag com Unleash e escreva testes para os dois estados.

• 1. Suba o Unleash localmente com Docker: docker run -p 4242:4242 unleashorg/unleash-server. Acesse localhost:4242 e crie uma feature flag chamada novo-checkout.
• 2. Num projeto Node.js simples, instale unleash-client e implemente uma rota que retorna comportamentos diferentes dependendo do estado da flag: novo-checkout = ON retorna o novo fluxo, OFF retorna o fluxo atual.
• 3. Escreva testes para os dois estados: flag ON (novo fluxo), flag OFF (fluxo atual). Execute ambos os conjuntos de testes.
• 4. Ative e desative a flag pelo painel do Unleash enquanto os testes rodam. Documente: como você garantiria em CI que ambos os estados estão sempre cobertos?

Crie uma suíte de smoke que executa em menos de 2 minutos e bloqueia PRs quando falha.

• 1. Anote seus 5 testes mais críticos com test("@smoke titulo", ...).
• 2. No package.json: "smoke": "playwright test --grep @smoke".
• 3. No GitHub Actions, configure para rodar o smoke em PRs e a regressão completa no merge para main.
• 4. Teste: faça um selector quebrar intencionalmente. O PR ficou bloqueado? O erro foi claro?

Conduza sessão exploratória com time-boxing e relatório.

• 1. Escreva 3 charters para o Sauce Demo com missão, área e riscos específicos. Ex: 'Explorar checkout focando em estados de erro de pagamento para identificar bugs de usabilidade'.
• 2. Execute cada charter em sessões de 25 minutos. Durante cada sessão, documente em tempo real: o que testou, encontrou e as perguntas que surgiram.
• 3. Produza um Session Test Report: cobertura vs. planejado, bugs por severidade, áreas não cobertas e recomendações para a próxima sessão.

Use técnicas formais para derivar casos de alta cobertura.

• 1. Para uma regra com múltiplas condições (ex: frete por CEP, peso e valor), aplique análise de causa-efeito: identifique todas as causas e efeitos possíveis.
• 2. Construa a tabela de decisão completa. Aplique cobertura MC/DC: cada condição deve afetar independentemente o resultado. Quantos casos o MC/DC requer?
• 3. Compare a cobertura da técnica formal vs. intuição. Qual encontrou mais casos de borda? Documente a diferença como argumento para técnicas formais em regras críticas.

Adicione testes de acessibilidade à sua suíte Playwright existente.

• 1. Instale: npm i -D @axe-core/playwright
• 2. Crie accessibility.spec.ts com o código abaixo. Execute em 3 páginas do demoqa.com.
• 3. Para cada violação encontrada: anote impacto (critical/serious/moderate), elemento afetado e regra WCAG violada.
• 4. Escolha 1 violação critical, pesquise a correção HTML e documente antes/depois.

Configure testes de acessibilidade automatizados que rodam em cada PR.

• 1. Adicione @axe-core/playwright ao projeto. Escreva um teste que abre cada página principal, roda o scan e falha se encontrar violações Critical ou Serious.
• 2. Configure threshold: falha apenas para violações novas. Declare as existentes como aceitas temporariamente no arquivo de configuração do axe.
• 3. Integre no GitHub Actions. Configure comentário no PR com resumo das violações: número por nível de impacto e link para o relatório completo.

Configure uma pipeline profissional que executa testes, publica relatório e bloqueia merge em falha.

• 1. Crie .github/workflows/playwright.yml com o YAML abaixo. Faça push e abra um PR.
• 2. Em Settings Branches Branch protection rules: adicione o job de testes como "Required status check".
• 3. Faça um teste falhar intencionalmente. O PR ficou bloqueado? A notificação de falha chegou por e-mail?
• 4. Acesse o artifact do relatório na página do workflow Actions e confirme que o HTML está acessível.

Execute testes E2E em modo headless dentro de um container.

• 1. Crie um Dockerfile para Playwright usando a imagem oficial mcr.microsoft.com/playwright:latest. Instale dependências e configure o script de teste.
• 2. Execute os testes no container: docker run playwright-tests. Verifique que passam sem interface gráfica. Use o relatório HTML como artefato de saída.
• 3. Integre no GitHub Actions: step que faz build da imagem e executa os testes. Configure upload do relatório como artefato para download após a execução.

Configure publicação automática de relatórios no pipeline.

• 1. No GitHub Actions, configure Allure Report: instale allure-playwright, execute com output para allure-results e use a action de publicação como GitHub Pages.
• 2. Configure o JUnit XML como formato adicional. Use upload-artifact para salvar os XMLs. Verifique que o GitHub parseia os resultados na aba Tests do Actions.
• 3. Configure notificação de falha: use if: failure() para enviar mensagem no Slack ou criar issue quando testes falharem na main.

Configure gates automáticos que bloqueiam merges quando a qualidade cai.

• 1. Configure o SonarCloud no repositório. Defina Quality Gate: cobertura mínima de 70%, zero bugs críticos e zero vulnerabilidades. Configure status check para bloquear o PR.
• 2. Simule quebra de gate: adicione função sem teste e abra um PR. O pipeline deve bloquear automaticamente. Adicione o teste e verifique que o gate passa.
• 3. Documente os gates em QUALITY_GATES.md: quais são, por que foram escolhidos, critério de revisão semestral e quem aprova exceções.

Divida a suíte em workers paralelos e meça o ganho.

• 1. Configure sharding no Playwright: divida em 4 shards com --shard=1/4 até --shard=4/4 no GitHub Actions com matrix strategy.
• 2. Use playwright merge-reports para consolidar os 4 relatórios num único HTML. Configure como artefato. Verifique que todos os testes aparecem.
• 3. Meça: tempo sequencial vs. paralelo. Documente o ganho em minutos e o custo em runners adicionais. Justifique (ou não) a adoção permanente.

Configure pipeline completo com stages de build, teste e deploy.

• 1. Crie pipeline YAML com 3 stages: Build (npm install + build), Test (npm test + PublishTestResults) e Deploy (só executa se os anteriores passaram).
• 2. Configure a task PublishTestResults com formato JUnit. Acesse a aba Tests do pipeline e verifique histórico de execuções e testes mais lentos.
• 3. Adicione aprovação manual antes do Deploy: configure um Environment com regra de aprovação do QA lead. Simule o fluxo completo e documente o tempo médio.

Execute um ciclo de teste real com TestRail, cobrindo planejamento, execução e relatório.

• 1. Crie a estrutura no TestRail: Project Suite Section Test Cases. Adicione 10 casos para o módulo de login do OrangeHRM.
• 2. Crie um Test Plan com ambiente definido: browser, OS, URL do ambiente de homologação.
• 3. Execute todos os casos e marque: Passed, Failed, Blocked (com comentário explicando o bloqueio).
• 4. Gere o relatório de execução. Qual é a taxa de sucesso? Quais bugs precisam ser abertos no Jira?

Produza um plano completo para uma feature e execute-o.

• 1. Para o carrinho do Sauce Demo, escreva um plano com: escopo, itens fora do escopo, riscos, abordagem (manual/automatizado/exploratório), ambiente necessário e critérios de saída.
• 2. Execute o plano e registre: casos que passaram, falharam e foram bloqueados. Atualize com os achados reais vs. planejado.
• 3. Produza um resumo executivo de 1 página para o PO: status de qualidade, bugs por severidade, cobertura real vs. planejada e recomendação de go/no-go com justificativa.

Implemente TDM com dados sintéticos e isolamento por teste.

• 1. Use Faker.js ou Faker Python para gerar 20 usuários com dados realistas. Substitua qualquer dado hardcoded nos testes por dados gerados dinamicamente.
• 2. Refatore dois testes de API para usar beforeEach (criar) e afterEach (limpar). Execute ambos em paralelo 5 vezes. Dados de um interferem no outro?
• 3. Identifique campos PII (nome, CPF, e-mail). Aplique mascaramento nos dados de teste. Documente a política de dados do time.

Configure o Allure para gerar relatórios com histórico, screenshots em falhas e categorização.

• 1. Instale: npm i -D allure-playwright e npm i -g allure-commandline. Configure em playwright.config.ts.
• 2. Nos testes, adicione: test.info().annotations.push({type:"feature", description:"Login"})
• 3. Configure hook afterEach para screenshot em falhas: if (testInfo.status === "failed") await page.screenshot({...})
• 4. Execute 3 vezes. Gere com histórico: copie allure-report/history allure-results/. Rode allure generate --clean && allure open

Configure um dashboard que o time consulte ativamente.

• 1. No Grafana (gratuito), crie dashboard com: taxa de sucesso dos testes ao longo do tempo, tempo de execução da suíte por semana e testes ignorados por sprint.
• 2. Configure uma fonte de dados com dados históricos de 4 sprints. Identifique tendências: a suíte está ficando mais lenta? Taxa de sucesso caiu após alguma mudança?
• 3. Apresente na retrospectiva da próxima sprint. Use os dados para propor uma ação concreta com métrica de sucesso definida.

Crie um conjunto de prompts reutilizáveis que amplificam sua produtividade como QA.

• 1. Teste este prompt com uma user story real: "Você é QA sênior. Dado a user story abaixo, gere: 10 casos positivos, 5 negativos, 3 edge cases. Formato: tabela com ID|Descrição|Pré-condição|Passos|Resultado Esperado. Story: [cole aqui]"
• 2. Refine o prompt até o output ser realmente útil. Anote cada iteração e o que mudou.
• 3. Crie mais 3 prompts: (a) converter critérios em Gherkin, (b) revisar caso de teste apontando lacunas, (c) gerar 50 cadastros com dados brasileiros realistas.
• 4. Documente no Google Docs, nome, quando usar, prompt completo, exemplo de output. Este é seu Prompt Cookbook.

Configure testes visuais com IA para detectar regressões de UI.

• 1. Crie conta gratuita no Applitools. Integre o SDK Playwright e configure captura de baseline para as 3 páginas principais do Sauce Demo.
• 2. Faça uma mudança visual pequena no CSS via DevTools. Execute com Applitools e veja o diff visual. Aceite a mudança intencional e rejeite a acidental.
• 3. Configure no CI: execute em dois branches (main como baseline e branch com mudança). Verifique que o Applitools detecta e reporta a diferença automaticamente no PR.

Faça uma auditoria completa da arquitetura de testes de um projeto open source real.

• 1. Escolha um projeto no GitHub com pelo menos 100 stars e uma pasta de testes. Analise: distribuição da pirâmide, padrões usados, cobertura reportada.
• 2. Identifique pelo menos 5 débitos técnicos: testes duplicados, seletores frágeis, dados hardcoded, ausência de isolamento, falta de paralelismo.
• 3. Projete a arquitetura ideal para o projeto: diagrama com camadas, ferramentas sugeridas e justificativa para cada decisão.
• 4. Escreva um documento de 1 página com o plano de migração: o que mudar primeiro, riscos do processo e métricas de sucesso.

Selecione e implemente métricas que o time realmente use para tomar decisões.

• 1. Selecione 4 métricas: uma de processo (bug escape rate), uma de produto (MTTR), uma de automação (flaky test rate) e uma de entrega (deployment frequency). Defina como cada uma é calculada.
• 2. Configure coleta automática no CI/CD e crie dashboard. Estabeleça baselines atuais e defina metas para o próximo trimestre com justificativa.
• 3. Apresente nas próximas 3 reuniões de sprint review. Após a terceira, avalie: o time usa os dados para decidir? Alguma métrica está sendo 'jogada'?

Use TDD e BDD de forma integrada para desenvolver com alta cobertura desde o início.

• 1. Escolha feature nova simples. Antes de qualquer código, escreva os cenários BDD em Gherkin com PO e dev. Esses cenários se tornam os testes de aceite automatizados.
• 2. Usando TDD, implemente em ciclos Red-Green-Refactor: teste unitário que falha, mínimo para passar, refatora. Repita até todos os cenários BDD estarem cobertos.
• 3. Compare cobertura TDD+BDD vs. feature equivalente sem essas práticas. Qual o tempo adicional de desenvolvimento? Qual a diferença em bugs encontrados em QA?

Implemente um teste de carga avançado com múltiplos cenários e integre ao GitHub Actions.

• 1. Crie o script abaixo com 2 cenários simultâneos: leitura e escrita. Rode localmente e analise os percentis.
• 2. Adicione thresholds que bloqueiam o deploy: p95 < 500ms, error rate < 1%, p99 < 1000ms.
• 3. Configure o GitHub Actions para executar o teste de performance uma vez por dia às 2h da manhã.
• 4. Analise: em qual nível de carga o p95 começa a ultrapassar 500ms? Esse é o limite de capacidade atual.

Interprete resultados de teste de carga para identificar o gargalo.

• 1. Execute teste k6 em ramp-up de 0 a 200 VUs em 5 minutos. Colete throughput, taxa de erro, P50, P95 e P99. Identifique o ponto exato onde a performance começa a degradar.
• 2. Correlacione com métricas de infraestrutura: a degradação começa quando CPU atinge 80%? Quando conexões de banco esgotam? Essa correlação aponta o gargalo real.
• 3. Produza relatório de 2 páginas: resumo executivo (o sistema aguenta N usuários com SLOs satisfeitos), análise técnica (onde está o gargalo) e recomendações priorizadas.

Use o WebGoat, app vulnerável da OWASP, para praticar security testing de forma legal.

• 1. Suba o WebGoat: docker run -d -p 8080:8080 -p 9090:9090 webgoat/goat-and-wolf
• 2. No OWASP ZAP, use Automated Scan em http://localhost:8080/WebGoat. Aguarde o scan completo (15-20 min).
• 3. Categorize todos os alertas por nível: High, Medium, Low, Informational. Para cada High: descreva o vetor de ataque, impacto potencial e remediação.
• 4. Escreva um relatório executivo de 1 página com: resumo dos riscos, vulnerabilidades críticas, impacto de negócio e roadmap de correção priorizado.

Aplique os testes de segurança mais críticos para APIs REST.

• 1. No OWASP Juice Shop, explore: BOLA tentando acessar recursos de outros usuários pelo ID, Broken Authentication tentando endpoints sem token e Mass Assignment enviando campos extras.
• 2. Para cada vulnerabilidade encontrada, escreva teste de segurança automatizado usando Postman ou código: confirma que a vulnerabilidade existe (red) e que foi corrigida (green).
• 3. Configure os testes de segurança no pipeline contra staging a cada deploy. Configure para notificar o time de segurança quando vulnerabilidades de alta severidade forem encontradas.

Configure análise estática e dinâmica como parte do pipeline de qualidade.

• 1. Configure o CodeQL (gratuito para projetos públicos) como action no repositório. Execute a análise em push para main e analise: quais vulnerabilidades foram encontradas e qual a severidade?
• 2. Configure o Snyk com npx snyk test no pipeline. Configure para falhar com vulnerabilidades High ou Critical em dependências diretas.
• 3. Documente a política de segurança do time: quais vulnerabilidades bloqueiam o deploy, quais exigem tratamento em X dias e quais são aceitas como risco após avaliação.

Configure sua suíte Appium para executar em devices reais no BrowserStack.

• 1. Crie conta no BrowserStack (trial gratuito com 100 minutos). Obtenha sua User e Access Key.
• 2. Adapte suas desired capabilities para o BrowserStack: substitua appium:app por app com o app ID do BrowserStack.
• 3. Execute o teste em 2 devices diferentes: Pixel 6 (Android 13) e Samsung Galaxy S21 (Android 12). Compare os resultados.
• 4. Analise o relatório no BrowserStack: vídeo da execução, logs, screenshots por step. Quais diferenças de comportamento você identificou entre os dois devices?

Execute testes mobile em dispositivos reais na nuvem.

• 1. Configure conta de trial no BrowserStack. Execute testes Appium em 3 dispositivos reais: Android antigo (API 28), Android atual (API 33) e iPhone. Compare com resultados do simulador.
• 2. Identifique pelo menos um comportamento que difere entre simulador e dispositivo real: animações, sensores, rede. Documente como evidência do valor dos dispositivos reais.
• 3. Integre no CI com GitHub Actions: execute os testes mobile nos dispositivos mais críticos (menor e maior versão de SO suportada) a cada PR para a main.

Configure a stack de observabilidade localmente e crie dashboards de qualidade.

• 1. Crie um docker-compose.yml com Prometheus, Grafana e uma aplicação Node.js com métricas expostas (use prom-client).
• 2. No Grafana (localhost:3000, admin/admin), adicione o Prometheus como datasource.
• 3. Crie um dashboard com 4 painéis: (1) taxa de requests/s, (2) p95 de latência, (3) error rate, (4) availability das últimas 24h.
• 4. Configure um alerta que envia e-mail quando o error rate ultrapassar 1% por mais de 5 minutos.

Execute RCA completo usando logs, métricas e traces.

• 1. Escolha o erro mais frequente da última semana no Sentry ou Grafana. Execute RCA com os 5 Porquês partindo do sintoma (o que o usuário viu) até a causa raiz sistêmica.
• 2. Valide o RCA com dados: cada resposta deve ser corroborada por dado de observabilidade, não por suposição. Se não houver dado, você encontrou um gap de observabilidade.
• 3. Produza Post-Mortem no formato padrão: timeline, impacto, causa raiz com evidências, ações corretivas e ações preventivas.

Configure Healenium e veja o auto-repair em ação quando um seletor muda.

• 1. Configure com Docker Compose: docker-compose up -d usando o docker-compose.yml oficial do Healenium.
• 2. No projeto Selenium Java, substitua o driver: WebDriver driver = SelfHealingDriver.create(new ChromeDriver())
• 3. Execute o teste uma vez para criar o baseline. Depois modifique o HTML de um elemento via DevTools (mude o id ou class).
• 4. Execute novamente. O Healenium deve detectar a mudança e sugerir o novo seletor. Veja o relatório em localhost:7878.