Blog

go back to the blog

Influence Diagrams vs Cause Effect Tables

  • 24/11/2014
  • 24414 Views
  • no comments
  • Posted by Emma
-->

The Influence of Friends

Every few months, a group of friends in the software testing industry meet for a weekend. We started doing this because we never got through all the discussions we wanted to have at conferences. I have found these weekends have been a really useful place to learn new concepts and to try out new ideas that I have had about the industry. They have influenced my thinking and my practice as a tester, test manager and quality manager.  The software testing retreat which I attend is not the only testing retreat, and it is not the only mixed social and work event around. They are happening in many places now, and I would recommend that you join one or start your own because it is a very agreeable way to meet your peer group, to learn from others, to be influenced and to influence, and to make friends in the industry.

In this article I am going to talk about a techniques introduced to me at a retreat, influence diagrams, and contrast it with a test technique that I have used for a much longer time.

 

Influence diagrams versus cause-effect diagrams

Use of cause-effect diagrams and tables is a test design technique taught and used by testers, so I think it will be useful to compare them with influence diagrams as they look a little similar. I have used cause effect tables and cause effect graphs for some time, as a useful technique for designing tests based on specifications. I started using influence diagrams in the last few years because of the influence of friends in the industry, at the retreat.

I have been managing a change programme over the last 4 years, in particular an improvement programme for the quality of products and services delivered by the company. Influence diagrams have helped me to analyse and understand human behaviour during the changes, especially to identify the reasons for unexpected setbacks and unexpected successes. In particular they help me to identify:

  • Vicious and virtuous circles: patterns of self-perpetuating and self-reinforcing behaviour;
  • Cusps or nodes that show activities that sit between vicious and virtuous circles where an individual or group might flip its behaviours from one to the other – need to be monitored;
  • Recommendations for the next area to improve;
  • Recommendations for activities to leave alone;
  • Things I had not thought about;
  • Key messages for senior managers and the MD about the change programme.

 

I’ll talk about this more and give examples in my EuroSTAR presentation in Dublin in November 2014.

 

Cause Effect Diagrams and Tables

So first let’s remind ourselves about cause-effect diagrams. Cause-effect diagrams and tables are used as a software testing technique. They show definite causal relationships. If the cause-effect diagram shows an arrow between two nodes in the diagram, then the cause will lead to the effect. If there is no arrow, there is no link. For example in a specification we might have the statement:

“If Bank-account-balance is less than 0.00 then charge overdraw-interest of 5%, unless there is an overdraft agreement in place in which case the interest is 2.5%.”

This statement tells us that it is absolutely certain that if the bank account is overdrawn (balance less than zero) then interest of 5% will be charged.

As testers we can examine the statement and start to challenge it by asking questions, and by drawing up cause effect diagrams and tables. We can ask the business analyst or product owner “is this what you really meant?”

NumberStatement1234
Cause 1Bank-account-balance is less than 0.00TrueTrueFalseFalse
Cause 2Overdraft agreement in placeTrueFalseTrueFalse

 

Once we have the diagram and table we can start to think about how the effects fit with the cause and we come to some conclusions:

  • The specification tells us that the interest rate of 5 % is charged if the account is overdraw and there is no overdraft agreement:
NumberStatement1234
Cause 1Bank-account-balance is less than 0.00TrueTrueFalseFalse
Cause 2Overdraft agreement in placeTrueFalseTrueFalse
Effect 1Charge interest of 5% TRUE  

 

  • We can draw that as

Isabel fig. 1

 

  • The specification tells us that the interest rate of 2.5 % is charged if the account is overdrawn and there is an overdraft limit:
NumberStatement1234
Cause 1Bank-account-balance is less than 0.00TrueTrueFalseFalse
Cause 2Overdraft agreement in placeTrueFalseTrueFalse
Effect 1Charge interest of 5% TRUE  
Effect 2Charge interest of 2.5%TRUE   
  • We can draw that as:

Isabel fig 2

  • The specification does not say it, but if the account is not overdrawn we’d expect that no interest is charged, therefore in any of the circumstances where the account is zero or more we would expect no interest to be charged :
NumberStatement1234
Cause 1Bank-account-balance is less than 0.00TrueTrueFalseFalse
Cause 2Overdraft agreement in placeTrueFalseTrueFalse
Effect 1Charge interest of 5% TRUE  
Effect 2Charge interest of 2.5%TRUE   
Effect 3Do not charge interest  TRUETRUE
  • We can draw that:

Isabel fig 3

  • We could reasonably assume that all the other outcomes are false (should not happen) but – if this was a real specification we’ want to check that, and we’d want to ask lots of questions for example “What interest rate is charged if there is an overdraft agreement but the customer exceeds that?” and “Do you really want to hard-code the interest rates in the system?”

 

NumberStatement1234
Cause 1Bank-account-balance is less than 0.00TrueTrueFalseFalse
Cause 2Overdraft agreement in placeTrueFalseTrueFalse
Effect 1Charge interest of 5%FALSETRUEFALSEFALSE
Effect 2Charge interest of 2.5%TRUEFALSEFALSEFALSE
Effect 3Do not charge interestFALSEFALSETRUETRUE

 

Our completed cause-effect diagram will look like this:

Isabel fig 4

Each arrow implies an absolutely certainty; this will or will not happen, 100% certainly, depending on the labelling of the arrow. If A happens B will happen. If A happens C will not happen.

We can now perform tests where we check that what we expect happens, and what we do not expect does not happen. This works well to analyse complex digital on/off true/false applications.

Influence Diagrams are Different…

Human and organisation behaviour is often analogue rather than digital – there are nuances. Things are not certain but have probabilities of occurrence. So in contrast to cause effect methods, influence diagrams are more subtle; there are nodes (circles) for potential causes and potential effects, but we do not have 100% certainty about what will happen. The arrows have an implied or actual probability associated with them; if A happens B is more likely to happen, if A happens C is less likely to happen. Because influence diagrams have this subtlety we can use them to model activities where we do not have certainty: human interactions, group behaviour, human reaction to process, and similar.

Let’s examine the “Customer overdraws” problem in a slightly different way. The specification and cause-effect work above show us what we expect the IT systems at the bank to do. With an influence diagram we can start to look at the effect on the customer and on bank employees of implementing and enforcing the overdraft processing.

The influence diagram allows us to be broader in what we describe. I am still going to keep this simple – almost cartoon-like – but in reality we could add as much complexity as we wanted.

Think about the bank account. Suppose we ask “what would make customers angry about their accounts?” We can imagine a situation where the customer overdraws the account. The overdraft charges start on the account, so when the customer sees their statement, they find they have been charged. This makes them angry, and they contact the bank and shout at a member of staff.  This might or might not happen, but we can make a diagram to help us think about and discuss why they are angry, what else might happen, how to prevent any problems, and so on.

Isabel fig 5

Next we ask “why did that happen?” And we start to add things to the diagram that show the reasons why the customer was angry:

Isabel fig 6

But surely the customer must know the deal? They terms and conditions say that they will be charged if they overdraw. Now imagine that the customer overdraws, and does not realise this. In fact, the customer believes that they have not overdrawn, because their salary was due into the account that day. However, the bank has processed the debit before the credit.

Isabel fig 7

We can add other influences into the diagram. What else makes a customer angry? Suppose the customer gets slow service when they contact the bank – for example being held in a long phone queue – this will be likely to make them angrier. They might also get angry if the account is only overdrawn for a tiny amount of time but they are charged for a fixed length of time. If they do not realise in time that they have overdrawn, and if they do not realise that the interest and other charges will run for a fixed period, their bank balance may continue to drop more than they expected, leading to another dip into overdraft the following month. This causes us to redraw the influence diagram. The new influence diagram below is very simplified but we can see that as well as asking the IT system oriented questions that the cause effect diagram makes us think about, drawing the diagram helps us start to ask questions, formulate tests and suggest improvements around:

  • Processes and procedures such alerting customers to their balance
  • Terms and conditions for the bank account and overdraft
  • Customer touch points such as the customer help line, queueing on the phone or in the branch
  • IT systems processing order affecting outcomes for the customer
  • Potential vicious circles where the bank and customer need to change how they interact.

Isabel fig 8

 

Summary

In this article I have shown how a cause effect table and graph can be used to analyse a specification where the links between cause and effect are certain. In contrast, an influence diagram can be used to analyse possible behaviour and possible influences on behaviour by circumstances, systems or people, and is helpful to us for thinking about “What if?” questions. In an influence diagram the links between the nodes do not show certainties but possibilities.

Both techniques are useful, they complement each other and used together widen the scope of what we consider when testing. Not just the IT system but also the business processes.   Not just the business process but also customer touch points. Not just the digital and certain but the analogue, human and uncertain.

My talk for EuroSTAR Online, in September 2014 showed how to draw an influence diagram and discuss ways in which they are useful. At the EuroSTAR Dublin Conference in November, I will discuss the change programme and as part show some of the influence diagrams I used during the change programme itself. Isabel’s will present a keynote talk on Restore to Factory Settings: What to Do When a Change Programme Goes Wrong. 

References

 

Author: Isabel Evans

Isabel EvansIsabel Evans has nearly thirty years of experience in the IT industry, mainly in quality management and testing in the financial, communications, and software sectors. Her areas of expertise are software quality management, software testing, teamwork, and training. Since the mid-1980s, her quality management work has focused on encouraging IT teams and customers to work together, delivering results via flexible, customer-focused, risk- and test-driven processes designed and tailored by the teams that will use them.

Her work for the BCS SIGiST Standards Working Party focused on quality attributes, especially usability.

Isabel is a popular speaker at software quality conferences worldwide and has been a member of several working groups for industry improvement. Her publications include the book “Achieving Software Quality Through Teamwork” and Chapters in “Agile Testing: How to Succeed in an eXtreme Testing Environment”; “The Testing Practitioner” and “Foundations of Software Testing”.

Isabel is a Chartered IT Professional and a Fellow of the British Computer Society.

 

Blog post by

go back to the blog

Emma

Emma has been working for EuroSTAR since 2012. She looks after EuroSTAR Social Media, helps the online team out with content etc. and also helps the Expo team looking after sponsors and helping them get ready for the conference!

Leave your blog link in the comments below.

EuroSTAR In Pictures

View image gallery