Internship wrap-up

First and foremost, I would like to thank the outreachy organizing team for coming up with such an amazing idea. When I left school, I was looking for ways of getting further involved with open source software, creating a network and building my skills and possibly forge a career. I had been volunteering as a documenter and tester when one of the community members mentioned outreachy.

Outreachy has been a dream come true for me. It is what I hoped for and much more.

My fear

Starting out, my biggest fear was related to my lack of technical Information Technology skills. As a volunteer, I had the liberty to turn down roles that I felt were out of my skill set. But there I was, a paid intern with open source with the need to deliver efficiently and effectively, and terribly afraid of not meeting my goals.

However, the beauty with open source is that there is a community, one that has people with a diverse set of skills. And guess what, they are always ready to respond to queries in the community forums. In addition, outreachy internship mentors are always willing to guide interns where necessary. My mentors at mUzima mobile did a splendid job at making sure I got the help I needed. My fears did not see the light of day!!!!  😊

Amazing things 😊

Working with mUzima mobile as an intern has been really amazing. I have seen myself grow, taking on tasks I would have initially shied away from because they seem too hard or too technical. The main objective of my internship was to improve documentation of the mUzima testing process through creating re-usable tests. In order to fully accomplish this, I had to fully understand the mUzima mobile application and the mUzima core module hence giving me an in-depth understanding of the project. Once I had documented all the tests, then came the testing of the different releases of the mUzima apk and core module against the created tests. While executing my tasks, I got to learn more about the mUzima software, how to troubleshoot, was able to identify bugs and most importantly improved my skills for software documentation and testing.

This internship has also improved my communication skills. As an intern, I participated in scrums three times a week and calls twice a week. Through the scrums, I communicated my progress and also raised any issues encountered during the course of the week while I used the calls to demo the projects I had worked on. This has greatly improved my presentation and communication skills. In addition, I have improved greatly as far as meeting deadlines is concerned. I am better at managing my time and working under pressure.

Though I fully accomplished my main internship objective, I intend to continue volunteering with mUzima as a documenter and tester. Most importantly, will be working towards improving mUzima user documentation on the mUzima wiki and website.

Prospects

The skills I have acquired during my outreachy internship with mUzima are already proving useful in shaping my career. For the next 6 months, I will be working on a mobile health project where one of my roles will be developing a user guide. With the 3 months experience gained with outreachy, I have no doubt that I will do an excellent job with my new assignment!!!

Thank you Outreachy!!! Thank you team mUzima!!!

To OpenSource!!!

Advertisement

The Glass, Half Full 😊

This blog was due last week, which was week 7 and half my journey as an outreachy intern with mUzima mobile. I was unable to post it earlier due to prior engagements, but better late than never. Speaking of timelines, often project goals, expectations and timelines are set but as one progresses, these may be modified due to new developments.

Just finished week 8 of my internship and I must say the glass is half full 😊. So much growth, new connections, and of course new skills. Have you noticed that my blogs keep getting better! Hahaha.. Well, I didn’t think I would have anything to put down for my very first blog. Look at me now 😊, can’t wait to have a look at the glass, full.

My internship objectives and timelines at mUzima

The main objective of my internship is to improve mUzima testing and documentation by implementing a plugin on Jira which allows for testing against the different releases of the mUzima for Health Provider app and mUzima Core Module using the same set of tickets.

mUzima for Health Providers

Specifically, my internship objectives are to

  1. Research on the top three JIRA plugins for testing and documentation along with the pros and cons
  2. Start using the JIRA plugin for testing and documentation
  3. Create test tickets along with their description, steps and expectations, as well as an indicator for each step (fail or pass) on mUzima JIRA
  4. Write up documentation for the tickets on mUzima Wiki
  5. Test the tickets against different versions of mUzima for Health Provider app and mUzima Core Module

According to the timeline, a total of about 60 tests should be documented by the end of week 8 and then a kick off of ticket testing in week 9 as per specific objective 5.

mUzima Core Module

The look of the glass half full

It has been quite an interesting journey and I am indeed achieving my internship goals and meeting my expectations as well.

After doing research, a decision was reached to use the Zephyr plugin for improving the mUzima documentation and testing. The plugin was installed and then tests created. By the end of week 8, I had reached a total of 17 tests for the mUzima Core Module and 20 tests for mUzima for Health Provider application. This brings it to a total of 37 tests out of the anticipated total of 60.

Ideally, an average of ten tests should have been documented a week. However, the process of documenting a test requires a lot more time than anticipated. A test involves a series of steps that are taken to use a software as related to a particular functionality or feature. In order to effectively document the test, the following are necessary;

  1. An in-depth understanding of the software which can be achieved by reading the existing documentation and making inquiries in the community.
  2. Identification of the various software functionalities and features. Once these are identified, one has to test them and see if they actually behave as expected. If there are any bugs, these have to be reported and documented on JIRA for fixing. Until the bugs are fixed, one cannot complete documenting the test steps for that particular functionality or feature as there will be missing information.
  3. For each functionality or feature, a test is then created with the different steps to be taken while testing the functionality or feature. This involves adding the result to be expected after execution of each test step and having “Pass” or “Fail” as execution options at step level and for the overall test as well.
Tests for the mUzima for Health Provider application
Tests for the mUzima Core Module
A sample of the test details

As you have seen, effective documentation of tests requires a good amount of time and it was therefore necessary to adjust the timelines in order to ensure quality. All projects set timelines within which project goals should be achieved. However, for various reasons these may need to be adjusted in order to enable the project team to deliver quality work as long as they are committing the expected amount of time to the project.

All the best as you manage your timelines!

Happy Tester and Documenter!

Let’s talk mUzima

What is mUzima?

The “m” in mUzima stands for mobile and “Uzima” is a Kiswahili word that means life.

mUzima is an open source android based mobile application for healthcare workers that seamlessly integrates with OpenMRS. mUzima code has been made available for access from the mUzima github. OpenMRS is an open source medical record system.

Why mUzima?

mUzima was developed and first implemented in Kenya, East Africa out of the need for a solution to allow for continuity in healthcare delivery in a low resource clinical setting. With the move towards e-health, Kenya had over 800 implementations of electronic medical record systems (EMRs) all over the country. However, not all facilities could afford to install an EMR and for these, there was a central server where they would send their data. In addition, healthcare workers made frequent home visits in the communities to provide healthcare. The patients identified in these home visits had to eventually be linked to healthcare services at the hospitals. There was however no solution at the moment to allow for centralization of patient data from the remote facilities and home visits while ensuring that one consolidated electronic health record was maintained for each patient.

mUzima was developed, providing that mobile solution that works offline and integrates with OpenMRS, one of the most widely used EMRs in Kenya.  With mUzima, remote facilities can now easily enter patient information and send it to the central server in real time or enter offline and then send later with access to internet. Additionally, healthcare providers who do community visits in areas with poor connectivity are able to collect patient data offline, send it to facilities and easily link patients to healthcare services.

Centralization of patient information enabled by mUzima adopted from https://www.muzima.org/

How does mUzima interact with OpenMRS?

mUzima-OpenMRS interaction adopted from https://www.muzima.org/

The connection to the OpenMRS server enables authentication of mUzima users and also allows the users to search for patients against the server when connected to internet. mUzima allows for download of form templates, concepts, encounter data, cohorts, healthcare provider information, locations and notifications from the server for use by healthcare workers. Once data is collected, data from patient registration and encounters can be sent to the OpenMRS server for integration into the patient records.

Where has mUzima been implemented?

mUzima has been widely implemented in western Kenya in HIV care, and chronic disease management and has been adopted by the Ministry of Health Kenya as an extension of the national medical record system (KenyaEMR) which is a distribution of OpenMRS. mUzima is also being piloted in Mozambique.

How can you get involved in mUzima?

mUzima is open source and therefore has a community just like any other open source software. One can get involved as a documenter, tester, developer, implementer or as an ambassador😊.

  • Join the mUzima mailing list to start participating
  • Visit this site to get started as a developer
  • Visit this site to get started as an implementer

mUzima has a number of projects which community members can contribute to depending on their area of interest.  These include;

  1. mUzima for Healthcare Providers: This is an android application used by healthcare workers during healthcare delivery. This is the main mUzima application that integrates with OpenMRS.
  2. Device Management and Security (DMS): This application was developed to secure mobile devices on which the mUzima for Healthcare Providers application is installed given the sensitivity of the data that is handled. This application offers functionalities like locking devices to a set circumference, remotely locking and or wiping devices that are lost, and monitoring activities on the devices.
  3. mUzima Fingerprint: This module was developed to allow for unique identification of patients at facilities so as to reduce on cases of patient mis-identification and duplication. The module is installed on the OpenMRS server.
  4. Smart Health Register (SHR): This project is aimed at providing for easy mobility of the patient records. It is a functionality available within the mUzima for Health Providers application. A smart card reader is connected to a device on which mUzima is installed and patient records are loaded onto a smart card. Data on the smart card can also be sent to the OpenMRS server.

My work at mUzima as an outreachy intern

The focus for my internship is testing and documentation of the mUzima for Healthcare Providers application. To see how this application works, download the application from play store and connect to the demo server. Instructions can be found here.

As a tester and documenter, I am involved in;

  • Testing tickets

The mUzima programming team is always working in close collaboration with the implementers to make the software better. Therefore, new features are often added, existing features improved and bugs fixed. This therefore requires a team to test the new releases to ensure that they are functioning as expected. Documentation of the test results is done on the mUzima jira.

  • Review of existing documentation

This involves reviewing documentation on the mUzima wiki, website and jira so as to keep it up to date and of good quality.

For jira documentation I am currently working on using the zephyr plugin to make release testing easier and consistent with subsequent releases. The zephyr for jira plugin brings on board the functionality of being able to re-use tests while testing of the different software releases.

Join team mUzima and save lives! 🙂

It’s okay to ask for help

For the biggest part of my involvement with open source software as a documenter and tester, my work has involved tasks that range from testing new software features for bugs and documenting them on jira ticket tracking system, to documenting software features through creating videos. During my application for the outreachy internship with mUzima mobile, the tasks I was assigned were not so different from what I had been exposed to. Making contributions that led to my acceptance as an outreachy intern was pretty smooth, I was in my comfort zone. However, life is not full of comfort zones and once in a while, we do step out of our comfort zones. This could find us prepared or unprepared but at the end of the day we have to deliver.

My first tasks as a mUzima outreachy intern involved testing tickets on the muzima jira https://tickets.muzima.org , reviewing existing mUzima documentation and coming up with ways of improving it. I tested tickets and documented test results on jira, reviewed documentation on the website https://www.muzima.org/ and wiki https://wiki.muzima.org, updated the wiki where necessary while taking note of areas to improve on the website. This I achieved easily, got an in-depth understanding of the project while also making contributions.

With the next set of tasks came an avenue for learning, I was to do something new, something out of my usual tasks. I was excited but at the same time a bit anxious. The task was to create a project on the mUzima jira and install the zephyr plugin to allow for better management of the test cycles with the different muzima releases. This plugin provides functionalities like ability create test cases that can be cloned and re-used for testing against different software releases and also ability to clone testing steps under each test case.

First, I had to read up on the plug-in and watch tutorials using some resources provided by my mentor. Next, I proceeded to create a project on the mUzima jira. The steps were pretty forward for creating a new project! Guess what! I could not find the button for “Create new project”. I looked up all online resources I possibly could but still no button! Then I thought to myself, could it be that I am working with a different version of jira! It wasn’t the case. I was frustrated! 😦 I was running out of time, the conference call in which I had to present my work was coming up but I was afraid to ask for help on how to find a mere button. After spending a whole day looking for the button, I eventually decided to reach out to my mentor for help. She responded by saying she would grant me administrator privileges to enable me proceed. All that time in my search for the button, it did not occur to me that all I needed were administrator privileges. If I hadn’t reached out to my mentor, I would not have created the project and installed the plugin on time. Additionally, if I had reached out earlier, I would have saved a lot of time. But well, better late than never! 😊 Asking for help when stuck became much easier while executing the next steps in my tasks. I had to ask in order to learn.

We all get stuck sometimes, be it with simple or complex tasks and it is okay to ask for help when we do. As outreachy interns, we can ask for help from our mentors, open source community members, outreachy internship organizers and other people who we think can help.

Ask and learn! 😀

My Outreachy Journey Begins

With a background in Environmental Health Science and great passion for technology, I enrolled for Master’s in Health Informatics with the aim of gaining knowledge and skills in information technology that I could apply in the healthcare field. It was during my Master’s program that I had my first encounter with the term Free and Open Source Software (FOSS).

I was intrigued by the community aspect of FOSS and how it provided an easy and fast approach to problem solving by users of this software. In 2015, my involvement with FOSS began. I joined communities of software like OpenMRS, mUzima, and MOODLE as a volunteer. As a volunteer,  I participated by responding to conversations in the community forums and also did some documentation and testing. It was through my interaction with members of FOSS that I learnt about Outreachy internships.

As an Outreachy intern with mUzima software, I am building my skills in testing and documentation while getting paid for a period of three months. Outreachy internships run twice a year and interns have the privilege of choosing the FOSS they would like to work with.

Visit https://www.outreachy.org/for more information on how to become an outreachy intern

cropped-logo.png                                              download (2)