My OpenMRS Fellowship Journey: Piumal Rathnayake

Community
,
1

Hello everyone! I’m Piumal, a Computer Engineering undergraduate passionate about open-source software. I joined OpenMRS back in 2020 and since then, I have been contributing to several projects at OpenMRS. I also participated in Google Summer of Code at OpenMRS in the last two years.

I’m happy to announce that I have been selected as a QA Engineering Fellow for the OpenMRS Fellowship program. I’m really excited to start my fellowship journey and contribute towards the development of OpenMRS while further enhancing my skills with the guidance of my mentor @jayasanka. Our focus is on improving the overall product quality and implementing solutions to maintain the product quality while improving the developer experience.

My main goals for the first two weeks of the fellowship were to get to know about the fellowship, refine my fellowship plan, and also to start working on the tasks I got assigned for. On February 2nd, I had a call with my mentor, where we discussed the current state of the Quality Assurance side of OpenMRS and upcoming plans for it. Additionally, we discussed about refining my fellowship plan and goals. On February 13th, we had a comprehensive orientation session for the fellowship, which addressed all of my questions and concerns related to the program.

Apart from those, I had been working on several tasks during this period. As the first task, I was assigned to resolve the random failures on contrib-qaframework 2.x E2E Tests. For that, I went through all the 2.x e2e tests and identified the tests which contains bugs. I initiated this thread to give my updates and to continue the discussion on 2.x e2e tests. Also, I was able to fix 2 of the failing tests with the following PRs.

Meanwhile, I was planning to propose a project for this year’s Google Summer of Code (GSoC) related to QA. Specifically, the project idea was about implementing an effective unit and integration test strategy for OpenMRS3. More details about the proposal can be found at Ideas for GSOC 2023 - #10 by piumal1999.
We had some discussions on this in the QA squad call as well. However, based on the feedback received, the suggestions were to do this as a fellowship capstone project instead. Also, it was suggested that we can use this as a GSoC project if we can limit the scope of the project to only improve test coverage, with a test strategy implemented by ourselves.

That’s most of it about the first two weeks. And finally, I would like to thank OpenMRS for giving me this amazing opportunity. I’m thrilled to be working with you all and looking forward to contributing to the community’s growth and development.

9 Likes
2

Hi everyone, It has been almost one month since I started my OpenMRS Fellowship journey.

During the last two weeks of the month, I was mainly working on the OpenMRS3 Patient Lists E2E tests. My task was to list out the required set of E2E tests and implement them using Playwright. Initially, I went through the patient lists app to gain an understanding of its basic functionality, and updated the 3.0 E2E Testing Plan: Workflow Cases Document with the suggested list of E2E tests. Meanwhile, I went through the esm-patient-lists micro frontend and the openmrs-cohort-module to identify the API endpoints that needed to be used when writing the tests.

However, the patient lists app had a lot of bugs and errors, and that was a blocker to continuing my work on writing the E2E tests. Therefore, I listed out all those issues and created this thread seeking solutions. Additionally, I created this set of JIRA tickets for fixing those bugs and errors. Until these issues are resolved, I was able to get familiar with Playwright and E2E tests by referring to the Playwright documentation.

Regarding RefApp 2.x E2E tests, I identified another failing E2E test and created a JIRA ticket for resolving that. A new contributor worked on the ticket, so I was able to help him by reviewing the pull request. With that, now all the RefApp 2.x E2E tests are fixed.

The other task I worked on was researching on Unit and Integration tests, for designing a good testing strategy for micro frontends. For that, I went through several documentations, blog posts and articles to get an understanding of testing environments, common testing patterns, best practices etc. I hope to come up with a detailed document on my findings in the upcoming week.

5 Likes
3

It is the second month of my fellowship journey. During the first two weeks of this month, I worked on several types of tests used in OpenMRS QA, and I gained new knowledge on them.

Under 3.x End-to-End tests, I worked on the patient lists E2E test. Previously there were a lot of bugs in the patient-lists microfrontend, and during the first week, most of those bugs were fixed by the microfrontend squad and some new features were also implemented. So I had to update the patient lists test plan on 3.0 E2E Testing Plan: Workflow Cases Document accordingly. Then I opened a pull request for adding the relevant test cases. However, the patient list component has one remaining bug, which needs to be fixed before the pull request can be approved.

I also did some research on Unit & Integration tests and created a document with my findings. While creating the document, I went through all the existing microfrontend modules and learned about their current status on unit and integration tests. Additionally, I read some documentations and blog posts to learn more about these tests to select the best testing strategy for OpenMRS3. I included all those references in the document. According to my findings, one suggestion is to use MSW (Mock Service Worker) to optimize the O3 integration tests and make it easier to write the tests.

Apart from that, I was assigned to look into some failures on OpenMRS Platform tests, and I was able to find the commit that caused the error. Therefore, I informed the developers about the issue, and they resolved it later. With that, all the RefApp 2.x are passing now.

In the upcoming weeks, I will finalize the Unit & Integration test document and check the possibility of adding a GSoC project based on that.

1 Like
4

The past two weeks have been very productive, and I would like to share some of the activities I have been involved in during that period.

On 15th and 16th March, we had the OpenMRS Virtual Mini Community Meeting, where I presented the Squad Showcase Representing the QA Support Team with @jayasanka and @anjisvj. During the session, we addressed three common questions that OpenMRS implementers and developers have, and I presented about the stability of O3 and how we plan to achieve stability through QA. You can find the recording of the session here.

image
image2723×1450 149 KB

Over the past two weeks, all the major bugs related to the esm-patient-lists app were fixed, particularly the issue with the delete patient list option. Thanks to @manojll, who resolved it by fixing the openmrs-cohort-module, I was able to finalize the patient-list e2e test and update my pull request.

However, I encountered another problem that blocked merging the patient-list e2e test. In the GitHub action workflows, we have been using the ubuntu-latest image, and in that runner, port 8084 is used by a service called mono by default. As a result, the esm-patient-lists app fails to run on port 8084, which is the port set automatically for the app. I opened a ticket for this issue, and @chiran is currently working on it.

Apart from those, I had the opportunity to learn how to release OpenMRS modules through the bamboo dashboard. I was able to get access to the OpenMRS bamboo dashboard and release the version 3.4.0 of openmrs-cohort-module. Also, I learnt how to add newer version of openmrs modules to the dev3 environment.

In some good news, we were able to add a GSoC Project idea based on the Unit & Integration test strategy we discussed earlier. To learn more, you can refer to the document included in my last post, my comment on GSoC Ideas List, or the project Wiki. I am willing to be the primary mentor for this project, so if anyone is interested, feel free to reach out through Slack or OpenMRS Talk.

I also began reviewing the existing marking rubric used to rate the GSoC contributor application. We need to get it ready before the end of the contributor application period. I went through it and made some improvements and had an informative discussion with other mentors on 2023-03-26T18:30:00Z.

In the upcoming weeks, I hope to fix the issues mentioned earlier, create the wiki page for integration tests, and start working on a new O3 test plan. Regarding GSoC, I aim to finalize the marking rubric and help interested students by reviewing their proposals.

2 Likes
5

At the start of April, I was working on a few tasks related to Google Summer of Code 2023. With the help of @jayasanka, I was able to finalize the marking rubric for grading and ranking the GSoC student applications. After finalizing, we shared it on the OpenMRS gsoc slack channel, so that applicants could read through it and improve their applications and project proposals accordingly.

We had two QA related project ideas within GSoC 2023 project ideas, which are “Extending E2E Automated Tests for the OpenMRS3” and “Enhancing Component Test Coverage and Quality for OpenMRS3”. We received a significant amount of GSoC student applications for those projects, so @anjisvj and I started evaluating the applications according to the marking rubric.

Meanwhile, I worked on documenting O3 Unit and Integration test strategy and initiated the wiki page for that.

In the second week of April, my Pull request on O3 Patient Lists E2E tests finally got merged. But after merging it, the testOnPush job on e2e workflow failed due to the same issue I mentioned in my last update.

Later, I was able to fix it by changing the base port of the server with this PR.

After completing the esm-patient-lists e2e test, we decided to start implementing e2e tests on other smaller micro-frontend modules. So I chose the OCL Subscription Module which I built during the last GSoC. I created an epic to track its progress, and I’m still identifying and documenting the required test cases while working on the basic playwright test configurations on that repository.

I also started researching on documenting a manual test plan to implement for OpenMRS3. These manual test plans are used for testing the features that cannot be directly tested with e2e tests. Usually, these are executed before a major release or once every specific time period. While doing this, I learned about a JIRA plugin called XRAY that can help manage manual and automated tests as Jira issues, create and execute test plans, and generate reports, among other things. It also has a bamboo integration feature. I hope to look further into this because it can help the OMRS QA Support team to manage most of their work at a single dashboard.

Over the next two weeks, I hope to continue working on the O3 test plan and the OCL Subscription module e2e tests.

3 Likes
6

Well done @piumal1999 .

1 Like
7

Over the past two weeks, my primary objectives were to add E2E test coverage to the OCL subscription module and to conduct research on the O3 manual testing plan.

To track the progress of the OCL module test coverage, I created a Jira epic. The OCL subscription module is located within the esm-admin-tools mono repo. Therefore, as my first task, I set up the Playwright e2e tests on the esm-admin-tools repository. After configuring Playwright with this pull request, I checked the functionalities of the OCL subscription module and identified the necessary e2e test cases and documented them. I also completed the implementation of those test cases within the week, with the following pull request:

As I said last week, we discovered a Jira plugin called X-ray, which is a valuable tool for streamlining the process of test management and automation. It also has a bamboo integration, which we can use for enhancing the CI with automatic test report generation. We thought that kind of tool would be beneficial for the OpenMRS QA process. Therefore, I configured a private Jira instance and installed the Xray plugin to test its features.

Also, I went through the Xray documentation to better understand its functionality and created a discussion thread, including a demo:

However, I later discovered that an alternative to Xray called Zephyr had already been installed in the OpenMRS Jira instance. Therefore, I plan to compare the two tools to determine which one is better suited for OpenMRS quality assurance.

In addition to these tasks, I improved the unit and integration tests wiki page by adding test case naming conventions. Finally, I would like to mention that I am eagerly awaiting the release of the GSoC student list next week.

2 Likes
8

As mentioned in my last post, my first task for the month of May was to compare the Jira plugins Xray and Zephyr. I installed and tested both editions of Zephyr on my test Jira instance, and read relevant documentation to come up with my comparison. You can find more information about it here:

Based on my findings, I suggested using Xray as the test management tool for OpenMRS. I also examined the possibility of using Xray with automated tests, such as e2e, unit, and integration tests in OpenMRS3 modules. I discovered that we can use the JUnit test reports to create test execution reports and update test plans on Xray, and we can automate it using GitHub Actions or Bamboo builds. I have posted my findings here:

Given these useful features, Xray will be very helpful for the OpenMRS community. However, we need to identify when and where to use these features in the OpenMRS development process.

During the past two weeks, I worked on several other tasks in addition to my comparison between the Jira plugins Xray and Zephyr.

While going through the contrib-qa-framework repository, I discovered that the web driver versions used in our e2e tests hadn’t been updated recently. Previously, we had been updating them manually whenever a new driver version was released. Instead of manually updating the drivers, I tried setting up a driver management tool that automatically downloads and uses the latest web driver version when running the tests, which was suggested in the Selenium documentation. I tried the tool locally, and it was successful. However, when running the same tests through GitHub actions, some of the test cases were failing randomly. Therefore I need to investigate and address those issues before submitting a pull request.

I also intended to set up a Mock Service Worker (MSW) on the esm-admin-tools repository within this week. However, I couldn’t complete the task due to a dependency issue in the mentioned repository. The admin tools mono repo had been using an older version of the esm-framework. But upgrading the dependencies causes some other errors when running the dev server. To seek a solution, I posted my issue on the openmrs3-helpme Slack channel.

Besides those tasks, @anjisvj and I had our first meetings with our GSoC students. We were delighted to welcome the two highly skilled individuals who were chosen for the two QA-related projects in OpenMRS for GSoC 2023. I’m looking forward to working alongside these talented individuals on their GSoC projects and am excited to see the progress we can make together. We also had a nice onboarding session with all the mentees and mentors on May 5th.

image
image1380×826 94.1 KB

My main tasks for the next two weeks will be fixing the issues mentioned earlier, having discussions regarding selecting a fellowship capstone project, and assisting the GSoC students.

1 Like
9

Hi all, I’m back with my fellowship journey updates for the latter half of May.

One of my main tasks for these two weeks was to configure the mock service worker (MSW) on the esm-admin-tools repository to enhance the component tests. Previously, there were some dependency and configuration issues in the esm-admin-tools repository that were hindering my progress in setting up MSW. Fortunately, @ibacher resolved those issues at the beginning of the week, allowing me to proceed with configuring MockServiceWorker (MSW) on the repo.

With MockServiceWorker, we can intercept API calls specified in the handlers and replace them with predefined responses when running the tests. Using it have some advantages such as easier usage, reducing duplication of mock setup across tests, and having simpler and cleaner code.

By following the MSW documentation, I configured it on the esm-admin-tools repository with a sample handler with this pull request . However, I encountered an issue where this network call interception didn’t work with the esm-admin-tools repository. To address this matter, I initiated a discussion on OpenMRS Talk.

In addition, I worked on a task related to the RefApp 2.x tests. I discovered that we had written two sets of E2E tests for the 2.x OCL subscription module in the contrib-qa-framework repository. One test was developed using Selenium, while the other was created using Cypress. The Cypress test was the only remaining Cypress test in the QA framework. After reviewing both feature files, I noticed that the Selenium test have more detailed steps. As a result, I created a ticket and submitted a pull request to remove the duplicate e2e test, which was written in cypress. This also allows us to remove Cypress from the contrib-qa-framework repository, enabling us to use the repository solely for Selenium 2.x tests.

During this week, I also focused on my fellowship capstone project. I had discussions with @jayasanka to choose a project idea. Together, we identified some problems in the existing QA process of OpenMRS and decided to develop a project idea involving automated testing in CI/CD pipelines, reporting, and manual test management. Currently, I’m working on my project proposal and hope to get it approved soon so that I can start working on it in June.

Apart from these tasks, I had my regular meetings with GSoC mentees and also reviewed some pull requests.

10

My main goal for the first two weeks of June was to find a project idea for my fellowship capstone project. Initially, I thought of doing a backend-related QA project. However, upon discovering that the backend was stable and didn’t require immediate QA improvements, I had to search for another idea.

After discussing with @jayasanka, I decided that my fellowship capstone project would involve the CI/CD pipeline, streamlining manual tests, and generating reports using the Jira Xray test management tool. I drafted a proposal and initiated a thread to discuss it further.

During the week, we had a discussion on this with @burke during the Technical Action Committee call. Unfortunately, we discovered that the Xray plugin couldn’t be installed because our Jira installation was not compatible.

Since the Jira migration won’t happen soon, we had to remove the tasks related to manual test streamlining and reporting from the project proposal. As a result, I had to revise my fellowship capstone project plan once again.

The only remaining idea we had was to improve end-to-end, unit, and integration tests to enhance test coverage and quality. However, this is a bit challenging since we have two ongoing GSOC projects based on those tests, and I have to select modules that won’t interfere with their project plans. Hopefully, we will be able to separate some modules and work on them for my fellowship capstone project.

Apart from that, these are a few updates regarding the other work I have been doing over these two weeks:

During the first week, I had the bi-monthly fellowship check-in call with both my mentor and the fellowship program administrators. The purpose of this call was to discuss my accomplishments, challenges, and upcoming milestones related to the fellowship.

You may recall that last month I started a thread to discuss the issues I faced while trying to configure the mock service worker on the esm-admin-tools repository. However, based on Ian’s insights, we decided not to use MSW as it might cause problems in the long run.

I have also been working on implementing an automatic web driver management feature for the Selenium tests in the contrib-qa-framework. Initially, I tried to achieve this using a third-party plugin, but later I discovered that the newer versions of Selenium have this feature built-in. So, I opened a pull request to add the automated web driver management feature, which provides benefits such as eliminating the need to store drivers in the repository, removing the manual update requirement for drivers, and streamlining test execution for developers who no longer have to search for drivers compatible with their operating system and browser.

The pull request was merged, but it caused some test failures due to a mismatch in the node versions we were using. Therefore, I quickly opened a follow-up PR to fix it, and now the QA framework passes all the tests successfully.

11

I began the third week of June by making some improvements to the testing guide of the new O3-docs. Specifically, I enhanced the e2e testing section by adding more details and instructions on writing new tests, do’s and don’ts, best practices, test naming conventions etc. You can find the updated doc from here.

Over the past few weeks, we’ve been facing a bug that causes the e2e test process on the esm-patient-chart repository to consistently fail. Despite the tests passing locally, the GitHub action builds were failing after running for around 30 minutes or more. When investigating this issue and reviewing failed workflow logs, I noticed that the tests were failing at random steps without clear error messages. However, I did find some annotations in the overview of each failed workflow indicating a connection loss with the GitHub action runner and occasional crashes.

Based on this information, I concluded that the GitHub Actions Runner might be crashing due to resource limitations. The default runner has a 2-core CPU and 7 GB of RAM, which proved insufficient to run all 17 esm apps in the esm-patient-chart simultaneously.

To address this problem, @ibacher suggested several solutions in the related Slack thread. I’m currently trying one of the suggestions. Since this issue is critical, I decided to include it as part of my fellowship capstone project.

Speaking of the capstone project, after some discussions, I updated my project plan based on the following main objectives:

  1. Fixing the resource limitation issue with running e2e tests on the esm-patient-chart, as mentioned earlier.
  2. Enhancing e2e test coverage of the esm-patient-chart, patient-registration, esm-form-builder, and other o3 repositories.
  3. Implementing manual test plans for the main functionalities.

We had a few other ideas, such as unit and integration test coverage and automated performance testing. However, I removed those from the proposal because I realized they would increase the scope and exceed the available time. You can find more details about the project here.

In addition to the above tasks, I made a minor improvement to the esm-form-builder app by utilizing the form search functionality in e2e tests.

From this week onwards, I will be working on the capstone project, beginning with resolving the resource limitation issue.

12

During the past two weeks, I focused on creating pre-filled Docker images for running the end-to-end (e2e) tests. I initiated a talk thread to provide updates on this task.

Previously, we encountered a problem with the e2e tests, as setting up the backend environment before running the tests took a significant amount of time. This delay was caused by automatic data generation at the startup of the backend environment. To address this issue, we decided to create new Docker images for the backend and the database, with pre-filled data.

As a first step, I investigated the feasibility of manually achieving this by using the existing docker-compose.yml file we used for the e2e tests. However, since that docker-compose stack utilized two volumes, and volumes cannot be committed with images, I created a separate docker-compose file to run without volumes.

Then I waited until the data generation process was completed. Once done, I committed snapshots of the backend and the database, and then pushed them to my Dockerhub.

image
image2530×970 199 KB

Later I automated this process with a shell script and configured a Bamboo job to execute it.

image
image1674×680 55 KB

Following that, I created another docker-compose file to utilize the pre-filled images for setting up the backend environment. This was successful, as I managed to start the backend environment in less than 2 minutes, compared to the previous duration of around 15-20 minutes.

image
image2600×354 24.7 KB



Additionally, I opened a draft PR to update the docker-compose file used for the e2e tests:

Furthermore, I opened another PR for the docker-compose file which is to be used when creating the pre-filled images:

Once these PRs are merged, I will be able to update the Bamboo jobs and complete the task. For more detailed updates, please refer to:

Last week we had the mid-evaluation of the GSoC projects as well, and I submitted my evaluations for the projects I am mentoring. Apart from that, I had the weekly GSoC project update calls with the mentees and reviewed their PRs as usual.

13

Previously, I had opened a pull request for the docker-compose file which will be used to create the pre-filled docker images. Recently it was merged, allowing me to create a sample bamboo job using the newly created docker-compose stack. The job worked well, and my next step will be to move the bamboo job to a stage in the Distribution 3.x build.

I also investigated some issues that were causing failures in the esm-patient-management e2e tests. Currently, these tests are consistently failing with various errors. After some debugging, I identified several bugs, such as a loading issue and problems with params. I opened a PR to fix these issues. However, there is still a bug that prevents the patient chart from loading, which needs to be addressed to pass the tests successfully.

Another area I worked on was creating a script for dynamic docker images for e2e tests in esm-patient-management. Previously, running the e2e tests on GitHub Actions consumed excessive resources (RAM, CPU etc.) because running the microfrontends in development mode is resource-intensive. This led to random test failures due to these limitations. As a solution, Ian proposed creating a production-type docker image for the front end, containing only the required and changed MFs to save resources. With these dynamic docker images, we can run all the microfrontends with less than 300MB of Ram, significantly reducing resource usage. I opened a draft PR for this improvement, but it cannot be merged yet due to the patient chart error mentioned earlier.

Additionally, the OpenMRS conference recently started, and I had hoped to do a lightning talk. However, I was unable to do a live session as I was travelling to Singapore at the same time. Instead, I recorded a small lightning talk video, which was played during the conference.

You can find the video here:

In the next month, I will be focusing on completing my remaining tasks and working on the final reflection.

14

During the first two weeks of August, I finalized the Bamboo stage used for creating the pre-filled images and added it to the Distribution 3.x build. Subsequently, it was approved and enabled, making the pre-filled images available on the openmrs DockerHub account thereafter.

Furthermore, the error in the patient chart, which I mentioned in my previous post, was resolved by someone. This cleared all the blockers I had encountered. Consequently, I was able to finalize my pull request concerning the utilization of dynamic Docker images for e2e tests in esm-patient-management.

Following that, I replicated the same improvement in the other O3 mono-repos, namely esm-patient-chart and esm-admin-tools. This led to a significant reduction in the time taken to run e2e tests on those repositories.

Here are the relevant pull requests for your reference:

Subsequently, I extended this feature to other single-micro frontend repositories as well. Although it presented some challenges initially, such as modifying the dynamic frontend image-building script, I managed to successfully implement it within the week. This enhancement improved the automated e2e testing process for the esm-form-builder and esm-cohort-builder apps.

For your reference, here are the related pull requests:

15

It’s the last two weeks of my OpenMRS Fellowship journey. During these two weeks, I focused primarily on some minor tasks.

Similar to the previous week, I continued my work on optimizing e2e tests by adding the feature to the esm-core repository as well.

Additionally, I updated the O3-docs documentation with information related to e2e test automation and optimization using pre-filled Docker images and dynamic lightweight frontend Docker images. The pull request is currently under review, and I’m hopeful it will be merged soon.

In addition to these tasks, I reviewed the 2.x e2e tests and identified legacy e2e tests that need to be rewritten as BDD tests. Subsequently, I initiated a JIRA epic and created individual tasks for the tests that require rewriting. This approach allows anyone to take ownership of these tasks and complete them.

Furthermore, I dedicated time to reviewing pull requests submitted for esm-patient-management unit and integration tests. Alongside this, I actively participated in the weekly QA squad calls and maintained regular communication through weekly meetings with the GSoC mentees.

Lastly, I started working on my final fellowship reflection report and presentation. These will be shared here within the next few days, summarizing my journey and contributions over the course of the fellowship.

16

Hi all, As my fellowship comes to an end, in this post, I’ll share a summary of what I did throughout the past 7 months. I started my fellowship as a QA engineering fellow in February 2023. Since then, I have primarily focused on improving the overall product quality of OpenMRS and enhancing the OpenMRS developer experience.

Here are some of the tasks I completed during my fellowship:

  • Created the marking rubric for rating GSoC contributor applications.
  • Proposed a unit and integration test strategy for O3 and initiated a Google Summer of Code (GSoC) project based on that.
  • Presented in the OpenMRS virtual mini-community meeting.
  • Reviewed GSoC applications for the two QA-related projects.
  • Mentored in two GSoC projects (one as the primary mentor and one as the secondary).
  • Conducted research on test management tools (Xray and Zephyr).
  • Added automated WebDriver management to the QA Framework.
  • Updated O3 documentation with E2E test-related documentation.
  • Reduced the time taken for E2E tests by more than 75% (with pre-filled Docker images for the backend and database).
  • Reduced the resource consumption of E2E tests by more than 80% (with lightweight dynamic frontend Docker images).
  • Delivered a lightning talk at the OpenMRS '23 conference.
  • Improved 3.x end-to-end (E2E) test coverage by writing tests.
  • Addressed various bugs and test failures in the QA framework.

Top achievements:

  • Optimized the automated E2E testing process:
    • Reduced test execution time by over 75%.
    • Minimized test execution resource consumption by more than 80%.
  • Led squad calls and provided mentorship to community members.
  • Mentored two projects in GSoC (one as the primary mentor and the other as a backup mentor).
  • Resolved numerous critical bugs and issues in the testing procedures.

Contributions:

Code contributions:

  • 20+ Pull Requests in 8 Repositories:
    • Patient management - 5 PRs
    • Patient chart - 2 PRs
    • Admin tools - 5 PRs
    • Core - 1 PR
    • Form builder - 2 PRs
    • Cohort builder - 1 PR
    • QA framework - 5 PRs
    • Distro Ref App - 1 PR
  • 1 Bamboo plan improvement

Talk Threads (6+ topics | 50+ posts):

Demos and presentations:

Next steps:

  • Continue refining the automated testing processes for further optimization.
  • Enhance the manual testing procedure by incorporating test management tools.
  • Keep creating and reviewing tests for O3.
  • Explore additional domains, including frontend development and DevOps, to broaden expertise.

Final Reflection:

I really enjoyed mentoring, contributing, and collaborating with the OpenMRS community, especially during GSoC 2023. The experience of leading squad calls, delivering demos in squad meetings, participating in mini-community meetings, and presenting lightning talks at the OpenMRS conference was truly fulfilling. I am immensely grateful for the invaluable opportunities that have allowed me to grow both personally and professionally.

I would like to express my gratitude to the OpenMRS community for giving me this incredible opportunity, especially my mentor, @jayasanka , and the fellowship program administration. I am thankful for their guidance throughout the program.

Here is a short video reflecting on my final thoughts:

Slide deck:

4 Likes
17

Thanks for all your hard work, @piumal1999 ! :heart:

2 Likes