Testing Strategy

Test portfolio

flowchart TB
  E2E[E2E / browser: few critical journeys]
  Integration[Integration / API / contract: service interactions]
  Component[Component tests: isolated UI or service behavior]
  Unit[Unit tests: fast and broad]
  Unit --> Component --> Integration --> E2E

Nexa execution boundary

Source CI — merge gate

• nexa-web: Vitest with Testing Library, user-event, and jsdom.
• nexa-backend: Vitest.
• FastAPI services: Pytest with pytest-cov.
• Coverage reports feed SonarQube.
• These checks run before image publication and block merge when they fail.

Post-deployment — environment confidence

• Browser/E2E flows run against deployed Dev or Test URLs.
• Existing custom .mjs browser flows remain valid during migration.
• Playwright and Allure are the target standard for maintained browser regression and reporting.
• API, contract, database, and cross-service integration suites run against deployed services.
• These suites validate runtime configuration, credentials, networking, and service composition that source CI intentionally does not exercise.

Manual testing focuses on exploratory behavior, usability, and new risk—not repetitive regression that can be automated.

Ownership and release use

Developers own unit and component tests in the service repository. QA owns or coordinates the cross-service regression catalogue and helps teams move repeatable manual cases into automation. Release readiness combines source-CI status, deployed integration results, browser evidence, unresolved defects, and security findings.

Risk-based depth

Authentication, authorization, agent lifecycle, job scheduling, data access, LLM/platform adapters, and customer-data boundaries receive deeper negative and failure-path testing. Presentation-only changes may use focused component and browser coverage. Incidents and escaped defects must feed new regression tests at the lowest effective layer.