ClinicFlow QA Automation Lab

Projeto voltado à análise de qualidade e automação de testes para o ClinicFlow, uma aplicação web de gestão clínica com front-end, API REST, autenticação por perfil, cadastro de pacientes, agendamento de consultas e dashboard de indicadores.

O objetivo deste repositório é apresentar uma abordagem ponta a ponta de Quality Engineering: leitura de produto, priorização por risco, definição de critérios de aceite, registro de defeitos, automação de API/UI com Playwright e execução em CI com publicação de artefatos.

Escopo funcional coberto

A suíte prioriza os fluxos de maior impacto para a operação do produto:

1. RBAC / controle de acesso: valida permissões para admin, recepcionista e médico em pacientes, consultas e usuários.
2. Agendamento de consultas: valida criação de consultas, regras temporais, conflito de agenda, paciente ativo e transição de status.
3. Dashboard de indicadores: valida consistência de métricas operacionais exibidas pela API e pela UI.

Estratégia de automação

A automação está organizada em dois níveis complementares:

• tests/api: valida regras de negócio diretamente na API, com foco em rapidez, isolamento e diagnóstico objetivo.
• tests/e2e: valida jornadas críticas no navegador, com foco em integração, permissões visíveis e comportamento percebido pelo usuário.

No CI, as suítes de API e UI rodam em jobs paralelos por matriz do GitHub Actions. Cada job executa em runner isolado, com sua própria instância da aplicação, reduzindo o tempo total de feedback sem criar disputa sobre o estado em memória usado pela aplicação.

Defeitos conhecidos do produto são rastreados por ID e cobertos por testes automatizados. Esses cenários permanecem documentados para preservar evidência técnica e facilitar a conversão em regressão quando o comportamento for corrigido.

Estrutura do projeto

.
├── app/                         # Aplicação ClinicFlow usada como alvo dos testes
├── docs/                        # Documentação de análise, estratégia, cenários, defeitos e CI
│   ├── 01-analise-riscos.md
│   ├── 02-cenarios-criterios-rastreabilidade.md
│   ├── 03-estrategia-ferramentas.md
│   ├── 04-defeitos-encontrados.md
│   ├── 05-evidencia-ci.md
│   └── evidencias/
├── tests/
│   ├── api/                     # Testes de API com Playwright request
│   ├── e2e/                     # Testes E2E de UI com Chromium
│   ├── pages/                   # Page Objects
│   └── support/                 # Apoio para autenticação, massa e defeitos conhecidos
├── .github/workflows/qa.yml     # Pipeline GitHub Actions
├── playwright.config.ts
├── package.json
└── tsconfig.json

Substituição da aplicação alvo

A pasta app/ contém a aplicação ClinicFlow usada como alvo dos testes. Ela pode ser substituída por outra versão da aplicação, desde que a nova base mantenha o contrato técnico esperado pela suíte:

• comando de instalação executável via npm run app:install;
• comando de inicialização executável via npm run app:start;
• aplicação disponível em http://localhost:3000;
• endpoints, autenticação, perfis, massa inicial e regras de negócio compatíveis com os cenários automatizados;
• elementos de UI e fluxos críticos compatíveis com os seletores e Page Objects existentes.

Quando a aplicação alvo evoluir de forma legítima, os testes devem ser revisados para refletir o novo contrato do produto. Se a substituição alterar rotas, payloads, usuários, massa de dados, textos visíveis ou estrutura de tela, falhas na suíte podem indicar apenas divergência contratual entre a automação e a versão validada.

Documentação complementar

A pasta docs concentra a documentação técnica e funcional do projeto. O conteúdo esperado é:

• docs/01-analise-riscos.md: leitura da aplicação, premissas, dúvidas de produto e mapa de riscos priorizado.
• docs/02-cenarios-criterios-rastreabilidade.md: critérios de aceite, cenários positivos/negativos/de borda e rastreabilidade entre regra, cenário e automação.
• docs/03-estrategia-ferramentas.md: estratégia de teste, justificativa das ferramentas, separação API/UI, dados, ambiente e próximos passos.
• docs/04-defeitos-encontrados.md: bug reports com severidade, passos de reprodução, resultado esperado, resultado atual, impacto e cobertura automatizada.
• docs/05-evidencia-ci.md: descrição da pipeline, paralelização, artefatos gerados e orientação para consulta de evidências no GitHub Actions.
• docs/evidencias: registros textuais de validação local quando aplicável.

Requisitos

• Node.js 18 ou superior.
• NPM.
• Chromium instalado pelo Playwright.

Instalação

npm install
npm run app:install
npx playwright install chromium

Execução manual da aplicação

npm run app:start

Acesse: http://localhost:3000

Usuários disponíveis:

Perfil	E-mail	Senha
admin	admin@clinicflow.test	admin123
recepcionista	recepcao@clinicflow.test	recepcao123
médico	medico@clinicflow.test	medico123
médico	sofia@clinicflow.test	medico123

Execução dos testes

Todos os testes:

npm test

Somente API:

npm run test:api

Somente UI/E2E:

npm run test:e2e

Modo visual:

npm run test:headed

Relatório HTML:

npm run report

Relatórios e artefatos

Após a execução local, o relatório HTML fica em:

playwright-report/index.html

No GitHub Actions, a pipeline publica artefatos separados por suíte:

• playwright-report-api
• playwright-results-api
• playwright-report-e2e
• playwright-results-e2e

Os resultados incluem relatório HTML, JUnit, JSON e evidências geradas pelo Playwright. Traces, screenshots e vídeos são retidos apenas em falhas.

Defeitos conhecidos cobertos por automação

ID	Área	Resumo	Cobertura automatizada
BUG-CF-001	RBAC/API	Recepcionista e médico conseguem excluir/inativar paciente pela API.	tests/api/rbac.api.spec.ts
BUG-CF-002	Consultas/API/UI	Sistema aceita agendamento no passado.	tests/api/appointments.api.spec.ts, tests/e2e/appointments-ui.e2e.spec.ts
BUG-CF-003	Consultas/API	Sistema aceita fim anterior ao início.	tests/api/appointments.api.spec.ts
BUG-CF-004	Consultas/API	Sistema aceita sobreposição para o mesmo médico.	tests/api/appointments.api.spec.ts
BUG-CF-005	Consultas/API	Sistema aceita agendamento para paciente inativo.	tests/api/appointments.api.spec.ts
BUG-CF-006	Status/API	API não valida transições de status e permite sair de estados finais.	tests/api/appointments.api.spec.ts
BUG-CF-007	Dashboard/API/UI	consultasAtivas conta consulta cancelada como ativa.	tests/api/dashboard.api.spec.ts, tests/e2e/dashboard-ui.e2e.spec.ts
BUG-CF-008	RBAC/UI	Médico visualiza formulário de cadastro de paciente.	tests/e2e/rbac-ui.e2e.spec.ts