3D model for testing contexts

If software testing is solely about finding bugs, I would do nothing else to hack, break and attack the solution. In one context the testers job is to “positively destroy” the solution. Taking this to the extreme – this contradicts with the shared purpose to deliver value to some one“. If the context require that the tester is not allowed to report errors (#bad, but it happens) – that contexts is also not good taking to the extreme. If the acceptance criteria is that X severity bugs can be released, gaming the play will leads us not to look for them.  Where does your team score on the Bug hunters dimension

Mission: Break the solution
Mission: Confirm solution

In a Rapid Software Testing situation, testing is on the spot, with the given information at hand within a short time frame. I could imagine that a lot of mobile app development projects have very few formal/informal tests besides: “Does it work – then ship it“. Enterprise settings and medical systems need a higher degree of conformity to contracts, standards, certifications and FDA approvals. Where does your context score on the Exercise dimension:

Mission: Skipping
Mission: Deep-dive

A lot of testing contexts have the job to verify the solution. Given so and so requirements, so and so predefined charters, testcases, scripts … verify that the thing works as predicted. To solve this problem brawn is usually enough, tasks are broken down and systematically applied (machine checking). On the other end of the scale is a more learning context, where sapient tests trigger exploration based on brains. Where does your context score on the Thinking dimension

Mission: Prepared
Mission: Explored

When you start considering these dimensions it’s easier for you to get to the what, the where, the whom and how much. In some contexts the sliders are not easily moved. But even so consider to apply a bit of the dimensions in the various phases of your software testing – scoot over the application in “gold master testing” and snow plow testing. Verify and learn, test and check, break and confirm.

[ Rob Lambert | Thanks for the information, I’ll make up my own mind though ]

As professional skeptics we need to make up our own minds and come to our own conclusions. That should be done using any supporting material we can, but ultimately from our own information, decisions and activities

Please make your own model – what 3 dimensions characterizes the testing in your context? 

See also:

• What if – and Does it Matter
• Testing can add business value to any project state
• Softwaretesting is only dead, if it stands still

• Black or white – it is the same box