Test Plan

Document Change Control

List Of Approvers

Project Overview

1.       Introduction

1.1.        Purpose

The purpose of this test plan is to define the testing strategy, resources, and schedule for Sprints 1-7 of the استدامة الرياض project. It aims to ensure that the core foundations of the sustainability system—Entities, KPI Streams, and Project/KPI linkages, KPO/Project progress submission—are functionally sound and traceable.

1.2.        Scope

This plan covers the testing activities for the specific features delivered in the Sprints 1-7 build, Activities Covered: Functional Testing, E2E Regression Testing (Manual)/Integration Testing, UI Testing, Localization Testing, and Defect Management, Test Summary Reporting and traceability verification for the following features:

• Entity registration and classification.
• KPI Stream configuration.
• Sustainability Project/Procedure registration including milestones and activities.
• KPI Card modifications and project-to-KPI linking.
• KPO/Project progress submission
• Security & access rights for every role

Target: Maximum coverage of all enhancements across the Employee Screen, Organizational Structure, and Job Classification modules , Mandate &over time modules via below sprints

RCRC > RCRC_Sprints > Sprint 1 (1/11 - 1/24)26RCRC > RCRC_Sprints > Sprint 2 (1/25 - 2/7)61RCRC > RCRC_Sprints > Sprint 3 (2/8 - 2/21)32RCRC > RCRC_Sprints > Sprint 4 (2/22 - 3/7)53RCRC > RCRC_Sprints > Sprint 5 (3/8 - 3/21)27RCRC > RCRC_Sprints > Sprint stab 6 (3/30 - 4/5)8RCRC > RCRC_Sprints > Sprint 7 (4/5 - 4/18)10

2.       Test Basis

3.       Approach

The testing strategy follows a structured, Agile-based methodology integrated into the development lifecycle. Testing is divided into sequential phases to ensure comprehensive quality checks, prioritizing a robust manual execution strategy for foundational stability. This is balanced with a Risk-Based Testing approach, which directs intensive effort toward critical system areas, specifically financial/weight logic and automated notification triggers, to ensure high-stakes functionalities are verified with the highest priority.

3.1.        Features to be tested\not to be tested

• To be tested: All Sprint 1 User Stories (Entities, Streams, Projects, KPI Cards, and Linking).
• Not to be tested: Data migration from legacy systems, mobile app performance, and third-party API integrations (out of scope for Sprints 1-7).

3.2.        Test Design Techniques & Prioritization

A.   Test Design Techniques

• Boundary Value Analysis (BVA): Applied to the Reminder Days (Range 1-7) and the Name fields (300 characters for projects, 70 characters for streams).
• Equivalence Partitioning: Used to categorize valid and invalid inputs for Entity Types (RCRC vs. External) and KPI Types (Direct vs. Indirect).
• Security Testing Strategy for Access Rights
  • A. Positive Validation (Authorized Access)
  • B. Negative Validation (Unauthorized Access/Penetration)
• Error Guessing / Negative Testing: Attempting to save a Milestone or Activity without providing a description to check for mandatory field enforcement.
  • Entering non-numeric characters in Weight (الوزن), CAPEX, or OPEX fields.
  • Attempting to deactivate a Stream (مسار) that is currently linked to an active KPI to verify the system warning and block.
  • Entering a Start Date that is later than the End Date to trigger logical validation errors.

B. Risk-Based Testing & Test Case Prioritization

Test cases are prioritized using a P1–P3 scale based on their impact on sustainability tracking and financial accuracy:

3.3.        Review Plan

3.4.        Suspension and Resumption criteria

• Suspension: If any "Showstopper" (Severity 1) defect blocks more than 40% of testing progress.
• Resumption: Once the blocking defect is fixed and verified in the test environment.

3.5. Constraints

• Compressed Testing Window: Due to aggressive delivery timelines, the time allocated for system and integration testing was severely restricted.
• Reduced Test Documentation: By mutual agreement with stakeholders to avoid timeline slippage, Test Cases were not authored for some User Stories. Testing for lower-priority stories was conducted via exploratory sessions rather than formal scripted testing.
• Dependency Management: The project required a complete mid-cycle re-adjustment of US dependencies, sequences, and priorities. This shift forced the QA team to abandon existing test schedules and realign testing efforts with the new critical path.

4.       Resource and Training

<Details of available resources included within the plan, their function, and any identified training requirement(s) required for the plan.>

5.       Test Pass/Fail Criteria

• Pass: 100% of Critical and High priority Test Cases passed. 0 Critical/High defects open.
• Fail: Any Critical defect remaining open or more than 5% of test cases failed.

6.       Environment

• Software: Separated Test Environment dedicated for testing only match production criteria, Web Application (Chrome/Edge latest), SQL Server, ClickUp for Bug Tracking.
• Hardware: Standard QC Workstations.

7.        Deliverables

8.        Non-Functional Testing