Why We Test
Much has been written about software testing. There are examples and tutorials for every kind of software testing under the sun at the end of a Google search. Unit tests, Smoke tests, UI tests, workflow tests, Load tests, and Hydration tests, just to name but a few!
As Developers write code, they do local manual testing to ensure they have built the correct code. As the system delivers functionality, Developers, Testers, or Project Managers do manual workflow tests to see how the flow works and if it is what was desired.
Manual Testing
While this testing is essential and worthwhile, it quickly becomes costly – when a new feature is added, the manual testing has to repeat all of the earlier testings to ensure nothing got broken or removed by accident as well as ensuring the new features are correct. Manual testing at scale is problematic because people tend to start becoming blind to features they have tested many times before.
The goal is to start with manual testing because the ramp-up time is small, then begin automating tests so that the repetitive nature of the testing does not become too expensive and is more reliable.
Automated Testing
The automation of tests comes at a cost as well. Developers or testers have to spend time to write and validate the automation. Often, the cost of testing can equal or exceed the cost of actually writing the software.
Naysayers sometimes question the value of testing. Even testing proponents debate about how much testing is enough. Clients, who are footing the bill, may not understand the value of testing – after all, they want features!
So, why then, do we test?
Modern software is developed in an evolutionary manner – only essential features are built so that an early MVP can be used quickly to gauge the viability of new market space. The market feedback drives what new features will be added over time. Gone are the days of large monolithic specification documents. That, in itself, is a good thing, since specification documents were generally out of date before the ink dried. And legitimate changes are almost never backed into the specification. Specifications tended to be write-once, read-once.
To accommodate these two factors, testing is a necessity.
6 Reasons Testing Is Necessary
Reason 1: Only writing the code that is needed.
Because the requirements are evolving constantly, the development team should avoid building features that have not been asked for yet. Tests for each software unit and feature document what the unit or feature does.
Reason 2: Having a living specification that is guaranteed to be kept up to date.
If we write tests for each feature, we have a complete description of how the code works. This is a living specification of what the software actually does. (It is guaranteed to be correct since if you change the code and break an existing test, you must go back and fix the test or the code, whichever is incorrect.)
This is more valuable than a written specification that is generated before any code is written. Such a written specification describes what the software SHOULD do. The actual written software may do more or less than what is in the specification — which makes the specification misleading (or just plain wrong).
Reason 3: Fixing defects before they get into the codebase.
The easiest and most efficient time to find and fix a bug is in the minute right after you write the code. So having tests that identify the bug immediately after you write it (by accident, of course) is much more efficient than finding the error after it goes to production.
Reason 4: Protecting the codebase from accidental regression errors.
Often when adding new functionality to an existing system, you can unintentionally break a part of the code. These errors are insidious because they can remain hidden until a poor user runs into them in production. Tests that are run every time you do a build protect you and the codebase from these hidden errors.
Reason 5: Ramping up new Developers
Particularly when bringing an additional developer in to help with coding, or turning the codebase over to a support team of developers, written tests are a great resource to bring those people up to speed.
The tests ideally are at a higher level of abstraction than the actual code, and are “human” readable – this saves the developer from needing to read the entire codebase to find where individual capabilities of the system live.
Reason 6: Being kind to your future self
Imagine yourself six months from now. Why did you write a particular bit of code? What were the difficult parts of getting it correct?
If you have tests and you wrote them diligently, you can read the tests and understand why you did things.
And that is why we test
We test because it is an integral part of the development process and the ongoing documentation of the product. We test because we take pride in what we do, and in the understanding that software development is not a once and done activity – we know that the product will grow and evolve over time and that our future selves, or those that come after us, will appreciate the testing artifacts that we left as their roadmap.
Interested in consulting, development, or design on a project?
Let’s chat about your ideas!