Automation. If we look at the “economics” of testing, the value of testing is in the number of test cycles that can be run and the speed of how quickly they can be run after a modification. If we can run the tests very often and really fast, essentially after every modification, the cost of creating the tests (and test automation) becomes largely irrelevant.

The reverse is true in “traditional testing”. Because that testing, unfortunately, relies on significant amounts of human labor, it is very expensive to run. Any test comprehensive test run will take countless of hours of human work, and will take significant amounts of calendar time. As a consequence, it makes economic sense to collect a larger set of modifications to test at the same time. Because of time constraints, the actual tests executed will be optimised to most likely areas of failure, resulting in increased risk of regression errors going undetected in areas of lower scrutiny. It also, obviously, means that for many features the testing comes much after the actual development, and therefore decreases the value gained. And, I won’t even go into how bad humans are in repetitive testing. I was a test manager at one point doing exactly this, because I didn’t know anything better.

So, because of high costs of test execution, the focus is on the cost of testing, and that consideration trumps most other concerns. But the focus should instead be in the value seek to deliver through testing, and optimising that (as is the Agile credo in general).

So, what is the value of testing? Testing (verification) allows us to confirm two things – the new thing we’ve built is working as intended, and that we have not introduced errors in other parts of the product. The more comprehensively we can do this, and the faster we can know the results, the better. Also, if we can do it after small amount of changes, it will be easier for us to understand the failures we’ve made and fix them (in large batches there may be dependencies between the bugs, and even bugs caused by other bugs in the system). Therefore, the more frequently and faster we can do this, the greater the value we gain from testing.

The only way to really drive these two factors is to remove humans as completely as possible from the execution of (verification) testing. We are slow, costly, and prone to testing errors. Therefore, as a strategy, all verification testing (and notice, this is different from validation) should be as automated as possible. Machines do testing fast, cheaply, and in a very predictable fashion. This way, ultimately, we can run comprehensive testing after every modification, as desired.

If we can do this, how we create the test automation and how much is costs, is of lesser importance. However, obviously, in a resource/time constrained environment, we will also want to be smart about that. This is where test-drive approaches come into play. The development should be driven by small increments that provide testable functionality. These are called e.g. “vertical slices” (e.g. user stories use this idea). Each modification is complete behavioral change through the system, with aligned modifications in all affected layers (UI, control, model, interfaces). The system can be compiled, tested, and deployed after each modification. Of course, each individual change is a very small behavioral change, but in aggregate they result in larger feature level changes in the product. As a part of each of these vertical changes, a test (or a set of tests) is created before the code level change, to understand and describe the behavioral change needed, and to be able to immediately confirm that the actual code modification is correctly implemented.

There is “art” to making this approach work, and if you’re unfamiliar with it, I recommend reaching out to experts and other resources (including AI these days) to learn it properly.

Note, as referenced above, this approach only applies to _verification_ part of testing, i.e. confirming that the system works, and keeps working, as specified/expected. The validation part of testing, i.e. critiquing the product and seeking to make it better, such as exploratory testing or usability testing, do not similarly benefit from automation. In fact, an argument can be made that validation is specifically a human activity, because the whole point is to discover new things (either bugs we haven’t even thought of, or new feature ideas to consider).

[All of the above assumes you want to do a good job with testing. If the quality of the testing is not relevant, there are easier and cheaper ways to “increase efficiency”.]