Test Plan - v2

Comprehensive Test Plan for the OpenLMIS Project

Table of Contents

1. Introduction

2. Scope

3. Objectives

4. System Overview

5. Test Strategy

   • 5.1 Test Types

   • 5.2 Test Levels

6. Test Environment

   • 6.1 Hardware and Software Requirements

   • 6.2 Test Data

   • 6.3 Tools

7. Test Plan

   • 7.1 Functional Testing

   • 7.2 Integration Testing

   • 7.3 Performance Testing

   • 7.4 Security Testing

   • 7.5 Usability Testing

   • 7.6 Compatibility Testing

8. OpenLMIS Services

   • 8.1 Fulfillment

   • 8.2 DHIS2 Integration

   • 8.3 Reports

   • 8.4 Requisition

   • 8.5 Notification

   • 8.6 Auth (Authentication and Authorization)

   • 8.7 HAPI FHIR (Health Level Seven - HL7)

   • 8.8 Reference Data

   • 8.9 Stock Management

9. Critical Paths

10. Test Cases

• 10.1 Functional Test Cases

• 10.2 Non-functional Test Cases

11. Defect Management

12. Entry and Exit Criteria

13. Risks and Mitigation

14. Test Schedule

15. Responsibilities

16. Glossary

1. Introduction

This document outlines the test plan for the OpenLMIS (Open Logistics Management Information System) project, an open-source platform for managing the supply chain of medical products. The test plan ensures that the system operates as intended, meets all functional and non-functional requirements, and is robust, secure, and efficient for all users.

2. Scope

The scope of this test plan covers testing the functional and non-functional aspects of the OpenLMIS system, including testing modules like requisitions, stock management, order fulfillment, and reporting. The system will be tested across multiple environments (web, mobile, API) and with various user roles (administrators, warehouse managers, health facility users).

3. Objectives

• Validate that all functionalities work according to the specified requirements.

• Ensure the system meets performance, scalability, and security standards.

• Detect and fix defects early in the development cycle.

• Verify the system's usability and accessibility.

• Ensure compatibility across different platforms and browsers.

4. System Overview

OpenLMIS is a web-based logistics management platform designed to streamline the supply chain process for essential medical products. Key features include:

• Requisitions: Capturing supply needs from facilities.

• Stock Management: Tracking and managing inventory.

• Order Fulfillment: Processing and distributing orders.

• Reporting: Generating reports for forecasting, stock levels, and historical data.

5. Test Strategy

The testing strategy includes a mix of manual and automated testing to ensure thorough coverage across all functional and non-functional aspects of the system.

5.1 Test Types

• Functional Testing: Ensures that the application behaves according to specifications.

• Integration Testing: Verifies that individual modules work together as expected.

• Performance Testing: Tests the system’s performance under various conditions (e.g., load and stress testing).

• Security Testing: Assesses the system's ability to withstand attacks and safeguard data.

• Usability Testing: Evaluates the user interface and user experience.

• Compatibility Testing: Tests the system across different platforms and browsers.

5.2 Test Levels

• Unit Testing: To be done by developers during the coding phase to ensure individual components are working correctly.

• Integration Testing: To be done after unit testing to ensure that modules communicate with each other properly.

• System Testing: Full system tests to verify the complete functionality of the system.

• Acceptance Testing: Testing the system against business requirements to ensure it meets user expectations.

6. Test Environment

6.1 Hardware and Software Requirements

• Servers: For hosting the OpenLMIS application, database, and services.

• Browsers: Chrome, Firefox, Safari, Microsoft Edge.

• Mobile Devices: Android and iOS devices for testing the mobile version.

• Operating Systems: Windows, Linux, macOS.

6.2 Test Data

Test data will include sample requisitions, stock levels, orders, and reports, ensuring that the data reflects real-world use cases. Sensitive data will be anonymized for security purposes.

6.3 Tools

• Test Management: JIRA, Zephyr for test case management and defect tracking.

• Automation: Selenium for automated functional testing.

• Performance: JMeter for performance testing.

• Security: OWASP ZAP for security vulnerability assessment.

• CI/CD: Jenkins for continuous integration testing.

7. Test Plan

7.1 Functional Testing

• Login and Authentication: Ensure different user roles can log in and access the appropriate functionality.

• Requisition Process: Test requisition creation, submission, approval, and rejection workflows.

• Stock Management: Validate stock tracking, adjustments, and reporting features.

• Order Fulfillment: Test the process of order creation, dispatching, and receipt.

• Reporting: Test the accuracy and completeness of generated reports.

7.2 Integration Testing

• API Integration: Ensure that external systems can interact with OpenLMIS via APIs for requisition, stock, and order data.

• Module Communication: Test the interaction between requisition, stock management, and reporting modules.

7.3 Performance Testing

• Load Testing: Assess how the system performs under typical user load.

• Stress Testing: Push the system beyond its limits to identify breaking points.

• Scalability Testing: Evaluate how the system performs as the number of users and transactions scales.

7.4 Security Testing

• User Authentication: Test for vulnerabilities in the login system, including brute force attacks.

• Data Protection: Ensure that sensitive data such as stock levels and requisitions is protected.

• API Security: Validate that all APIs are secure and prevent unauthorized access.

7.5 Usability Testing

• User Interface: Assess whether the system’s interface is user-friendly and intuitive.

• Accessibility: Ensure that the system is accessible to users with disabilities (e.g., screen reader compatibility).

7.6 Compatibility Testing

• Browser Compatibility: Verify that the system works correctly across multiple browsers.

• Device Compatibility: Ensure that mobile and tablet users have the same level of access as desktop users.

8. OpenLMIS Services

8.1 Fulfillment

The Fulfillment Service is responsible for managing order fulfillment. This includes processing requisitions into orders, managing shipments, and keeping track of delivery statuses. It interacts with stock management and reporting services for tracking orders and updating inventory levels.

• Test Areas:

  • Order creation from requisitions.

  • Tracking shipment statuses (pending, shipped, received).

  • Integration with Stock Management and Requisition services.

8.2 DHIS2 Integration

The DHIS2 Service integrates with the District Health Information System 2 (DHIS2), which is used for health information management. OpenLMIS synchronizes key metrics such as stock levels, order fulfillment data, and requisition reports with DHIS2 for national health data monitoring.

• Test Areas:

  • Data synchronization between OpenLMIS and DHIS2.

  • Correctness and timeliness of the data transferred.

  • Data consistency in case of network or system failures.

8.3 Reports

The Reports Service generates various reports based on requisitions, stock levels, fulfillment status, and other key metrics. These reports are used by facilities, central offices, and health administrators for decision-making.

• Test Areas:

  • Accuracy of requisition, stock, and fulfillment reports.

  • Performance of the reporting engine under high loads.

  • Correct formatting and export (PDF, Excel) of reports.

8.4 Requisition

The Requisition Service is one of the core modules that captures and manages requisitions (requests for stock). It enables facilities to request stock based on consumption data and forecasts. It is also responsible for handling approvals and rejections at different hierarchical levels.

• Test Areas:

  • Requisition creation, submission, and approval workflows.

  • Integration with Fulfillment and Stock Management services.

  • Validation of requisition data (forecast vs. consumption).

8.5 Notification

The Notification Service sends alerts and updates to users based on events such as requisition approval, order shipment, and stock levels. It handles different communication channels, such as email and SMS.

• Test Areas:

  • Triggering notifications based on events.

  • Correctness of notification content.

  • Timeliness of notifications across different communication channels.

8.6 Auth (Authentication and Authorization)

The Auth Service handles user authentication and authorization, ensuring that users can only access the services and data they are permitted to. It supports various user roles such as administrators, health facility managers, and warehouse operators.

• Test Areas:

  • User login, logout, password recovery.

  • Role-based access control (RBAC) to different modules.

  • Session management, token expiration, and security.

8.7 HAPI FHIR (Health Level Seven - HL7)

The HAPI FHIR module is responsible for integrating with the FHIR standard for exchanging healthcare data. It facilitates data exchange with other healthcare systems using the FHIR protocol, ensuring interoperability.

• Test Areas:

  • FHIR-compliant data exchange (patient records, inventory data).

  • Validation of the data formats and structures.

  • Secure API communication using FHIR endpoints.

8.8 Reference Data

The Reference Data Service manages all static data, such as product catalogs, facility details, and geographic hierarchies. This service ensures that accurate and consistent reference data is used across all OpenLMIS modules.

• Test Areas:

  • CRUD (Create, Read, Update, Delete) operations on reference data.

  • Synchronization of reference data across different modules.

  • Handling of large datasets (e.g., large product catalogs).

8.9 Stock Management

The Stock Management Service keeps track of inventory levels at various facilities and warehouses. It updates inventory based on stock adjustments, consumption, and fulfillment of requisitions.

• Test Areas:

  • Stock adjustments (increases, decreases) and transfers.

  • Reconciliation of stock with physical counts.

  • Integration with the Requisition and Fulfillment services for real-time updates.

9. Critical Paths

Critical paths represent the essential workflows in OpenLMIS that must function correctly for the system to meet its core objectives. These workflows are highly prioritized for testing due to their critical impact on the supply chain process.

9.1 Requisition Submission and Approval Process

1. A facility creates a requisition based on stock consumption.

2. The requisition goes through multiple approval levels.

3. Once approved, it is converted into an order in the Fulfillment Service.

• Potential Failures:

  • Incorrect requisition data leading to stock shortages.

  • Delays in approval processes that could disrupt the supply chain.

9.2 Order Fulfillment and Stock Update Process

1. Approved requisitions generate orders.

2. Stock is allocated based on available inventory.

3. Orders are shipped and received by the requesting facility.

4. Stock levels are updated in real-time.

• Potential Failures:

  • Orders are not processed correctly, leading to discrepancies between stock levels and requisitions.

  • Shipment delays or incorrect stock level updates could lead to stock-outs or overstock situations.

9.3 Data Synchronization with DHIS2

1. Stock data, requisitions, and fulfillment statuses are synchronized with DHIS2.

2. Health administrators use this data for national-level reporting.

• Potential Failures:

  • Incorrect data in DHIS2 could affect critical health decisions.

  • Failure to synchronize data in real-time might lead to outdated information at the central level.

9.4 Stock Management and Reconciliation Process

1. Facilities track stock levels after consumption, stock adjustments, and shipments.

2. Physical counts are periodically reconciled with the system records.

• Potential Failures:

  • Discrepancies between system records and physical counts might lead to stock discrepancies.

  • Incorrect stock reconciliation could disrupt future requisitions.

9.5 User Authentication and Role-Based Access

1. Users log in with their credentials.

2. Access to modules is restricted based on the user's role (e.g., facility manager, warehouse operator).

• Potential Failures:

  • Unauthorized access to sensitive data.

  • Inability to access critical modules, impacting operational workflows.

10. Test Cases

10.1 Functional Test Cases

10.2 Non-functional Test Cases

11. Defect Management

All defects will be logged and tracked in JIRA. Severity levels will be assigned to defects, and priority will be set based on the impact on the system. All critical defects must be resolved before the release.

12. Entry and Exit Criteria

• Entry Criteria: Test environment is set up, test data is prepared, and all requirements are documented.

• Exit Criteria: All test cases executed, no critical defects remain unresolved, and test reports are reviewed.

13. Risks and Mitigation

14. Test Schedule

15. Responsibilities

16. Glossary

• API: Application Programming Interface

• CI/CD: Continuous Integration/Continuous Deployment

• DHIS2: District Health Information System 2

• FHIR: Fast Healthcare Interoperability Resources

• JIRA: A tool used for issue and project tracking