projeto_tests_kit

Guia o desenvolvedor em testes completamente livres, sem script ou planejamento prévio, conduzidos pela intuição e experiência. Use esta skill SEMPRE que o objetivo for testar de forma rápida e informal, sem roteiro predefinido. Acione quando o usuário mencionar: "teste ad-hoc", "teste livre", "testar sem planejamento", "quero só clicar por aí e ver o que quebra", "não tenho tempo para escrever testes formais agora", "quero fazer um teste rápido antes de entregar", "teste informal". Diferente do teste exploratório (que usa sessões estruturadas com charter e heurísticas), o ad-hoc é pura exploração livre sem compromisso de documentação formal. Ideal para verificações rápidas, descobertas iniciais de um sistema desconhecido ou validações de urgência. Funciona para qualquer tipo de software.

Guia o desenvolvedor ou Product Manager na estruturação do processo de validação com o usuário final ou stakeholder do negócio — o UAT (User Acceptance Testing). Use esta skill SEMPRE que o objetivo for preparar e conduzir a homologação de uma entrega com o cliente ou usuário real. Acione quando o usuário mencionar: "UAT", "User Acceptance Testing", "teste de aceitação", "o cliente vai testar o sistema", "entregar para homologação", "quero preparar o UAT", "critérios de aceitação", "o usuário precisa aprovar a entrega", "homologação com o cliente", "BDD", "Given-When-Then" (no contexto de aceitação de entrega), "aceite do cliente", "aprovação do stakeholder". Diferente do teste de sistema (feito pelo time técnico), o UAT envolve o usuário final ou negócio como principal validador. Usa linguagem de negócio, não técnica. Agnóstico de linguagem de programação.

Guia o desenvolvedor na validação completa de APIs — contratos, endpoints, payloads, autenticação, códigos de status HTTP e comportamento sob condições de erro. Use esta skill SEMPRE que o objetivo for testar interfaces de programação de aplicações, independentemente da ferramenta (Postman, curl, código, insomnia ou qualquer HTTP client). Acione quando o usuário mencionar: "testar API", "teste de API", "API testing", "validar endpoints", "testar REST", "testar GraphQL", "testar contrato de API", "verificar se a API está retornando certo", "testar autenticação da API", "testar headers", "criar coleção de testes para minha API", "como testar meus endpoints". Não confundir com teste de integração (que testa comunicação entre módulos internos) — esta skill foca especificamente em interfaces HTTP. Agnóstica de linguagem e ferramenta.

Guia o desenvolvedor na criação de testes baseados no conhecimento interno do código-fonte. Use esta skill SEMPRE que o objetivo for garantir cobertura de caminhos de execução, verificar branches, condicionais e loops, ou calcular métricas de cobertura de código. Acione quando o usuário mencionar: "cobertura de código", "code coverage", "teste estrutural", "teste de caixa branca", "white box test", "quero cobrir todos os caminhos do meu código", "como testar esse if/else", "análise de fluxo de controle", "path testing", "cobertura de ramos". Não confundir com caixa-preta (que não acessa o código) nem com testes de integração (que testam comunicação entre módulos). Esta skill é ideal para desenvolvedores que têm acesso ao código e querem garantir que todos os caminhos lógicos estão cobertos por testes. Funciona em qualquer linguagem.

Guia o desenvolvedor na criação de testes baseados exclusivamente no comportamento externo do sistema, sem acesso ou análise do código-fonte. Use esta skill SEMPRE que o objetivo for validar se o sistema faz o que foi especificado, testar como um usuário ou consumidor de API, aplicar partição de equivalência ou análise de valor de borda. Acione quando o usuário mencionar: "teste funcional", "teste de caixa preta", "black box test", "testar sem ver o código", "testar como usuário", "partição de equivalência", "valor de borda", "boundary testing", "testar com base nos requisitos", "validar o comportamento esperado", "testar uma API sem saber como foi implementada". Diferente da caixa branca (que analisa caminhos internos do código), a caixa preta parte dos requisitos e especificações. Funciona para qualquer linguagem e é ideal quando o testador não tem ou não quer acessar a implementação interna.

Guia o desenvolvedor a validar o comportamento do sistema sob volumes crescentes de usuários e requisições, identificando o ponto de degradação de desempenho e a capacidade máxima suportada. Use esta skill SEMPRE que o objetivo for responder "o sistema aguenta N usuários simultâneos?" ou "a partir de quantos usuários o desempenho degrada?". Acione quando o usuário mencionar: "teste de carga", "load testing", "carga de usuários", "o sistema aguenta N usuários simultâneos", "quero testar com X requisições por segundo", "antes do lançamento testar com a carga esperada", "quero saber quando o sistema começa a degradar", "escalar usuários gradualmente e ver o comportamento", "carga de pico". Diferente do teste de desempenho (condições normais) e de estresse (além dos limites), a carga vai do normal até o máximo planejado. Requer ambiente representativo.

Guia o desenvolvedor na validação do comportamento do sistema em diferentes navegadores, sistemas operacionais, dispositivos e versões de dependências. Use esta skill SEMPRE que o objetivo for garantir que o sistema funciona corretamente para usuários em diferentes ambientes. Acione quando o usuário mencionar: "teste de compatibilidade", "compatibility testing", "cross-browser", "testar em diferentes browsers", "testar em diferentes sistemas operacionais", "funciona no Safari, Firefox, IE?", "compatível com mobile", "responsivo?", "testar em diferentes versões da dependência", "backward compatibility", "funciona no Android? No iOS?", "testar em telas diferentes". Diferente dos testes funcionais (que verificam o comportamento) e de usabilidade (que verificam a experiência), a compatibilidade verifica se o mesmo comportamento correto ocorre em todos os ambientes suportados.

Guia o desenvolvedor na medição e validação de métricas de desempenho do sistema — tempo de resposta, throughput e uso de recursos em condições normais de uso. Use esta skill SEMPRE que o objetivo for medir quão rápido e eficiente o sistema é, estabelecer um baseline de performance ou identificar gargalos. Acione quando o usuário mencionar: "teste de desempenho", "performance testing", "performance test", "quão rápido está a API", "tempo de resposta", "medir throughput", "latência", "TPS", "transações por segundo", "baseline de performance", "benchmark", "o sistema está lento e quero medir", "quero definir SLAs de desempenho". Diferente do teste de carga (que aumenta o volume de usuários) e de estresse (que vai além dos limites), o desempenho mede em condições normais. Agnóstico de ferramenta e linguagem.

Guia o desenvolvedor a identificar o ponto de colapso do sistema, testando-o além de seus limites operacionais definidos para verificar como ele falha e se consegue se recuperar. Use esta skill SEMPRE que o objetivo for encontrar o limite máximo do sistema, verificar se a falha é graceful ou abrupta, ou realizar soak testing (carga sustentada por longos períodos). Acione quando o usuário mencionar: "teste de estresse", "stress testing", "stress test", "quero saber o limite do sistema", "ponto de ruptura", "o que acontece quando o sistema colapsa", "testar além da capacidade", "soak testing", "durabilidade do sistema", "o sistema aguenta horas sob carga?". Diferente do teste de carga (que valida dentro dos limites planejados), o estresse vai propositalmente além deles. Requer ambiente isolado e pré-requisito de baseline de carga.

Guia o desenvolvedor em uma verificação rápida e superficial do sistema como um todo para determinar se um novo build ou deploy foi bem-sucedido e se as funcionalidades críticas básicas respondem. Use esta skill SEMPRE que o objetivo for determinar se vale a pena avançar para testes mais profundos ou se o build está quebrado. Acione quando o usuário mencionar: "teste de fumaça", "smoke test", "smoke testing", "o sistema subiu?", "o deploy funcionou?", "validar o build", "checar se está de pé", "build verification test", "preciso saber se o sistema básico está ok antes de testar mais". Diferente da sanidade (uma feature específica) e da regressão (abrangente), a fumaça cobre o sistema inteiro de forma superficial — só caminho feliz — e deve terminar em menos de 15 minutos. Resultado é binário: PASSA (avança) ou FALHA (para).

Guia o desenvolvedor na validação da comunicação e do contrato entre dois ou mais módulos, serviços ou componentes que precisam trabalhar juntos. Use esta skill SEMPRE que o objetivo for verificar que módulos distintos se comunicam corretamente quando integrados, não de forma isolada. Acione quando o usuário mencionar: "teste de integração", "integration testing", "testar como dois módulos se comunicam", "validar a integração com o banco de dados", "testar a camada de serviço com o repositório", "meus módulos A e B precisam se comunicar", "testar a integração com uma API externa", "verificar o contrato entre componentes". Diferente de testes unitários (que isolam completamente) e de sistema (que testam o sistema todo), a integração foca na junção de partes específicas. Agnóstico de linguagem e framework.

Guia o desenvolvedor a validar como o sistema se comporta e se recupera diante de falhas — crashes, perda de conectividade, indisponibilidade de serviços dependentes, corrupção de dados ou interrupção abrupta. Use esta skill SEMPRE que o objetivo for verificar a resiliência e tolerância a falhas do sistema. Acione quando o usuário mencionar: "teste de recuperação", "recovery testing", "chaos engineering básico", "o que acontece quando o banco cai", "e se o sistema falhar no meio de uma transação", "resiliência do sistema", "fallback", "circuit breaker", "testar tolerância a falhas", "o sistema precisa se recuperar de quedas", "o que acontece em caso de falha". Este é um teste avançado que NUNCA deve ser executado em produção. Requer ambiente isolado com capacidade de restauração rápida. Agnóstico de linguagem.

Guia o desenvolvedor a garantir que funcionalidades existentes continuam funcionando corretamente após uma mudança de código. Use esta skill SEMPRE que o objetivo for verificar que uma alteração (nova feature, refatoração, correção de bug, atualização de dependência) não quebrou nada que funcionava antes. Acione quando o usuário mencionar: "teste de regressão", "regression testing", "quero garantir que não quebrei nada", "fiz uma mudança e quero verificar o impacto", "validar depois de um merge ou PR", "o que testar antes de um release", "minha refatoração pode ter quebrado algo", "validar que o código antigo ainda funciona". Diferente da sanidade (que testa uma funcionalidade específica) e da fumaça (que verifica só o básico do sistema), a regressão cobre todas as funcionalidades afetadas pela mudança. Funciona em qualquer linguagem.

Guia o desenvolvedor em uma verificação rápida e focada de uma funcionalidade específica após uma mudança local ou correção de bug. Use esta skill SEMPRE que o objetivo for confirmar que uma funcionalidade específica ainda está funcionando após uma alteração pequena, sem executar a suíte completa de testes. Acione quando o usuário mencionar: "teste de sanidade", "sanity check", "sanity test", "quero verificar rapidamente se essa feature ainda funciona", "fiz uma pequena correção e quero testar só essa parte", "verificação rápida antes de passar para QA", "checar se minha mudança não quebrou a feature". Diferente da fumaça (sistema inteiro, superficial) e da regressão (abrangente, todas as funcionalidades afetadas), a sanidade foca em UMA funcionalidade com profundidade moderada. Dura entre 15 e 30 minutos.

Guia o desenvolvedor na identificação e teste de vulnerabilidades de segurança no sistema, com foco em práticas acessíveis baseadas no OWASP Top 10. Use esta skill SEMPRE que o objetivo for verificar se o sistema está protegido contra as ameaças de segurança mais comuns. Acione quando o usuário mencionar: "teste de segurança", "security testing", "pentest básico", "vulnerabilidades", "OWASP", "SQL injection", "XSS", "cross-site scripting", "testar autenticação e autorização", "quero saber se minha API está segura", "auditoria de segurança básica", "dados dos usuários estão protegidos", "IDOR", "CORS", "injeção". Esta skill cobre o nível básico acessível a qualquer desenvolvedor — pentest profundo requer especialista em segurança ofensiva. Agnóstica de linguagem e framework.

Guia o desenvolvedor na validação do sistema completo como uma unidade, verificando que todos os componentes integrados se comportam corretamente em conjunto e que os requisitos do sistema são atendidos de ponta a ponta. Use esta skill SEMPRE que o objetivo for testar fluxos completos do usuário em um ambiente representativo do de produção. Acione quando o usuário mencionar: "teste de sistema", "system testing", "teste end-to-end", "testar o sistema completo", "testar de ponta a ponta", "verificar se o sistema atende os requisitos", "testar o fluxo completo de uma funcionalidade", "antes de entregar para o cliente quero testar por completo", "validar o sistema em staging". Diferente de integração (módulos específicos) e UAT (validação com o cliente), o teste de sistema é feito pelo time técnico no sistema completo. Agnóstico de linguagem e stack.

Guia o desenvolvedor ou designer na avaliação da facilidade de uso de uma interface, verificando se os usuários conseguem completar suas tarefas com eficiência, eficácia e satisfação. Use esta skill SEMPRE que o objetivo for avaliar a experiência do usuário, aplicar as heurísticas de Nielsen ou conduzir testes com usuários reais. Acione quando o usuário mencionar: "teste de usabilidade", "usability testing", "UX testing", "o usuário consegue usar o sistema", "teste com usuário real", "heurísticas de Nielsen", "avaliação heurística", "minha interface é intuitiva", "quero testar a experiência do usuário", "facilidade de uso", "o usuário trava em algum ponto?". Diferente do UAT (que valida critérios de aceitação de negócio), o teste de usabilidade foca na experiência e facilidade de uso. Agnóstico de plataforma (web, mobile, desktop).

Guia o desenvolvedor em sessões estruturadas de teste exploratório usando charters, heurísticas e timeboxing. Use esta skill SEMPRE que o objetivo for explorar sistematicamente uma funcionalidade em busca de problemas não cobertos por testes formais, usando técnicas como SFDPOT, HICCUPPS ou mnemonics de James Bach. Acione quando o usuário mencionar: "teste exploratório", "session-based testing", "teste com charter", "quero descobrir bugs que não sabia que existiam", "testar com heurísticas", "investigar essa funcionalidade profundamente", "exploração estruturada". Diferente do ad-hoc (completamente livre), o exploratório tem missão, tempo definido e registro. Adequado para qualquer nível, mas mais produtivo com alguma experiência prévia.