This blog was due last week, which was week 7 and half my journey as an outreachy intern with mUzima mobile. I was unable to post it earlier due to prior engagements, but better late than never. Speaking of timelines, often project goals, expectations and timelines are set but as one progresses, these may be modified due to new developments.
Just finished week 8 of my internship and I must say the glass is half full 😊. So much growth, new connections, and of course new skills. Have you noticed that my blogs keep getting better! Hahaha.. Well, I didn’t think I would have anything to put down for my very first blog. Look at me now 😊, can’t wait to have a look at the glass, full.
My internship objectives and timelines at mUzima
The main objective of my internship is to improve mUzima testing and documentation by implementing a plugin on Jira which allows for testing against the different releases of the mUzima for Health Provider app and mUzima Core Module using the same set of tickets.
Specifically, my internship objectives are to
- Research on the top three JIRA plugins for testing and documentation along with the pros and cons
- Start using the JIRA plugin for testing and documentation
- Create test tickets along with their description, steps and expectations, as well as an indicator for each step (fail or pass) on mUzima JIRA
- Write up documentation for the tickets on mUzima Wiki
- Test the tickets against different versions of mUzima for Health Provider app and mUzima Core Module
According to the timeline, a total of about 60 tests should be documented by the end of week 8 and then a kick off of ticket testing in week 9 as per specific objective 5.
The look of the glass half full
It has been quite an interesting journey and I am indeed achieving my internship goals and meeting my expectations as well.
After doing research, a decision was reached to use the Zephyr plugin for improving the mUzima documentation and testing. The plugin was installed and then tests created. By the end of week 8, I had reached a total of 17 tests for the mUzima Core Module and 20 tests for mUzima for Health Provider application. This brings it to a total of 37 tests out of the anticipated total of 60.
Ideally, an average of ten tests should have been documented a week. However, the process of documenting a test requires a lot more time than anticipated. A test involves a series of steps that are taken to use a software as related to a particular functionality or feature. In order to effectively document the test, the following are necessary;
- An in-depth understanding of the software which can be achieved by reading the existing documentation and making inquiries in the community.
- Identification of the various software functionalities and features. Once these are identified, one has to test them and see if they actually behave as expected. If there are any bugs, these have to be reported and documented on JIRA for fixing. Until the bugs are fixed, one cannot complete documenting the test steps for that particular functionality or feature as there will be missing information.
- For each functionality or feature, a test is then created with the different steps to be taken while testing the functionality or feature. This involves adding the result to be expected after execution of each test step and having “Pass” or “Fail” as execution options at step level and for the overall test as well.
As you have seen, effective documentation of tests requires a good amount of time and it was therefore necessary to adjust the timelines in order to ensure quality. All projects set timelines within which project goals should be achieved. However, for various reasons these may need to be adjusted in order to enable the project team to deliver quality work as long as they are committing the expected amount of time to the project.
All the best as you manage your timelines!
Happy Tester and Documenter!