I was taking a look at some documentation last week. It listed a bunch of quality initiatives and said what each of them ensured.
Ensured.
I had to stop and take a deep breath.
Several deep breaths.
And a brisk walk around the block.
I am triggered by wording like this. When someone says they've done some kind of testing, all that it ensures, assuming we can believe them, is that they've done something that they call that kind of testing.
Literally, that's it.
Setting some thresholds for a static analysis tool doesn't ensure quality. It ensures that the tool, when it is run, will look for certain kinds of patterns, in the code that it sees, and alert when a certain level of positive matches are found. The rules it uses may or may not conform to our idea of what quality means and, even if they do, there are likely bugs in either our thinking or the tool.
Configuring a traditional pull request workflow doesn't ensure quality. It ensures that there are blockers to code being committed that require someone, usually not the person asking to merge their changes, to push a button. What the button-pusher does before pushing the button is up to them, and whether it aligns with whatever anyone else thinks of as quality, regardless of team conventions, is an open question.
Even an activity as dear to my heart as exploratory testing doesn't ensure quality. The testing mission might be well-motivated, have great prioritisation of risks to investigate, and be carried out by a skilled practitioner using helpful tooling on a product which is extremely testable. But it can still miss important issues. Issues that people who matter would regard as quality concerns.
Doing some kind of testing ensures nothing except that some kind of testing was done.
Image: https://flic.kr/p/7QZekd
P.S. I had a chat with the author of the document and explained my position on this. Ironically, it ensures that he now knows how to make my eyelid twitch in any conversation around testing.
Comments
Post a Comment