As a company, we have made lots of project in different domains. We have clients all around the world coming to us with super ideas of their products. There are very different projects that range from small 2-3 months time span to ones that take even more than 1 year to develop. No matter what size and domain the project is, there is always this one thing that can dramatically improve its quality - the tests.
“...the paradox of testing: We want to find defects in the software under test, but we do not really want to find them”. - Philip Armour
Testing is an integral part of any successful software project. We, developers, know that pretty well and some of project owners know that, too.
Unfortunately, testing is still an area of software development in which businesses cut corners for budget or scheduling purposes. Let's not forget, however, that it’s cheaper and faster to make sure things work well right away, and even the simplest testing processes can generate great results.
Testing reduces the number of bugs and has a measurable impact on product quality and customer satisfaction. In this article, I'll explain how your software can benefit from testing and especially from automated one.
Uncovered code is like buying a pig in a poke
Sometimes there are clients that want to pass us an already written project (or so-called “legacy code”) just to add some new features or to simply continue the work. The first thing we look at while analyzing the project is the presence (or absence) of tests.
When passing a project to a different team, the unknown code is even harder to change and more susceptible to regression than a newly developed one. It’s a really big risk for us to deep dive into code we’ve never seen before. When the project is covered with tests, the risks connected with making changes in the existing code are significantly smaller.
The tests can serve as a part of documentation as well. It helps us deeply understand the domain we are working on and grasp the concepts of what the code actually does. It reveals the edge cases which developers might not be fully aware of.
Regression - your hidden enemy
Without covering your code with tests, you can never be sure that some change doesn’t violate the features written before. Nobody ever expects regression. Even a small tweak can have unexpected consequences when developers change or modify their software. The purpose of regression tests is to make sure that a recent program or code change has not adversely affected existing features.
In untested code, errors might betray you later, during the software development and the further we go, the harder it gets to solve the old problems. So there is not only the risk of regression but also the risk of misunderstanding the business purpose of the software.
Biases are everywhere and our job is to minimize them as much as possible. The truth is that the more code you write, the more bugs you can produce. One can say: “developers should test their own code”. Indeed, we have to, but that’s not enough. There are always some things happening under the hood and none of us can be 100% sure this is correct. Writing code and actively testing require two different mindsets, and it’s very difficult for a developer to catch bugs in their own code. Writing tests is what has to be done to do so.
Manual vs. automated tests
Software testing is a huge domain, but it can be categorized into two groups: manual testing and automated testing. Although neither of these options are technically superior, the type of testing depends on various factors, including project requirements, budget, timeline, expertise, and suitability.
Manual testing is a good choice for smaller projects without significant financial resources. The short-term cost is lower and, since manual tests are based on human reactions, they’re more likely to find real user issues. But there is also a certain incapacity of manual testing, which occurs in test cases that have frequent repetition. Furthermore, manual testing requires repetitive work.
Since humans tend to lose concentration quickly, it happens they overlook things that weren’t right. Automated testing is good to use in large projects that require regression, load, and performance testing or any repeated execution. Automation runs test cases significantly faster and can be used 24/7.
Automated testing is more suitable for regression testing because of frequent code changes and the ability to run the regression tests in a timely manner.
Writing tests that go through different user scenarios and letting a machine do user simulation for us might be more expensive and harder to implement in the beginning, but it’s worth the effort especially with a lot of testing ahead.
Automate the process of software development
In most projects, we use CI (Continuous Integration) tools that help us deliver software faster and more reliably. They reduce costs and the time necessary to merge the work of different developers in one project. It can also help us detect errors early prevent them from leaking to the production environment. Continuous Integration and unit tests run automatically whenever they detect incoming new changes.
How can testing help save money?
The clients are always concerned about the cost of writing tests, but what they should be worried about instead are the costs of NOT writing tests. Does it make your project’s TTM (Time To Market) longer? Yes, it does, but it also makes the product more reliable and valuable for its users. Fewer bugs are also part of the conversion rate which product owners aim for.
The center of every business is a satisfied customer. If the product is not reliable, you need to invest more money in fixing. The earlier the defect is found, the less development rework is required, which minimises the implementation cost. Software with good quality brings happy clients, customer retention, reputation and brand image.