My OpenMRS Fellowship Journey: Daud

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
                         EPIC 5:  AUGUST
               Taking the QA technical work forward  --> 

The first phase of August has been encapsulated with learning more of the project configurations, as well learning more tools and reading more resources to be in position to providing technical assistance to others. This has been another vigorous learning experience(sometimes would find myself late to bed) and has enabled me acquire a wider scope on our QA projects and as well advance my technical skills in a more advanced way than before!

Of course leaning a new thing in tech everyday is my custom and will continue exploring more resources and tools to advance to higher skill sets in software development and perhaps be a resource in the QA team/squad and as well to the community.

          Working in Partnership With Other Squad Members!

Working together as a team is part of QA squad culture and is helping us to move forward with the tasks within the squad and I can ideally recommend other teams/squads within the community to embrace the culture. Its worth living as community contributors!

Besides working along with others and providing support to aid them progress in advancing to higher skill set, have been able to learn from them in return and as well grow my leadership skills in software project management. Thanks to @sharif @jwnasambu @irenyak1 @insookwa @grace @jayasanka @mherman22 @suruchi @hadijah315 @jnsereko and others for your cooperation in the QA team, its worth imitating!

                Leaning on the shoulders of the Giants

Leaning on the shoulders of @ibacher and @dkayiwa is another new experience and has made me grow to more like them in a short period of time have so far been with them. Every day I learn from them in every angle in how they make their work done and soon or latter I will be in their category in how they handle their technical work across different projects. I like how @dkayiwa makes his precise and clear comments on the PR and as well how @ibacher makes the PR author think like him through his reviews. From their reviews am now a consultant to myself before I make any PR to any of our repos to ensure the code base is of standard and aligns with quality assurance ethics.

As my culture states it clearly that “If you’re on the shoulders of the giants feed the giants and they will lift you”. Surely am being lifted by these geeks and soon will be a giant too in lifting others on my shoulders as well. Shout out to @dkayiwa and @ibacher for your endless support and will lean on you and consult you whenever I need guidance.

                 Silent mentors behind the seen!

I must say am learning as well from @grace @christine @jennifer and @janflowers in how they make things done and as well how they approach different scenarios in the community. These are silent mentors to me and am glad to learn from their experience :grin:.

                 Summary of the technical work done

Well a lot of tasks have been accomplished during the period and among them are listed below.

  • Developed two workflow tests: Encounter Management Test and Manage User account Test.

  • Supported others working on the remaining ignored old legacy test and in return increasing the test coverage to 95%. (Only 3 tests are remaining as of now with my eyes on them as the assignee(s) are working on them).

  • Developed the steps one can take to run the RefApp 2.x test locally and updated the QA Technical Documentation wiki page.

  • I and @bistenes provided support to @jayasanka who is pioneering the automated tests for 3.x RefApp and soon ending the project with a success regardless of the challenges pioneers face in software development.

  • Monitoring the test status via QA Dashboard and ensuring the tests in master are passing both with GitHub Actions and Bamboo builds.

  • In order to provide technical support to other squad members get acquainted with the new workflow based testing, I developed a demo that explains clearly the Technical Workflow for OpenMRS QaFramework (Length: 10 minutes).

The last phase of August will focus on:

  • developing new workflow tests.

  • providing technical support to other squad members and mentoring new members in the squad to aid them get on page with the technical work.

  • monitoring test status via QA Dashboard and responding to any test that might be failing.

  • providing technical support to contributors for 3.x RefApp workflow tests and as well write workflows as well for project. I know @bistenes and @mksd are keeping an eye on functionality that are ready to be subjected to automated tests and will keep an eye too and as well get close to them for their guidance.

  • of course exploring more resources and tools via google.com to advance to higher skill set as a QA Test Engineer and as well in software development.

  • Looking for ways to improve our QA processes and as well how other squads can incorporate automation in their workflows.

  • meeting Dictionary Manager(DM) geeks and brainstorm with them how we can achieve having separate workflows for each DM tests so that we can have each of them tracked separately via the QA Dashboard.

  • working on getting started developer guide for quality assurance and glad to be working with @christine in that angle.

  • sharing resources with other squad members via qa-slack-channel to support them in their growth in software development.

  • working on any task that my require attention as requirements change in software development.

7 Likes

great work!!! continue the great work, including the mentoring of newbies in qa-work. kudos

1 Like

Awesome Work @kdaud. And thank you for being helpfull

                              EPIC 6: AUGUST

 Selenium Legacy Tests Comes To an End With  a Recorded Coverage of 100% 

I found myself 2 days late to update my thread according to my structured plan however, for the past two days my hands were dirty looking into the five tests that were still ignored in master branch and finally they were made back to life :100:.

All the selenium legacy tests in openmrs-distro-refernceapplication master are automating their respective functionality on every PR that is triggered and on every merge that is made. This is a good milestone for OpenMRS community, in addition to the new E2E workflow tests that are currently being developed by the QA contributors our 2.x RefApp will have a minimal maintenance burden since these tests will do the work of automating 2.x RefApp functionality behind the seen and we shall be tracking their status on our QA-Dashboard.This is amazing !!

A word of thanks to our contributors who have worked tirelessly to see the team strikes the greatest % a team can ever achieve. Great work deserves appreciation cc: @sharif @insookwa @gracebish @irenyak1 @achilep @mherman22 @jwnasambu

     Eyes now on E2E Workflow tests coverage for 2.x and 3.x RefApp !

Am putting my focus on increasing new workflow coverage for 2.x RefApp to make sure that the uncovered critical functionalities/features of the Reference Application are put under automation. We already have three developed E2E workflow tests that are running in qaframework repo and more workflows are soon joining the master branch. As a team we are looking at covering the remaining 2.x RefApp functionalities/features so that we support the community in maintaining 2.x RefApp and focus our attention on 3.x RefApp development with ease.

Besides increasing E2E workflow tests for 2.x RefApp, am also looking at how the team will support E2E workflows for 3.x RefApp to see that both projects are taking place for Reference Application.

                  New members joining the QA squad !

We are grateful for the new members joining the squad and getting started with the technical work. Besides providing membership to them, I and @sharif are providing technical support to get them acquainted with the technical work. Glad to see @mherman22 @jonathan @kmuwanga @pasindur2 @ndacyayisenga @jnsereko and others picking up tickets on our QA-Kanban-board.

Thanks to @jayasanka for laying out a good ground for E2E Automated tests for 3.X RefApp and even after the GSoC program has continued supporting the project. I have just learnt of recent of his mentor ship is providing to those getting started with 3.x Automated tests. This is really a good thing, thanks and keep the fire burning :seedling: . Will be glad to create tickets for 3.x RefApp and avail them on the Q-Kanban Board so that contributors pick them up and work on them.

                   Learning skills from other fellows !

Attending the PM calls led by @herbert24 has not only helped me get to know what other teams/squads are working on but also enabled me acquire skills from other collegues in how they make their things done. Glad to be travelling with @sharif @hadijah315 @suruchi @jwnasambu and others who are a key element in my open source development growth since the journey began. Learning how to collaborate with others is helping me grow each single day in my journey.

                     Mentors deserves appreciation !

Am grateful :pray: to be moving along with @dkayiwa @ibacher @mksd @bistenes @grace @jennifer @janflowers and their contribution in my journey is indeed a blessing to me and to the community. Am always lifted up by these mentors whenever am blocked and this keeps me moving and pressing forward → in my journey. Each of them has lessons to learn from and a collection of all is what am aiming to become a life time mentor.

        Summary of the technical and non-technical work done:
  • Developed E2E workflow test : Inpatient encounter.

  • Cleared the selenium legacy tests that were still ignored in master striking the percentage to 100%.

  • Provided support to @jayasanka to ensure his GSoC project comes to success :fireworks:.

  • Updated the QA Technical wiki-page with the steps of running locally automated tests for 2.x RefApp, 3.x RefApp, and Dictionary Manager.

  • I and @christine developed Getting Started Guide with QA and soon to launch it out to the documentation team to carry on the next step. Thanks to @gracebish @jennifer and the team for providing guidance in documentation, this is another skill have acquired along the way and will look for ways to improve it.

  • Provided mentor ship to team/squad members and this will continue through out the fellowship journey and even beyond !

      First half of September will focus on:
    
  • Increasing E2E workflow tests coverage both for 2.x and 3.x RefApp.

  • Set up Coveralls to work with Module RefApp repo: RATEST-196

  • Putting my hands dirty with Platform core tests. This sounds interesting and have already got a membership in Platform Team/Squad. cc: @tendomart @dkayiwa

  • As mentioned earlier, I will provide mentor ship and technical support to other squad members and will work together with my colleague @sharif .

  • Reflecting on my fellowship plan to plot well the ladders I need to climb to strike my target goal in the program.

Every day am driven by the fact that a single line of code saves millions of lives around the globe and this keeps me witting more lines of code to have lives around the world saved :globe_with_meridians:.

7 Likes

Great stuff! looking forward to this documentation

These tests must be interesting to be a part of, would love to join in after getting my foot on the ground in QA —> @jayasanka

3 Likes
                          FIRST HALF: SEPTEMBER
 Increasing Automated Workflow Tests For 2.x and 3.x Reference  Application

The first half of the month has been encapsulated with writing more automated workflow tests for 2.x & 3.x RefApp and great progress has been registered. The period has been another thrilling experience when providing technical support to other squad members get to learn the QA Framework and am glad that our technical team is growing in number which satisfies me especially seeing other colleagues growing their technical skills and expertise in QA Tools.

As a result, more automated tests have been developed for both 2.x and 3.x Reference application. Below is the QA Dashboard that tracks the current Project Status.

  2.x RefApp Automated Workflow Tests

 3.x RefApp Automated Workflow Tests

Breaking of Selenium Legacy Tests

One week after the team striking a coverage of 100% of selenium legacy tests that were ignored over the past years, I noticed build failures on the UI when Bamboo builds could not pass plans on weekends and this made me step back to look into why the tests were failing. It was a learning experience figuring out the issue through the guidance of @dkayiwa and @mogoodrich who lifted me on their shoulders and elevated me to configurations that helped me fix the problem. Though the solution required less than 2 hours to have things resolved, I found myself taking two days to figure out the solution but it was worth the experience because along the way I learnt more skills in trouble shouting breaking tests.

  3.x RefApp automated workflow tests breaking suddenly

As work around writing automated tests for 3.x RefApp is progressing, the existing tests in master branch suddenly got broken and this gave me another experience of its own. I remember spending a sleepless night and would not figure out the right solution. I googled almost every site that would talk about the problem but the solution there could not resolve the issue. I decided the following day to reach out to the community and in less than 10 minutes after posting the thread on talk, lo & behold a geek gave guidance on how I would approach the problem and following the guidance helped me resurrect the tests. Thanks @ibacher @dkayiwa for always putting your shoulders for every one, I guess my shoulders are getting stronger and already lifting others within the community.

 Interesting Weekly QA Calls

The QA weekly calls on every Tuesdays at 7:00 PM EAT are so interesting to attend and I find myself can not miss any of them. New members are able to understand the work around the squad and no question is left unanswered for any one who may have questions or concerns. Am always excited by the demos when squad members are showcasing what they are working on and get feedback from other technical squad members. Thanks @irenyak1 @sharif @insookwa @jonathan @gracebish @mherman22 @irenyak1 @ndacyayisenga @jwnasambu and others for making the QA calls interesting!

The last phase of September will;

  • Focus on platform core tests

  • Ensuring the Set-Up wizard for Platform is working

  • Get familiar with REST API automated tests

  • Provide technical support to the squad members

A word of thanks to my mentors @dkayiwa @ibacher @grace @jennifer @janflowers for putting your shoulders to lean on in my journey!

Write Code :globe_with_meridians: Save Lives motivates me every single day !

8 Likes

@kdaud Thanks for your support always. Keep growing.

1 Like

Thanks to you and the whole QA squad for giving a safe landing in the squad. The instant responses for one with a blocker and growing our confidence in both software testing and communication. cc: @sharif @kdaud @christine

2 Likes

Great job @kdaud

2 Likes

Great job @kdaud.

1 Like
                       LAST HALF: SEPTEMBER

              Increasing Test Coverage For Our REST API 

It was a humble beginning when I started working on automated tests for REST API. This is because I had to learn some back end technologies that are used in automated testing and being a new venture I took two days when reading various google sites that helped me get started with the technical work. Then my hands got dirty with the codes when writing these tests and as of now the coverage has been increased for our REST API. Thanks to @dkayiwa @ibacher who with love have lifted me on their shoulders as I get my foots into back-end development.

       Supporting the ongoing technical work within the squad

As new members are joining the squad, supporting them is one of my priority and it is satisfying to see them growing their skills and expertise every single day. This has increased the technical members within the squad working on tickets that resides on QA Kanban Board.

Making code reviews is another priority now that PRs are increasingly coming from different squad contributors. Thanks to @sharif collaborating together in ensuring reviews are made in time for contributors work and providing significant feed back to the technical contributors as they work on tickets.

  Resurrecting RefApp 3.x Search and Registration workflow test.

Despite the effort that was made to resurrect the automated tests for 3.x RefApp in the beginning of September, one test remained in a comma. I stepped back to investigate why the test was failing and after spending a full night while investigating, the test finally came back to life.

As October arrives, I will;

  • increase the automated test coverage of REST API with a goal of shooting to 100%.

  • support Platform 2.5.0 release both for alpha and beta cc: @tendomart

  • provide technical support to other squad members and will work together with my colleague @sharif

  • immerse my foots into back-end development and will take up some tickets on Platform Kanban Board

  • reflect on my fellowship plan to plot well the ladders I aught to climb to strike my target goal as I come to the end of my journey.

A word of thanks to @dkayiwa @ibacher @grace @jennifer @mogoodrich @christine and the QA squad members who have made my journey to be a journey like no other!

                  Bye Bye September! Welcome October!
6 Likes
                 LESSONS LEARNT SINCE 1ST OCTOBER 2021
  1. Continuous Integration

card

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

The goal of continuous integration is to minimize the impact of problems found when integrating different software components together. A regular integration cycle ensures that the components are integrated together in small pieces. The advantage of this approach is that you don’t have to deal with large problems which might be troublesome to solve. Instead, you will face only smaller problems which in general should be easier and faster to solve.

The true test which reveals if you are really doing continuous integration is this: What do you do when your build fails? If you are doing continuous integration, you will start fixing the problem as soon as you are aware that it exists. This is the condition which must be fulfilled before you can claim that you are doing continuous integration without lying. Keeping the build green should be of higher priority task than any other task in software development.

  1. Fix Broken Builds Immediately

A key part of doing a continuous build is that if the mainline build fails, it needs to be fixed right away. The whole point of working with CI is that you’re always developing on a known stable base. It’s not a bad thing for the mainline build to break, although if it’s happening all the time it suggests people aren’t being careful enough about updating and building locally before a commit. When the mainline build does break, however, it’s important that it gets fixed fast

Learning that fixing build failure is of higher priority task in software development. This doesn’t mean that everyone on the team has to stop what they are doing in order to fix the build, usually it only needs a couple of people to get things working again. It does mean a conscious prioritization of a build fix as an urgent, high priority task.

                      Work Done
  • Increased the test coverage for REST API

  • Resurrected CI for QA Framework module. While investigating why CI for the module was failing since the 1st October, along the way had to learn Bamboo configurations for the module. Reaching out to the community for support was so beneficial in figuring out the issue and resolving the problem that had persisted on the module for over 17 days. And now the CI is green!

During the process, I also learnt the handshake process that takes place during server certificate verification when CI is taking place. curl performs SSL certificate verification by default, using a “bundle” of Certificate Authority (CA) public keys (CA certs) and these certificates expire after a specific period of time because HTTPS server uses a certificate signed by a CA represented in the bundle. Thanks to @ibacher who gave more scope on this subject through his comment. Great thanks to @dkayiwa @sharif @mozzy for your support during the process of resurrecting CI build.

                   Work To Do

The remaining phase of the month will focus on finishing the remaining REST API tests and also looking for a smart way of integrating deployment Technic on qaframework module for all the PRs so that a committer or even a non-technical person can just press a button and the changes are deployed on the server, run against the existing code base and returns the build result. When this is effected, will then look for a way of integrating the same in other openMRS repos.

Great thanks to @jennifer @grace @janflowers @dkayiwa @ibacher @christine @mozzy for your continued guidance and support in my fellowship journey!!

3 Likes
                            LAST PHASE OF OCTOBER

The last phase of the month encapsulated many learning areas in my journey;

  1. I got an opportunity to go through the workshop that was conducted by @achachiez from @AMPATH and was focusing on Form-Builder tool;
  • understanding the form features

  • creating a form using formbuilder

  • translating a medical form orders form into an Ampath form

The beauty with the form generated by the tool is that one is able to create a custom one and was interesting to play around with the tool and generated a customized form.

It was a nice experience learning from the attendees who were 8 in number coming from different back ground. I realized there is a lot to learn in the field of technology and being a good developer, one must be open and willing to learn from others.

  1. I and @sharif had a chance to interact with a quality assurance specialist for one of the organisations which uses OpenMRS platform to develop health Information systems distributing them in various hospitals and clinics. As per the conversation on this talk post the organisation wishes to tap on the benefits of automated testing to achieve quality for their products before sent into production and currently we are looking into how we can provide the necessary support to them.

I also believe other organisations implementing OpenMRS platform in developing health care systems would be glad to tap on the benefits of automated testing for their product and am looking in how best we can support such implementations in regard to automated testing. cc: @grace

  1. Integrated Heroku into qaframework but realized limitations with the tool in terms of pricing and rather opted to reach out to community for guidance on getting a Suitable tool for auto-deployment of application on github

  2. It was interesting to see one of the automated tests known as Clinical Visit Test catching a bug in Platform 2.5.0 which is under construction. cc: @tendomart

  3. Attended Mentor Office Hours which has enhanced my communication skills in general. Thanks to @jennifer for organizing these calls every Wednesday at 6:00 pm(EAT) that are helping those who attend to improve their communication skills.

  4. Provided technical support to squad members and ensuring our CI is ever green. Thanks to @dkayiwa @ibacher who are ever present whenever we need assistance from them. I also want to acknowledge the great work from my colleague @sharif in supporting other squad members and also adding more test workflows to our module, of recent he migrated all the pages that were residing in distro-referenceapplication and now they got citizenship in qaframework module. Just few days ago he added Report Workflow Test which is now running in master!

During November I will be focusing more on how best our implementers can tap on the benefits of automating their products and also make survey with different implementers of OpenMRS systems to see how best we can support them to better end user experience using their products.

A word of thanks to @grace @jennifer @janflowers @dkayiwa @ibacher @mozzy @mksd @christine for your endless support which has been a key element in growing my skills both technical and non-technical ones in open source development!

4 Likes

That was not a bug in the platform. It was simply that the appointment scheduling module has not yet updated its resources to include support for platform 2.5

2 Likes

Am surprised you create time to read through our blogs!

Thanks @dkayiwa for the information on the subject!

By the time I was investigating the issue I thought it was a bug but now I understand from the provided information on the subject that the issue came as a result of the failure of the REST call that fetches appointment types openmrs-module-appointmentscheduling/AppointmentTypeResource1_9.java at master · openmrs/openmrs-module-appointmentscheduling · GitHub.

The solution was to update the supported platform versions by adding a string of "2.5.*" within the Resource to cater for Platform 2.5.0. Something like;

supportedOpenmrsVersions = {"1.9.*", "1.10.*", "1.11.*", "1.12.*", "2.0.*", "2.1.*", "2.2.*", "2.3.*", "2.4.*", "2.5*"})

Daniel most of your comments on talk posts and PRs are filled with something to learn :grinning_face_with_smiling_eyes:

:rofl:

:+1: :+1:

Love all the interesting aspects of QA that you are seeing, experiencing, and sharing! Keep up the great work @kdaud. Our QA program is so critical to our long-term success in supporting Ministries with their healthcare programs. Have you had a chance to look into what @mozzy and @pmanko are working on for the “Testable FHIR IG” for OpenMRS?