It's an important thing for testers to revisit their definition of "what testing is about". Throughout this blog I have explored and revisited many facets of testing, and on the train today, I felt compelled to revisit this once again.
This is my current take on testing - it might change tomorrow, or next year, but it will change. It's not fallible, but not meant to be. It's designed to be a vision, that is readable and engaging.
The Mission Of Testing
The mission of testing is to seek out unexpected behaviour when a system is placed within differing scenarios, and to make both the quest and it's findings known to those who make decisions.
The prudent tester knows that as they are exploring the unknown, they can never know how much "unexpected behaviour" is left to discover, but can only estimate the risk based on what they know to work (or otherwise).
The Determination Of Scenario
The imaginative tester uses their skill to derive scenarios for testing from their understanding of the system through methods including - but not limited to - requirement, business value, standard expected behaviour or simple curiosity.
The Management Of Testing
The experienced tester knows that the time allocated for testing is finite whilst variations and imagination are almost infinite, and thus there are always more scenarios they can imagine than the time available.
Hence, they will always prioritise first the most compelling scenarios which are more representative or where there is great expected risk.
But the wisest of testers will make these choices transparent to all, both peer and those with the power to make decisions, and will encourage ownership and debate beyond those who call themselves testers. They will seek to incorporate such direction where it is valid, but champion and mentor when they feel it is inappropriate.
The Execution Of Testing
As the mission of testing is seeking the unexpected, and as they are trying to fit the infinite variation of scenario into a finite time-box, the visionary tester knows it is more important to use their time to explore as many scenarios as possible, and will seek to use any documentation for this activity which is as lightweight and unobtrusive in this pursuit as possible.
"and to make it known to those who make decisions."
ReplyDeleteMaybe. It might be to make it known to a programmer or a designer or a raft of other people who don't make decisions... unless those decisions are things like what code to write, in which case there isn't anyone in the company that doesn't make decisions. The marketing guy makes decisions about what to put on the website. Does he need to know? Maybe - you might be doing claims testing on the website contents.
Perhaps discovering who the test clients are is a part of the testing role - after all the information uncovered in testing is only useful when communicated to someone who cares about it. You need to know who needs to know what concerning the output of your report. Bugs to programmers, efficiency reports to project managers, coverage and perceived quality to both.
Just a thought.
All good points - and I tweaked that bit already based on a Twitter conversation (thanks Sunjeet).
DeleteIMO even a developer makes decisions - they decide to some extent, or else influence through reasoning, what defects and issues are worth resolving.
It's also a very tester thing, we want to simplify a definition, but also add a lot of caveats all over the place. Heck, I really wanted to just say, "The mission of testing is to seek out unexpected behaviour when a system is placed within differing scenarios", but the rest of the stuff wouldn't stop lol.