I contribute to LinkedIn’s collaborative articles and was reading one on testing sorting algorithms. There were many entries for the article on how sorting should be tested. Many testers assume that their development team needs to write custom sorting logic. Unfortunately, there are many developers who feel the same way and write code to implement their own sorting logic.
So many hours are spent implementing sorting logic, testing it, opening bugs, fixing them, opening more bugs, etc… Everyone makes this complex, but it shouldn’t be. The bugs might be found, but that does not mean it’s a quality product. The time spent on this should not be acceptable to anyone on the team.
I am going to go over three examples over the years where I have seen this type of implementation play out. It’s buggy and very costly. The number of bugs opened did not mean there was a quality product.
Sorting Example
I’ve been on many projects and releases where sorting was needed. There was sorting in dropdown lists, tables, reports, and other functionality.
In almost all cases, sorting should be handled by the sorting algorithms of the coding libraries. For example, if the project is using .NET, using List<T>.Sort or LINQ OrderBy should handle almost all cases of sorting. There is no reason to reinvent the wheel–development should almost never implement their own sorting logic. There is no need to. The only logic that should be implemented is which field and sub-fields the sorting is on. (For example, first name, last name, email…)
This also means that there is no reason to test the sorting logic! Yep. This is coming from a tester. I mean, there is no reason to test the core sorting logic. It’s already been tested by Microsoft or another company that wrote the libraries the development team should be using. The only testing that needs to be done is around which fields and sub-fields are used for the sorting.
Sure, do a few cursory tests to make sure the sorting wasn’t implemented with a developer’s own sorting logic, but there should not be hours and hours spent testing this. If bugs arise, it likely indicates incorrect implementation. In such cases, pause testing and consult with the development team regarding the sorting implementation.
In the end, this should be a conversation between all stakeholders, but having development implement their own sorting rules is costly. You can tell it is by all the different opinions on how best to test sorting from that LinkedIn article.
*To be fair, I think the DBAs get sorting right from what I have seen. They use Order By and let SQL handle it. They never implement their own logic.
Date Field Example
On one project where we generated reports, our UI had a Start Date and End Date field. The user needed to enter a valid date or we would display various validation messages depending on what the user entered: “Correct date format is MM/DD/YYY”, “Alpha characters are not allowed.”, and “There’s no leap day that year.” Ok, I made the last message up, but you get the point. We had plenty of messages that we needed to test.
The developer attempted to implement his own date validation logic, and after opening multiple bugs and spending way too much time on this, I suggested to the development lead that why not use the .NET DateTime.Parse() method to determine if the user’s input was a date or not. If Microsoft determines the user’s string is a date, then use it. If the Parse() method throws an exception, display a validation message saying, “Invalid date”.
We ran this by the BA since we would now display one message for an invalid date, which was a requirement change, but we explained how the current implementation and any future implementation of date fields would have huge time and cost savings. Of course, the BA thought this was a good approach.
Microsoft Graph API Example
On another project, we grabbed appointment data from Outlook calendars and created events in another system. The Outlook appointments could be recurring events. The developer implemented his own recurring logic when inserting these into the other system. There was lots of code written, and when I started finding a few issues with the functionality, it started taking too much of our time fixing the issues and finding more bugs.
I thought it was quite strange that this recurring logic would need to be implemented since Outlook obviously had the logic to create recurring events. This doesn’t mean it was exposed in their API, but I was wondering why it wouldn’t be.
I did some research and found the correct way to get the information from Outlook using the Graph API. Since I was testing and also doing some development on this project, I implemented a solution and ran it by the developer who was pleasantly surprised by this. He was glad we could go down this route. This means the custom recurring events logic did not have to be tested anymore since we were using the same logic that Outlook used.
Conclusion
With these three examples, you can see how quality is not always achieved by the number of bugs that are being opened. Sometimes, quality is achieved by changing the design or using a different implementation. Many times, there is no reason to reinvent the wheel. Custom implementations in these cases often lead to unnecessary complications and reduce the quality of the product.
As testers, we need to be an advocate for quality and not just want to open bugs. Developers and testers should seek solutions that are efficient and that can contribute to a quality product.