I am Nsereko Joshua, an undergraduate software engineering student at Bugema University (Uganda), currently in my last year of study. I love working with teams and solving problems to better the world.
With great excitement, i am glad to join the 3rd cohort (2022) of OpenMRS fellowship Program as a Quality Assurance fellow aiming at the development and maintenance of the OpenMRS QA tooling, with @dkayiwa as my fellowship mentor.
During the fellowship program, i hope to rapidly bundle up my quality assurance expertise introducing/extending Quality Assurance beyond its current scope, to increase the reliability of our product, users’ confidence and the community’s credibility hence saving more lives.
First month(April)
Reached out my mentor for an analysis of the current state of QA and were more work is needed.
Polished my knowledge about OpenMRS Quality Assurance tooling.
As the saying goes, “ travel broadens the mind ”, i am so optimistic that in this journey, i will pick up Daniel’s brain increasing on the number of resourceful Quality Assurance personnels to grow more entry-level devs through mentorship.
A big thank you to the OpenMRS Fellowship Program administrators lead by @jennifer for granting me this opportunity.
May begun with an informative meeting with @dkayiwa. We outlined which work had been left out yet it’s a priority to the community with regards to OpenMRS Quality Assurance. We concluded that we had to improve/recreate FHIR integrated tests to use an OpenMRS instance with a real database. FHIR is now the intermediate service layer of our OMRS connecting the frontend to the database. OMRS frontend systems are now pulling/pushing data to and fro the OMRS database using FHIR yet some functionality (seamingly working) fails on deployment.
I also had to reach @ibacher since he was informative about this whole thing.
Migrating work to a new module just like I had done it before
Skipping it’s tests locally but running them on pull requesting
Migrating running and stoping docker into a new Job
What was hard
updating the openmrs instance to use the latest of the FHIR2 module, that is to use the build at the current PR. We had to delete the omod file that comes bundled in the qa-openmrs docker image at default and add our own generated after successful build of the project.
I had to migrate this functionality to a new job (b/c docker has issues with windows ) which means that the functionality of building the .omod file was in another job hence another runner, we had to find a way of sharing the build output to the second Job which i did through artifact upload and download.
Future of this work
Extending what is done here to more domains beyond Patient
Creating issues for the interested to crime in
Now that i think the instance is working well, I am going to devote some of my time to look into how to raise tests of 3.X together with performance of the different components of the 3.X with regards to O3: Improving O3 Performance
I wouldn’t have reached this far if it wasn’t the help of @ibache, @dkayiwa@kdaud and @sharif that have repeatedly reviewed and suggested on my PR. Thank you so much
My Third Fourth and Fifth month (July, August and September)
General Observation: The priority of new features, enhancements / improvements to the Quality Assurance tooling vary depending on what other developers beyond QA are focusing on. This means that QA devs have to be flexible enough to dance to other dev’s tune making sure that as devs are moving fast, they aren’t breaking things.
July
I devoted most of my time in this month working on the Integrated Tests for the OpenMRS FHIR2 domains ie. the Patient and Observation specifically.
At the same time, i was following the work of @pasindur2 during his Gsoc’22 coding period working on the OpenMRS 4.x tests.
My goal that month
Reorganise the newly created module to avoid duplication
Join @jayasanka and @pasindur2 as they were working on developing the e2e test for OpenMRS 4.x under the program of Google Summer of Code 2022
Creating Integrated Tests for CRUD operations on the OpenMRS FHIR2 Observation Domain, link
Creating Integrated Tests for Search operations on the OpenMRS FHIR2 Observation Domain
Creating Integrated Tests for Search operations on the OpenMRS FHIR2 Patient Domain
What was hard
Watching out all the implemented tests and test logic in all the OpenMRS QA tools raised a number of concerns whose priority was heard to determine because every test and technology developed by the QA Team is worth keeping alive and healthy.
August
In this month, i devoted 100% of my time to developing 4.X tests so that they can be bundled up quickly so as to reduce the scenario where developers send PR seemingly working but breaking other components while in Production.
My goal that month
Creating Patient Search test for OpenMRS
Creating Patient Clinical test for OpenMRS
Reducing Release of broken docker images for OpenMRS 4.x
The Release of the OpenMRS docker images for the OpenMRS 4.x which we use as the testing instance was broken hence well scripted tests failed instead. Worst of all, no one was sure about what was failing the images. It was thought that the failure was more from the development side (o3 dev side ) rather than the docker release side. The microfrontend devs at the same time weren’t certain about the PR that would be breaking the instance meaning that it would only take a miracle to make the instance work.
September
I focused on finding a way of reducing the docker release failures in a way of running tests before each docker image release. Meaning that each merge at GitHub - openmrs/openmrs-distro-referenceapplication at 3.x has to trigger all OpenMRS tests to run. This was to be extended to all other esm repositories with doing a little tweaks to docker so that user changes are punched into the instance.
My goal that month
Upgrade to @badeball / cypress-cucumber-preprocessor which seamed to be the solution to @before hooks running uncontrollably even when tags where present.
Cypress was waiting for 2 minutes for a component to be available which is a lot of time. I reduced that to 20 seconds which seamed fair enough.
Fix ability of running all openMRS 4.X tests with only one command
Allow Tests to run in Parallel so as to increase Speed.
What was hard
Upgrading to @badeball / cypress-cucumber-preprocessor required reconfiguring everything because the new version is now maintained by @badeball hence almost everything was altered. At the same time, because this is kinder a newer tool, resources in form of blogs and FAQs were scarce making it difficult to make work.
Conclusion
Great regards to my mentor @dkayiwa , with great help from @ibacher, @jayasanka and @pasindur2 for the great work they are doing in QA and in the OpenMRS community as a whole.
I also thanks the OpenMRS Fellowship admin team for this program.
Am sorry for not updating monthly, i think too much about solving the issues in QA that i end-up forgetting about this other side.
I dedicated this month to focusing on the CI pipeline for OpenMRS 4.x by binding all the available o3 tests to the release pipeline which means that every push to every esm repo had to is execute all the available tests.
My prediction of bringing this to life was to use GitHub actions, meaning i had to create an optional GitHub workflow in every esm repository, which is a little tiresome.
The easy-peasy alternative was to use OpenMRS-Bamboo tool which monitors every change to the tracked esm repositories. On every commit to these repositories, it builds, runs and executes all these tests automatically.
My goal this month
Run all o3 E2E tests on every push
This is how the workflow was designed.
build the instance but don’t deploy to doccker-hub. (clone 1. Distribution 3.x and exclude the deploy job)
check if instance is running
timeout --help "Exiting because instance hasn't started in 10 minutes." 10m bash -c 'while [[ "$(curl -s -o /dev/null -w ''%{http_code}'' http://localhost:8080/openmrs/login.htm)" != "200" ]]; do echo "Waiting for server" && sleep 10; done'
Checkout the o3 tests repository, install dependencies, run all tests and generate junit.xml file reports for a pretty display of whats failing.
. $NVM_DIR/nvm.sh
nvm use --lts
npm install
cd packages/cypress
npm run refappCypress
Finally, (compulsory) stop the instance and remove created volumes. (sometimes the backend breaks in case of persistent volumes)
What was hard
Bamboo is actually a kinder new tool to me. Understanding how to make things work right took me lots of hours, banging my head on the wall.
Future on this work
Running smoke tests to inform devs about the “broken instance”; An instance is tagged broken if;
Can’t log in.
Can’t register a new patient.
Can’t register a new patient offline.
Can’t open the patient chart.
Can’t open a form in the workspace. (this test hasn’t been created yet because clicking the “Forms Button” for opening the workplace seams broken, @grace)
Conclusion
Great regards to my mentor @dkayiwa , with great help from @ibacher and the OpenMRS Fellowship admin team for this program.
This fellowship has introduced me to many tools and technologies than i had earlier thought. As a matter of fact, i believe to have a midlevel understanding of the CI pipeline for both OpenMRS 2.x and OpenMRS 4.x.
