Skip to content

Quality Plan

IU Alumni Platform (ALUMAP)

Project: ALUMAP — Interactive Alumni Map

Team: Ahmad Helaly, Majed Naser, Roukaya Mohammed, Ghadeer Akleh, Aleksandr Kovalev

Part 1: Introduction

1.1 Purpose

This Quality Plan defines the verification and validation (V&V) approach for the ALUMAP project. It specifies what quality activities will be performed, when, by whom, and with what tools.

1.2 Scope

This plan applies to all components of the ALUMAP system:

ComponentTechnologyCriticality
Backend APIPython 3.11 / FastAPIHigh
Mobile App (Alumni)Flutter / DartHigh
Telegram Mini-AppFlutter WebMedium
Admin PortalNuxt 3 / Vue 3 / TypeScriptMedium
InfrastructureDocker Swarm / AnsibleMedium

1.3 Project Overview

ALUMAP connects Innopolis University alumni through:

  • Mobile application (Flutter) for alumni
  • Telegram Mini-App as lightweight alternative
  • Admin portal (Nuxt 3) for university staff
  • REST API backend (FastAPI) with PostgreSQL database

Key features:

  • User authentication (email/password + OTP)
  • Event creation and participation
  • Interactive map showing alumni locations
  • Profile management with graduation year
  • Admin user verification and event approval

Part 2: Quality Requirements (ISO 25010)

IDQuality AttributeRequirementThresholdMetricTool
QR1Functional SuitabilityAll critical features work correctly100% pass rateTest pass ratepytest
QR2ReliabilitySystem stays operational99.5% uptime (target — not measured)Monthly uptimePrometheus/Grafana set up (dashboards provisioned); no data collected yet
QR3Performance (API)API responds to requestsp95 < 500ms (target — not measured)Response time percentilePrometheus/Grafana set up; no data collected yet
QR4Performance (Map)Map loads on mobile≤ 5 s (E2E TC3 budget)Map load timeE2E (Playwright, TC3) — passing
QR5SecurityUser data protected0 high-severity vulnsVulnerability countbandit (in CI; 0 high-severity)
QR6MaintainabilityCode is testable and modifiable≥70% floor (measured 84.9%)Line coveragepytest-cov
QR7CompatibilityFeature parity across platformsnot formally measuredManual spot checksManual (Telegram limited by RU restrictions)
QR8UsabilityUsers complete key tasksnot formally measuredExploratory testing (no formal usability study)

Part 3: The 11 Decisions Framework

Decision 1: Activities

We split quality activities into two distinct kinds:

  • Product quality (direct) — activities that verify or improve the product itself: tests, static analysis, security scanning, monitoring. These map to Quality Control (QC).
  • Process quality (indirect) — activities that improve how the team works so defects are prevented before they reach the product: code review, quality gates, regression discipline, defect triage. These map to Quality Assurance (QA).

1a. Product-quality activities (QC — direct)

ActivityApplicationStatusJustification
Static Analysis (Lint)Backend (ruff)In CIFast, catches syntax/style errors early
Static Analysis (Lint)Admin (pnpm lint)In CIEnforces Vue/TypeScript best practices
Infrastructure LintingYAML, Ansible, ShellIn CIPrevents deployment failures
Security ScanningBackend (bandit)In CIDetects high-severity vulnerabilities (QR5)
Unit TestingBackend (pytest)In CIFast regression feedback
Unit TestingAdmin (vitest)In CIPinia store logic, pagination, edge cases, error handling
Unit TestingMobile (flutter test)Active (not yet in CI)Native Dart testing
E2E TestingAdmin + Mobile Web (Playwright)Active (run manually)Validates complete user journeys
Exploratory TestingMobile + AdminActiveFinds UX and platform bugs
Production MonitoringRuntime metricsSet up (no data collected yet)Extends V&V into production
Backup ValidationPostgreSQLActiveEnsures data recoverability

1b. Process-quality activities (QA — via team process)

ActivityApplicationStatusJustification
Code ReviewAll pull requestsActiveCatches design issues; 10:1 ROI
Quality GatesPre-merge (CI)ActiveBlocks merge on failing checks (see Part 4)
Defect TriageAll reported bugsActiveSeverity-based handling (see Decision 10)
Regression TestingAll platformsManual (not gated)Critical for sprint releases
Regression After Bug FixSpecific feature + related areasManual (not gated)Each P1/P2 fix triggers regression

Decision 1.5: Regression Testing Strategy

What is Regression Testing: Ensuring that new code changes do NOT break existing functionality.

Scope of Regression:

PriorityFeatures to TestWhenResponsible
P0 (Critical)Login, Event creation, Map displayEvery release + after each P1 fixKovalev
P1 (High)Profile edit, Event participation, Admin approvalEvery sprintKovalev
P2 (Medium)Filters, Search, NotificationsBefore major releasesKovalev

Regression Test Suite Composition:

Test TypeCountCoverageAutomation Status
Smoke tests5-7Critical pathsActive (subset of the 19 E2E)
Core regression~19 (built)Main featuresActive (E2E, run manually)
Full regression50-60 (target)All featuresPartial (19 E2E + manual exploratory)
Bug-specificPer bugFixed bug + related areasManual

When to Run Regression:

TriggerTypeTime EstimateWho
New sprint releaseFull regression (P0+P1)4 hoursKovalev
P1 bug fixSmoke + bug-specific1 hourKovalev
P2 bug fixBug-specific only30 minDeveloper
Infrastructure changeSmoke only30 minHelaly
HotfixSmoke + affected area2 hoursKovalev + Helaly

Regression Testing Process:

StepActionIf PASSIf FAIL
1Bug Fix / Feature Complete→ Step 2Return to development
2Run unit tests→ Step 3Return to development
3Run smoke tests (5-7 scenarios)→ Step 4Return to development
4Run core regression (~19 E2E scenarios)→ Step 5Return to development
5Deploy to test server → Manual exploratory→ Step 6Return to development
6ProductionDoneReturn to development

Regression checklist

Decision 2: Interactions

Workflow Integration:

1. Development Phase

Write code → Local linting → Commit

2. Pull Request Phase (Gate 1)

Steps

  1. Open Pull Request (PR)
  2. Run CI:
    • Lint (ruff, pnpm, infra linters)
    • Security scan (bandit)
    • Unit tests + coverage gate (pytest, vitest)
    • Build
  3. Code Review (1+ approver)
  4. Quality Gate

Outcomes

If gate passes

  • Merge to main
  • Build Docker image
  • Deploy to Swarm
  • Activate Prometheus monitoring

If gate fails

  • Return to Development Phase

Interaction Points Table:

PhaseActivityToolResponsible
Pre-commitLocal lintingruff, ESLintDeveloper
Pull RequestCI lint + buildGitHub ActionsAutomated
Pull RequestCode reviewGitHub1+ team member
Pre-mergeQuality gateBranch protectionAutomated
Post-mergeDocker build + deployGitHub ActionsHelaly
RuntimeMonitoringPrometheus/GrafanaHelaly
DailyBackup validationCronHelaly
On Demand (per bugfix/feature)Exploratory testingManualKovalev

Decision 3: Artifacts

ArtifactV&V MethodStatusTool
Backend Python codeStatic analysisActiveruff
Backend Python codeUnit testsActivepytest
Admin Vue/TypeScriptStatic analysisActivepnpm lint
Admin Vue/TypeScriptUnit testsActive (in CI)vitest
Mobile Flutter codeStatic analysisActiveflutter analyze
Mobile Flutter codeUnit testsActiveflutter test
Ansible playbooksInfrastructure lintingActiveansible-lint
Shell scriptsInfrastructure lintingActiveshellcheck
YAML filesInfrastructure lintingActiveyamllint
Database backupsBackup validationActivepostgres-backup-local
API endpointsExploratory testingActiveManual
Full user journeysE2E testingActivePlaywright

Decision 4: Timing

PhaseFrequencyActivitiesEntry CriteriaExit Criteria
DevelopmentContinuousLocal lintingCode writtenNo lint errors
Pull RequestPer commitCI lint + buildPR openedAll checks pass
PR ReviewPer PRCode reviewCI green≥1 approval
Pre-mergePer PRQuality gateReview approvedGate passes
Post-mergePer mergeDeployMerge to mainContainer running
ProductionContinuousMonitoringService runningNo alerts
Daily00:00 UTCBackup + validationCron triggersBackup verified
On DemandSprint boundaryExploratory testingSprint endCheck list passed
Per sprintAfter codeUnit testsCode complete70% coverage
Per releaseBefore deployE2E tests (manual run)Release candidateAll scenarios pass

Decision 5: Responsibility

RoleNameQuality Responsibilities
Product Owner & DevOpsAhmad HelalyCI/CD pipeline, monitoring, backups, ruff lint
Requirements & BackendMajed NaserAPI correctness, unit tests
Documentation & FrontendRoukaya MohammedAdmin portal UI validation
Frontend & ConfigGhadeer AklehComponent testing, configuration validation
Project TesterAleksandr KovalevE2E tests, regression, test documentation

RACI Table:

ActivityGhadeerAleksandrHelalyRoukayaMajed
Write unit testsIRACI
Write E2E testsIR&AIIC
Write regression testsIR&AICI
Run regression suiteIR&ACII
Code reviewRCACI
Run CIRCAII
Triage bugsRRICA
Release decisionCCR&ACC

Table Acronyms

  • I - Informed
  • R - Responsible
  • C - Consultant
  • A - Accountable

Decision 6: Extent

Coverage Targets by Criticality:

ComponentCriticalityCoverage TargetTest Types
Backend AuthHigh (A)70%Unit + Integration + E2E
Backend EventsHigh (A)70%Unit + Integration + E2E
Backend OtherMedium (B)70%Unit + E2E
Mobile Main FlowsHigh (A)70%Unit + E2E
Mobile OtherMedium (B)60%Unit + E2E
Admin PortalLow (C)50%E2E + Unit (vitest, store logic)
InfrastructureMedium (B)100%Static analysis

Decision 7: Cost/Time

Dates below are the actual commit dates from the repositories, so every entry is verifiable in git history.

Completed Effort:

ActivityEffortDate · Evidence (PR)Status
CI/CD pipeline setup8 hours2026-02-23 · PRDone
Infrastructure linting (yamllint / ansible-lint / shellcheck in CI)2 hours2026-02-23 · PRDone
Prometheus + Grafana4 hours2026-02-23 · PRDone
Database backups2 hours2026-03-08 · PRDone
Backend unit tests (pytest, 453 tests, in CI)16 hours2026-06-28 · PRDone
Exploratory testing (3 on-demand sessions: 6h / 2h / 5h)13 hoursad-hoc · —Done
Mobile unit tests (flutter test, 86 tests)8 hours2026-07-01 · PRDone (not yet in CI)
Admin unit tests (vitest, 2 Pinia stores, 31 tests, in CI)4 hours2026-07-26 · PRDone
E2E tests (Playwright + POM, 19 scenarios)16 hours2026-07-13 · PRDone (run separately)
Security scanning (bandit, high-severity gate in CI — 0 high-severity findings)2 hours2026-07-26 · PRDone
Load test R-04 (Locust, read-load vs test server)4 hours2026-07-27 · PRDone — server saturates at ~10–20 concurrent users (feed p95 ~14–33s, ~1 req/s, 0 errors)
Backend coverage gate (--cov-fail-under=70, in CI)1 hour2026-07-27 · PRDone
Smoke test in CI (post-deploy, verifies traffic)2 hours2026-07-26 · PRDone

Planned Effort:

ActivityEstimated EffortTargetResponsible
Wire flutter test into CI2 hoursby 2026-07-28Helaly, Kovalev
Manual regression run (unit + E2E) before release1 hourbefore releaseKovalev

E2E in CI is intentionally deferred (unstable test server would produce flaky false failures); the suite is run manually before release instead.

Decision 8: Tools

CategoryToolCommandStatus
Python lintingruffruff check .Active
Vue/TS lintingpnpmpnpm run lintActive
YAML lintingyamllintyamllint .Active
Ansible lintingansible-lintansible-lint playbooks/*.ymlActive
Shell lintingshellcheckshellcheck scripts/*.shActive
Unit testingpytestpytest --cov-fail-under=70 (CI)Active — coverage gate enforced in CI
Unit testingflutter testflutter test --coverageImplemented (not in CI)
Unit testingvitestpnpm testActive (in CI)
E2E testingPlaywright + Pythoncd e2e && pytestActive (manual / separate run)
MonitoringPrometheusScrape /metricsSet up (no data collected yet)
VisualizationGrafanaDashboardsSet up (no data collected yet)
CI/CDGitHub ActionsWorkflowsActive

Decision 9: Training

SkillNeeded ForCurrent StatusTraining Plan
Python + pytestBackend testsHelaly, Kovalev2-hour session
Flutter testingMobile testsKovalev learningSelf-study + teach team
Playwright + PythonE2E testsKovalev (adapted from Selenide/Java)Done
GitHub ActionsCI/CDHelaly has experience; others basicOn-the-job

Decision 10: Defect Handling

Defect Severity Levels:

SeverityDefinitionResponseRelease Gate
P1 (Critical)Data loss, security breach, blocks featureFix NOW - hotfix branchBlocks release
P2 (High)Major bug, workaround existsFix this sprint≤2 allowed
P3 (Medium)Minor bug, cosmeticAdd to backlogTracked, not blocking
P4 (Low)Enhancement, nice-to-haveBacklog for futureNot tracked

Defect Triage Rules:

  • Who triages? Tester + Developer (within 24h)
  • Escalation? PO at weekly meeting (if disagreement)
  • P1 handling? STOP current task, fix immediately
  • Verification? Tester only (P2-P4), Developer + Tester (P1)
  • Release gate? Any P1 open - NO release

Decision 11: Measurements

DimensionMetricTargetToolVisibility
Agreement-BasedCI pass rate100%GitHub ActionsAll team
Agreement-BasedCode review completion100%GitHubAll team
Risk-BasedP1 bugs open0Bug trackerPO + Tester
Effort-BasedTesting hoursPer sprintManualTeam
CoverageLint violations0ruff, yamllintCI output
CoverageBackend test coverage≥70% floor (CI gate)pytest-covmeasured: 84.9% line / 69.2% branch
CoverageMobile test coverage (logic layer)70% targetflutter test --coveragemeasured: ~20% logic (UI via E2E)
ProductAPI uptime99.5% (target — not measured)Prometheusdashboards set up; no data collected yet
ProductAPI response timep95 < 500ms (target — not measured)Prometheusdashboards set up; no data collected yet
ProductBackup success100%CronHelaly

Part 4: Quality Gates

GateWhenChecksWhoStatus
Pre-submit (Pull Request)Before merge to mainruff, bandit, pytest (70% coverage gate), pnpm lint + build + vitest, yamllint, ansible-lint, shellcheck, ≥1 approvalAutomated + PeerActive
Post-submitAfter mergeDeploy to Swarm + automated smoke test (public endpoints + Swarm replica health)CI/CDActive
RegressionAfter merge / before releaseSmoke (P0) + Core regression (P1)KovalevPartial — deploy smoke automated in CI; functional regression manual
ReleaseBefore production deployAll gates passed, no P1 bugs, backup verified, monitoring healthyHelalyActive

Regression Gate Details

CheckTimeFailure Action
Smoke tests (subset of the 19 E2E)30 minBlock release
Core regression (~19 E2E scenarios)2 hoursBlock release
Bug-specific regression30 min - 2 hoursBlock fix deployment

Gate 1: Pre-submit (Pull Request)

CheckCommandFailure Action
ruff lintruff check .Block merge
bandit security scanbandit -r app --severity-level highBlock merge
pytest (backend unit)pytest --cov-fail-under=70Block merge
pnpm lintpnpm run lintBlock merge
pnpm buildpnpm run buildBlock merge
vitest (admin unit)pnpm testBlock merge
yamllintyamllint .Block merge
ansible-lintansible-lint playbooks/*.ymlBlock merge
shellcheckshellcheck scripts/*.shBlock merge
Code review≥1 approvalBlock merge

Gate 2: Release Criteria

CriteriaConditionVerification
All pre-submit gates passedGreen on mainGitHub Actions
No P1 bugs openBug tracker zeroManual check
≤3 P2 bugs openDocumented with workaroundsBug tracker
Backup verifiedLatest backup restorableCron job
Monitoring healthyNo critical alertsPrometheus

IU Alumni Platform Documentation