A good software tester will adopt a critical approach to their work and will probe the right parts of a system to find information they think might lead to a bug. They will turn over relevant rocks and use a sharp eye for clues that might lead to bugs. Sound familiar?
It seems to me that software testing and detective work have a lot in common, one involves searching for clues to evidence in order to convict dangerous criminals and the other involves searching for clues that could provide evidence of an important bug. A good tester, like a good detective, will be able to spot vulnerable parts of a program and isolate them under test just as a good detective is able to spot inconsistencies in a suspect’s story and probe with relevant questions.
Crucially, detectives and testers alike must search in the right places in order to do their job well. Its no use hashing over the same patch of ground or piece of code. Both must cover ground laterally and dig deeper when they come across something suspicious. But what are the right places to look for something suspicious? There is no one sure fire way to interface with bugs and different testing approaches may be equally relevant. Detective work and testing both afford the individual the freedom to investigate using the means they see fit.
No two programs are the same and nor are any two criminal investigations, hence why it’s important for practitioners of both to adopt varied, context sensitive approaches to working. You wouldn’t run cross browser tests before ensuring that the basic functionality of a site worked as it should. Failing to take account of context impacts workflow and results in fewer bugs being uncovered. The same no doubt is true of detective work.
It is the detective element of testing that makes it enjoyable and without it we would uncover less bugs.