Identifying Information Value in Testing

In a previous post, ref [1], I wanted to re-make the case for focusing (or re-frame) testing on information that was valuable to the stakeholder, customer and so, ultimately, of value to the business.

From a testing perspective trying to identify which information is important or valuable to a customer and/or stakeholder is difficult. This is complicated when there are several stakeholders involved - usually each with differing agendas and priorities. It can be complex when the customer isn’t visible or available for consultation.

Information that appears valuable to the tester might not appear valuable to a customer.

How to tackle these problems? One way is to make the needs (value) visible. This will help align needs of the stakeholder (and business) with the priorities of the tester and vice versa.

In many cases, this may happen organically via iterative correction, but there are risks that the priorities and needs of the business are not the same as the development organisation (teams and testing).

Therefore, to help me make some of the decision making, needs for decision making, and the value of those decisions to an organisation visible I tried to model aspects of identifying information value. A model for this is below.


A Decision Model: FICL
Decisions about which information to look for in a product (which ultimately dictates the testing goals) is helped by using the FICL model. This model is based on the work of Russo & Schoemaker, refs [2] & [3], and I use this model in many situations.

The FICL model (as I use it) is a combination of activities for Framing (F), Gathering Information (I), Coming to Consensus (C) and reflecting on lessons learnt (L). I explore some of the frames common to testers and teams in ref [4].

These elements can run serially or in parallel. Sometimes the information gathering is the first element, followed by framing to align and adjust. I would like to think that the learning aspect is always present - to reflect and update the other three aspects (which may iterate between framing, information gathering and consensus or information gathering and consensus).


Feature Walkthroughs
An important part of understanding aspects of the feature - which might be described at a high level use case - is to gather the team, with stakeholder and technical expert representatives - and walk through the feature.

There are many advantages of a feature walkthrough, including:-

• An early understanding of the feature development
• A common understanding of the feature development
• Overcoming the lack of available documentation
• Helping to highlight assumptions, implied and unwritten requirements
• Raising awareness about processes and strategies that live in the organisation rather than in a document (so called tacit knowledge).

Ref [6] gives an example of this feature walkthrough, which is partly based on the dialogue work of Göranzon [7] to help the organisation make tacit knowledge explicit. Collins, ref [8], gives a very good academic view on tacit and explicit knowledge.


A Model for Identifying Information Value

A Model for Identifying Information Value

An Example Application

Let’s take an example of a feature for prototype development and demonstration to a customer (could be internal or external). The feature will not go live and doesn’t need robust upgrade possibilities.

An Example for Identifying Information Value

Problems or Opportunities?
In some ways these activities put extra overheads on the business - there is a lot more work, discussion, questioning before the testing starts...

That is a perception. Actually, testing (which can comprise a significant part of a software development budget) is starting early, focusing and aligning its goals to those of the business.


Next
Something I want to explore is how a team (or tester) working with details during development handshakes or checks whether they are still contributing to business value. That is, how they answer the question, “how does this test idea add value to the business need?”

A more complex example is probably useful - at least to me.


Feedback
As I mentioned in the first post, ref [1], this is work in progress. Comments and questions are very welcome!

References
[1] Tester’s Headache: Mapping Information Value in Testing
[2] Decision Traps: The Ten Barriers to Brilliant Decision-Making and How to Overcome Them (Russo, Schoemaker, Fireside, 1990)
[3] Winning Decisions: Getting It Right First Time (Russo, Schoemaker; Crown Business, 2001)
[4] Tester’s Headache: Framing: Some Decision and Analysis Frames in Testing
[5] Agile Testing Days 2011: Experiences with Semi-Scripted Exploratory Testing
[6] Dialogue, Skill and Tacit Knowledge (Göranzon, Ennals, Hammeron; Wiley, 2005)
[7] Tacit and Explicit Knowledge (Collins; University of Chicago Press, 2010)