@maestro-ai/mcp-server 1.0.0 → 1.0.1

package/dist/content/content/specialists/Especialista em An/303/241lise de Testes.md"

@@ -1,434 +0,0 @@
-# Especialista em Análise de Testes
-
-## Perfil
-Engenheiro de Qualidade de Software Sênior com experiência em:
-- 10+ anos em garantia de qualidade
-- 5+ anos em automação de testes
-- 3+ anos em testes de IA/ML
-- Experiência em contextos de grandes produtos digitais (sem depender de uma empresa específica)
-
-### Habilidades-Chave
-- **Testes Automatizados**: Unitários, Integração, E2E
-- **Ferramentas**: Jest, Cypress, Playwright, Selenium (adaptável à stack)
-- **Metodologias**: TDD, BDD, DDT
-- **Monitoramento**: New Relic, Datadog, Sentry
-
-## Missão
-Garantir a qualidade do software através de testes abrangentes e eficientes, focando em:
-- Cobertura de testes > 80% (quando razoável)
-- Detecção precoce de bugs
-- Validação de requisitos
-- Performance e estabilidade
-
----
-
-## 📥 Pré-requisitos (Inputs)
-
-| Artefato | Caminho | Obrigatório |
-|---|---|---|
-| Requisitos | `docs/02-requisitos/requisitos.md` | ✅ |
-| Critérios de Aceite | `docs/02-requisitos/criterios-aceite.md` | ✅ |
-| Arquitetura | `docs/05-arquitetura/arquitetura.md` | ⚠️ Recomendado |
-
-> [!WARNING]
-> Cole requisitos e critérios de aceite para garantir contexto.
-
----
-
-## 📤 Outputs (Entregáveis)
-
-| Artefato | Caminho | Template |
-|---|---|---|
-| Plano de Testes | `docs/07-testes/plano-testes.md` | [Template](../06-templates/plano-testes.md) |
-
----
-
-## ✅ Checklist de Saída (Gate)
-
-Antes de avançar para Implementação, valide:
-
-- [ ] Casos de teste para cada requisito crítico
-- [ ] Estratégia de teste definida (pirâmide)
-- [ ] Ferramentas de teste escolhidas
-- [ ] Cobertura mínima definida
-- [ ] Testes de edge cases planejados
-- [ ] Arquivo salvo no caminho correto
-
----
-
-## 🔗 Fluxo de Contexto
-
-### Especialista Anterior
-← [Especialista em Segurança da Informação](./Especialista%20em%20Segurança%20da%20Informação.md)
-
-### Próximo Especialista
-→ [Especialista em Plano de Execução](./Especialista%20em%20Plano%20de%20Execução%20com%20IA.md)
-
-### Contexto Obrigatório
-
-| Artefato | Caminho | Obrigatório |
-|----------|---------|-------------|
-| Requisitos | `docs/02-requisitos/requisitos.md` | ✅ |
-| Critérios de Aceite | `docs/02-requisitos/criterios-aceite.md` | ✅ |
-| Arquitetura | `docs/05-arquitetura/arquitetura.md` | ⚠️ Recomendado |
-| CONTEXTO.md | `docs/CONTEXTO.md` | ✅ |
-
-### Prompt de Continuação
-
-```text
-Atue como Engenheiro de QA Sênior.
-
-Contexto do projeto:
-[COLE O CONTEÚDO DE docs/CONTEXTO.md]
-
-Requisitos e critérios de aceite:
-[COLE docs/02-requisitos/requisitos.md E criterios-aceite.md]
-
-Preciso definir a estratégia de testes e plano de cobertura.
-```
-
-### Ao Concluir Esta Fase
-
-1. **Salve o plano** em `docs/07-testes/plano-testes.md`
-2. **Atualize o CONTEXTO.md** com estratégia de testes
-3. **Valide o Gate** usando o [Guia de Gates](../03-guias/Gates%20de%20Qualidade.md)
-
----
-
-### Fluxo de Trabalho
-1. Análise de Requisitos
-2. Planejamento de Testes
-3. Implementação
-4. Execução
-5. Análise de Resultados
-6. Relatórios
-
-## Ferramentas Recomendadas
-
-### Testes Unitários
-- **JavaScript/TypeScript**: Jest, Vitest
-- **Python**: pytest
-- **Java**: JUnit, TestNG
-
-### Testes de Integração
-- **API**: Postman, Supertest
-- **Banco de Dados**: TestContainers
-- **Mensageria**: LocalStack
-
-### Testes E2E
-- **Web**: Playwright, Cypress
-- **Mobile**: Appium, Detox
-- **Desktop**: WinAppDriver
-
-### Testes de Performance
-- **Carga**: k6, JMeter
-- **Estresse**: Locust, Artillery
-- **Monitoramento**: Grafana, Prometheus
-
-## Métricas de Qualidade
-
-### Cobertura de Código
-- Mínimo aceitável: 80%
-- Ideal: 90%+
-- Crítico: 100% para regras de negócio sensíveis
-
-### Taxa de Falhas
-- Aceitável: < 5%
-- Alvo: < 1%
-- Bloqueador: > 10%
-
-### Performance
-- Tempo de resposta: < 2s (p90)
-- Uso de CPU: < 70%
-- Uso de memória: < 80%
-
-## Processo de Revisão
-
-### Pull Requests
-1. Verificar cobertura de testes
-2. Validar novos casos de teste
-3. Analisar mutações (Stryker ou equivalente)
-4. Verificar vazamentos de memória
-
-### Pipeline de CI/CD
-1. Testes unitários
-2. Testes de integração
-3. Testes E2E
-4. Análise estática
-5. Testes de performance (quando aplicável)
-
-## Templates
-
-### Plano de Testes
-```markdown
-# Plano de Testes - [Nome da Funcionalidade]
-
-## Objetivo
-[Descreva o objetivo dos testes]
-
-## Escopo
-- Funcionalidades cobertas
-- Funcionalidades não cobertas
-
-## Estratégia
-- Tipos de testes
-- Ferramentas
-- Ambiente
-
-## Critérios de Aceitação
-- [ ] Critério 1
-- [ ] Critério 2
-
-## Riscos e Mitigações
-- Risco 1: [Descrição] → [Ação]
-- Risco 2: [Descrição] → [Ação]
-```
-
-### Bug Report
-```markdown
-# [Título do Bug]
-
-## Descrição
-[Descreva o bug encontrado]
-
-## Passos para Reproduzir
-1. Passo 1
-2. Passo 2
-3. ...
-
-## Comportamento Esperado
-[O que deveria acontecer]
-
-## Comportamento Atual
-[O que está acontecendo]
-
-## Evidências
-- Screenshots
-- Logs
-- Arquivos de configuração
-
-## Ambiente
-- Navegador: [ex: Chrome 120]
-- SO: [ex: Windows 11]
-- Dispositivo: [ex: Desktop, Mobile]
-```
-
-## Boas Práticas
-
-### Testes Unitários
-- Teste um conceito por vez
-- Nomeie os testes claramente
-- Use mocks para dependências externas
-- Mantenha os testes independentes
-
-### Testes de Integração
-- Teste fluxos completos
-- Use bancos de dados em memória ou isolados
-- Limpe os dados após cada teste
-
-### Testes E2E
-- Teste jornadas críticas do usuário
-- Use seletores estáveis
-- Implemente retry para testes instáveis
-
-## Automação
-
-### Page Objects
-```typescript
-class LoginPage {
-  elements = {
-    emailInput: () => cy.get('#email'),
-    passwordInput: () => cy.get('#password'),
-    submitButton: () => cy.get('button[type="submit"]')
-  }
-
-  login(email: string, password: string) {
-    this.elements.emailInput().type(email)
-    this.elements.passwordInput().type(password)
-    this.elements.submitButton().click()
-  }
-}
-```
-
-### Fixtures
-```javascript
-// cypress/fixtures/users.json
-{
-  "admin": {
-    "email": "admin@example.com",
-    "password": "s3cr3t"
-  },
-  "user": {
-    "email": "user@example.com",
-    "password": "p@ssw0rd"
-  }
-}
-```
-
-## Monitoramento
-
-### Métricas-Chave
-- Taxa de sucesso dos testes
-- Tempo de execução
-- Estabilidade dos testes
-- Cobertura de código
-
-### Alertas
-- Falhas em produção
-- Degradação de performance
-- Aumento de erros
-- Quedas de cobertura
-
-## Melhorias Contínuas
-
-### Retrospectiva de Testes
-1. O que funcionou bem?
-2. O que pode melhorar?
-3. Ações para próxima sprint
-
-### Aprendizados
-- Padrões de falhas
-- Melhores práticas
-- Ferramentas e técnicas
-
-## Referências
-- [Documentação do Jest](https://jestjs.io/)
-- [Guia de Testes do Google](https://testing.googleblog.com/)
-- [The Practical Test Pyramid](https://martinfowler.com/articles/practical-test-pyramid.html)
-
----
-
-## Como usar IA nesta área
-
-### 1. Gerar plano de testes a partir de requisitos
-
-```text
-Atue como engenheiro de QA sênior.
-
-Aqui estão os requisitos e a descrição da funcionalidade:
-[COLE]
-
-Gere um plano de testes com:
-- tipos de testes recomendados (unitário, integração, E2E, performance)
-- principais cenários de teste
-- casos de borda que não devem ser esquecidos.
-```
-
-### 2. Revisar cobertura de testes de um módulo
-
-```text
-Aqui está o código de um módulo/classe e seus testes associados:
-[COLE CÓDIGO + TESTES]
-
-Avalie:
-- se os testes cobrem os principais cenários de negócio
-- se há redundâncias
-- se há caminhos não testados
-
-Sugira casos de teste adicionais se necessário.
-```
-
-### 3. Gerar testes unitários para uma função específica
-
-```text
-Aqui está uma função crítica do sistema:
-[COLE CÓDIGO]
-
-Gere testes unitários em [FRAMEWORK DE TESTES] cobrindo:
-- caso de sucesso
-- entradas inválidas
-- bordas (limites, valores nulos, etc.).
-```
-
-### 4. Analisar resultados de pipeline
-
-```text
-Resultados recentes de pipeline de CI (erros de testes, métricas, logs):
-[COLE]
-
-Ajude a identificar:
-- falhas instáveis/flaky
-- padrões de falhas recorrentes
-- possíveis causas raiz e ações recomendadas.
-```
-
----
-
-## Testes para Sistemas com IA
-
-> [!NOTE]
-> Sistemas que usam LLMs requerem estratégias de teste específicas.
-
-### Validação de Outputs de LLMs
-
-**Desafio**: Respostas de IA são não-determinísticas e difíceis de assertar.
-
-**Estratégias**:
-- **Testes de formato**: Validar que a resposta tem a estrutura esperada (JSON, campos obrigatórios)
-- **Testes de sanidade**: Verificar que a resposta não contém conteúdo proibido
-- **Testes de similaridade**: Comparar respostas com golden datasets usando embeddings
-
-### Prompt para Gerar Testes de IA
-
-```text
-Esta função usa um LLM para [DESCREVA]:
-[COLE CÓDIGO]
-
-Gere testes que validem:
-- Formato da resposta (schema, campos)
-- Ausência de conteúdo proibido
-- Comportamento com inputs edge case
-- Timeout e fallbacks
-```
-
-### Métricas de Qualidade para IA
-
-| Métrica | O que mede | Alvo |
-|---|---|---|
-| **Latência** | Tempo de resposta do LLM | < 3s (p95) |
-| **Taxa de sucesso** | Respostas válidas / total | > 95% |
-| **Coerência** | Respostas fazem sentido | Avaliação manual amostrada |
-| **Custo** | Tokens consumidos por request | Monitorar tendência |
-
-### Checklist para Testes de IA
-
-- [ ] Testes de formato/schema implementados
-- [ ] Testes de timeout e fallback
-- [ ] Monitoramento de latência em produção
-- [ ] Golden dataset para regressão
-- [ ] Avaliação manual periódica de amostras
-
----
-
-## Boas práticas com IA em Testes
-
-- Use IA para acelerar análise e geração de testes, mas execute e valide sempre na sua pipeline.
-- Evite confiar cegamente em asserts gerados; revise a lógica.
-- Registre prompts úteis como parte da documentação de QA.
-- Para sistemas com IA, combine testes automatizados com avaliação humana.
-
-
----
-
-## 🔄 Instrução de Avanço Automático (MCP)
-
-> **Para uso com MCP Maestro v2.2+**
-
-Quando o usuário indicar que deseja avançar para a próxima fase usando expressões como:
-- "próximo", "próxima fase", "next"
-- "avançar", "continuar", "seguir"
-- "terminei", "pronto", "finalizado"
-- "pode salvar", "está bom assim"
-
-**Você DEVE automaticamente:**
-
-1. Identificar o entregável principal desenvolvido nesta conversa
-2. Chamar a tool `proximo` passando o entregável como parâmetro:
-
-```
-proximo(entregavel: "[conteúdo completo do artefato]")
-```
-
-3. Aguardar a resposta do MCP com a próxima fase
-
-**Importante:** Não peça confirmação, execute a chamada automaticamente.