OHRI-Specific
OHRI: Setup E2E Automated Tests
We have found the E2E UI-based automated tests have indeed already paid off for us in OpenMRS(Recent QA Automation Success Story!), and the OHRI team is interested too. The OpenMRS BDD-based Frontend Test Framework can be leveraged for this purpose, and some cypress tests already written for O3 may be useful for the OHRI package. We will try 2-3 simple happy-path E2E tests for major OHRI functionalities. We could start by focusing on items that OHRI devs tend to touch in their day-to-day work. Next steps TBC with @eudson & @christine, and I believe @larslemos has been doing some smoke tests for OHRI environments.
O3 + OHRI: Finding out what happens when we combine them
- Goal: A distro of OpenMRS should be able to add an OHRI package without their O3 apps being adversely affected.
- Problem: Manual testing of the OHRI package had been focused on an environment where the OHRI package itself was the only EMR functionality.
- Plan: Thanks to support from @alaboso, @ibacher, and @eudson, the representative “combo” testing environment was set up at ohri.o3.openmrs.org. Recently @christine (OMRS) and Veronica Muthee (UCSF) worked together to manually test the look, feel, and workflows in this combo setting. You can see a triaged inventory of the **issues identified in their manual QA review here. They also cross-checked if the identified issues exist in the separate OHRI demo vs O3 dev environments. Next they are logging known bugs into the relevant Jiras (eg OHRI vs OpenMRS).