My OpenMRS Fellowship Journey: Daud

                  Write Code! Save Lives!

I am Daud Kakumirizi from Uganda. After volunteering on OpenMRS projects for three years, I decided to contribute to this amazing community as a fellow.This being my first work as a fellow, I am both curious and excited with the program. I will be working on Quality Assurance as a QA Engineer and by the end of the fellowship, I desire to get more technical skills and expertise in QA tools that ensure quality in software development.

Getting into the QA technical work, I set up the dev environment already and took time to learn the workflow of the code. Joining the weekly squad meeting calls got me understand the work within the squad and also getting familiar with the squad members. The welcome that @grace made during my first meeting made me feel that I was already part of the squad.

My first call with my mentor @k.joseph was awesome! I discussed with him my fellowship plan and he gave me more ideas on how I can achieve more goals in addition to the one I had set for the program. As well, we discussed my progress and he assured me of his presence to contact him whenever I get any issue.

   ShowCase Experience:

“Who is willing to work on the QA showcase that will be presented in the Spring OpenMRS Community Meeting ?” was a question raised by @christine during one of the squad meeting and without delay I took up this task straight away. Though working on the blog made me sleep almost at 3 am But it was worth the time. Working on this demo gave me a great opportunity to get knowing Cucumber which is a software automation tool that supports Behavior-Driven Development. Learning how tests are automated with selenium and cypress was a thrilling experience compared to the manual testing

Throughout my fellowship journey, I will be updating this blog in respect to the work that I will be working on during the program.


Awesome!! Great to have you in the team Daud.

       First Fellowship Month(April):
  • Integrating with the QA squad members
  • Attending QA and PM calls
  • Having calls with my mentor @k.joseph
  • Learning QA Tools and frameworks like cucumber which is a behavior-driven development (BDD) tool that can be used in test automation
  • Understanding the QA Workflow.
  • Working on tickets, helping new contributors , and making reviews on PRs for QA related tasks.

    Looking forward for May to be more productive and fruitful
                        FIRST PHASE: MAY

Resurrecting Breaking Tests within Reference Application Module

This has been a wonderful experience fixing a couple of breaking tests in openmrs- distro- referenceapplication module. Working on these tests has advanced my technical skills in debugging tests and being able to understand the hookup between openmrs-contrib-uitestframework and openmrs-distro- referenceapplication module. A demo showing a resurrected test can be located here

Reading a number of resources about Quality Assurance: Thoughts on Testing, Breaking and Fixing and Junit Library made me grow faster my technical know-how about the test classes present on the module.

Working on a blocker made me comprehend things that happen behind the seen concerning Cl build plans which I didn’t know before. Though more hours was spent on resolution, But it was worth the time helping me understand how the child module’s dependencies access its resources from the parent module through the configurations present in the <pom.xml> file. Researching about HTTP vs HTTPS made me know how OpenMRS modules are resolved at the conical repo present at maven repository. I got to know through @ibacher’s response to my comment

Helping others when blocked

Besides unblocking the victim, the experience has added a value onto my debugging skills in a special way getting the opportunity to learn what could be the exact cause and be able to figure out the resolution. This is gratifying to becoming a resource to the community

Dr. Travis

This tool is amazing in how at a trigger of a commit it instantly deploys the changes unto the server and returns a reliable report to the client. Waiting for the results whenever I push a commit makes me curious to see the report. I get a smile when I see green otherwise looking through the logs aids me figure out where things are breaking until Dr. Travis is happy.

1:1 with my mentor

@k.joseph is not only a mentor but a technical expert and a coach all at once. The fellowship weekly call not only motivates but also keeps me interested in the program. His advises has helped me be more fruitful, and providing support whenever am blocked. This is worth imitating and compels me to do the same.

Collaborating with other contributors

Working with colleagues’ @irenyak1 @jwnasambu @sharif @gracebish and others is a thrilling experience learning from them every single day.

Looking forward to achieving quality software releases from a community where writing a code saves millions of lives around the world :globe_with_meridians:.

                          LAST PHASE: MAY

Test Coverage Increased On Reference Application Module

Continuing with the first phase of May’s work, the focus was on resurrecting breaking legacy tests present on Reference Application Module raising 65% coverage and this gives a good roadmap for @herbert24 our Release Manager for Ref-App 2.12. By increasing the test coverage the next release will have this work inclusive achieving a better software release for our implementers. Regards to the colleagues @sharif, @grace , @irenyak1 and others who are working towards increasing the test coverage.

 Better Knowledge on Modules: openmrs-distro-referenceapplication openmrs-contrib-uitestframework and openmrs-contrib-qaframework.

Have been able to comprehend these modules and their work flow very well. Understanding the ancestor-hood of uitestfremework to qaframework module helped me know the work flow logic during the build plan both logically and remotely advancing my confidence while working on these modules. This ticket with its demo got me learn that a change on a referenced function in the parent module directly affects the respective client module and this is observed on the report after the build plan. Technically, noise will be heard from the child module regarding the change on the parent module.


This framework makes our CI processes effective and efficient in how it continuously deploys and builds modules giving a reliable report on changes that are introduced.

Bamboo Report: Green Vs Red

Often a green report on any build is preferred by the committer, but red reports have been a key element in advancing my technical skills as a QA Engineer. Though debugging a red report to make it green often takes me more hours but it’s worth the time in terms of technical skill advancement.

Community Engagement

Though OpenMRS is an open source organization, but I consider it to be a family worth living. No question have asked on talk that has not been answered. The community is really supportive to anyone open and willing to ask. The danger could be hesitating to ask otherwise am always compelled to give appropriate responses to posts I have idea on as a give back to the community

A mentor worth meeting

@k.joseph is instrumental in my fellowship journey presenting me challenges that have made me grow technically and now being a mentor to new contributors in the squad. He inspires me each day in advancing to higher technical skill sets in software development. Thanks @k.joseph for your mentorship.

A merge motivates a dev

Receiving a mail from github flagged Merged #380 into master is rewarding. Ideally this implies that my technical work will be inclusive in the coming releases. This grows my confidence with what am doing as a fellow and looking forward to doing more valuable technical work to ensure upcoming releases come with quality features for better end user experience.

Write code. Save lives! drives me every day to sit behind the screen to save lives around the world. As I work on the remaining tests in the coming phase, I will also dive into exciting work of writing new tests using BDD approach with exciting tools. Find this Epic in the coming updates …


:clap:Great job

1 Like
                              EPIC 1: JUNE

  Workflow Based Testing Framework For Reference Application

Unlike the old legacy ui test architecture, the new Workflow Based Testing Framework involves writing test cases that mimic the end user experience in a live environment. The framework ensures the tests are well documented through writing feature files that store the user stories written in a human readable language known as Gherkin language following a simple syntax of Given -> When -> Then and then these stories known as scenarios are wrapped into steps definition that performs the test automation magic on a feature.

Feature files hold scenarios which clearly explains what happens at every step of the feature’s interaction by the end user. One of the awesome feature among the many is that the framework supports customized tags in both feature files and definition steps providing technical implementers a free room to write tags that carry meta data on a test.

Working on new tools like cucumber studio is fun and easy for any one with interest in learning test automation. A lot can be said on the beauty of our new Workflow Based Testing Framework that was selected by the community But this video can tell it All.

                     Mentoring new Contributors

Besides being mentored by a great mentor, I have been able to acquire mentoring skills from @k.joseph. Apart from my technical work, I spend some time to mentor new contributors in the squad helping them get started with the technical work around QA. This is enlarging our technical squad working on the modules and as a result the old ignored legacy tests coverage has been raised to 75% and this paves a way for the upcoming Ref App 2.12 release.

               Interesting Live Session on Test Automation

Thanks @grace looking out for sessions like this which introduced me to Cypress tool. The session was very interesting encountering other QA Engineers elsewhere learning their technical skills and this triggered my interest in learning about Cypress in contrast to Selenium in which both tools inherit feature files. Though currently reading about the tool but soon will extend my technical support to OCL and MF modules in respect to automation.

A word of thanks to @k.joseph @christine @jennifer @grace @dkayiwa for your mentor-ship in my fellowship journey and regards to colleagues @sharif @gracebish @achilep @settix @irenyak1 @insookwa @jwnasambu and others working towards achieving quality software realizes to better end user experience.

Am driven by the community slogan Write Code :earth_africa: Save Lives!


I really appreciate your help whenever I reach out to you on BDD testing.


Thanks, @kdaud for your support in QA


Well done @kdaud.

1 Like

Good work @kdaud. Thanks for your help always.

1 Like
                        EPIC 2: JUNE  
BDD Workflow Based Testing Framework For Reference Application

Continuing from the previous epic, the last phase of June has been so fruitful in advancing my technical skill set as a QA Engineer. Working on the new workflow based testing framework has exposed me to new tools thus acquiring new skills in software development.

Echoing on the fellowship plan, I was able to achieve more than what I had set for the month of June and this has come true through following the guidance of the incredible mentor @k.joseph. Reading more about the new tools consumed within the framework has helped me grasp so quickly the logistics within the workflow for E2E Testing that mimics the end user experience in a live environment.

An interesting 3 minutes demo on Automated Clinical Visit Test can be located by just a click on this video

Having attended the session @grace looped us in, I was compelled to invade into cypress tool. After reading more resources about the tool, I moved to the technical part of which my dev environment is already up and running and started the cypress journey with ocl module which is led by @hadijah315 and @ibacher. This is an extension of the technical work which I desired in the journey and more about this exciting tool will be well captured in the next epic in July.

Challenge of the month.

While implementing the E2E Tests in the new workflow, I cannot forget the day when I spent a full night figuring out how to smartly handle user input validation in automated tests. Thanks to my mentor whom I contacted and he still gave me a room to figure it out and was a thrilling experience when I figured it out the following midnight, and I can now confidently say I am a consultant on validations.

2 Great Lessons From the Mentor 

Though the mentor might have not realized this, but have been able to acquire leadership skills from him. Have closely observed how he handles different scenarios in software development as a technical lead ensuring coordinating different contributors and keeping the project progressing thus acquiring the skills as well.

Secondly, I really like how @k.joseph provides a room for growth. He presents challenges that has made me grow my technical skills and expertise. Being open to growth is a key element in software development and I’m always willing to let my preconceived notions be broken at any moment. As well willing to let the data drive my decisions and accepting that I’ve never reached a final version of perfection. He always shows me there is something I can do to make stuff better.

Thanks to the Fellowship Admins @jennifer @grace @christine @dkayiwa @ibacher @janflowers giving me the opportunity to be part of this year’s fellowship experience with a community that deals with saving lives. Every day am driven by the fact that a single line of code saves millions of lives around the world :earth_asia: !

                              EPIC 3: JULY
            Automation!       Automation!         Automation!

Continuing with the new Workflow Based Testing Framework, the third Epic has been incredible with a lot of learning experiences. Having worked on three new workflow tests, have been exposed to new APIs and able to integrate them into the workflow. Working on new tools is exciting and at the same time challenging while integrating its logistics But personally I like to be challenged this has helped me grow faster my technical expertise in software development. Among other new workflow tests have implemented here is a 2-minutes video for Automated Vitals and Triaging workflow

Echoing on the old legacy ui test coverage, I was able to complete all the tests that I was assigned for the old test workflow and now those tests are ready running in master branch on every commit and every merge that is made to openmrs-distro-referenceapplication. Together with other contributors the test coverage now stands at 86% and aiming for a higher coverage than the current as contributors resolve the remaining ignored tests. Thanks to colleagues @gracebish @insookwa @irenyak1 @sharif @achilep @jwnasambu and others making this come true. This is a good roadmap for RefApp releases and to the community at large.

Great Mentor @k.joseph
Through his incredible mentorship in my journey have been able to mentor other onboarding new QA contributors through synching with them to help get acquainted with the automation workflows. Regards to @insookwa @irenyak1 @jwnasambu @gracebish @jayasanka and others providing technical support to the QA squad in an amazing ways that has raised the test coverage. As one researcher quoted " Tell Me Who Your Friends Is, I’ll Tell You Who You Will Become", I will be a great mentor too as @k.joseph and will be of value to OpenMRS community

            2rd Community Virtual Conference Experience

The virtual conference gave me a greater experience and knowing other organizations working along with us, and meeting implementers for our software and seeing how they use our systems. Technically experienced how other geeks else-where do interesting stuffs.

One of the two incredible moments in the conference was during the quiz that @grace took us through with a cool music in the background. I did not believe that I would end at 13th position out of 97 participants after obtaining 100% . Congs to @tanderson :clap: emerging in 1st position followed by @mksd in the 2nd position. However, I noticed my connection failed me to override these geeks simply my confirm action would take long to process my answer to the quiz moderator and thoughtfully these geeks’ connection was faster. Next time will have a clear connection and will override every one in the race. BTW I did see @dkayiwa and @ibacher on the top list and yet they participated, am not sure which exact positions these geeks were tagged at the end of the quiz!

The second exciting moment was during QAShowCase presentation where I was excited with remarkable responses when the demo was being presented. ["Interesting characters Sir Daud and Sharif...", "Great demo", "Great:)", "Fantastic automation", "Interesting demo", among others ]. This motivates working on a real world project with OpenMRS Community whose software impacts peoples lives around the world. Thanks to @sharif whom we worked together to see this show case come true, a special shout out to our mentor @k.joseph who provided incredible guidance and the technical support during the production time

Congs to @mozzy @gcliff for successfully fellowshipping with OpenMRS and working on interesting project of PLIR, I get motived seeing pioneers of this program being successful and hoping to succeed as well.

Waiting to share with the community what the last phase of July will bring. Award of thanks to @k.joseph @christine @grace @jennifer @hadijah315 and every one in the community making my journey interesting and full of learning


Oh this is interesting Daud - what test was this for? How did you do this? I remember last year before the Platform release, we went through a fair bit of manual tests to confirm that calls to the backend API seemed to be working well.

This is awesome! This is just the kind of automation that will make a longer-term difference and will help us maintain the 2.x RefApp with efficiency :slight_smile: Nice that it gives contributor Devs more immediate feedback too.

Can you help me understand; does this mean 86% of all possible functionality that exists in the RefApp? Or is it 86% of the previous Legacy Tests? (Which is good too)

Great attitude, Daud - you are already walking the mentorship path and I know you will continue to make Joseph’s memory proud in how you support and coach others too.

Agreed. In fact, Daud, once we have successfully engrained more automated tests and a culture of testing throughout the OpenMRS technical community, there is another journey ahead of us: Next, we should figure out how these tests can be used by implementers in their own implementations/distributions. All around the world there are people agonizingly doing manual tests of their OpenMRS system - our next big challenge is to make their lives better too. But that’s a conversation for another day :slight_smile:


Each test is a different experience however, I was referring to selenium API which is a critical part of the Selenium Webdriver Test Automation NOT calls to the backend API.

I strongly agree!

And the community’s decision of switching from manual testing to Automated testing was a critical decision whose benefits goes beyond imaginations. Efforts are being done by QA Squad to seeing this is achieved though its a journey which we are currently travelling cc: @sharif. Maintenance work for 2.x Ref App will be lessened and upcoming releases will be amazingly supported with automated tests without the pain that comes with manual testing.

Supporting 3.x Ref App is on my mind to ensure our new Ref App is also automated behind the seen. @jayasanka is already doing amazing work on this and other QA contributors. This will ensure our software has a better end user experience before being released for consumption by our implementers. I adopted what Christine sold to the community during the recent virtual conference, “Automation should come First not Last”.

This is the beauty of automated tests. The tests pick the run on any change whether its a back end change Or front end change and the run will always be made on every commit made on the repo and on every merge. CI is smart enough to give a reliable report though some times misses to catch some bugs especially when our severs are unstable on which it spins from however, Bamboo is a superman in giving a reliable report then.

The % is for the previous legacy ui tests which were written by then and were ignored not to run ci actions due to some reasons that is being addressed by the QA Squad and most of them have been resurrected already and are now running in master. Actually only 8 tests out of 57 are the only tests that are still ignored however, the good news is that the contributors are looking into it to make them resolved. cc @sharif @insookwa @gracebish

For those functionality that were not covered by the previous legacy tests(in old test workflow) for 2.x Ref App, we are writing their tests in new workflow based testing framework that was selected by the community which mimics end user experience in a live environment using cucumber feature file which documents the tests in a very smart way. cc: @christine . We have some new tests already that have been automated by our QA contributors and here is a 2-minutes video that explains it well than I can do in words.

I like this caption.

This is a journey we have as a community! I think @grace we may need to take one step at time, good enough the QA squad is increasing each day and we invite members around the community to join the squad to see this come true.

Any one interested to join this amazing QA work can check around this wiki here to get started and visiting our Jira Dashboard page here. Our weekly calls are conducted every Tuesday 7:00 pm EAT where one can get to know the ongoing work in the squad. Also the squad members are very supportive to any one who may need 1:1 onboarding session with the work to get started. AFAICT QA work is very interesting and a good venture for any one!

Would be amazing supporting x critical workflows for our implementations/distributions with automated tests around the world. I think @christine this is a good idea to have in our pipeline. I saw @ssmusoke’s interests in this as well here

I agree for now

cc: @sharif @christine @dkayiwa @ibacher @burke @jennifer

1 Like
                            EPIC 4: JULY
                    Leaving a Legacy that Counts !

I’m unfortunate that my mentor passed-on during my fellowship journey! However, I must say Joseph with selflessness earnestly did his role in my journey. A lot of skills I learnt during the three and half months from his mentorship and I knew there was much more I would grasp if I had a chance to finish my journey with him.

Nevertheless he left me a legacy worth living! His legacy will always remind me in how to truly be a “contributor” in my own life. My last fellowship call with him passionately encouraged me not only to be a great community dev but as well be a thoughtful, patient, and insightful community member!

A word of thanks to @paul @jennifer @grace @janflowers and ALL who provided endless support and comfort to help us recover from the grievous moment putting in mind that some members are still recovering ! Regards to @grace and @jennifer who checked me now and again to ensure I am able to go through this hard moment !.

And at the same time I was so motivated with how the community quickly responded with empathy on the matter for the loss of my beloved mentor.

                         Technical Work Resumes --->

       Automation                  Automation            Automation

Continuing with my fellowship journey without a mentor seemed a little darker since my ambition in this program is to become a QA expert and at same time an expert software engineer whose contributions can positively impact people’s lives around the world. Thanks to @dkayiwa and @ibacher who willing fully covered the missing gap of my mentor and this enabled me to pick up once again with the technical work and continue with my journey →

In summary have been able to complete two new workflow tests and both of them are already running in master branch, and will be inclusive in supporting the soon coming 2.x RefApp release that @herbert24 is spear heading. Below are short videos that show these new workflow tests that have been developed following the new workflow based testing that mimics end user experience in a live environment.

E2E Automated Clinical Visit Test Workflow (Length: 2 min: 31 sec)

E2E Automated Vital and Triaging Test Workflow (Length: 3 min: 58 sec)

A word of thanks to our QA contributors @gracebish @insookwa @jwnasambu @sharif @hadijah315 @jayasanka @irenyak1 @mherman22 @achilep and others for the amazing contributions to the squad!

As August arrives I will :

  • continue to increase the new workflow test coverage

  • support automated tests for 3.x RefApp

  • provide technical support to OCL

  • mentor onboarding QA contributors with the new test framework to aid them get acquainted with the test workflow.


Just to confirm: the RefApp release is not required in order to implement and run these tests already, right? Or if so, can you help me understand why?

Very helpful to see this summary of your priorities. In fact please keep up this habit in your future posts as well :slight_smile: I know that things change in software development and we run into things we don’t expect (hence the Agile Manifesto…) but it’s helpful to see what you’re planning and prioritizing for the weeks ahead.

1 Like

Also: It’s wonderful to see these videos of the automated tests running! :tada:

I have 2 simpler questions:

  1. Does the Vitals workflow test include checking that the vitals results show up in the EMR as expected?
  2. This made me realize that some business-level people would probably like to know exactly what is being tested under the “Vitals and Registration Workflow” test. Could we add links to our dashboard that would take them straight to the feature file (since gherkin is so readable, this would answer their questions)? Or, is the feature file not necessarily a 100% accurate representation of what all is actually running in the selenium test?

There is a dependency relationship between RefApp release Vs Implementing and running these tests. Implementing and running these tests ideally mean that the specific functionality they are testing are safe to be used by the end system users before the next version is released for our implementers. For-example in the Vitals and Triaging test workflow one of the user stories validates user input when the entered value of the vital is above the maximum value use case: the system should not save temperature above 43 Celsius and should alert to the data entry clerk until he/she records a value that is within the range (25-43) Celsius.

On the other hand having these tests running in master is a means of maintaining our 2.x RefApp in the long run putting in mind that the future product which we are eyeing at as a community is 3.x RefApp. Since we will have two versions being used concurrently (we won’t get rid of 2.x RefApp based on what I grasped from our recent virtual conference) so these automated tests will help us provide maintenance support for 2.x RefApp version. And perhaps some implementers may opt to remain using 2.x while others will choose 3.x version so we need to cater for ALL!

Not really!

However, based on the test implementation it asserts(confirms) that the entered data is truly saved in the vitals table. And if so then the test passes otherwise it should fail the run.

BTW it would be nice to have the vital results show up and this functionality(button) is provided by the system to end user where he/she just clicks on the button and the vitals are displayed(some where besides the vitals table), however since this is a test running behind the seen the assertion mechanism have mentioned above is good enough for the test since the test will fail the run when the vitals are not saved in the system.

Ideally the major goal of this particular test is not vital results showing up but to confirm ;

  • when normal vitals are entered, the system should be able to save them into the vitals table, and as well

  • validate that if a user enters a vital value which is below or above the acceptable range of that given vital, then the system should not save such data but rather display an alert to the user to comply until the entered value is within the acceptable range of that given vital in context.

Well, both are very good ideas! @sharif may as well have more ideas too though I think we need to think about this as QA team to see how far we can go along with it.

@dkayiwa’s comment here about feature files is a good start for us as we think through the idea on how best we can handle it with reference to business-level people!

1 Like

Vital workflow checks all the functionality that can be captured on vitals page, include capturing observation, diagnosis.So the idea is to comfirm whether the workflow is passing, One major goal is to ensure atleast all functionalities rotating around vitals are captured with in the steps definition, then by the time it reaches on dashboards, dashboards simply show us whether everything runs as expected or not.

This means that if there is a change with in a module forexample coreApps or registrationModule which holds or parents vitals Page, then dashboards might fail since they ar connected with our ci/bamboo

The feature files are very necessary since they are the ones corresponding to the step definitions/tests classes, Then Adding a link to our dashboards probably in ReadMe to show feature files would not bring it out clearly as dashboards does i think.

1 Like