When I talk about testing I tend to talk about information. For me, testing is all about information. Information that helps decision makers make decisions, and information that informs risk. How we identify that information depends on the type of information we need, and to know that we can do several things… identify risk, ask questions, user research, analyse specifications, find out what’s important to those who matter; the list goes on.
Only recently have I actually thought about this as a model. So I thought I’d spend some time visualising it (something that helps me think deeper about a subject).
What testing means to me at a high-level:
If testing wasn’t all about information, then it would be all about risk (generally speaking). So first up I like to talk about risk and risk identification. Testers (for the most part) are good at that. We tend to come with varied backgrounds; business, tech, users, and so-on. So we can view a product with many different lenses which provides greater risk identification coverage.
Then I move to the information required in order to understand and potentially mitigate the risk. The information we seek depends on the risk we’re trying to understand, as does how we seek and identify it.
Let’s visualise that part:
I then like to talk about gathering and reporting the information. Test reporting can be very painful, or it can be a breeze. Which one it ends up being not only depends on your stakeholders, but also on how you gather the information while testing. If you don’t record your testing (screen captures, notes, etc.) then how are you going to gather the information you need to report? Pass and fail? Whatever… realistically that means nothing. You need to work out what your stakeholders need (or in the real world, what they want) to see, and then gather the information in a way that translates as easy as possible to it. You may have a project sponsor that totally gets what you’re doing and completely trusts you, and so doesn’t need to see anything… but lurking in the background is the internal audit team who need to see EVERYTHING! So I like to include that when I talk about testing as it can make your break your entire effort (rightly or wrongly).
Thoughts? Feedback is always welcome.
Peace…
Martial Tester 
Hi,
Thanks for sharing!
IMO, 1st is not identify risks. Without information provided by tests, it’s impossible to identify it confidently. “Predict risks” is good to start, which is important for test design.
For information part, as well, I suggest to change the order of gather and identify, like seek gather and identify.
Just my personal opinion…
Thanks for your comment and feedback Kevin.
I’m not sure I see the ultimate difference between ‘identify risk’ and ‘predict risk’. A risk is something that may happen in the future so when you’re identifying risk in essence you’re predicting it. Can you clarify for me?
I completely agree that we can adjust as we identify information from our testing, in fact I think we most definitely should, however you need a starting point. In my experience this is often a point in time where the product is not yet available to test and so questioning while identifying risk helps me to focus my attention when I do finally get my hands on the product.
In regards to your second point, I prefer the order seek -> identify -> gather as I don’t want to gather all of the information unless I need it. While too much information is often better than not enough, I always look to reduce waste wherever possible and gathering unnecessary information has been wasteful for me in the past. However, I can see you’re point (at least I think it’s your point)… if we gather all the information we may be able to use it to identify certain patterns of product bahaviour that we couldn’t have otherwise. So again, thank you.
Pingback: Testing Bits – 7/10/16 – 7/16/16 | Testing Curator Blog