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
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
Looking forward to achieving quality software releases from a community where writing a
code saves millions of lives around the world .
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
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.
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
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 …
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 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.
Good work @kdaud. Thanks for your help always.
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.
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 !
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 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 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
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
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)
As August arrives I will :
continue to increase the new workflow test coverage
support automated tests for
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 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.
Also: It’s wonderful to see these videos of the automated tests running!
I have 2 simpler questions:
- Does the Vitals workflow test include checking that the vitals results show up in the EMR as expected?
- 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!
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.
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.
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 .
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-channelto support them in their growth in software development.
working on any task that my require attention as requirements change in software development.