Particularly for legacy software, automated tests aren’t very common, even though these projects usually would need them the most. Testing can be annoying for some developers, especially if one is not used to the process. Rest assured, automated testing is a worthwhile effort: it can save a project in the long-run (ergo you stay employed) and indirectly ensure a positive work atmosphere (ergo you stay happy). This article compiles a comprehensible list of why you should use Test Automation whenever possible, ideally from the start of a project.
1.) Manual Tests are error-prone & resource-intensive
When resorting to manual testing, you require competent staff to do the testing. But not only does this staff have to exist, it also need to know what the system does, what needs to be tested, what the use cases and edge cases are (and so on). Detailed test instructions and extensive knowledge about an application itself are required to make manual tests be reproducible.
Testers are human beings and human beings are prone to make errors as well.
A well-designed automated test spares human resources and is reproducible at all times. Only the person who writes these tests needs detailed test instructions or requirement knowledge to design them. Compare this to to the X amount of (future) testers that you need to introduce, coordinate, document and supervise when testing manually.
2.) Writing Automated Tests helps writing Clean Code
Particularly, writing automated unit tests or employing test-driven-development techniques force developers to write code that is testable.
A good automated test does not need extensive use of mocking frameworks. If too many units of one system have to be mocked, it’s an indication its source code is not sticking to single responsibility principles and therefore is hard to test or worse, completely untestable. Testable code is divided into many small, reusable chunks of logic, e.g. via fine granulation of modules or classes. When a system is still young, this may appear unnecessarily clunky or bloated at first: after all, e.g. creating four classes for a single feature can be a little annoying. But as it system grows, it ensures maintainability and modularity. Many small classes can be reconfigured to work in a different setup more easily than one large behemoth class that first has to be refactored tediously. The long-term benefits outweigh the annoyances in this case. Plus, one can make use of UML and code generation to mitigate these initial problems.
3.) Automated Tests help document the System
Even if no documentation for an automated test (or worse, entire system) is available, it can be be still derived from a well-written test. In this case, the test itself is the test protocol (although in an ideal world, it shouldn’t replace documentation). In mathematical terms, if a system has a function f(x), a test is its inverse function f^-1(x), similar to how we can double check the product of two numbers (multiplication) via its inverse function (division). This circumstance in itself indirectly documents the functionality of a system. An automated unit, integration, or end-to-end test, even if it ceases to work for whatever reason, as long as the requirements didn’t change, it can be used as directive for a manual test.
4.) Implementing Automated Tests ensures Clarity
As developers implement tests that make sense for a new requirement, they have to consider potential edge cases, error handling and a set of well-defined errors, warnings or messages returned as feedback. These details will be used in the tests as guidelines to test against. If any affect security, third party systems or other vital business logic, questions about the implementation in detail will arise. Ideally, developers approach and discuss these cases with the appropriate expert (for backend: architects, engineers, security experts; for frontend: requirement analysts, UI/UX Designers or the clients themselves). This process is inherent in test automation and helps refine requirements further towards a feasible optimum. Documenting these details ensures clarity and avoids confusion.
5.) Automated Tests ensure Software longevity
Last but not least, both the documentation and requirements analysis efforts that are necessary to create automated tests and the automated tests themselves avoid software death in the long-run. A lot of software has a hard limit on how much it can grow and how complex it can become. Some relevant factors are e.g. available staff, staff competence, hardware resources, quality assurance methods and business/development processes that are currently in place.
Some software will reach that hard limit much faster than other, depending on presence or severity of aforementioned factors. High quality software grows slowly in the beginning, but in the long run will outpace and outlive software that was developed quickly and sloppily. In a worst case, development speed of low quality software converges to zero. A festering unhappiness follows with frustrated developers desperately trying to keep up implementing features in a system that simply won’t let them implement features in adequate speed, while customer requirements and expectations continue to grow. Stress and pressure can burn out your staff and the resulting work atmosphere can tear entire teams apart.
Another important aspect is that legacy code that is not always testable and can be rather inflexible. Adding tests in such advanced projects can be impossibly difficult and the won’t yield the same benefits than they would have had if test automation processes were present from the start. I’d even go so far as to say that the effort can be so high that one should consider to scratch efforts for test automation for such legacy projects altogether and instead refocus time and energy on the rewriting the whole application with test automation. In my opinion, just writing tests for legacy software for the sole reason e.g. to adhere to newly introduced company guidelines is pointless either and a waste of valuable team resources, when those resources could be used elsewhere with higher efficiency. Writing automated tests is a team effort and should be practiced from the start for the largest benefit.
I hope this article illustrates how even implementing a minimum of automated tests will help with the software development process. But… What happens if you do not test Software automatically from the start?
Further Reading
If you wish to dive further into this subject matter of software quality, feel free to check out the following books:
- Clean Code – Robert C. Martin, ISBN 978-3826655487
- Refactoring – Martin Fowler, ISBN 978-0201485677