Today’s post is a quick reflection on 2 things that struck me whilst delivering this week’s training.
First, a quick background on the training I deliver: Attendees experience a 2 day workshop where they can try out Context Driven Testing techniques in a realistic project environment. As part of the training course, I have an application expert on standby (known as ‘The Oracle’) ready to conduct a system walkthrough. I don’t offer this information freely, but I do clearly state that he is available for support throughout the course.
In this week’s course, a team quickly identified they would like an application demo… but had put a big red line through it on their strategy mind map. I spotted this and asked them why. The conversation went like this:
First, a quick background on the training I deliver: Attendees experience a 2 day workshop where they can try out Context Driven Testing techniques in a realistic project environment. As part of the training course, I have an application expert on standby (known as ‘The Oracle’) ready to conduct a system walkthrough. I don’t offer this information freely, but I do clearly state that he is available for support throughout the course.
In this week’s course, a team quickly identified they would like an application demo… but had put a big red line through it on their strategy mind map. I spotted this and asked them why. The conversation went like this:
Team: “We need a demo, but obviously that’s not possible”
Me: “Is it not?”
Team: “No. We’re in training, so it’s not possible”
Me: “Are you sure? Maybe you should try asking”
Team: “Yes, maybe normally, but this is training so we can’t”
Me: “But if you wanted to know for sure, who would you ask?”
Team: “Well, you’re our stakeholder & trainer, so I guess you”
Me: “Yes, perfect. Good idea”
Team: “…. (Silence)”
Me: “so… “
Team: “…. (Silence)”
Me: “Are you going to ask me?”
Team: “Really? But there isn’t actually anyone available is there”
Me: “Are you asking me?”
Team: “Er, ok. Is there anyone who could provide us with a walkthrough?”
Me: “Great question! Yes, ‘The Oracle’ knows the system and could provide you with a walkthrough.
Team: “Oh OK Thanks”
(team move back to carry on with their analysis)
Me: “So are you going to contact him?”
Team: “But we have to test tomorrow, so he won’t be available to give us a demo in time, will he?”
Me: “Maybe if you give him enough notice. Why don’t you contact him now and find out”
(finally they did and the demo was quickly arranged)
There are two ‘learnings’ that really hit me from this, things which can hamper testers success:
1. We limit ourselves! Testers often impose or assume limitations that do not really exist. (To be fair, this is actually a ‘people’ issue and not specific to testers, but my experience this week has a testing context.) Because they were in a training course, they self-imposed a restriction on contacting the outside world… yet they had full network access and telephones. They had a great idea, which would help them deliver a better result, yet they came up with a reason why they couldn’t do it, instead of checking whether it was possible.. Worryingly I also see these limitations in real projects, especially where teams are in different locations. The most common objection raised to adopting CDT techniques is that “my project team won’t let me”. But when we speak to those project teams and present them with a logical reason for the change and discuss the benefits of it, they don’t object (even if they are naturally change-resistant) and actually support the improvements
2. Questioning Skills. There is often little value in only asking one level of question. It needs to be followed up with more questions to really clarify the detail, but from what I’ve seen, this follow up rarely happens. During the test analysis phase of my training I provide limited information to the attendees via a Business Requirements Document. In order to really understand what needs to be tested, the teams have to seek out a lot more information. Some of our testers are very good at identifying the right question to ask… but often the answer only gives them 50% of the information they actually need. Without more detail that 50% can be misleading. As testers we need to dig and make sure we truly *understand* the information we get. James Bach’s critical thinking Heuristic “Huh? Really? So?” is a fantastic aid to checking whether we fully understand the information we have.. Check out this video to find out more
_http://www.youtube.com/v/8TX6rzz60xQ
I’ve delivered the course many times and only 2 teams have asked, completely unprompted, whether ‘The Oracle’ can come to the training and give a product demo. Its skills, courage, confidence and determination (or perhaps you might call it ‘common sense’) like this that gives testing teams a good name.
Have you seen this restrictive behaviour hamper your projects? Can you share experience of improvements achieved by not limiting yourself with unnecessary restrictions? Would love to hear from you.
Me: “Is it not?”
Team: “No. We’re in training, so it’s not possible”
Me: “Are you sure? Maybe you should try asking”
Team: “Yes, maybe normally, but this is training so we can’t”
Me: “But if you wanted to know for sure, who would you ask?”
Team: “Well, you’re our stakeholder & trainer, so I guess you”
Me: “Yes, perfect. Good idea”
Team: “…. (Silence)”
Me: “so… “
Team: “…. (Silence)”
Me: “Are you going to ask me?”
Team: “Really? But there isn’t actually anyone available is there”
Me: “Are you asking me?”
Team: “Er, ok. Is there anyone who could provide us with a walkthrough?”
Me: “Great question! Yes, ‘The Oracle’ knows the system and could provide you with a walkthrough.
Team: “Oh OK Thanks”
(team move back to carry on with their analysis)
Me: “So are you going to contact him?”
Team: “But we have to test tomorrow, so he won’t be available to give us a demo in time, will he?”
Me: “Maybe if you give him enough notice. Why don’t you contact him now and find out”
(finally they did and the demo was quickly arranged)
There are two ‘learnings’ that really hit me from this, things which can hamper testers success:
1. We limit ourselves! Testers often impose or assume limitations that do not really exist. (To be fair, this is actually a ‘people’ issue and not specific to testers, but my experience this week has a testing context.) Because they were in a training course, they self-imposed a restriction on contacting the outside world… yet they had full network access and telephones. They had a great idea, which would help them deliver a better result, yet they came up with a reason why they couldn’t do it, instead of checking whether it was possible.. Worryingly I also see these limitations in real projects, especially where teams are in different locations. The most common objection raised to adopting CDT techniques is that “my project team won’t let me”. But when we speak to those project teams and present them with a logical reason for the change and discuss the benefits of it, they don’t object (even if they are naturally change-resistant) and actually support the improvements
2. Questioning Skills. There is often little value in only asking one level of question. It needs to be followed up with more questions to really clarify the detail, but from what I’ve seen, this follow up rarely happens. During the test analysis phase of my training I provide limited information to the attendees via a Business Requirements Document. In order to really understand what needs to be tested, the teams have to seek out a lot more information. Some of our testers are very good at identifying the right question to ask… but often the answer only gives them 50% of the information they actually need. Without more detail that 50% can be misleading. As testers we need to dig and make sure we truly *understand* the information we get. James Bach’s critical thinking Heuristic “Huh? Really? So?” is a fantastic aid to checking whether we fully understand the information we have.. Check out this video to find out more
_http://www.youtube.com/v/8TX6rzz60xQ
I’ve delivered the course many times and only 2 teams have asked, completely unprompted, whether ‘The Oracle’ can come to the training and give a product demo. Its skills, courage, confidence and determination (or perhaps you might call it ‘common sense’) like this that gives testing teams a good name.
Have you seen this restrictive behaviour hamper your projects? Can you share experience of improvements achieved by not limiting yourself with unnecessary restrictions? Would love to hear from you.
Recent Comments