Document Change Control

List Of Approvers

Project Overview

1.       Introduction

1.1.        Purpose

The purpose of this test plan is to define the strategy, scope, resources, schedule, and pass/fail criteria for testing the Technology Projects Management (ادارة مشروعات التقنيه) module within the Compliance Management project.

This document aims to:

• Plan and control all testing activities (functional & non-functional).
• Estimate effort, resources, and timelines for the remaining testing scope (API, system, UAT, smoke, regression).
• Identify product and project risks and define mitigation and contingency actions.
• Provide a shared reference for QA, development, product, and business stakeholders.

1.2.        Scope

In scope:

1. Functional testing for all features delivered in Sprints 1–18, including:

• Master data screens and configurations
• Project instance creation and lifecycle
• Integration with existing Compliance Management components
• Any software / hardware / tools needed during test planning , execution or reporting other than default ALM (i.e. clickup)

1. I testing (new module APIs and related integrations)
2. stem testing (end-to-end flows across the module and related modules)
3. Smoke testing for each new build / deployment
4. Regression testing for critical and high-usage flows
5. Basic non-functional testing (usability, basic performance sanity, basic security checks)
6. Support and coordination for UAT with business stakeholders.

Out of scope (for this release):

1. Full performance / load / stress testing under peak usage
2. Formal penetration testing (security assessment)
3. Data migration for legacy systems (if any, unless explicitly planned later)
4. Automation testing (UI/API) – only planned for future releases.

2.       Test Basis

Testing will be based on the following artifacts (where available):

• Business Requirement Documents (BRD) for Compliance Management and ادارة مشروعات التقنيه
• SRS / Functional Specifications for the Technology Projects Management module
• User Stories & Acceptance Criteria for Sprints 1–24 in ClickUp
• UI/UX Mockups and Design Documents for master data and instance screens:

Google Sheetادارة المشروعات التقنية-قاموس البيانات

• Configuration & Workflow Design Documents for project lifecycle and permissions
• Demo recording and feedback from 02-11-2025 demo to PO and Tech Lead
• Demo recording and feedback from 01-04-2026 demo to all stakeholders
• Organization Test Strategy / QA Process documents.

#	Source Title	Source Work Product	Information Extracted
1	Click Up User Stories & Acceptance Criteria	ادارة المشروعات التقنية > Scrum PM _Sprints	Business rules, field behaviors, workflow steps, role/permission expectations, and pass criteria per story.
2	Data Dictionaries / Field Specs (attached in stories)	ادارة المشروعات التقنية-قاموس البياناتGoogle Sheet•Spreadsheet•1.09 MB• Jun 22	Field names (EN/AR), types/lengths, mandatory flags, default values, validation rules (e.g., Max Score, Required Minimum Score, item count logic).
	ERD / Schema Overview (Project Charter)		Key entities (Inspection Type, Plan, Visit, Violation, Penalty, Resource) & relationships to design integration tests and data pre-requisites.
	Activity Diagram (Project Charter)		End-to-end flow boundaries, hand-offs (Create Plan → Perform Visit → Submit/Approve → Penalties), state transitions to test.

3.       Approach

Testing will follow the organization’s standard QA process and ISTQB-aligned practices.

Planned test levels/phases:

1. Smoke Testing

• Objective: Validate that the deployed build is stable enough for further testing.
• Scope: Core login, basic navigation, critical master data & project instance creation.

1. Functional Testing (UI + Business Logic)

• Validate all user stories and flows for master data, project instances, and configurations.
• Include both positive and negative test scenarios.

1. System & Integration Testing

End-to-end workflows:

• From project creation → approvals → updates → closure.
• Integration with other Compliance Management components (users, organizations, KPIs, notifications, etc.).

1. Regression Testing

After fixes and new stories (especially permissions separation), rerun a regression suite focused on:

• Critical flows
• High-risk areas (permissions, workflow transitions, reporting).

1. User Acceptance Testing (UAT) Support

QA to support business users during UAT:

• Prepare UAT scenarios
• Help with data setup
• Track and retest UAT defects.

1. Non-Functional Checks

• Basic performance sanity (page response time, API latency)
• Usability consistency with the existing Compliance Management system
• Basic security checks (role access, data visibility).

3.1 Features to be Tested / Not Tested

Features to be tested:

Master Data Management:

• Project types, categories, owners, stakeholders
• Configuration of project templates and parameters

Project Instance Management:

• Create, edit, and view project instances
• Project lifecycle states (e.g., Draft → In Review → Approved → In Progress → Closed)
• Attachments and documentation (if applicable)

Permissions & Roles (Sprint 13 User Stories)Role-based access control for:

• Inspectors / Project Owners
• Compliance Officers
• Administrators

Access control on:

• Screens
• Actions (create/update/approve/close)
• Data visibility (projects, organizations, etc.)

Workflow & Notifications

• Triggering of status changes
• Notification/alert rules (email/in-app, if available)

Integration Points"

• Integration with core Compliance Management entities (e.g., organizations, users)
• Synchronization of master data between modules (if applicable)
• API endpoints used by UI and external systems (if any).

Features NOT to be tested in this release

• Advanced analytics or BI dashboards that are not yet implemented
• Future integrations with external third-party systems not delivered in Sprints 1–13
• Mobile application (if in a separate epic) unless explicitly included
• Any experimental or backlog features that are not part of current release scope.

3.2 Test Design Techniques

The following design techniques will be used:

• Equivalence Partitioning for input fields (e.g., numeric ranges, text input, optional vs. mandatory)
• Boundary Value Analysis for date ranges, numeric limits, and pagination
• Decision Table Testing for permissions, access matrix, approval rules
• State Transition Testing for project lifecycle states and status changes
• Use Case / Scenario-Based Testing for end-to-end workflows per user story.

3.3 Review Plan

All test cases, checklists, and test data will be peer-reviewed by another QA engineer or QA Lead.Critical flows (permissions, lifecycle, integrations) will be additionally reviewed by:

• Product Owner (for business coverage)
• Technical Lead (for technical completeness).

Review comments must be resolved before test execution starts.

3.4 Suspension and Resumption Criteria

Suspend testing if:

• Test environment is unavailable or unstable for more than 2 consecutive hours.
• More than 20% of executed test cases are blocked due to environment or deployment issues.
• A critical defect prevents execution of core flows (e.g., cannot log in, cannot create project).
• From sprint 19-24, move all the data from Clickup to the new project in Odoo system, and make a Demo and the results are some enhancements
• In sprint 24 & 25 the team still working on the enhancement

Resume testing when:

• Environment stability is restored and confirmed by a successful smoke test.
• Blocking defects are resolved, redeployed, and verified by re-testing.
• Updated build passes smoke testing without new critical/blocking issues.

3.5 Constraints

• Time constraint: Remaining testing (API, system, regression, UAT support) must be completed within Sprint 18 timeframe.
• Environment constraint: Only one shared QA/UAT environment might be available, shared with other modules.
• Resource constraint: Limited dedicated QA resources; some effort may be part-time.
• Documentation gaps: Some requirements may exist only inside user stories, not a full SRS, requiring clarification with PO/BA during testing.

4.       Risks and Contingencies

4.1.        Product risks

• Incorrect permissions configuration may expose or restrict data improperly.
• Incomplete or incorrect workflow transitions (e.g., project cannot move to next state, or can skip mandatory states).
• Data inconsistencies between UI and backend (e.g., incorrect values saved, missing fields).
• Incorrect reporting/output data that affects decision-making.
• Potential performance issues when handling a large number of projects and configurations.

4.2.        Test Project risks

5.       Resource and Training

Roles & Responsibilities:

1. QA Lead / Test Owner:

• Prepare and maintain test plan
• Coordinate with PO, Tech Lead, and Dev team
• Monitor execution & report status.

1. QA Engineers:

• Design test cases and test data
• Execute tests (UI, API, system, regression)
• Log defects and retest fixes.

1. Product Owner (Ahmed Osama):

• Clarify requirements and priorities
• Approve test coverage for UAT
• Provide UAT sign-off.

1. Technical Team Lead (Mahmoud Elbadry) & Dev Team:

• Provide technical clarifications & API documentation
• Fix defects promptly
• Support environment setup.

Training Needs:

• Business process training on Compliance Management and Technology Projects Management on new Odoo system workflows.
• Overview of roles and permission matrix.
• Tool-specific training if needed (e.g., ClickUp for test tracking, Postman for API testing).

6.       Test Pass/Fail Criteria

The release will be considered ready from QA perspective if:

• 100% of planned test cases for this release are executed.
• All Critical and High severity defects are:
• Fixed and successfully retested, or
• Formally accepted and documented with PO approval and mitigation plan.

• Open Medium severity defects: not more than 5 and must not affect critical business flows.
• Open Low severity defects: acceptable if they are cosmetic/minor and documented, with a plan for future fixes.
• No blocking issues exist in:
• Project creation and lifecycle
• Permissions and access control
• Integrations with core Compliance Management entities.

If these criteria are not met, the release should be considered failed from testing perspective, and a go/no-go decision must be taken in a separate release meeting.

7.       Environment

Test Environment Components:

• Application: Compliance Management platform with ادارة مشروعات التقنيه module deployed
• Environment Type: QA / UAT environment
• Database: <DB name / schema> (representative test data set)
• OS / Infrastructure: <e.g., Linux servers, Docker, etc.>
• Client: Web browser (Chrome latest, Edge latest); mobile browser if applicable

• Tools:
• ClickUp (user stories & sprint management)
• <Test management / Defect tracking tool> (if separate)
• Database client (for data verification)
• Screen recording tools for evidence if needed.

Configuration details (URLs, credentials, versions) will be maintained in a separate Environment Configuration document or secure shared location.

8.       Testing Tasks & Schedule

8.1.        Test Estimation

Effort and task details are aligned with the Sprint Plan in the clickup which includes user story sizes, assigned resources, and time estimates for each testing phasefor "ادارة مشروعات التقنيه" in sprints from 1 - 18:

8.2.        Deliverables

8.3.        Schedule

All detailed schedules are maintained in the Click up and will be updated as the project progresses For "ادارة مشروعات التقنيه" : ادارة المشروعات التقنية > Scrum PM _Sprints Dependencies: Test execution is dependent on feature availability, environment setup, and data readiness.

8.4.        Non-Functional Testing

The following non-functional testing activities will be conducted for the ادارة مشروعات التقنيه project:

• Usability Testing: Ensure the system is user-friendly, intuitive, and aligns with business workflows.
• UI Testing: Validate that user interface elements (layouts, fields, navigation, and responsiveness until publish mobile App) .