Imagine the following conversation around writing tests:
Product owners: We don’t have time to do that, we are chasing deadlines!
Developers: Maintaining production and test code will double our work efforts!
QA: Don’t you need us anymore!?
Business: Double the efforts? That will double the cost and the time needed! We can’t afford that!
Sounds Familiar?
Those are possible reactions of people working on software systems when presented with the idea of including tests in the development cycle, especially, if they have never done this before. If people are not familiar with how tests are integrated into the software development process, then it will be a difficult task to introduce this scary idea of having to write and maintain all those extra lines of code that tests add to the picture. Especially if it’s a legacy software product with thousands of lines of code already in place and there are very well established processes everyone follows.
Below I will discuss the two eras in the evolution of software systems.
My Experience – Resistance to Change
At some point in my software development career, I became part of a team working on a product that has been in the market for about ten years. There we were following good practices, had a nice software development process, and people were great. We developed features, did bug fixes, and made successful releases.Â
Little did I know how things were about to change after two years in the project.
Change is Inevitable
One day, a new software development manager joined the team. And he didn’t take too long before doing the unthinkable. He not only suggested but actually started deploying the idea of writing tests. He also wanted developers to aim for 70% coverage of code!
Chaos.
Developers were very reluctant to the idea because the effort and time usually needed to complete a task would increase significantly. Later, product owners would not be happy when the programmers pumped their estimates with 2-3 days or even doubled them. Oftentimes one could hear someone say:
“I’m done, but I need to add tests”, which translates to: “I’m done with the actual code which satisfies the requirement, but I need to add tests for it”.
I’ve been there. It was a new concept for most of us involved, and there was a big learning curve. We had to master Unit and Integration tests, and frontend tests. And we had to do it while keeping the estimates reasonable and delivering the day-to-day work in a timely fashion.Â
How to Achieve the Required Code Coverage
Stress levels were up. Sonar, a software program that we used for static code analysis and quality check, didn’t make it any easier for us as well. When you write a new piece of code, you can create a test for it and then just forget about it. But sometimes, you would need to touch on existing functionality, maybe even make a tiny little change to the code. But that could result in modifying whole flows, and Sonar would ask you to make tests for parts of the code you’ve never even planned on changing! And that could be some legacy code that hasn’t been maintained for years.
Then this follows: you need to write tests for it, refactor it, and you may even be forced to change another code and repeat. I remember that for a couple of sprints – the desired coverage was even reduced to 50% so people could handle the new workload.
But I guess this is normal. Every change is hard. People need time to adapt. But it’s worth it, I promise you.
Benefits of Writing Tests
 At one point though, something magical started happening. The tedious process of writing tests after “being ready” with a task was changing for the better. It was becoming ever so easier, lighter to accept and follow the new software development process. Finally, people have learned the fundamentals and were on their way to mastering the art of writing tests.
Gradually, the benefits were becoming more and more obvious.
Confident Developers
As a developer, you write code for all the scenarios you think of. By writing a test for each of those cases, you feel confident that you have covered the main flow but also some weird edge cases you have thought of.
Less Bugs Discovered During QA
With tests constantly running, you can easily be certain to a great extent that QA won’t discover many bugs.
A Lot Less Regression
You are also calm that you won’t “break” any existing functionality. Without tests, it often happens that somebody develops something or makes massive changes that impact a big part of the system, resulting in totally unrelated modules getting damaged—the so-called regression. Tests are a key safety net of the system and prevent any breaking changes from getting introduced into the main codebase long before submitting the changes because developers can run the test on their local machines during the development phase. Tests are also checked just before merging any code into the main working branch.
Test-Driven Development
At some point, we also introduced the Test-Driven Development, or TDD, approach. But I won’t go into details here as TDD deserves a separate blog post. So stay tuned, we have a lot more topics planned for 2022!
Confident Product Owners and a Happy Client
With more confident developers preventing a lot of issues in advance and with QA discovering fewer issues with the software system, product owners who commit to deadlines are also a lot more confident when doing so. And this leads to more met deadlines which ultimately means that the client requesting all the features and changes will be satisfied with the work done and will be highly likely to continue working with you.
Conclusion
Creating a comprehensive suite of tests will save you a lot of headaches in the mid and long run. In 2022, with software systems becoming bigger and more complex, having tests to protect you from issues is of paramount importance. We at Dreamix, a bespoke software development company, possess a deep understanding of the topic and would be happy to help you introduce tests to your existing software system or to embark on a completely new journey with you and ensure the quality of your emerging product from the very beginning.
