1) Testers: you might be tempted to ask in public forums about how to address some problem that is making your testing harder, slower, or less valuable. Before you do that, make sure that you’ve reported a testability issue to your team. You’re quite possibly seeing actual bugs.
2) Reporting testability problems is SUPER important, because everybody is already working under uncertainty and time pressure. Usually they don’t grasp this: things that make testing harder or slower give bugs more time and more opportunities to survive undetected.
3) One of the most prominent time vampires in testing is, somewhat ironically, this: when you find a bug, you must take time to investigate it and report it. That takes time away from performing other tests. That is: shallower bugs actively inhibit deeper testing.
4) The bugs that you DO find tend to be the easiest bugs to find, almost by definition. (Almost; you might slip up and miss a shallow bug, or you might get lucky and find a deep bug earlier.) Deeper bugs tend to take time, effort, determination, skill, variation, etc., to find.
5) Thus, again, reporting on shallow bugs means that deeper bugs will elude us. But wait, there’s more. Setting up to test (including persuading your product and your tools to get along and play nicely) can suck up tons of time when the product isn’t intrinsically testable.
6) Intrinsic testability includes stuff like scriptable interfaces and log files. Those things vary in quality too. So you might have an API, but it’s hard to use, poorly or archaically documented, gives ambiguous error codes. Those bugs inhibit finding more important bugs.
7) You may have logging, but if it’s inconsistently implemented across components in your product, you might have some trouble merging logs from different components. Being able to do that could help with pinpointing bugs more quickly, saving time for more new tests.
8) Having trouble getting some tool to recognize on-screen elements in your Web app? (Let’s drop an antihistamine on my allergy to using tools at the human UI level for a moment.) Your product is probably unfriendly to screen readers for the vision-impaired; an accessibility bug.
9) Is testing or pinpointing bugs difficult at lower levels? Is your product (as @jamesmarcusbach colourfully says) a mess of spaghetti code, served in a sauce of confusion? Congratulations; you’ve got maintainability bugs on your hands. Those bugs will conceal and breed others.
10) Is it a tedious pain in the ass to get stuff done in the product? Is it annoying, frustrating, confusing to test? Huzzah! You’re probably looking at usability bugs. Does it behave inconsistently when you use it? When you drive it with tools? Probably reliabilty bugs there.
11) Now, here’s a political and psychological issue: many testers, especially new testers, are reluctant to report testability problems. Why? Because this stuff—especially automated GUI checking—is supposed to be easy. It must be! All the tool vendors say it is!
12) So many testers are nervous about reporting testability problems, because testing is supposed to be easy. “Anyone can find bugs! Why our users find bugs all the time! Why aren’t YOU finding those bugs?!” Answer: you were busy finding—or trying to find—other bugs.
13) This problem is often magnified by a manager who says stuff like “the team should figure it out” or “don’t come to me with problems; come to me with solutions”. This, to me, is evidence of a manager abdicating the first job of management: helping people to solve problems.
14) Problem reporting is the paramount focus for testers. Everyone else in the project is envisioning and achieving success. Our socially challenging job is to test—to challenge—the idea that everything is okay, and when it isn’t, to reveal that it isn’t. This is a tough job.
15) It is to some degree embarrassing to admit that we can’t solve every testing that comes our way. Yet often, it’s much harder and slower to do that without help from developers, managers, or other team members. Getting help usually has to start with asking for it.
16) Testability doesn’t happen by accident. Testability problems tend to go unnoticed until a tester points them out—which means that we must admit to having those problems. But those problems often redound to problems—actual bugs—for other people. Report those bugs!
17) Intrinsic testability—features or aspects of the product that making testing—isn’t all there is to *practical* testability. The risk gap—the difference between what we know and what we need to know—matters. The smaller the risk gap, the greater the *epistemic testability*.
18) If we have a clearer idea of what the customer wants, *value-related testability* is increased. When the project context is set up to make testing faster and easier, we’ve got better *project-related testability”. And better testers make for better *subjective testability*.
19) For more on the Rapid Software Testing take in testability, you can look here developsense.com/blog/2017/09/d… and here satisfice.com/download/heuri…
