Considerations to Achieve High-Quality Assurance Software
Two weeks ago, I was implementing the second feature in the Digipus project, and in this article, I’m going to share with you how I ensure the quality of software that I learned from the PMPL course through the feature. I encourage you to read my first article first of this project to get a clear idea of the story behind the project, the stacks, and the environment I’m working on before reading further because this is a continuation of that article. Check out the article here.
Methodologies
In order to implement the second feature of mine, I will use some methodology to help me to work in scope, fast, and make sure the quality of software remains the same or higher than before.
- Agile — I and a team together implement all features one by one quickly
- Test-Driven Development —Test first and implementation comes after that, it helps me to scope my implementation
- Test Partition — Help me to figure out what tests that could cover my implementation
Recommendation Feature
The second feature I worked on the project is the recommendation feature, this doesn’t sound cool as you imagine, because it’s a simple implementation that only considers the like count and the date of creation. So what the feature does is only sorting all education posts/matters by considering like count and the date of creation in ascending order. The priority is the like count and the date creation is a second priority as a tie break of the first priority.
Test Creation
The first thing to do is create a test, we will not use traditional thinking to make it but instead, we will use partition based on functionality-based.
Test Partition
Let’s as the feature does, the feature considers two parameters which are the like count and the date of creation. So because we are using functionality based, then we can say that the like count and date of creation are two different characteristics that we need to add. Furthermore, we see that number of contents needs to be considered as well. So here is the full partition I’m looking for this particular feature.
We clearly see when we use all combinations, then we will get 2 * 2 * 2 = 8 tests in total. But take a look again, we actually can only get 5 tests in total, because when we use empty contents, other characteristics can’t be applied, so the tests are not redundant. And because it’s a cheap number, so I’m totally okay to use ACoC for the combination with little reducing tests.
Implement Unit Tests
Functionality Implementation
Tests are done, now let’s jump to the actual implementation. There are two things that need to do to implement the feature, first is the code to sort the contents, and the second is the view of it. Here is the actual code to get a recommendation from the original list of contents.
This is the code of the view, it’s pretty simple and straightforward that I only add a button to trigger the recommendation.
Result
Tests are completed without no issue and the code coverage remains the same, which is still in 94%. The Linter stage is perfectly fine, there is no issue to appear there. Check the result below to see in visual.
Takeaways
By finishing this article, I learned some things that I don’t know before about maintaining the quality of software. Before taking the course, I have my own principles about software quality, but it doesn’t convince me enough because no one can confirm whether is acceptable or not. But, thanks to the course it answers me about my faith, the course emphasizes some ideas I have when considering software quality, such as creating a test by partition and how we approach to test whether input-based or functionality-based.
