Test Strategy

Introduction

The purpose of this document is to outline the OpenLMIS test strategy. Look at the Testing Guide for more information.

Responsibility

SolDevelo QA Team:

• creating features part of contract tests
• creating java part of contract tests
• create and update acceptance criteria
• perform regression tests (every second sprint, i.e. once a month)
• comprehensive manual tests after every sprint
• create test plans and test regression cycles
• perform manual tests
• daily bug tracking

QA Testing Workflow within a Sprint

QA Contract Test Workflow (needs to be reviewed by team)

Tickets for automatization by contract tests are in Contract test Epic (OLMIS-1012). Contract Tests Tickets should be connected with test cases from Test Cases part. Tickets for automatization should be prioritized by Mary Jo Kochendorfer (Deactivated). Main QA Automatic Workflow consist of following points:

1. Tickets designed to automate by the contract tests are found on the Contract Test Epic (OLMIS-1012). 
2. QA write feature part of contract test. QA should add a feature in a ticket description. QA also should push feature file to Github. Name of pull request should consist of the name of the ticket+Feature and should be linked in the comment.
3. When feature part is finished QA should assigned ticket to 
   1. should implement java part for contract test.
4. QA verify if the test passes in Jenkins.
5. The ticket should be closed (Done status) if pass all tests in Jenkins.

Contract test tickets are added to Sprints. Epic are grouped by Requisition, Distribution, etc. and by the user (ie. Admin).

Contract test Ticket Workflow

During implementing contract tests are available four statuses:

• To Do – at this stage QA implements feature part of contract tests, when QA finish, he/ she should change status on In Progress and assigned ticket to Paweł Gesek
• In Progress – at this stage, Paweł Gesek implements java part of contract tests. When he finishes he should change status from In Progress to In review.
• In review – QA verify by Jenkins if tests pass. When tests end with successful status should be changed for Done.
• Done – contract test ticket is closed.  

Contract test status

We can see a comprehensive report of our contract test on our Jenkins, HERE.

There are two elements on the page, chart, and table.

According to the chart, we can know all the status of the test.

According to the table, we can know all the details of the test.

• The first column is our Feature, we can see how many tests we are running on our project. We can go to see the test details by clicking it. We can see all the details by click Scenario and Steps of this test when we are in the Feature Report.
• The second column is a status of each feature. 
• The third column is a status of each Scenario in the feature.
• The last column is about the status and time used for testing of each feature.

Regression Test cases for review and potential duplicate steps that are already in another test case:

OLMIS-3006 - Getting issue details... STATUS

OLMIS-3009 - Getting issue details... STATUS

OLMIS-3005 - Getting issue details... STATUS

Product Testing

Sam Im (Deactivated) is responsible for scheduling testing and assigning the test cases and testers to the Test Sessions so the execution can be tracked and bugs are logged as part of this session. 

NOTES:

Items the above document should cover:

• Philosophy: (examples may include: we want to catch bugs as quickly as possible after code is committed to make it less time-consuming to fix; we want to automate as much of the testing as is feasible so that later when other developers extend or customize OpenLMIS they will have a safety net to know if they broke something)
• UI testing: including lists of which devices/browsers are supported, and which we prioritize for manual testing
• Translation: list of which languages are officially supported and which will be tested
• Summarize who is responsible for which types of testing. Include links to current documentation. Some examples (these may be inaccurate, but just examples):
  • SolDevelo QA team: perform manual testing across browser/device/version combinations
  • Developers: write unit tests for all Java code; write protractor tests for all AngularJS UI
  • SolDevelo QA team: write cucumber acceptance tests for all high-level requirements and configuration differences across countries (such as push versus pull, different combinations of approval hierarchies and programs)
  • ___: performance testing
  • ___: security testing
  • ___: code style guide conformance
  • ___: interface style guide conformance (colors, fonts, sizes, UI consistency, accessibility)
  • ___: internationalization/translation testing
• The remainder of our bug reporting guidelines (what details need to be in a bug)
• Summary of bug workflow (where bugs go in JIRA, who will triage or assign, who will follow-up to verify the bug is fixed)