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 …

12 Likes

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

3 Likes

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.

6 Likes

@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

5 Likes

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.

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

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

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.

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

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.

Warm regards

cc @jennifer @nikeshbalami @christine

1 Like