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.

OpenLMIS: the global initiative for powerful LMIS software