Quality Assurance Plan (QAP)

Quality is not an accident. We adhere to a strict strategy to ensure reliability, maintainability, and security for the FirstBreath project.

📏 Style Consistency & Standards

Branch Strategy (Git Flow)

We use a rigorous branch structure to organize development.

Main Branches

• dev: Main development branch. Contains code intended for the next production release.
• master / main: Production branch. Every "push" or merge to this branch corresponds to a new version.

Secondary Branches

All working branches must start from dev (or master / main for hotfixes) and be merged via Pull Request.

• feature/: Adding a new feature.
  • V-Model: Implementation, Unit Tests, Integration Tests.
  • Example: feature/google-analytics
• bugfix/: Correction of a non-critical bug (non-production).
  • V-Model: Testing phase and acceptance.
  • Example: bugfix/upload-fix
• hotfix/: Urgent correction of a critical bug in production.
  • V-Model: Implementation -> Validation Tests -> Acceptance.
  • Example: hotfix/connection-crash
• chore/: Maintenance, code cleanup, dependency updates.
  • Example: chore/update-react
• experiment/: POC or technical experimentation.
  • V-Model: Design and Feasibility.
  • Example: experiment/webrtc-video-flow

Naming convention: type/name-description (e.g., feature/add-login).

Commit Standards

We follow the Conventional Commits convention to ensure a readable history and allow automatic changelog generation.

Format: type: subject

Allowed Commit Types

1. feat:: Adding a new feature.
   • Example: feat: add user authentication
2. fix:: Bug correction.
   • Example: fix: fix crash during image loading
3. chore:: Technical tasks without functional impact (deps, config).
   • Example: chore: update React version
4. refactor:: Code improvement without behavioral change.
   • Example: refactor: simplify validation logic
5. style:: Aesthetic code changes (spaces, formatting).
   • Example: style: fix indentations
6. test:: Adding or modifying tests.
   • Example: test: add tests for user validation
7. docs:: Documentation changes.
   • Example: docs: add Docker instructions
8. build:: Changes related to the build system or external dependencies.
   • Example: build: add Webpack
9. ci:: Changes to CI/CD configuration files.
   • Example: ci: add E2E test to pipeline
10. perf:: Performance improvements.
    • Example: perf: improve API response time
11. revert:: Reverting a previous commit.
    • Example: revert: remove feature X
12. hotfix:: Urgent correction in production (often used in branch name, sometimes as commit type to highlight urgency).
13. experiment:: Experimental code or POC.

🧪 Testing Strategy

We apply the testing pyramid to ensure optimal coverage.

1. Static Analysis (Automated)

• Tools: ESLint, Prettier, SonarQube.
• When: On every commit (via Hooks or CI).
• Checks: Code style, potential bugs, cognitive complexity, security flaws.

2. Unit Tests (Back & Front)

• Backend: Japa (AdonisJS).
• Frontend: Vitest (React/Next.js), Jest (Mobile).
• Scope: Validation of isolated business logic.

3. Integration Tests

• Scope: Verification of interactions between modules (e.g., API <-> Database).

4. End-to-End Tests (E2E)

• Tool: Playwright (Infrastructure configured, tests pending).
• Status: Manual testing only. Automated tests are yet to be implemented.
• Scope: Critical user journeys (Login, Account Creation, Main Flow).
• Environment: Staging (Local via Docker Compose).

5. Performance & Load Testing

• Current status: Not implemented as a dedicated phase.
• Justification: The FirstBreath platform is an internal B2B tool with a limited, controlled user base (equine breeding farms). The traffic volume does not require dedicated load testing at this stage.
• Monitoring: Docker resource limits and container health checks provide baseline performance oversight.
• Future consideration: If the camera-manager service scales to handle many concurrent RTSP streams, dedicated performance profiling will be introduced.

📅 Test Protocol Phases

Testing is integrated into every phase of the development lifecycle:

Phase	Activities	Responsible	Tools
Development	Unit tests, static analysis (lint, format), Storybook component testing	Developer	Vitest, Jest, Japa, ESLint, Prettier, Storybook
Pull Request	CI pipeline: lint + typecheck + unit tests + integration tests + build verification	CI (GitHub Actions)	GitHub Actions, SonarQube
Code Review	Mandatory peer review, SonarQube Quality Gate check	Team reviewer	GitHub PR Review, SonarQube
Pre-Release	Manual E2E testing of critical journeys on staging (Docker Compose)	QA / Developer	Docker Compose, manual testing
Post-Deploy	Monitoring, manual regression check	Team	Docker health checks, logs

🎯 Justification of Tool Choices

Each tool was selected based on its fit with our technology stack, team expertise, and project constraints.

Tool	Used In	Why This Tool
Vitest	Frontend, Showcase	Native ESM support, Vite-integrated, significantly faster than Jest for modern React/Next.js projects. Compatible with the existing vitest.config.ts and @testing-library/react.
Japa	Backend	Native AdonisJS test runner. Zero-config integration with the framework, supports both unit and functional (integration) test suites out of the box.
Jest	Mobile App	Default and officially supported test runner for Expo/React Native (jest-expo). Choosing it avoids configuration complexity for a mobile environment.
pytest	Vision	Python standard for testing. Rich plugin ecosystem (pytest-cov, pytest-mock), simple syntax, and excellent support for mocking hardware dependencies (camera, GPU).
Playwright	Frontend (CI)	Cross-browser E2E testing with reliable auto-waiting. Chosen over Cypress for its native multi-browser support and better CI integration. Currently configured in CI, tests pending.
Storybook	Frontend, Showcase	Component isolation and visual regression testing. Integrates Chromatic for visual diffs and @storybook/addon-a11y for accessibility checks.
ESLint	All JS/TS repos	Industry standard for JavaScript/TypeScript linting. Framework-specific configs available (eslint-config-next, Expo config).
Prettier	Backend, Frontend	Opinionated code formatter ensuring consistent style across the team without debate.
Black	Vision	"The uncompromising Python formatter." Eliminates style discussions for Python code.
Flake8	Vision	Lightweight Python linter complementing Black for catching logical errors and undefined names.
SonarQube	All repos	Self-hosted static analysis platform. Provides centralized quality dashboards, Quality Gates, and tracks technical debt over time. Chosen over cloud alternatives for data sovereignty.
GitHub Actions	All repos	Native CI/CD integration with GitHub repositories. Self-hosted runners for full control over build environments.

🔄 Continuous Integration (CI/CD)

Our GitHub Actions pipelines enforce the following rules:

1. Build Pass: Code must compile without errors.
2. Lint Pass: Code must respect formatting standards.
3. Tests Pass: All unit tests must pass.
4. Quality Gate (SonarQube):
   • 0 Critical Bugs.
   • Duplication < 3%.
   • Maintainability Rating A.
   • Minimum code coverage (depending on module).

♿ Accessibility

We integrate accessibility into our development process following industry standards.

Standards

• WCAG 2.1 (Level AA): Target compliance level for all user-facing web applications.
• RGAA 4.1: French accessibility guidelines, largely aligned with WCAG 2.1 AA.

Implementation by Platform

Platform	Approach	Tools
Frontend (Control-Hub)	Automated checks during component development and CI	@storybook/addon-a11y, eslint-plugin-jsx-a11y, Playwright A11y tests
Showcase	Automated checks via Storybook A11y addon, CI integration	@storybook/addon-a11y, Storybook test runner
Mobile App	Manual testing with screen readers	VoiceOver (iOS), TalkBack (Android)
Backend / Vision	Not applicable	—

Key Practices

• Semantic HTML: Proper heading hierarchy, ARIA labels, alt text for images.
• Keyboard Navigation: All interactive elements must be keyboard-accessible.
• Color Contrast: Minimum ratio 4.5:1 for normal text (WCAG AA).
• Screen Reader Compatibility: Tested with VoiceOver and TalkBack for mobile.

🔒 Security

• Dependency Audit: npm audit and safety check (Python) executed in CI.
• Code Scan: SonarQube detects "Security Hotspots".
• Code Review: Mandatory for any Pull Request before merging into develop or master.

📊 Test Coverage Metrics

Current coverage metrics from SonarQube (as of last CI run):

🛠️ QA Tools by Repository

Repository	Language	Linting & Formatting	Testing	Static Analysis & CI
Control-Hub-Back	TypeScript (AdonisJS)	ESLint, Prettier	Japa (Unit & Int), c8 (Coverage)	SonarQube, GitHub Actions
Control-Hub (Frontend)	TypeScript (Next.js)	ESLint, Prettier	Vitest (Unit), Playwright (E2E), Storybook	SonarQube, GitHub Actions
Mobile App	TypeScript (React Native)	ESLint	Jest (Unit)	SonarQube, GitHub Actions
Firstbreath Showcase	TypeScript (Next.js)	ESLint	Vitest (Unit), Storybook	SonarQube, GitHub Actions
Firstbreath Vision	Python	Black, Flake8	Pytest (Unit)	SonarQube, GitHub Actions

CI Pipeline Enforcement

Every repository enforces quality checks via GitHub Actions.

1. ✅ All CI jobs passing (lint, typecheck, tests, build).
2. ✅ SonarQube Quality Gate passed.

SonarQube Quality Tracking

Our self-hosted SonarQube instance provides continuous tracking of:

• Code coverage evolution over time.
• Technical debt and maintainability ratings.
• Security hotspots and vulnerability detection.
• Duplication rate enforcement (< 3%).

Pull Request Review Process

Every Pull Request follows this process:

1. Developer creates a branch following the naming convention (feature/, bugfix/, etc.).
2. CI pipeline runs automatically on push.
3. SonarQube analysis runs in parallel.
4. At least one team member reviews the code.
5. Reviewer checks: code logic, test coverage, adherence to standards.
6. Once CI passes and review is approved, the PR is merged.

Examples of QA-Driven Corrections

The following types of corrections are regularly driven by our QA process:

• SonarQube findings: Code smells, cognitive complexity reductions, and security hotspot resolutions are tracked and addressed as part of the regular development cycle.
• CI failures: Build or test failures on PRs are fixed before merge, ensuring dev and master / main remain stable.
• Code review feedback: Architectural improvements, naming conventions, and edge case handling are caught during peer review.