## Testing cannot be complete or perfect 100% coverage with testing is not feasible, even if you automate tests. Complete testing isn't part of the main goal of testing. The main goal is to to find useful information for our stakeholders, in a structured way. Risk is the driver to find this useful information. If you don't see (a lot of) risk somewhere, then testing that bit is going to be a waste of your time. ## Testing cannot assert quality > [!NOTE] A quote by Michael Bolton (saw this on LinkedIn): > Testing is not a part of quality at all. Not a small part, not a tiny part. > > Quality isn't a thing. It doesn't have parts. Quality is a set of relationships between a product and some person(s) who matters, and how to they ascribe value to things about the product. > > Testing isn't part of that set of relationships. Testing is a means of observing and assessing quality. That doesn't make it a part of quality. > > Diagnosis is a means of observing and assessing health, but it's not a part of health. Investigative journalism is a means of observing and assessing government ethics and efficiency, but it's not a part of government ethics and efficiency. > > Testing IS a part of responsible *development work*. Testing is part of *producing* something of quality, of value to some person. Testing can be not only a small part of that, but a big part; should be, to my mind. > > To say that testing is part of quality, though, is to sow confusion, I believe. There are no guarantees. Testing can find problems, but never prove the absence of problems. We'll gather information about the state of the application, but testing on its own does not change or assert anything. Only actions, based on what was found, will cause change. Testing as activity is only half of the loop, deciding what to do with it closes the loop. Speaking of the dreaded word: [[What is quality]]? ## Testing will not find all the issues You can't test what you don't know. There will always be unknown unknowns, even if a very experienced tester is on board. This is because no one is free of biases, everyone has gaps in their knowledge, and not all risk can be eliminated. With [[exploratory testing]], we'll purposefully go into the unknown territory, but this cannot be done perfectly (see the first limitation of testing: it cannot be complete). ## Testing isn't free of biases "Who tests the tester?". Common wisdom is that a developer can't test their own work, but a tester is also a fallible human. Thinking that automation solves this problem is also wrong, the biases will just be embedded in code. To deal with this, an option is to get more people doing test activities. An experienced tester can coach other people to do effective testing. There might be fewer blind spots and more problems uncovered by letting more people test, but again: no guarantees. By the way, [[developers can test their own work.]] ## Testing shouldn't sign-off on releases Testing should inform, but not decide whether a release is too risky or not. This is a business decision. We, as testers, *inform* the business about the problems we found while testing, and they can decide whether the risk of releasing is worth it. We can *advice*, but stay clear of deciding. When you sign off as a tester on a release you open yourself up to a political blame game in case something goes wrong. Important books that deal with this topic: [[Perfect Software and Other Illusions about Testing]] [[Thinking, Fast and Slow]]