Table of Contents
...
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
- All functional bugs should be Blocker or Critical bugs:
- UI to Server failure: bugs that are caused because the UI passes incorrect values to server, not human readable
- Blocker:
- Minor:
- Blocker:
- Configuration issues: demo data is wrong
- Blocker:
- Minor:
- Blocker:
- Visual inconsistencies: Visual bugs (text goes outside of a modal), missing error icon
- Critical:
- Minor:
- Critical:
- Presentational issues: Workflow bugs (back button doesn't go to where you expect it), tabbing
- Blocker:
- Minor:
- Blocker:
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.
...
When a bug is created it will automatically get sent to the "Roadmap. Remember to open the bug once " status. It should stay in this status until it has been created and change the status triaged and reproduced - only then its status can be changed to "To Do" so that it appears and when it happens, the bug becomes visible in the product backlog to prioritize.
In summary, each of these steps completes the QA workflow process for a sprint.
...
Final testing of all features should happen on the UAT server (https://uat.openlmis.org/). Some testing may also happen on the test server (https://test.openlmis.org/), in case the UAT server is temporarily unavailable. The UAT server's rebuilding is triggered manually. In order to rebuild it, and thus perform the test on the latest changes, one has to log into Jenkins (http://build.openlmis.org/) and schedule a build of the OpenLMIS-3.x-deploy-to-uat job. One needs to do it when no other jobs are in the build queue, so to to ensure that the server contains the latest changes. After the build is successful, one has to wait for a several minutes and then, it is possible to start testing. Several minutes before scheduling the re-deploy to UAT, one has to inform others on the #qa Slack channel that one intends to do so because others might be using the server and after the re-deploy, all data they entered will be wiped. The test server always contains the latest changes but its use is not normally recommended, as it is very frequently rebuilt (after the rebuilding, all data entered during testing are erased) because it is used for development work. In order to be sure that one contains the most-recent changes, one has to log into the application and look at the upper-right corner, where information on when the software had last been updated is visible. If only the e.g. Software last updated on 17/05/2018 text is visible, the software is up to date. As soon as it becomes outdated, information that there are updates available appear next to the text concerning the date of the last update.
...
Before a big regression test, QA must update the test users and scenarios to support each of the features that are part of the big regression test. It is also important to note that a few test cases entail changing the permissions of demo data users. Before executing such a test case, one needs to inform others on the #qa Slack channel that one is going to change these permissions. Having executed the test case, one has to restore the user's permissions to the default ones manually or by scheduling a re-deploy to UAT. In both cases, one also has to inform users on #qa that one is changing the user's permissions back to normal. In general, one should avoid changing the permissions of demo data users if it can be avoided. Instead, one can create a new user and assign suitable rights to them.
Translation Testing
While OpenLMIS 3.0 supports a robust multi-lingual tool set, English is the only language officially provided with the product itself. The translation tools will allow subsequent implementations to easily provide a translation for Portuguese, French, Spanish, etc. QA testing activities should verify that message keys are being used everywhere in the UI and in error messages so that every string can be translated, with no hard coding. The v3 UI is so similar to v2 that QA staff could also apply the Portuguese translation strings from v2 to confirm that translations apply everywhere in v3.
...