Testing skills #4 - Note taking

 Why is note taking an important testing skill?

There are a variety of ways to capture the evidence of our testing but if are notes are not of suitable detail then the value of our testing can be diminished.  Taking notes enables us to improve our knowledge and reinforces our understanding of the product being tested. This is part of utilizing critical thinking skills which was discussed in the chapter on 'critical thinking'

Robert Lambert discusses the need to have good note taking skills when performing exploratory testing

"During a session a good exploratory tester will often narrate the process; all the time making notes, observations and documenting the journey through the product. This level of note taking allows the tester to recall cause and effect, questions to ask and clues to follow up in further sessions." 

Explaining Exploratory testing relies on good notes - Robert Lambert - 2013

Michael Bolton wrote the following about note taking when testing:

"One of the principal concerns of test managers and project managers with respect to exploratory testing is that it is fundamentally unaccountable or unmanageable. Yet police, doctors, pilots, lawyers and all kinds of skilled professions have learned to deal with problem of reporting unpredictable information in various forms by developing note-taking skills." 

An Exploratory Tester’s Notebook  - Michael Bolton - 2007

There are a variety of note taking methods which you as a tester can utilize.  This page has an example of a few of them. Note Taking Systems - Student Academic Services - Cal Poly

One method that I have found extremely useful especially when capturing information from conferences or for recording my findings when testing is the 'Cornell Method'

The Cornell method was developed by Dr Walter Pauk of Cornell University and is widely used by University students.  It is a very useful method to help you work out if you can remember what you have written.

First of all you need to create a layout for each page in your notebook as follows. Alternatively use this Cornell Method PDF generator.

The method has 5 steps.

1. Capture what is being said or what you observe in the note taking area
2. As soon as possible review your notes and capture key details in the Review(Cues) column, add any questions you may have thought of.
3. Cover up your notes only showing the review column and now try to summarize your thoughts based on the cues.  Provide answers to any of the questions you wrote in the review column.  Use the summary column at the bottom to summarize your understanding and learning.  If you are struggling with your summary it could indicate that your notes are not sufficient.
4. Ask yourself questions on the material both the cues and the notes. Think about how you apply this information to your work.  How does it fit with what you already know?
5. Spend some time reviewing your notes and summary every so often to reinforce your understandings.

It is crucial that as a tester you practice your note taking skills.  Poor note taking can lead to missed problems and hinder knowledge sharing with the team.  Your notes are what helps to turn your tacit knowledge into explicit knowledge. 

Testing skills #3 - Leading Teams

If you are leading a software development team it is a good idea to provide to provide an environment in which each member of the team feels safe, valued and important.  It takes a lot of skill to lead teams without resorting to command and control style of managing the team.  Providing the team a safe environment in which it is OK to experiment a little and be able to learn from failing is crucial to encourage creativity and innovation within the team.   When leading a team in this way you can act as the facilitator and ensure that the bad elements of teamwork do not start to impact the team dynamics.  You can be the sounding board, the oracle, the voice of reason, the mentor, the confidant, by doing this you encourage the team to flourish which leads to success.

As a leader you also need to give the team a clear direction of what you expect the team to deliver, this can change as time passes however, this should always be transparent and visible to the team.  Ask yourself as the leader what do you want from the team?  What is your ultimate goal and then explain that to the team along with your preferred priorities.  Then step back and watch the team self-form around the problem to provide you with a solution.

The principles behind the the agile manifesto has some useful tips for leading and working in teams.

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

J Richard Hackman provides the following five tips for leading teams.

1. Teams must be real. People have to know who is on the team and who is not. It’s the leader’s job to make that clear.
2. Teams need a compelling direction. Members need to know, and agree on, what they’re supposed to be doing together. Unless a leader articulates a clear direction, there is a real risk that different members will pursue different agendas.
3. Teams need enabling structures. Teams that have poorly designed tasks, the wrong number or mix of members, or fuzzy and unenforced norms of conduct invariably get into trouble.
4. Teams need a supportive organization. The organizational context—including the reward system, the human resource system, and the information system—must facilitate teamwork.
5. Teams need expert coaching. Most executive coaches focus on individual performance, which does not significantly improve teamwork. Teams need coaching as a group in team processes—especially at the beginning, midpoint, and end of a team project.

Leading Teams: Setting the Stage for Great Performances - J. Richard Hackman - 2002

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:

• Real world applications of pacing and leading
• How to persuade anyone using pacing and leading
• What is NLP
• Influencing skills: a how-to guide, or, How to get what you want without making enemies

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.

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.

Further reading on abductive reasoning:

• Abduction, Deduction and Induction in Qualitative Research - Jo Reichertz
• Abductive Thinking and Sensemaking: The Drivers of Design Synthesis - Jon Kolko
• Abductive Reasoning - Wikipedia - 2015

This article has been taken from the Testing and the Social Science chapter in my book - The psychology of Software #Testing.

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.**

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!