Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS »
Discussion: OpenMRS Talk »
Real-Time: IRC Chat

Documentation

Skip to end of metadata
Go to start of metadata

The QA 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 the QA Team Members list below 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 Team Members

    1. Natalia Płonka
    2. Tomasz Mueller(inactive)
    3. Ada Yeung
    4. Rafal Korytkowski
    5. Yulia Khisamutdinova
    6. Pavlo Leschcuk
    7. Barbara Cimpa
    8. Lee Breisacher
    9. Farruh Umarov
    10. Shashank Chourasia
    11. Sivapriya Natarajan
    12. Baurzhan Dosym
    13. Shilkumar Nagalgave
    14. Rammohan Banda
    15. Kaweesi Joseph
    16. Rajesh Houde
    17. Gokhan Mandas
    18. tendo kiiza Martyn

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 contact Rafal Korytkowski (raff on https://talk.openmrs.org/) in case of any further questions.

How to contribute

Joining the QA Team you can do the following:

  1. Fix automated tests <- Your help is needed!
  2. Execute existing test cases
  3. Write new test cases
  4. Automate manual test cases

QA Leaders

Below we will shortly describe QA processes for QA leaders.

  1. The QA work is organized in test cycles, which are executed in test sprints. Test Cycles should follow the following rules:
    1. 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
    2. Add a Test Case to Test Cycle like described in  How to add a Test Case to Test Cycle
    3. All automated tests should be added to Automated Tests Test Cycle
    4. Release Tests Test Cycle should contain functional Test Cases that should all have 'Pass' status before next version can be released
    5. Each version of OpenMRS should have separate Release Tests Test Cycle
    6. Regression Tests Test Cycle should contain test cases regarding issues that have already been fixed in order to check if they didn't reappear
    7. Each version of OpenMRS should also have separate Regression Tests Test Cycle
    8. If you need to add a new Test Cycle, follow instructions in How to create a Test Cycle

  2. Sprint Tests are test cycles created for specific development sprints. Sprint Tests should follow the following rules:
    1. Before finishing each sprint a Sprint Tests Test Cycle needs to be created concerning actual sprint
    2. Name of the Test Cycle should include both the Sprint name/number and "Sprint Tests" char sequence
    3. A Sprint Tests Test Cycle should contain Test Cases covering all the functionalities developed during the spring
    4. 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.
    5. In the cloned Test Cycle you automatically have all the Test Cases from the original
    6. 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
    7. 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   
    8. 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

  3. Release Tests are test cycles created for specific releases. Release Tests should follow the following rules: 
    1. Before each release, a Release Tests Test Cycle needs to be created concerning this concrete release
    2. Name of the Test Cycle should include both the Release name/number and "Release Tests" char sequence e.g.: "OpenMRS 2.2 Release Tests"
    3. 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
    4. 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.
    5. 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
    6. 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

  4. Regression Tests are test cycles created for specific releases, which cover bug fixes. Regression Tests should follow the following rules:

    1. Regression Tests Test Cycle should include Test Cases concerning concrete bug issues that had already been fixed before a release

    2. Name of the Test Cycle should include both the Release name/number and "Regression Tests" char sequence e.g.: "OpenMRS 2.2 Regression Tests"

    3. A Regression Tests Test Cycle concerning a concrete release should include Test Cases concerning issues fixed in that release or in previous releases.