Tibor Uittenbogaard | 06 dec 2018
This article is part of a series about the key elements of successful strategic development strategy.
What is test coverage?
With the term “test coverage” we are referring to automated tests: unit tests, functional tests, integration tests and possibly regression tests. When it comes to test coverage, there’s always a discussion. How much coverage is enough? Where does it end? In my opinion, those are the wrong questions.
The question I think you should ask is:
What is the purpose of test coverage?
To prevent you (or the team) from making the same mistake twice.
From a practical point of view: test coverage is always less than 100%. There’s no (humanly reasonable) way you can cover all code, use cases, systems compatibility and scenarios, not even if you only focus on the “happy flow”. And even if it were humanly possible to have 100% test coverage for all use cases, it wouldn’t be economically viable.
Therefore, tests should begin with providing coverage for key features and mission-critical components that are bug-sensitive and hard to test. And tests should from that point evolve, just like the project does. Automated tests should be practical and supportive – not a mission of its own.
Include test coverage to ensure maintainability and transferability
The reason why you should include test coverage as a default standard in your basic development toolkit is not only to ensure quality is maintained as the project continues development. Equally important is the maintainability of the project, and transferability of the project between developers, agencies and teams. For example when the project goes from the development team to a service team to be supported and maintained, or when new people that start working on the code, test coverage ensures they don’t need to know every detail and feature by heart - the tests ensure their blind spots are covered.
Furthermore, tests are also a form of documentation. Especially functional tests are very human-readable. Reading test scripts for example in Gherkin immediately gives you a pretty good insight into what the project does.
And again: the tests should evolve to provide more and more quality and quality assurance along the way. For every new insight, bug or feature, the developers should ask themselves if an automated test can prevent future bugs, and they should assess if a test shall have a level of added value that is equal to- or greater than the cost (time) of implementing the test.
A strategic development strategy does not only consists of lifecycle management and test coverage, but partnership is also an important factor. Which questions should you ask your development agency when developing built-to-last software solutions? Read the blog about Partnership here.