Monday, 21 September 2015

Testing skills #2 - Influencing by listening

Having recently attended an excellent internal workshop on the' artistry of influence'.  One of the key takeaways I got from the course was to be able to influence you need to STOP and LISTEN to what the person is saying and most importantly how they are saying it.

During the course I discovered that when communicating we have a preference for using one of three types of senses, sound, sight and touch.  Which when converted into communication terms become auditory (sound), kinesthetics (touch) and visual (sight).

Do they use visual words such as 'see, bright, focus', kinesthetic 'feel, handle, hard' or Auditory 'hear, ring a bell, sound right'.

Once you uncover their prefer sense for communicating you can try and match their preferred sense.  This is called pacing and its roots can be found in our tendency to form tribes and groups based around similar traits.  This enabled us to survive as a group, since we shared similar habits and vocabulary.  It also encouraged strong relationships within the groups.

It is also useful to established the tonality of the person you are listening to.  Are they talking quickly, loudly, slowly or quietly? Ask a friend to help you practice by matching the voice tonality and their preferred sense.  By listening to others and the way they talk you can start to establish a rapport and build a relationship in which they can be influenced on a subconscious level.

Be careful when influencing others that it does not become more than just trying to persuade others of your thoughts and ideas.  If people feel or find out they are being manipulated then you will loose their respect and destroy any possibility of a working relationship.  The key aspect when trying to influence people is to ensure that they know it will have a positive benefit for them, even if at the same time you will gain a positive benefit.  The person you are trying to influence has to see a benefit in it for them.

It is not about YOU it is about THEM,

There is a lot more involved in using listening as an influencing tool and this is only an introduction.

Let me know how you get on with this tip on influencing by listening.

Further reading:




Thursday, 17 September 2015

It meets the business requirements

Recently I came across an interesting software requirements issue whilst eating out at a UK restaurant chain.

They had one of those common deals you can come across in similar chains.  You choose a main meal from a limited, but tasty, menu.  You get unlimited drinks of either tea/coffee or fizzy drinks. (soda) and you can have unlimited access to the salad bar .  To end your meal you get an ice cream sundae.  All of this for the sum of £9.99!

I was with my wife and we both ordered a main meal and a drink.  Whilst our meal was being prepared we went and selected our bowl of salad from the salad bar.  We set about eating our salad, during this time the drinks arrived followed by our main meal.  We only just managed to finish our main meal and was feeling rather full by now.  So when the waitress came over and asked if there was anything else we both said no can we skip the ice cream sundae and just get the bill.

The table was cleared away and the bill arrived......

Can you guess how much the bill came to?

If you are thinking the same as my wife and I you would think the bill would be £19.98.   The actual bill came to £20.13.  I queried this with the waitress and she replied....

"Oh, that is because you did not have the ice cream sundae!"

Our reply was "WHAT", We have less but it will cost us more?

The waitress was very confused and went to see her line manager. Who came over and explained that what they will need to do is order us the ice cream sundaes and then go and let the kitchens know that there is no need to make it.  They did say we could take it with us!  Ice cream, in car for hours & warm day  not a good combination.

All of the orders were taken on a mobile phone app which fed back to the main system and the kitchens.  There appears to be no option to be able to mark an order as one of the deals. Each item is entered individually.  Once you have the four items it now knows which are part of the deal and works out the price.  Now the question to those reading this..... "Is this a defect?"

From the business requirements perspective this is, I guess, what they wanted from the software.

Since entering each item one at a time and then working out if it is part of the deal allows them to manage stock control and keep business costs under control.  It has one less step for the operator to carry out rather than if they had to press a button to indicate it was a deal,

From the end user experience perspective it is flawed.  It appears they did not expect customers to decline something that was in reality free. From the staff working there they had to override the system and implement manual processes to enable the correct price to be calculated. At the same time this will upset the stock control reporting that they have two less ice cream sundaes than they actually do.

When we look at software requirements and we start testing these requirements, it is important we look at the implementation from all perspectives.  This is especially true for systems that businesses use to help facilitate customer service.  Get this wrong and it can leave a bad impression on the business customers.

Tuesday, 15 September 2015

Testing skills - Abductive Reasoning

This is the first in a series of hopefully short articles which looks at  skills and techniques outside the traditional testing that can be useful to those who practice testing.

Future topics planned include:

  • Influencing by listening
  • Note Taking
  • Leading teams
  • Persuasion and how to sell
  • Speaking the language of business 
  • Remote teaching experiential style
  • Going beyond the model
If you can think of any others that would be useful please leave a comment. 

I am making these public,  since by writing it down and making it public I am committing myself to do it.  That is your first tip in this article, if you want to commit to doing something which you keep putting off, writing it down and make it public.

Abductive Reasoning.

 Abduction came about from the work of Jo Reichert, in this work Reichertz came up with another cognitive logic process to describe discovery when the researcher encountered surprising findings in the data. He called this "a cognitive logic of discovery".  Before this there were two types of reasoning in common use, 'inductive' and 'deductive'.
  • Inductive - Making generalized conclusions from specific observations
  • Deductive - Proving or disproving a theory from observations (scientific method)
Abductive reasoning is an important process for those involved in testing.  The majority of time when we are testing we discover surprising behavior in the software.  This normally makes us rethink our theories of how the software works and as such we begin to re-evaluate our understanding of the software.  We create a new rule, or test idea to further investigate the surprising element of what we have just tested. This is key within grounded theory; our thoughts about the software and how it behaves change as we explore the software more.  How we report these surprises and the behavior of the software is crucial to the value that testers provide to a project.
"There are two strategies involved in abduction, both of which require creating the conditions in order for abductive reasoning to take place"* (Reichertz, 2007: 221). 
The first is a ‘self-induced emergency  situation’ (Reichertz, 2007: 221). This means that in the face of not knowing what to make of a surprising finding, rather than dwelling on the infinite number of  possibilities, the analyst puts pressure on themselves to act by committing to a single meaning.
The second strategy is completely antithetical to the first. It involves letting your mind wander without any specific goal in mind, or what Pierce (1931–1935), a key writer on abduction, called ‘musement’* (Reichertz, 2007: 221). "
Qualitative Research Methods in Psychology: From core to combined approaches - Nollaig Frost - 2011.
Reichertz makes the following observation about these two strategies.
"What these two quite antithetical strategies have in common is tricking the thinking patterns of the conscious mind in order to create ‘an attitude of preparedness to abandon old convictions and to seek new ones."
 The SAGE Handbook of Grounded Theory:(Sage Handbooks) - Antony Bryant, Kathy Charmaz  - 2010.
Testers need to be able to abandon their old convictions and seek out new ones.  This is especially important when we are testing software, since our biases and beliefs and previous experiences can influence our decision making. Using some of the methods described in this book can allow us to challenge our thinking about the software and engage in abductive reasoning.

One famous use of abductive reasoning is that used by the fictional detective Sherlock Holmes by Sir Arthur Conan Doyle.  Many people believe, wrongly, that Sherlock Holmes uses deductive reasoning to solve his cases, when in reality he used abductive reasoning.
"Holmes' method doesn't resemble deductive reasoning at all. Instead, it's much more similar to a form of reasoning known as "Abductive Reasoning"Debunking Sherlock Holmes Myths - Maiza Strange  May 2014
To summarise abductive reasoning is taking your best guess based upon your current knowledge, observations and experiments.  These pieces of information maybe incomplete but you use your cognitive reasoning processes to form a theory or conclusion.  For example:
"A medical diagnosis is an application of abductive reasoning: given this set of symptoms, what is the diagnosis that would best explain most of them? Likewise, when jurors hear evidence in a criminal case, they must consider whether the prosecution or the defense has the best explanation to cover all the points of evidence. While there may be no certainty about their verdict, since there may exist additional evidence that was not admitted in the case, they make their best guess based on what they know."Deductive, Inductive and Abductive Reasoning - Butte College.
This article has been taken from the Testing and the Social Science chapter in my book - The psychology of Software #Testing.


Tuesday, 11 August 2015

Volunteers needed for a FREE remote testing workshop concept

I am looking for two or three people to act as guinea pigs for a remote testing workshop concept I am working on.

The workshop will be FREE but require a couple hours of your time each week for about seven weeks.  I am hoping to start this workshop be the end of August 2015.

  • Ideally the participants will be fairly new to testing with less than two years experience. 
  • Able to work within UK timezone (Early evenings)
  • Willing to provide feedback about the workshop.
Why am I doing this?

I want to give back to the testing community, I understand it can be difficult for those new to testing to develop testing skills and techniques that they can apply directly to their work.  The concept of the workshop is that there will be series of self learning exercises and some challenges that they can apply to their testing in their current role.   Each week the group will get together using video conferencing to discuss what they learnt and share it with others in the group.

I currently have one volunteer and I am looking for 2 or 3 more, if you are interested then please reach out to me via twitter @steveo1967 and we can discuss in more detail.

**UPDATE - it is now full - please contact me via twitter if you are still interested and I can create a waiting list.**


Monday, 10 August 2015

Using Aspects of Lean Coffee to Drive a Retrospective



Those who have been following my blog may have noticed that I have not updated it as frequently as I normally would, or would like to.  There are been a variety of reasons for this, I am writing a book which is taking a lot of my spare writing time, I have not had much of interest to write about and finally over the past year my role within testing has changed to one of being a scrum master for agile teams.  It has been an exciting and challenging role which over time I may blog about.  It has been strange since people have commented that I appear to be a natural in this role and part of me thinks this could be due to my skills as a tester that helps in this role.  I am still trying to get involved in some testing and hopefully there will be opportunities for me to do this.

This post is about an experiment I attempted with a scrum team recently for the retrospective.  I am unsure if I obtained this approach from somewhere, or it was just an idea I came up with.  I have decided to share it  via my blog for others to see if they find it useful.

A common approach to retrospectives is to get the team together and discuss what they felt went well, what could they improve and to have some actions for the team.   The way I have run this in the past is we take each of these statements and get some feedback from each members individual perspective.   Some of the questions that can be used can be found here - http://www.benlinders.com/2013/which-questions-do-you-ask-in-retrospectives/

What I found was these retrospectives did not appear to be that engaging and after awhile became a little stale.  So I had an idea to change the dynamics by introducing a lean coffee (http://leancoffee.org/) format.  Lean Coffee is a structured but agenda less meeting, which consists of three steps:

(1) Set up a Personal Kanban

This basically means create a series of post-its to represent
  • What we are currently discussing, "In Progress"
  • What we have discussed "Done"
  • What actions have comes from the discussions "Actions"

(2)What to Discuss

This can be any topic  that you wish to discuss, for the first retrospective I ran in this way I used the following:

  • Shout outs
  • What was good.
  • What was Bad
  • Improvement Ideas

The first four were placed upon the wall and then I gave the team members a set of post-its and pens to write down their thoughts for each of these titles. One post-it per comment

Shout Outs:
Who do you know who went beyond their normal day to day work to help the team.  This could be someone within the team or outside our team who helped support the team.

What was good
What do you feel went well in the sprint.
What made you feel good about what the team did,


What was bad
What do you feel went wrong in the sprint
What made you feel bad about something in the sprint

Improvement Ideas
How can we improve what we do?
What ideas do you have to make the team better?

(3) Vote and Talk

Once we had done this everyone was encouraged to go up and look what others had written and at the same time we decided to group similar comments together. After this we had some cookies, always bring cookies to a retrospective, I moved the In progress post-it over to the 'shout outs' column and people started to explain what they have written,  It was interesting that it was someone outside our team that people felt had added value to the team.  From this we as a team sent an internal gift and a recognition for their work.

Once we had finished with the 'shout outs' we moved this column to 'done' and move the 'in progress 'sticky to the next column  'What was good', we followed the same approach and everyone had opportunities to discuss what had been written.  At the same time any actions that came from the discussions was added to the Actions post-it.  This approach was then done for the rest of the columns 'What was bad' and 'Improvement ideas'.

The dynamics of the team during these discussions was far greater than at any of the other retrospectives and I felt as a scrum master it worked really well to encourage the different members of the team to participate.  Part of being a scrum master is to keep the various ceremonies you have for the team 'fresh' and 'interesting' and in this case it appeared to work well.  Will it have the same affect the next time, I am unsure however it is one more tool I can use to help the team. Let me know of your approaches to keep the team motivated and encouraged.  Also if you try this approach let me know how it works for you and your teams.

In Lean coffee you would normally VOTE on the topics you are interested in using dot voting,

"Each participant gets two votes. You can vote twice for the same thing or for two different topics. Simple put a dot on the sticky you are interested in. Tally the dots. "

Update: I have run this approach a couple of times since the first trial and  it appears to work very well.  I have tried to prevent it from being too routine and have changed the questions that are posted.  I have used titles such as "What was positive about the sprint" , "What was negative" "If we could improve on one aspect what would it be".  It is important to create varieity in the retrospective even if you are using the same approach.  It helps to keep the team interested and motivated.  Cakes and cookies help too!

Friday, 19 June 2015

What drives us? Extrinsic and intrinsic motivation.

After recently presenting a workshop at the Lets Test conference on Self-Learning one of the concepts that people found difficult to grasp was the difference between extrinsic and intrinsic motivation.  It may be due to the time constraints of the workshop or I did not explain clearly enough.   Therefore I decided to put together this article to give a little more detail about extrinsic and intrinsic motivational factors. 

One psychology aspect of motivation is to work out what motivation factors are intrinsic and which are extrinsic.  To begin with it is useful to define what is meant by extrinsic and intrinsic.
"Extrinsic motivation is ‘external’: people – in this case athletes – are driven to succeed by factors from outside i.e. money, prizes, acclaim, status, praise." 
"Intrinsic motivation comes from within i.e. an athlete driven by a need to succeed because they want to be the best and are not overly concerned by financial or ego boosts."
The Sports Mind - Extrinsic vs Intrinsic motivation
Many people and organizations mistakenly assume that people are motivated and driven by financial rewards and to some extent they are.  People do want to be financially rewarded for doing work. In the majority of cases money works as a motivation factor for people to get out of bed to go to work and do the normal everyday tasks.

As Kamenica points out:
"It is helpful to distinguish those tasks that people certainly do not want to do unless they are paid for them from those that people may or may not engage in.” 
Behavioral Economics and Psychology of Incentives -Emir Kamenica - 2012
However there are studies which show that rewarding someone with money for something they have a passion for can demotivate and make them less effective. 
“...tangible rewards tend to have a substantially negative effect on intrinsic motivation (…) Even when tangible rewards are offered as indicators of good performance, they typically decrease intrinsic motivation for interesting activities.” 
A meta-analytic review of experiments examining the effects of extrinsic rewardson intrinsic motivation. Deci EL1, Koestner R, Ryan RM
Since extrinsic rewards form only a small part of what motivates people it is important to find out what makes people 'tick'  How can you set an environment that encourages peoples passion and motivates them to be the best. Providing people with opportunities to pursue their passion be it time to study or learn can have a positive impact on a team as long as others in the team are given similar opportunities.  The psychology of motivation is complex and what may motivate someone may not motivate someone else.

If you find something that is of interest you and you want to become passionate about it or if someone on your team is showing a passion for a certain activity it is worth focusing on the intrinsic motivation rather than the extrinsic.  It is also important to be aware of the over-justification effect
"The catch-22 of extrinsic motivation. The over-justification effect occurs when someone naturally has a passion (intrinsic motivation) to see something through, but is offered a reward for its completion. Thus rendering them less effective. For instance, if an employee loves writing on your corporate blog but you decide to financially compensate them for each post. There is a chance they will find the writing less enjoyable. Since they have to be bribed into writing, then the task must not be worth doing for its own sake." 
12 Psychology Concepts for Improving Employee Motivation -Bradley Gauthier - August 17,2011
One way to inspire individuals is by using unexpected rewards. Unexpected rewards can inspire and motivate people; the key is to not expect a reward. For example if someone has done something that you feel was outstanding offering to take them for lunch and paying or giving a small gift of appreciation can go a long way to keep them motivated.  One approach that can be useful when showing your appreciation for someone is to say how much you appreciate their hard work rather than how clever they were.  This makes people value the effort more than anything else. You can use this kind of reward system to encourage the right behavior but it is important to realize that there is a thin line between unexpected and expected rewards.
“Yes, sometimes rewards do work, especially if people really don’t want to do something. But when tasks are inherently interesting to us rewards can damage our motivation by undermining our natural talent for self-regulation."
How rewards can backfire and reduce motivation -Psyblog
When thinking about the testing you are performing it is worthwhile investigating the motivating factors.  If the testing you are carrying out a scripted approach then your motivation could be linked to extrinsic rewards rather than intrinsic rewards.   It is worth asking yourself the following about the testing you are performing:
"Is the task at hand routine?  That is, does accomplishing it require following a prescribed set of rules to a specified end?" 
Daniel Pink -Drive
For these types of tasks extrinsic rewards can work.  As a tester you should question if testing is really this type of task? Read the following questions:
  • -When you are performing testing activities what is it that drives you? 
  • What gives you the most joy and value to yourself in the testing you are doing? 
  • Is it the satisfaction you get internally from uncovering how the system is working or not working? 
  • Is it the ability to be autonomous in your exploring of the software?
  • Or is it something else that drives you to carry on with your investigations?

If you are nodding to any of these then maybe the testing you are performing is linked to your intrinsic motivation.   This is different from the feelings you may get if carrying out step by step test scripts.  

Daniel Pink sums up what intrinsic rewards means to the individual.
"It concerns itself less with the external rewards to which an activity leads and more with the inherent satisfaction of the activity itself."  
Daniel Pink -Drive 
As an added complication Carles Malet described three motivational forces in his article "Motivation from Maslow to PerezLopez".
  • Extrinsic motivation: when individuals act prompted by an external reward (or punishment), such as wages or improvements in the labor conditions.
  • Intrinsic motivation: linked to the satisfaction that individuals obtain when performing certain tasks. The intrinsic motivation is linked to the human need of learning.
  • Transcendent motivation: when the action is directed towards satisfying needs of other human beings. The transcendent motivation is linked to human generosity and the inner call for serving other human beings. Parents will recognize transcendent motivation patterns in their acting with their children, and so will do senior supervisors when empowering employees and charting their career plans.

Adding the third motivation factor is an interesting one since it plays on our human nature to want to help and support others.  This as the example explains is apparent in our nurturing instinct where we get satisfaction for helping our offspring.  In the software testing industry I have seen many examples of this with people providing their time freely to support and help others to learn, rather than being inwards and looking for their own learning opportunities.   People depending on the context will apply different weighting to each of these motivational forces and being able to understand and know which has more significance to individuals and to yourself can help drive your and others passion.


Some of this material has been taken from the next chapter of my book – The Psychology of Software Testing – Building passion, due for publication July 2015.

Friday, 22 May 2015

Technical and Non-Technical Testing Skills

One of the sessions at the Romanian testing conference in Cluj last week was a debate on do testers need to be technical or non-technical. It was an interesting debate and one which causes some great discussions.  One of the first observations was many of the people present were willing to come forward and present the case that testers need to be technical.  The framing of the definitions to me made it difficult to choose which side to present for, since no one had come forward for the non-technical side I put myself forward along with Richard Bradshaw (@friendly tester)  and a couple of other people,  unfortunately their names have escaped me.

The debate was set in the style of one side presented their argument the other side had a chance to reply and then present their side to the various statements that were shown on the screen.   It was a lively and interesting debate and I will keep to the end of this article to let you know which side was voted the most persuasive.

The reason for this article is the issue I have with labeling people as technical or non-technical as if one is better than the other.  I have come across disparaging remarks made against those who see themselves as being non-technical especially if they do not use a computer programming language.   There are the endless debates at conferences, on twitter, in testing forums in which people say you cannot be a tester without knowing how to write code in a programming language.  It is as if you are seen as a second class tester if you do not code or wish to code. Worryingly is this also being reflects in career prospects for testers with many roles requiring testers to become programmers and code. 

The’ testers should code’ debate has been discussed many times and on my blog I have written many articles about this very subject.  (http://steveo1967.blogspot.co.uk/2014/06/a-discussion-on-do-tester-really-need.htmlhttp://steveo1967.blogspot.co.uk/2012/11/testers-should-learn-code.html) However this to me detracts from the issue at hand and what is meant by being technical.  During the debate the argument I presented started with the concept that the word technical has different meanings and that it is dependent on context.   This during the debate was missing from the technical and non-technical statements presented on screen for the debate.  (I did not manage to capture the statements due to being involved in the debate).  One of the assumptions I reached during the debate was that to many a technical tester has one of the following skills:
  • SQL
  • Programming
  • Performance
  • Security
  • In depth knowledge of the system under test

With these skills the conclusion made was this enabled them to be a better, faster tester who could test the system far better than someone who was non-technical.  These could be good skills for a tester to have and I am sure that in some situations they have value, however they are not the only technical skills a tester could have.

I questioned this conclusion and asked what about those who understand the business, user behavior, the domain – for example finance and the ability to communicate and sell the benefit of testing.  I asked if these were classed as technical or non-technical.   Many said there were non-technical; I disagreed and stated in the right context each of these areas could be technical.  Understanding human behavior and being able to  work out how humans interact and what is their motivation can be a very technical skill. Understanding the value of something to the business and the reasoning why it needs to be done for the benefit of the company is a technical skill.  

In summary the reason for this article is that we in the testing profession need to resist being labeled as either technical or non-technical and simply state we are testers driven by context who apply the relevant skills for that context

For those wanting to know the debate was won by the non-technical side.

I would also like to thank the organizers of this conference for a wonderful and welcoming experience.  If you have never been to the Romanian Testing Conference try to come along and attend,  the participates were some of the most engaged testers I have come across at conferences.