Thursday, 31 January 2013

Book Frames and Threads - Jan 2013 Update

This is an update to the map I use to track some of the book and reference material influences.

Changes since the last edition, ref [1], are marked in dark grey. Some changes I've put in this version:

  • Some online resources included
  • A re-use indication (books/texts that I refer back to are in larger font - the font isn't proportional to its popularity, but maybe for the next update)
  • Some author references are included
  • Some articles are referenced - but I'm aware that many are not included
This map will be printed out (to replace the previous version) on an A3 sheet by my desk. It sometimes generates curiosity and questions - which is then a useful medium for discussion about testing, and the many many influences from outside of software development.

Any recommendations for additions - whether books, publications or format?

References

Map


Saturday, 5 January 2013

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)

Wednesday, 2 January 2013

A Test Strategy

Test strategies are in one sense personal - all testers should have one, or be able to relate to one. Testers should be able to identify one, or identify components that make a test strategy important to them.

I am currently re-evaluating a test strategy and writing this down with appropriate influences, partly to document a work-in-progress and partly to aid reflection and feedback.

The strategy communication (which is different from the strategy) is simplified as a mind map below - with all the usual restrictions with mind maps, simplifications and presentations.

Test Strategy Representation



Question
Do you have a personalized or adapted test strategy?

Feedback
Feedback, comments and questions are very welcome.

Some References:
[] Satisfice: RST: CRUSSPIC STMPL
[] Kaner: General Test Design references
[] Tester's Headache: Mapping Information Value of Testing
[] Tester's Headache: Framing: Some Decision and Analysis Frames in Testing
[] Tester's Headache: The Documented Process Trap
[] Tester's Headache: The Linear Filter Trap
[] Tester's Headache: Silent Evidence in Testing
[] Tester's Headache: Challenges with Communicating Models II
[] Tester's Headache: Challenges with Communicating Models III