Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

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

Resources

Page tree
Skip to end of metadata
Go to start of metadata

About

The Quality Assurance Support team is a group of people who have come together with the common vision of improving the quality of OpenMRS products that are used within the community and in the vast implementations across the world. The team is achieving it's mission by improving the QA framework through providing guidelines, the best practices and automation to establish a proactive and systematic QA process within the community aimed at preventing bugs and releasing products to better end-user experience. 

Current Status VERY ACTIVE  

How does this project fit in with the strategy?

The work Quality Assurance support team does, plays a large part to ensure that OpenMRS products can be trusted and reliable so as to encourage sustainability. As result the team does not work in isolation but engages with other squads, teams and implementors in the community to ensure they have quality assurance in place.  All the activities the QA support team undertakes aims at fulfilling the following goals:

  1. Community-led.
  2. Sustainable and robust testing processes and framework.
  3. Foster a culture of quality assurance in developer and implementer practices.
  4. To produce high-quality OpenMRS products.

Background

Our journey began in 2019 and from the diagram below, one can see how the team has advanced over time.


We welcome any community member interested in joining the mission and leading various tasks to improve the QA program for OpenMRS.  The team has set up documentation and videos to best guide in your journey to become a "QA guru" which you can find on the links provided below:


How to Join

Weekly Meeting Information

When: Tuesdays at 10:30pm IST | 8pm Nairobi | 7pm Cape Town | 5pm UTC | 1pm Boston | 10am Seattle

team-calender Add to your Calender

Where: https://om.rs/zoomqa 

Notes: https://om.rs/qanotes 

Notes since July 2021 and older here

Talk:  QA Category

Slack channel #qa-support-team

GitHub:  Github Repository

Website Board/Additional Forum:  QA Board

How to Contribute

   a. Non Technical Contributions

  • Manual testers.
  • Technical Writers.
  • Mentors.

   b. Technical Contributions

  • Code reviewers.
  • Developers.

Useful Resources

10-Min Overview for Our QA Framework


5-Min Overview of Old Test Workflow vs New Test Workflow for OpenMRS 2.x Reference Application


10-Min Overview for Technical Steps When Developing a Test in BDD Framework


7-Min Overview for E2E Automated Tests for OpenMRS 3.x Reference Application


Meet the Members

  • No labels

1 Comment

  1. Thanks so much for improving this page Christine Gichuki . A few suggestions/ideas for your consideration: (And, CC @bstuder99 

    • Intro to overview of our QA Pyramid: Right now all the videos/helpful resources are about Frontend tests, but this team supports reviewing the full pyramid of QA. Perhaps we could add a prettier version of our QA Pyramid diagram (since this one is rather ugly (tongue) ) and explain that this team helps support issues at each of these levels, though in 2021 our strategic focus has been enhancing coverage through frontend workflow automation. 
    • Call attention to QA Dashboard: It feels especially important to call attention to the QA Dashboard here somehow. Where could we emphasize this? Maybe in Important Links? (I know our Repo is basically equivalent, but we could use a direct link to the QA Dashboard as well, like https://github.com/openmrs/openmrs-contrib-qaframework#qa-dashboard-project-status)
    • How to Join / Resources section: This (screenshot below) feels visually scattered. When I skimmed the page the first two times I actually missed seeing the buttons for the Repo & Board. Perhaps we could use something like the Info box to visually call-out/separate Weekly meeting info vs Important Links. I would also be nice to be consistent about how Button links are used; e.g. instead of having some be text links and some be buttons, a single section/group should use a consistent style. Before/After below: 
      • Before: 
      • After: