Page Comparison

Introduction

The purpose of this document is to outline the OpenLMIS test strategy.  Developers should reference the Testing Guide for the general automated test strategy for OpenLMIS.

The objective of manual and automatic tests are to catch bugs as quickly as possible after code is committed to make it less time-consuming to fix. We plan to automate tests as much as possible to ensure better control of product quality. All tickets should be tested manual by QA Team, selected tests will be automated at API level (by Cucumber) and UI level (ie. by Selenium).

...

• Functional issues: Offline functionality isn't working 
  • All functional bugs should be Blocker or Critical bugs:  OLMIS-3983 - Cannot access offline requisition DONE  OLMIS-4076 - It's possible to submit a requisition twice: duplicate status changes IN PROGRESS
• UI to Server failure: bugs that are caused because the UI passes incorrect values to server, not human readable 
  • Blocker: OLMIS-3509 - No error message when create user fails DONE
  • Minor:  OLMIS-3299 - Insufficient error message when submitting physical inventory with a future date TO DO
• Configuration issues: demo data is wrong 
  • Blocker:  OLMIS-3501 - I can select a program that is not supported by My Facility on the Create/Initiate page. DONE  OLMIS-2980 - Broken translations for Stock Management Adjustments page titles DONE
  • Minor:  OLMIS-2792 - Cannot add Issue for Essential Meds - demo data issue TO DO
• Visual inconsistencies: Visual bugs (text goes outside of a modal), missing error icon 
  • Critical:  OLMIS-3500 - The black background is only the height of the window DONE  
  • Minor:  OLMIS-3987 - Long text not wrapped properly in modals TO DO
• Presentational issues: Workflow bugs (back button doesn't go to where you expect it), tabbing 
  • Blocker:  OLMIS-3508 - Batch approval sticky rows do not respond to scrolling DONE  
  • Minor:  OLMIS-3746 - Source Comments input field not displayed correctly on Firefox TO DO

Step 2: Test Cycles

Test Cycles must be created at the beginning of each sprint. There should be one test cycle for the sprint, as well as a regression test cycle when required for a release. The purpose of creating test cycles is to track the progression of testing during a sprint cycle, and provide traceability for requirements.

...

1. QA starts testing when ticket is moved to QA column in Jira sprint board, or when the ticket status has changed to QA. There is no automatic notification for this until the ticket is assigned, so QA must manually check or the Dev must notify the QA. (Notification to QA must be via QA Slack channel, or directly, and in the General slack channel referencing the ticket that needs to be tested.)
2. QA deploys changes to test environment (uat.openlmis.org).
3. QA creates test case, or executes existing test case that is linked to ticket. QA should test all acceptance criteria in ticket. The test case must be associated with the current sprint test cycle.
4. If bugs are found, QA should change status for In Progress and assigned ticket to proper developer.
   1. When a bug is created it must be linked to the ticket.
   2. QA notifies developer that ticket has been moved back to In Progress (mention in ticket or mention in QA slack channel).
5. When all works properly QA should change status for Done and assigned ticket to proper team leader.

...