thoughts from the test eye

Nice!
However, I have a question:
* Isn’t it a problem including the words “that matter” when those words are a sub-part of what is important? I.e. “that matter” is as undefined as “important”.
Or should it be clarified that it matters to someone?

My twist:
“The more you learn about the specific context and what matters to its/the stakeholders, the better suited you are to find and select significant quality-related information that is of greater value than other.”

Thanks for the improvements!
It is tricky: matters/important are impossible to define (?), and we’re close to getting into the endless what is quality discussions.
I guess importance is both wider and more narrow than quality:
* not only quality is important
* all sorts of quality is not important

What is important is difficult concept. As testers we should focus us on what is most important or what matters the most. If it is less important than something that matters more, then we do what is more important first. Knowing that we can only do so many tests, we should not bother with those that do not matter or those that have no importance.

Still, all these facts are as far as we know and at a certain time. Everything changes!

So, I do not think matter/important is a binary value, instead more of a scale. Perhaps matter/importance are the tools in how we find what is valuable.

Whether it’s “what is important” or “what is it that matters now” – I’ve been thinking for the last few months in terms of decision and analysis frames.

What is important to me (or a stakeholder) is probably impacted by the frame (filter) by which I’m deciding it’s importance. Those frames have their limitations – so being aware of them (or trying) is the first step to understanding if the reason I select something is correct – or good enough.

Decision and analysis frames are subject to a range of cognitive biases – just like other thinking (typically anchoring and availability are common in frame choice) – so having an insight to your own and your stakeholder’s decision frame can help understand if it’s a ‘good enough’ frame, or what limitations it might have.

BTW, for decision and analysis this is part of my latest favourite heuristic – FICL (‘fickle’ in English = ostadig på svenska). F: Framing, I: Information gathering, C: Consensus, L: Lessons – I haven’t written about this fully yet, but the part about decision and analysis frames is here.

So, a take on ‘what is important’ might be

“The more you learn about the decision frames involved in considering what is important the better the understanding of what is good-enough just now, and also how those decisions/ratings are might not be good-enough, from both your own and your stakeholder’s perspective.”

Food for thought Simon, thanks.
I am not fully into frames yet.
I’m looking for what is inside the frame, the subjective “truths”.
But when reading your comment I understand that the frame in itself contains important views, so I guess what is important can be found in both the content, and how it is presented.

I can’t come further (right now) than “you need a variety of information sources, framed by stakeholders; you need your appropriate heuristics, that together with experience, collaboration and exploration, can guide to test what is important about the software.”
Not an easy sell…

Good points, Martin.
Nothing human is binary?

At the same time we don’t want to spend too much time comparing importance (hence the concept testworthy.)

Are we getting help from the words important/matter/value/quality?

Importance is quality to some person.

I may be too simplistic here but what is important isn’t the user and the mission the software was made for?

Aren’t tests made to assure the quality of the software so it does what the user expects it to do?

So the tester must have a profound knowledge of the software its domain and how the user is/will be using the software. Then everything that prevents the user to achieve the tasks he’s suppose to do in the software under testing is important. As the software may allow different tasks the order of importance may be the importance of the tasks the software was built to assist the user.

José, you’re absolutely right in theory, but it doesn’t work in practice.
We don’t know in advance all about what the users will do, feel, need, and in which environment.
And even if we did, the total combinations would be too much to cover with tests.

Understanding what users need (not only what they want) is a start.
But we should take other angles as well, because they can give insights, and results in faster ways.
By looking at requirements, we see what others believe is important.
By thinking about failure modes we find problematic areas.
By understanding which quality characteristics matter, we get ongoing test ideas almost for free.
With models we understand the system; using a white-box perspective can find problems that are fast to address.
Fears, rumors, risks and debt light the testing way.
The product’s history shows what tend to be problematic, and important.
Thorough knowledge about the business, or the technologies, help us test common, problematic, important things.
It helps if you know how competitors behave, which standards are applicable, or if there are legal aspects.
An analysis of the context guide you to places where testing provides most value.
Collaborative conversations take you further.

The list is not complete, and it’s the holistic merge that make us understand what is important, in many situations.
Skilled software testers are champions at finding shortcuts to test what is important.