Test Plan - v1
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
Identification: Issues are identified during test execution.
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.
Prioritization: Issues are prioritized based on impact and urgency.
Assignment: Issues are assigned to the relevant developer for resolution.
Resolution: Developers work to resolve issues.
Verification: Once resolved, QA re-tests the issue to verify the fix.
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