My OpenMRS Fellowship Journey 2022: Joshua Nsereko

A different light with OpenMRS Quality Assurance :hugs:

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.

Prior to this role, i contributed to OpenMRS security squad under the programme of GSOC 2021 where i patched security vulnerabilities in OpenMRS ReffApp 2.X. I have also raised PRs for FHIR2 and OpenMRS 3.0 of recent.

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.
  • Attended QA calls with @sharif, @kdaud, @christine and the whole QA team

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.

Until the next update …


@jnsereko Congratulations! keep going the sky is your limit.

1 Like

Excited to have you join us in QA @jnsereko ! Looking forward to seeing your contributions to the QA team and watching you grow in your fellowship. :slight_smile:


My First month (May)

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.

The Ultimate goal of this was to model tests for CRUD operations for the FHIR Patient Domain

what is done

What is left

  • 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 workflow

how much time needed

A week

What was hard

  • Starting and stoping docker containers on windows servers with GitHub actions hence GitHub actions failed a lot.

Future of this work

  • Extending what is done here to more domains beyond Patient
  • Creating issues for the interested to crime in

I send a special Thank you to @dkayiwa @kdaud @ibacher @sharif and all other QA team members for the support.

See y’all in a few.


@jnsereko Well done on that work of fhir real integration for patient domain test :+1:

My second month (June)

I have finished like three quarters of the work i had to do with this testing. But it has taken me another month yet it still seams like it might need some little alternation or addition to FM2-460: Create a real integration test for the Patient domain by jnsereko · Pull Request #402 · openmrs/openmrs-module-fhir2 · GitHub.

My goal this month

  • Migrating work to a new module just like I had done it before :white_check_mark:
  • Skipping it’s tests locally but running them on pull requesting :white_check_mark:
  • Migrating running and stoping docker into a new Job :white_check_mark:

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

cc @jennifer @christine


Excellent!! O3 Performance is definitely a major concern.

1 Like

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.


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 :white_check_mark:
  • 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 :white_check_mark:
  • Creating Integrated Tests for CRUD operations on the OpenMRS FHIR2 Observation Domain, link :hourglass:
  • Creating Integrated Tests for Search operations on the OpenMRS FHIR2 Observation Domain :hourglass:
  • Creating Integrated Tests for Search operations on the OpenMRS FHIR2 Patient Domain :hourglass:

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.


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

What was hard

  • 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.


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. :white_check_mark:
  • 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. :white_check_mark:
  • Did some of the pending work in o3 due to there urgency and priority (Marking Patient Deceased)
  • Fix Appointments Test Failure in OpenMRS 4.x :hourglass:
  • Fix Clinical visit Failure in OpenMRS 4.x :no_entry_sign:
  • Fix ability of running all openMRS 4.X tests with only one command :hourglass:
  • Allow Tests to run in Parallel so as to increase Speed. :hourglass:

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.


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.

Warm regards

cc @jennifer @nikeshbalami @christine


My sixth month (October)

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 :white_check_mark:

    This is how the workflow was designed.

    1. build the instance but don’t deploy to doccker-hub. (clone 1. Distribution 3.x and exclude the deploy job)

    2. 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'
    3. 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 use --lts
      npm install
      cd packages/cypress
      npm run refappCypress
    4. 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;

    1. Can’t log in. :white_check_mark:
    2. Can’t register a new patient. :white_check_mark:
    3. Can’t register a new patient offline. :white_check_mark:
    4. Can’t open the patient chart. :white_check_mark:
    5. Can’t open a form in the workspace. :no_entry_sign: (this test hasn’t been created yet because clicking the “Forms Button” for opening the workplace seams broken, @grace)


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.

cc @jennifer @nikeshbalami @christine

1 Like