Test Plan - v1

1. Objective

The main goal of this test plan is to ensure that the OpenLMIS system:

• Meets all functional and non-functional requirements.

• Is free from critical defects.

• Functions as expected under various conditions.

• Systematically handle issues and defects found during testing and resolves them before production.

2. Scope

The scope of testing includes the following modules of OpenLMIS:

• Requisition Management

• Stock Management

• Order Fulfillment

• Reporting (Including Superset reports)

• CCE Management

• BUQ Management

• User Management and Role-Based Access Control

• Administration Management

• Offline functionalities

   

The types of testing to be performed include:

• Functional Testing → Validate that all functional requirements of OpenLMIS work as intended.

• Regression Testing → Ensure that any recent changes or updates do not negatively affect existing functionality.

• Performance Testing → Assess the system’s performance under varying loads.

• User Acceptance Testing (UAT) → Validate the system’s functionality against the expectations of the end users and business stakeholders.

• Compatibility Testing → Test OpenLMIS across different browsers to ensure a seamless user experience.

• UI/UX Testing → Ensure that the layout, buttons, fonts, colors, and UI components are consistent across all modules.

3. Test Environment

• Test Servers: Dedicated servers for testing purposes.

3.1 Test Data

Test data will include:

• Test user accounts with different access levels.

• Sample requisitions, stocks, orders and products.

• Test scenarios for edge cases.

4. Test Deliverables

• Test Plan (this document).

• Test Cases: Detailed test cases for each module.

• Regression Execution Reports: Daily reports during regression tracking test progress.

• Defect Reports: Detailed reports on defects, their priority, and resolution.

• Test Summary Report: Summary report after all testing is complete, highlighting the outcomes.

5. Critical Path Identification

Critical Paths:

• Requisition Process: Creating and submitting requisitions

• Order Fulfillment: Managing and processing orders

• Stock Management: Tracking stock levels, adjusting physical inventory

• Reporting: Generating and viewing reports

• User Authentication and Role-Based Access Control

• System Notifications and Alerts via E-mail

• Data Sync and Integration: Data is correctly sync in offline mode

6. Issues Management

6.1 Issue Lifecycle

1. Identification: Issues are identified during test execution.

2. Logging: All issues are logged into JIRA with detailed information, including:

   • Steps to reproduce the issue.

   • Expected vs. actual results.

   • Severity (Critical, High, Medium, Low).

   • Module affected.

3. Prioritization: Issues are prioritized based on impact and urgency.

4. Assignment: Issues are assigned to the relevant developer for resolution.

5. Resolution: Developers work to resolve issues.

6. Verification: Once resolved, QA re-tests the issue to verify the fix.

7. Closure: Issues are closed if the issue is fully resolved and meets acceptance criteria/Expected results.

6.2 Issue Severity Levels

• Critical: Blocks critical system functions; must be resolved immediately.

• High: Affects major functionality; should be prioritized for the next release.

• Medium: Minor issues that do not prevent operation but should be resolved.

• Low: Cosmetic or low-impact issues that do not affect system functionality.

6.3 Issue Reporting and Communication

• Daily Meetings: To review defects, assign priorities, and discuss fix plans.

• Defect Tracking in JIRA: Provides visibility into the defect status for the entire team.

• Test Execution Reports: Include defect status, number of open issues, and high-priority defects.