It is often said that to ensure you have great test coverage across your test suite, that you need to think of the bigger picture. Understanding how a bigger system works helps you understand its different dependencies, usage patterns of customers and context that leads to solid and more accurate test design. The problem is this is all wrong.
Yes, understanding the greater system does indeed help understand things better, but testing the bigger system is neither efficient nor most-quality approach to testing. Instead, what you should focus on in your testing strategy, is how the individual components of code are built and prioritise your testing efforts on this. Whether it be unit tests, component tests etc, the closer to the code you can test, the better it is for your overall solution. In this agile world, you would think we have moved past this, but the reality is that many people I speak to are still stuck with this mindset and not prepared to dive into their testing earlier on.
Why is this?
Well for a start. Testing a complete system requires too much testing effort happen at the end, once code is either complete or near completion, meaning that defects are only found late and testers land up in a crunch. You want to try and uncover defects as soon as possible and outside of requirements, which should always be scrutinized, the next best place to do this is the moment a developer submits their code. Good unit tests with solid coverage will help to increase your automation coverage, provide fast pipelines and most of all, reduce testing effort elsewhere. The truth is though that while many people might talk against the limitations of unit testing, thanks to the ability to mock surrounding applications, the vast majority of testing can be covered at an automated level here, including DB calls, deep rooted integrations and complex API calls. Even things like poorly optimised code are better tested at this level rather than running expensive and long-winded load tests later.
Before just testing though what really should happen when a tester focuses closer to the code is a better understanding of how the developer is designing their systems an helping to get the design right. Testing at a code level is an important way of allowing the system to be designed in a maintainable and testable manner because if something can not be easily locked or unit tested, chances are its too complicated a design to begin with and not easily automatable at a higher level either, so getting this right early helps.
Test closer to the code
It also allows you as a tester to work through different developer’s code, pick up inconsistencies and spot integration errors before its too late. You will be able to look at how different endpoints are shaped; designed and determine how they would cater for specific integration scenarios and security which will allow for a better and more consistent design of software throughout. Yes, there are certain tools and linting procedures that can assist with most of these, but they are not going to provide consistent and thorough coverage that will satisfy the need of many testing and security teams, so putting proper tests in place early, makes things even better.
And ideally, what all this does is prevent defects in the system design which is what we’re after. Testers shouldn’t be challenged or inspired to try find defects in the software when they receive the final product but look to build quality in and rather take satisfaction in seeing as little defects as possible. After all, the whole purpose of testing should be to assure quality and not find holes in it. Even automation is really about ensuring quality and we should take this mindset in how we approach everything we do.
So, as a tester if you constantly find yourself looking at the bigger picture and trying to design great tests to bring all the parts of your software system together, instead you might find you time better utilised if you spent more effort looking at the smaller systems independently. Yes you might spend more time early on in the design of the system, but a whole lot less later on and, most importantly, with very little crunch effort and need for lengthy regression cycles following defect fixes.
This doesn’t remove the need for solid integration testing and a decent manual check to make sure everything speaks together seamlessly but does mean that your software can be checked thoroughly with high-quality confidence achieved in a very short space of time and enable you to support and fix things directly into production quickly.