The highest optimisation of testing is “to not do it all” ! i.e. don’t execute test cases. What does this mean? Prevent not detect. And this is quite possible when we clearly delineate testing at various quality levels. And PDTs at lower levels like L1-L3 are more amenable to be prevented rather than only being detected. In case we want to evaluate this frequently as means of health check, then automate these to ensure basic health checks.
A change of view that the testing need not be limited to dynamic evaluation, but also be accomplished by static proving. That is, ascertaining correctness not only via execution of test cases but by thinking through what can happen with the data sets.That instead of commencing evaluation with conformance test cases, we start in the reverse with non-conforming data sets first. Prove that the system rejects bad inputs before we evaluate for conformance correctness. And instead of designing test cases for every entity, we use a potential defect type (PDT) catalog as a base to check for non-conformances first. Using PDT catalog as the base for non-conformance check preferably via static proving and devising entity specific positive data sets for conformance correctness.
So how do these views shift us to do better developer testing at an early stage? Well, the biggest shift is about doing less by being friction-less. To enable smooth evaluation by using PDT catalog to reduce design effort, applying static proving to think better and reduce/prevent defects rather that executing rotely, and finally focusing on issues (i.e PDTs) first complementing the typical ‘constructive mentality’ that we as developers have. Rather than do more with stricter process, let us loosen and simplify, to enable ‘friction-less evaluation’.