How to turn around a project that has become a black box to the stakeholders? With the help of a QA audit, of course. Recently, we had a project where our goal was just that – bring one of the openIMIS implementations back on track. Let’s look back on our approach and how it went.

The Client

The International Labour Organization (ILO) is a specialized agency of the United Nations dedicated to promoting social justice and internationally recognized labor rights. It sets international labor standards, develops policies, and provides technical assistance to improve working conditions and employment opportunities globally.

openIMIS

openIMIS is an open-source software platform designed to manage health financing and social protection schemes, such as health insurance, social health protection, and cash transfer programs. It integrates beneficiary management, contribution collection, claim processing, and reporting into one system, ensuring efficient and transparent operations. 

openIMIS was first implemented in Nepal in 2016, and has been in a state of an ongoing development since then, expanding to new districts, and actively contributing to the improvement of health insurance coverage and access across the country. By continuously adapting to local needs and challenges, openIMIS has played a pivotal role in enhancing the efficiency of Nepal’s health insurance system, ensuring more equitable healthcare services, particularly for vulnerable and underserved populations.

The Goal

The main aim of our involvement was to perform an external audit of the project that is still being developed, so that suitable changes can be made to the development process. We were also engaged in fixing the defects that have been found. Additionally, our goal was to provide documentation, which would be vital for the stakeholders during any future decision making.

The Approach

Since producing the documentation was one of our goals, it meant that there wasn’t that much documentation to begin with. Still, gathering as much information upfront as possible was beneficial to us – more time spent on ingesting the available data means less time spent on figuring it out by ourselves.

Having read what we could, we were ready to take a look at how the application performs in practice during exploration testing. Or how it doesn’t perform, for that matter. The purpose of exploration testing is twofold. First of all, it lets us get a general idea of how the application works, what are its main components, and what is the current state of the app. Secondly, it serves as a starting point for any other testing activities, determining the next steps in that regard.

Once the exploration phase was complete, we moved on to mapping. In short, we mapped all the features present in the application. This was a key activity serving as a backbone for all of our reporting and documentation efforts. Based on the mapped features, we could describe the state of each of them, providing the much needed insight for the stakeholders.

While describing the state of the features, we focused on key points, such as:

• Business value,
• Technical state,
• Performance,
• Issue reporting.

We’ve also identified a need to create an extensive UML diagram, so that grasping the concept of the application flows would be significantly easier for anyone who needs to get to know the application, minimizing time to get up to speed and creating a single point of truth.

The Results

The resulting package was meant to highlight the issues found by the team, provide the development team with insight on how to improve the application, and provide documentation based on the current state of the application and its ready to market state. 

We’re happy to say that all of these goals were achieved by the things we put out. Since the project is still under development, there’s room for more auditing to be done. As a matter of fact, we’re currently in the middle of the 2nd phase of the audit, where we go more in-depth in terms of both the types of tests, as well as the features themselves.

It’s hard to imagine any team being better suited to this task than Quality Assurance, and so we were more than excited to take up this challenge. It gave us a great opportunity to use our skills and experience to provide the client with all the help and assistance they needed, and bring out great results that will, hopefully, be reflected in the future development of the openIMIS Nepal project.