The QA team Team will concentrate efforts around testing OpenMRS 2.x releases and testing features developed in sprints. Release testing will be announced prior to any OpenMRS 2.x release on https://talk.openmrs.org/c/developers/qa. It will typically begin as soon as a pre-release version i.e. alpha or beta is ready. Testing during development sprints will happen between releases. Please add yourself to see the QA Team's Wiki page or see the QA Team Members list below Trello Board to stay informed on any ongoing QA work!
We use Zephyr for JIRA to track the testing progress. To get familiar with the tool please see this webinar.
You can find our dashboard here.
In short you can find there test cycles, which group individual test cases. Test cycles are created for each release and sprint. In addition we have the Automated test cycle, which groups tests executed by our CI and the Ad Hoc test cycle, which groups tests not assigned to any other test cycle. Test cycles are created by project leaders, who specify the testing environment and the version of the software that will be tested (see the rightmost columns). You can expand test cycles to see individual test cases by clicking on > in the leftmost column.
QA
...
How to become a member of the QA Team
To become a member of the QA Team, or contribute in any other way to the QA process, please add yourself to the list above and post on talk https://talk.openmrs.org/ for ideas on how to help.
How to contribute
Joining the QA Team you can do the following:
...
QA Leaders
...
Processes
Below we describe QA processes.
- The QA work is organized in test cycles, which are executed in test sprints. Test Cycles should follow the following rules:
- All tests should be grouped in Test Cycles. Your module (project) should contain at least the following Test Cycles: Automated Tests, (project+release number) Release Tests and (project+release number) Regression Tests
- Add a Test Case to Test Cycle like described in How to add a Test Case to Test Cycle
- All automated tests should be added to Automated Tests Test Cycle
- Release Tests Test Cycle should contain functional Test Cases that should all have 'Pass' status before next version can be released
- Each version of OpenMRS should have separate Release Tests Test Cycle
- Regression Tests Test Cycle should contain test cases regarding issues that have already been fixed in order to check if they didn't reappear
- Each version of OpenMRS should also have separate Regression Tests Test Cycle
- If you need to add a new Test Cycle, follow instructions in How to create a Test Cycle
- Sprint Tests are test cycles created for specific development sprints. Sprint Tests should follow the following rules:
- Before finishing each sprint a Sprint Tests Test Cycle needs to be created concerning actual sprint
- Name of the Test Cycle should include both the Sprint name/number and "Sprint Tests" char sequence
- A Sprint Tests Test Cycle should contain Test Cases covering all the functionalities developed during the spring
- If you already have a Sprint/Release Tests Test Cycle and wish to create another one concerning a different sprint, Clone already existing Test Cycle instead of creating a new one.
- In the cloned Test Cycle you automatically have all the Test Cases from the original
- Next, you need to verify whether they are all up-to-date concerning software changes, and if not, simply remove the invalid Test Case from the cloned Test Cycle
- Also, some new Test Cases should be added if the sprint you wish to cover contains new functionalities or a major functionality change that requires new Test Cases
- If you clone a Sprint Tests Test Cycle from Release Tests Test Cycle, you need to remove Test Cases concerning upgrading to released version, installing released version
and other release-specific Test Cases
- Release Tests are test cycles created for specific releases. Release Tests should follow the following rules:
- Before each release, a Release Tests Test Cycle needs to be created concerning this concrete release
- Name of the Test Cycle should include both the Release name/number and "Release Tests" char sequence e.g.: "OpenMRS 2.2 Release Tests"
- A Release Tests Test Cycle should contain all the Test Cases from Sprint Tests Test Cases concerning sprints included in release, upgrading to released version, installing released version, and release-specific Test Cases described in Release Road Map/Manual not covered in sprints
- If you already have a Release Test Cycle and wish to create another one concerning a different release, Clone already existing Test Cycle instead of creating a new one.
- In the cloned Test Cycle you automatically have all the Test Cases from the original. Next, you need to verify whether they are all up-to-date concerning software changes, and if not, simply remove the invalid Test Case from the cloned Test Cycle
- Also, some new Test Cases should be added if the release you wish to cover contains new functionalities or a major functionality change that requires new Test Cases
Regression Tests are test cycles created for specific releases, which cover bug fixes. Regression Tests should follow the following rules:
Regression Tests Test Cycle should include Test Cases concerning concrete bug issues that had already been fixed before a release
Name of the Test Cycle should include both the Release name/number and "Regression Tests" char sequence e.g.: "OpenMRS 2.2 Regression Tests"
A Regression Tests Test Cycle concerning a concrete release should include Test Cases concerning issues fixed in that release or in previous releases.
...