Usage of words

I came across the following tweet:

Testing vs. checking is a low value semantic argument used by a cult for proving worthiness in the cult. All it ever was or will be.

— Marlena Compton (@marlenac) May 18, 2017

I tried to reply on Twitter but the message I tried to portray did not come across in the way I wanted it to.

Disclaimer:  I am not, nor ever have been a member of any cult.

Marlenas' words came across very strongly and appear to be based upon their negative experience when encountering discussions on the use of these words.  Others stepped in with their own experiences and the main message seems to be that the use of these words have been to derailed important discussions.  I find that a shame, since to me the distinction with these words has been useful to help talk to executives and others from outside the testing world about the risks of unfocused automation and testing.

My concern in the statement by Marlena is that the distinction is of low value  and a semantic argument.   Semantics and the meaning of words is vital for society to be able to flourish and this has been going on for a long time.  People have argued over what certain words mean and over time the meaning of some words change.  Some are taken over to deride or insult people and sometimes these words are reclaimed by those who are being insulted.  For example the word "Queer" to some this is a hostile word to others it is a badge of honor.

I worked in Israel for awhile and often would get strange looks when running workshops and replying to a question I would say 'smallish' It was awhile before I figured out that 'ish; is Hebrew for 'man' and I was saying 'small man'.  Culturally words can have different meaning and cause confusion, the same can be said of the words'checking 'and 'testing'  Using these words in the right situation and context to inform and have a discussion can be useful however if used to make a point or win an argument it becomes less useful.  If used in an attempt to show superior intellect then the discussion is already lost.

I use the distinction between the words when discussing the testing effort.  How much checking has been done against the amount of testing that has been done.  How much effort have we spent on putting in place explicit knowledge, information we feel we know, against the effort on information that we do not know, tacit.  Knowing the difference between these two items can be vital to help mitigate risk.  If all the effort and money is being spent on checking with very little testing then there could be a risk that something we do not know could be dangerous.  Unless we spend a little more effort on testing to uncover more of what we do not already know then there is unknown risks.  Another example could be that the product is mature and changes are minor so more effort is put into the checking.

For me having these meanings helps to inform and tell a story.  I do not use them to score points or be a member of a cult I use them because they have a value to me in my context.  I do not really care if you use these words or not.  I have explained how I use them and the usefulness I find in them.  Yes I will discuss with people why I feel the distinction has value but at the same time I respect others opinions and viewpoints.  To me it is a useful tool to be able to communicate with teams around the world.

A test is...

On twitter Santhosh Tuppad posted the following tweet:

It made me think about what 'a test' really is.

I made half an attempt to improve the statement Santhosh made and suggested the following:

This would make the statement read as following:

A Test is an experiment that tests to see if the testing yields observational information.

I have thought about this and it still does not appear quite right for what I would say is a test.

There have been many discussions on what testing is and how 'a test' relates to the testing.

• Testing vs Checking - Bolton 2009
• Testing vs Checking refined - Bach/Bolton 2013
• What is Software Testing - ISQTB
• Exploratory Testing - Kaner 2006

A test is a part of testing as some of the links above state, therefore the definitions used for testing could apply to a test.  However there is a gap if you are communicating with someone and they ask you 'What is a test?'  What is your reply?  'Oh, it is a part of testing'  Hence thanks to Santhosh I wanted to look a little more into the definition of a test.

My thoughts is that for a definition of a test we should borrow from the scientific method.

You start with a theory, you run a series of experiments against that theory, you observe what happens, you analyse what you saw, you report the findings and adjust your theory based upon your new knowledge.

There is no mention of finding bugs within that process, looking at a dictionary definition of test it gives the following:

a critical examination, observation, or evaluation :  trial; specifically :  the procedure of submitting a statement to such conditions or operations as will lead to its proof or disproof or to its acceptance or rejection a test of a statistical hypothesis (2) :  a basis for evaluation :  criterion 

 an ordeal or oath required as proof of conformity with a set of beliefs 

a means of testing: such as (1) :  a procedure, reaction, or reagent used to identify or characterize a substance or constituent (2) :  something (such as a series of questions or exercises) for measuring the skill, knowledge, intelligence, capacities, or aptitudes of an individual or group 

 a positive result in such a test 

:a result or value determined by testing

https://www.merriam-webster.com/dictionary/test

Wow so many different meaning for a simple word!  

To aid the definition it needs context.

We are focusing on a software test, this enables us to narrow the definition of 'a test'. Note we are not using the term 'test case'.  Using 'test case' I feel encourages limitations in the scope of what a test means.

To conclude the following is my definition of 'a test' within the context of software testing.

A test is a series of experiments performed against a theory that evolves based upon observational and behavioral information uncovered by the test.

The software testing part is the reporting of these evolving theories and the observation made.

What about you?  Could you improve this?  Do you have your own definition?

Fake News!

It has been a long time since my last post and I apologize, there have been many factors as to why this has been the case some to do with work load and others to do with my health.  Suffice to say I may not publish as often but I still want to get out into the public domain information that others may found useful.

The topic for this post is to do with the current wave of 'fake news' articles and how this may have influenced people and persuaded them to make decisions different from what they may have made if they had not seen such articles.

The concern is that there appears to be little critical thinking done around these stories by those who read them or watch them on the 'news' channels. These articles appeal to peoples biases either via 'confirmation bias'  (What is confirmation bias? - https://www.psychologytoday.com/blog/science-choice/201504/what-is-confirmation-bias) or appeal to authority.  (What is appeal to authority - https://yourlogicalfallacyis.com/appeal-to-authority)  Humans are easily duped or mislead and it requires conscious effort to overcome these fallacies and others.  There are many fallacies that we fall prey to and the following has a good list and description of them - http://www.webpages.uidaho.edu/eng207-td/Logic%20and%20Analysis/most_common_logical_fallacies.htm.

There are many guidelines and techniques that can be used to overcome such fallacies and clarify what is truthful or not.

One easy method is to look at the source of the information.

• Is the source reliable?  
• Does it come from multiple sources?  
• Does the source have an undisclosed agenda? 
• Can the information be verified independently?

Critically analyzing the information presented can help you make better judgement on  what is being said.

The following are a couple of techniques for critical thinking that I came across and are included in my book The Psychology of Software Testing

The 5 W's and H

Another technique, often used in journalism, is the five W's and one H.  The five W's are Who, What, When, Where and Why, The H is How.

The five Ws and one H have been immortalized in the poem 'I Keep Six Honest Serving Men' by Rudyard Kipling.

I KEEP six honest serving-men

They taught me all I knew; 

Their names are What and Why and When And How and Where and Who.

I send them over land and sea,

I send them east and west;

But after they have worked for me,I give them all a rest.    

I let them rest from nine till five,

For I am busy then,As well as breakfast, lunch, and tea,

For they are hungry men.

But different folk have different views; know a person small

She keeps ten million serving-men,

Who get no rest at all!  

She sends'em abroad on her own affairs,

From the second she opens her eyes

One million Hows, two million Wheres,And seven million Whys!    

Kipling, R - I Keep Six Honest Serving Men from The Elephants Child

The five W's and One H are a series of questions used to get the complete story, hence its use in journalism.  

Reporting on the 3 Little pigs story

• Who was involved? 
• The three little pigs (the first pig, the second pig and the third pig) and The Big Bad Wolf (a.k.a. Wolf).
• What happened?
•  Each pig constructed a house out of different materials (straw, sticks and bricks). Wolf (allegedly) threatened to blow over their houses and is believed to have destroyed both the straw and stick homes at this time. Pig one and two were able to flee to the brick house, where they remain at the moment. We’re still waiting to hear from local authorities, but it looks like the Wolf may have been injured while attempting to enter the brick house.
• Where did it take place?
• Outside a straw house, a stick house and a brick house.
• When did it take place? 
• At various times throughout the day.
• Why did it happen? 
• Apparently the Big Bad Wolf was trying to eat the pigs. Several eyewitnesses recall the Wolf taunting the pigs before he destroyed the straw and stick homes by chanting, “Little pigs, little pigs, let me in.” The pigs apparently scoffed at the Wolf’s idle treats, saying “Not by the hair of our chinny, chin chins.” It’s believed this angered the Wolf and led to him blowing the houses down.
• How did it happen? 
• It would appear the first two homes were not built to withstand the Wolf’s powerful breath. The incident inside the brick house is still being investigated, but early indications suggest the Wolf fell into a boiling pot of water when trying to enter the house through the chimney.

Porter Jermey, Five Ws and One H: The Secret to Complete News Stories Journalistics - Aug 2010

If you read any articles and it does not appear to follow this journalistic technique would be cause for concern as to its truthfulness.  You may want to delve deeper and see if the article is accurate and independent in its reporting.  

16 Steps to become a critical thinker

The following set of steps are based upon the article 'Intro to Logic: Techniques of Critical Thinking'.  

It is a useful critical thinking exercise to examine each of these steps and rewrite them to form your own set of steps to enable critical thinking.

• Clarify
• Ask questions to clarify what is being said.  Simplify to aid clarity.
• Be accurate.
• Facts can only be in the past.  Is anything in the statement making future predictions?  If so this is not fact.  Are the facts correct? Is there any factual evidence to back up the statement?
• Be precise.
• Make sure what is being said is accurate, try to avoid ambiguity.
• Be relevant.
• Make sure to stick to the issue under discussion, avoid falling for strawman or other fallacies.
• Know your purpose.
• Figure out what the most important thing is in the discussion.  Try to remove any related but not relevant information (see 'be relevant' above).
• Identify assumptions.
• When involved in critical thinking it is important to be aware that all thinking is based upon some level of assumption. Try to identify these assumptions.
• Check your emotions.
• Emotion can directly affect our critical thinking.  Try to keep emotions under control when discussing issues.  Ask yourself are my emotions influencing my judgement?
• Empathize.
• Look at what a person is saying from their viewpoint.  Try to put yourself in their shoes, how would you feel if someone spoke to you in the way in which you are speaking to them.
• Know your own ignorance.
• Know your level of knowledge. You do not know everything and what you do know may be wrong. Be gracious when someone proves you wrong, learn from being wrong.
• Be independent.
• Do not follow the crowd.  Verify information with dependent thought.  Do your own research to verify what is being claimed. 
• Laurent Bossavit has a wonderful book on this subject called The Leprechauns of Software Engineering
• Think through implications.
• Look at what is being claimed and see what the implications of this claim could be.  Look for alternative implications, both negative and positive.
• Know your own biases.
• Being aware of your biases is crucial when involved in critical thinking.  How are they affecting your judgement? Are they affecting your judgement of others?
• Suspend judgement.
• Do not arrive at a conclusion and then try to find reasons that support your conclusion.  Use the scientific method as discussed earlier in this chapter. Form a theory on how it should work and then attempt to find ways to disprove your theory. 
• Consider the opposition
• Look for alternative and opposite perspectives.   Do not base your conclusion from one source.  Look for sources that disagree with the first source.
• Recognize cultural assumptions.
• Be conscious of stereotyping and cultural bias.  It does not mean if someone is from a different culture or period in time that their views are any less greater than your own.
• Be fair, not selfish.
• We are naturally selfish creatures and find it hard to be wrong and admit our mistakes.  Be fair with yourself and others, look for selfish traits in yourself and others.

Some links:

• https://commons.wikimedia.org/wiki/File:How_To_Spot_Fake_News.jpg
• http://www.criticalthinking.org/
• https://www.skillsyouneed.com/learn/critical-thinking.html
• http://www.umich.edu/~elements/5e/probsolv/strategy/ctskills.htm
• https://globaldigitalcitizen.org/critical-thinking-skills-cheatsheet-infographic

Speaking events.

I am due to speak at a couple of events this year.

• A workshop on self learning at the Romanian Testing Conference in May 2017.
• Psychology and Testing  at the Midlands Tester Meetup - June 2017

Debating and challenging.

“The smart way to keep people passive and obedient is to strictly limit the spectrum of acceptable opinion, but allow very lively debate within that spectrum....” 
― Noam Chomsky, The Common Good

There has been a lot of debate, posts and discussions about what is acceptable and not acceptable within the testing community recently and it makes me feel sad and unhappy.  Some appear to have disintegrated into personal attacks and the message has been lost and to me that feels wrong.  Could things have been worded differently?  Of course and hindsight is a wonderful thing.   I am not going to go into detail of these discussions or state who was right or who was wrong.  You can form your own opinions and look up the discussions yourself.

 What I will say is we have to be careful as a community of  limiting the ability to challenge ourselves and allowing others to challenge us.  This should be done respectably  and with the purpose of trying to help us all learn without it becoming a personal attack and counter attack.  As the above quote states if we want to be passive and obedient then sure let us limit what can and cannot be said.  what is seen as acceptable to someone may not be so acceptable to others.  In the same way each individual has their own perspective of what quality is:

"quality is of value to a person" - Jerry Weinberg

I am not closed to the fact that as humans we will often disagree passionately with each other and to me that is OK, however once emotions are involved it can lead to some behaviors which  are not so pleasant. Maybe if you feel in these situations it is best to step back and think before replying.  I try to do that a lot and hence my delay in writing this post.

As individuals we will see the same thing in a different way, hear the same words differently and read into what someone is doing wrongly, hence the unreliability of eye witness in court trials. We may say things which we feel is right  at the time which has unintentional results .   Allowing time for people to explain their intentions and what they meant, is to me respecting each other.   The outcome from this maybe an apology, correction of facts or better clarification of what was meant.

I have to believe that in our community people do not deliberately try to hurt or upset others  however I feel as a community we need to challenge ourselves and others to improve our knowledge and skills.

Let us respect each other even if we do not agree, otherwise people will use this to limit what can and cannot be debated and decide for us what is acceptable to challenge.  At the same time using this to limit what we can and cannot read, listen to and who we can talk to.   To me this starts to become like 1984 and big brother.

To finish we may not always agree with each other but sometimes as the song in Frozen goes we have to

"Let it go"

If the worst thing you get from this post is having that song in your head all day then my job is done. :o)

What do we mean by testers learning to be technical?

I recently read a post by Justin Rohrman entitled "Do testers need to code".  The following line gave me some concerns:

"So, I think that testers do need to learn some programming skills now."

Now I wish to begin by stating I am not against testers learning to code  if that is something they are interested in and they want to learn.  On the other hand it may not be the best value skill you could bring to a team, especially if you already have 5-6 exceptional coders on your team.   Justin within the article tries to align to this thought with the following:

"My new feeling is that testers need to learn to program, or at least become more technical –write SQL, use developer tools effectively, read code — for any sort of longevity in the field. "

I have blogged about this in the past- 'A discussion on do tester really need to code.' in which I talk about adding value by learning the syntax of code.  I was asked on twitter by Marcel Gehlen to provide an example of what I meant by this.  I replied with the following:

'I understand the syntax of the french language but I am terrible at speaking it.'

The main point of this update to the 'testers need to code' debate is around what we mean by being 'more technical'?  To the majority of people and from the many articles I come across this implies learning to code.  I feel this is too narrow and at the same time limits the potential and opportunities testers may have.  As an example if you now have a team in which everyone can code and there is a need to reduce the team due to financial and business pressures.   If the decision being made is based upon coding skills then I feel testers could be at risk.

Where does this learning to code end?    In the modern development world of 'devops' are we now going to state that operational people and marketing people should now learn to code?  we could end up with an over saturated market of half decent coders.  What skills are going to make testers stand out and be seen to be adding both team and business value?

Taking a step back what do we mean by coding?

I can writing scripts in bash which to me is similar to writing test script in the sense of logical following steps.  At the same time I understand the command line interface to enable me to deploy a test environment.  Going forward into the devops model I can write dockerfiles to create containers..

#
# Super simple example of a Dockerfile
#
FROM ubuntu:latest
MAINTAINER Andrew Odewahn "odewahn@oreilly.com"

RUN apt-get update
RUN apt-get install -y python python-pip wget
RUN pip install Flask

ADD hello.py /home/hello.py

WORKDIR /home

Example from http://odewahn.github.io/docker-jumpstart/building-images-with-dockerfiles.html

I understand how to use ansible to deploy an environment to enable me to test and run automated checks.

These are, what many would class as, highly technical skills.  However as Jerry Weinberg just posted about 'Becoming a Better programmer; ' there are other skills that are of value to a team and to the business that many would not class as technical.  The ability to get people to work well together and collaborate and communicate is a highly desirable skill to have.  Since it is classed as a soft skill not a lot of emphasis is placed upon this as a skill testers should learn.

What about analytical skills, as more and more companies move to a devops model for software delivery, the skill of being able to determine patterns within the software from all the data and collate that data to help improve try and improve the quality is a highly demanding and technically challenging skill.  I can see this skill becoming highly desirable in the future.  Maybe a tester could invest their time learning this skill?

Then we have the other areas such as an understanding of human behavior to help influence the design .  Learning about social science and systems thinking to help see the big picture and overcome obstacles for the team.   I have been running a series of blog posts on skills testers should learn away from the traditional 'must code' school of thought.  Using your time wisely to practice and improve these skills can help you become a better tester and more importantly show your value to the business.

A few examples are given below (feel free to browse my blog for other examples)

• http://steveo1967.blogspot.com.co/2016/06/testing-skills-10-persuasion-and-selling.html
• http://steveo1967.blogspot.com.co/2015/11/testing-skills-8-being-skeptic.html
• http://steveo1967.blogspot.com.co/2015/10/testing-skills-7-reflection.html

Also with your testing skill set you could mentor, coach and teach others about testing and how they can use that to help improve the software.  Set yourself a goal of coaching the programmers in simple test techniques that they could look to add to their frameworks to enable you to focus more on the difficult to find issues using exploratory testing .

Again I wish to state I am not against tester learning and if they feel they have a passion towards coding then go and do it.   At the same time think about what else they could learn that adds both team and business value.

Testing Skills #10 - Persuasion and Selling

Like it or not everyone is now a salesperson.

As Daniel Pink states in his book 'To Sell is Human':

"If you spend any of your time both personal or in work "persuading, influencing, and convincing others," you're in sales."

The world of work is changing as described by Peter Drucker:

"The world of work is changing from one of manual workers to a world  of knowledge workers"

 Landmarks of Tomorrow

With this world comes the need to be able to persuade and sell to others.

“To sell well is to convince someone else to part with resources—not to deprive that person, but to leave him better off in the end.”

Daniel H. Pink, To Sell Is Human: The Surprising Truth About Moving Others

We all now have to sell our ideas and convince others that our ideas are sound and the right ideas.  How often have you needed to sell the testing you are performing?  Or persuade someone that a defect really does need to be fixed?

Having these skills is crucial for testers to be able to carry our their daily testing activities.

What follows are some tips on how to persuade and sell to others with a focal on selling testing.

The first tip is to be able to ask the right questions rather than try to provide answer.  This to some may appear simple however as Daniel Pink states:

“In the new world of sales, being able to ask the right questions is more valuable than producing the right answers. Unfortunately, our schools often have the opposite emphasis. They teach us how to answer, but not how to ask.”
Daniel H. Pink, To Sell Is Human: The Surprising Truth About Moving Others

When selling testing it is not that important to explain the technicalities of testing and how you go and do this.  This is vitally important when talking about testing to senior management.  Instead ask questions such as:

• What do you see as the biggest risk for this product?
• Where is our revenue going to come from with this product?
• Is there anything about this product that gives you sleepless nights?

By asking these types of questions you can then use the information provided to reassure the person how testing may be of value in this situations. Sell less about testing and more about what it may do to support the business needs.

At the same time their is a need to be able to persuade people about doing the right testing.  This could be other peers and colleagues.  In these situations it is not about selling but about showing to people the value of testing by doing.  Working closely alongside people so they can see in real time the benefits of the testing that is being performed goes a long way to helping to persuade people. The art of persuading is more based on showing by doing rather than by trying to sell an idea.  If you are in a situation as a tester to be given an opportunity show the value of testing, lead by utilizing practical examples rather than explaining theory.  People are more easily persuaded by examples they can relate to rather than a theoretical example that has no relevance to them.

To conclude it is important for testers to have the ability to sell the benefits of testing and the skill to persuade others of these benefits.   Selling testing will normally mean not talk about testing but the value testing can bring in terms of bottom line and risk.  Persuading others of the benefit of testing is more about showing what testing is and how it can add value.  To get better at either of these skills you need to practice and practice and practice even more.  Try and get others you are comfortable with to help you to practice and give you feedback on your selling and persuasion skills.

A list of games taken to Testbash

Testbash in Brighton was yet again a highly organised and community based testing conference.

Signup for the Ministry of Testing Dojo to see the talks, which should be available soon.

At a pre-testbash meetup in Brighton I was asked by Rosie if I would not mind bringing some of my collection of games along. That may have had something to do with having a big interest in games and how they can be useful for testers to improve creative and critical thinking skills.

After the conference I had a few requests for a list of the games that I brought along to the Testbash gaming evening.  To provide a reference I have created this page to list the games I brought along and some I did not due to limited luggage space.  All the links are for the UK version of Amazon unless otherwise stated.

Dixit

A wonderful abstract communication game with highly detailed artwork.  The purpose of the game is to describe the card you have to enable some of the players to have a good idea of what your card is.  There is a twist, you want to communicate so only a few people get it, but provide enough information to make sure that no-one does not get it. If everyone guesses your card or no-one guess your card then no points are awarded. A useful game about communication and providing enough information. It comes with many expansions which can be seen when looking at the main link.

Quirkle

Quirkle is a cross between dominoes and the card game SET (See below).  You place tiles that meet a set of rules.  The tiles placed in a single line have to be either same colour, different shape OR same shape different colour.   You score double points for getting a set of six, a quirkle!  A great game but needs good lighting and a lot of space!  One of my current go to games for a bit of fun and lateral thinking skills.

Quirkle Cubes

Quirkle cubes takes that concepts of quirkle and adds a random element and the ability to use a different strategy.  Unlike the original quirkle you can now see other players hands and can choose on your turn to roll some of your cubes to change the hand you have. This version require a lot more thought about tactics.

SET

This seems to be the 'go to' testers game of choice.  A game of visual perception, where you have to find a set of three that matches the rules of the game.  A set is three cards where either the feature is the same or the feature is different on all cards. A feature is either colour, shape number or shade.

Fluxx & Star Flux

A card game of ever changing rules where the object is to have cards, keepers, that meet the goals.  However the goals can and do change along with the rules as well. I do have the board game version of this which is fun since the board changes as well as the rules and goals.

Fluxx Dice

Fluxx dice is an expansion for the fluxx card game which adds an extra dimemsion. By rolling the dice you change the draw and play rules every single hand. Adds a great new random dynamic to the game.

Ice Dice

Ice dice or ice pyramids is a set of dice and pyramids which can be used for a variety of games. The most common one for testers is to play Zendo. This game is where a master sets a rule and shows an example of the rule and an example that does not meet the rule.  The student has to try and work out the rule by building their own pyramids and ask if it meets the rule or not.  A wonderful deductive game to challenge the mind and expand the investigative skills of testers.

Colt Express

One of my favorite games at the moment.  Each player has a bandit trying to take loot from a train whilst avoid the marsh and other bandits.  Each player has aset of action cards that they select at random.  These actions cards such as punch, fire, move, steal and so on are player during a round.  A round has a series of turns.  Some of the actions are played face up for all to see and some are placed face down.  At the end of the turn section, the action cards are played one at a time and the action carried out for that player.  It is fun to watch as some thought goes into what actions to play depending on where your bandit is, however it never quite works out as your expect.  This to me has alot in common with coding, we create what we think works only to find it ends up in a big mess.  Highly recommend this game for all testers!

Blink

A fast paced game where there are no turns.  You try to place your cards down that match the play decks by matching either colour, shape or number.   The first to get rid of there cards wins.  An ideal game for improving your pattern spotting skills.  One of the reasons I got this game was based upon an article by James Bach - Quick Oracle - Blink Testing.

Frenzi

This card game needs a lot of space to play and can become very hectic.  All the cards are placed on the table and then they are turned to the other side, they are double sided cards. Each player gets a rule card which shows what they need to have facing up at the end of the round.  They could be looking for a color, number or shape.  The first round is colour, then shape and finally number.  A timer is set and everyone starts to turn cards over using one hand.  The aim is to have as many of the cards facing up that matches your own rule. This is a quick and face paced game where it quickly becomes manic! You need lots of room to play this game and it is based on quick visual perception.

Rory Story Cubes

Rory story cubes are little dice with pictures on each face.  The dice are rolled then the players one at a time pick up a cube and using the picture that is face up start to tell a story, they leave it on a cliff hanger for the next player to pick a cube and continue the story.  Once the last cube is selected the person who picks this provides an ending to the story. These cubes are great for creative play and improving story telling skills.

Story Wars

A wonderful game in which two teams battle it out to convince an impartial judge why their character(s) should win. They is magical lands, characters and special weapons to use.  This game is useful for those wanting to improve their influencing and convincing communication skills.

This is quite an expensive game at the moment, I picked it up in the USA for $15.   You can obtain a PDF to printout for free from the manufacturers website see here.

Disruptus

I have previously done an in depth review of this game on this blog spot. See here.

Dobble

A quick game of spotting the same item on a different card.  You place two cards face up and the first to spot the same image on both cards wins those cards.  A clever game where every card has an image that is on another card. What makes it tricky is the images could be bigger or smaller or rotated.  Another game that improves the visual perception of the players.

Loonacy

This is another visual percetion game where the players try to match one of the two characters in their hand with the game cards.  There are no turns and the first to get a match keeps goig until they have no cards left and are declared the winner.

Cubu

Cubu is an intense game of following a sequence of colours and numbered squares with the aim to get rid of all your cards before the other player does.  This game requires a lot of concentration to be able to workout which way would be best for your sequence and to throw a proverbial spanner in the works there are action cards which can force you to miss turns, pick up more cards and other actions that inhibit your chances of winning.

Interviews and Videos

I thought I would start the new year with a brief post about what I have been up to over the holiday period.

I was approached by the editors of Teatime with Testers magazine seeking permission to publish my current series of posts on testing skills - the first one has been published and you can download the magazine for FREE from here - http://www.teatimewithtesters.com/ .

During December Matt Young got in touch with me from the company Functionize to see if I would be willing to do a podcast with their CEO Ray Grieselhuber about "Why automation will not replace manual testing."  This ended up being a really good discussion in which everything from why automation can be useful, to a philosophical debate about what being human means.  We ended up chatting for so long that the article had to be split into two parts.  The podcast and articles can be found at the links below.

• http://www.functionize.com/blog/John-Stevenson-Test-Automation
• http://www.functionize.com/blog/Automated-Testing-John-Stevenson-Ray-Grieselhuber
• https://soundcloud.com/functionize/john-stevenson-on-test-automation - Podcast

During this period Richard Bradshaw started a great new concept of Whiteboard testing.  Considering I do not live that far from Richard I decided to pop over and we recorded a couple of sessions.  Links to these session can be found below:

A look at the test automation pyramid
Test Execution Model

I intend to record a few more whiteboard sessions in the near future.  If you have any great ideas for whiteboard sessions then please do record them and help support this wonderful initiative.

*EDIT*

Oh and I will be speaking in Brighton on March 11th at Testbash.  Hope to see you there.

Test Execution Model - updated

This is a follow on to the post I recently did about the automation pyramid that Richard Bradshaw gave at MEWT.

Following on from this some in the testing Twitterverse asked if Richard and I would do a video for the new initiative created by Richard called Whiteboard testing.  Instead of one video we decided to do two.  The first looked at the history of the test automation pyramid and you can watch it here: A look at the test automation pyramid.  The second video was a chance for me to present my own model which I have called the test execution model and can be seen here: - John Stevenson Test Execution Model.


After the video was posted I had a message from Dan Ashby who wanted to discuss more with me about the  test execution model and what he felt was missing.  We arranged a chat and discussed the model and broke down a few assumptions we were both making.  The outcome from this chat was the need to add a few extra parts to complete the test execution cycle.  With thanks to Dan I would like to present the next generation of the model.

The changes that Dan suggested for the model are as follows:

• As you test you turn some of your tacit knowledge into explicit knowledge which then can be added to your checks and become known known information.  This is represented by the flow from the testing arrow to the checking arrow at the top of the diagram.
• As you create more checks these in turn become oracles which you can use as heuristics for your future tests.  This is represented by the flow from the checking arrow to the testing arrow.

This then gives a cycle of test execution were the testing feeds into the checking which in turn can feed back into the testing.  It should be noted that is model is for test execution which does not only apply to only testing the product deliverable.  Testing is carried throughout the development cycle and as such testing activities can occur during artitecture & design discussion and during coding. Testing activities can and should occur anywhere during the development and deployment of the product and this model should be used in that context with regards to test execution.

Testing Skills #9 - Differentiating between wants and needs

One common discussion that keeps cropping up from testers saying that their managers are telling them that they 'want' this and that they 'want' that.  Normally in connection with 100% test automation or some other new shiny testing discussion point. A crucial skill a tester can have is the ability to separate what some one wants and what they really need.

It is common for people to not see the huge difference between these two words but having the ability to do so can improve your testing skill set.

The difference between the two is easy to explain with the following scenario.

Imagine that you have decided that you to be fitter and to do so you decide you want to be able to swim ten miles in one session.

Now ten miles is a lot and since the average human swims at about  two mph that is going to take about five hours to complete. You may never get around to meeting this want but you may come close.

Now one day you decide that you want to go sailing off the coast of Britain, you sail out to ten miles from the coast when suddenly the boat is hit by a huge wave and destroys it.  You are ten miles from the coast and if you do not make it back within five hours you will die due to the exposure to the cold water.  You now need to swim 10 miles in a single session.

This is the difference between wants and needs.  What people want is not necessarily what they need.

As a tester you should try and uncover what people need when they say they want this or that.  In the test automation example  it is useful to probe deeper and ask what is the problem they are trying to resolve.  By doing this you can get to the needs rather than the wants.

When the manager says "They want to automate all the testing" delve deeper to understand the problem the manager is trying to solve.  Ask "Why do they want to try and automate all of the testing?", "Uncover the needs so that you can understand what is being asked.

** The story about swimming is not my own and I cannot recollect where I first heard this.  If any of the readers can let me know where it is from I will add the correct attribution. 

Testing Skills # 8 – Being a Skeptic

 “Science is the organized skepticism in the reliability of expert opinion.”  Richard Feynman

The reason for this article is based upon a recent twitter conversation regarding how someone sometimes avoids skepticism due to its negative nature.  I fully understand what they mean when skepticism is used in way to attack a person or their character (ad-hominem argument).  The purpose of this article is to provide information about how useful having a healthy dose of skepticism is for those involved in software testing.

Many people have a belief that the purpose of testing is to prove that the software works as expected.  This is really a fallacy since testing cannot prove that the software will always work the way you expect. There is always an element of doubt in proving that it works due to the nature of software and how it is used. This is the same as in the field of scientific research where someone comes up with a theory based upon their experiments and then their peers using a fair bit of skepticism try to prove the theory wrong.  This is the crux of any scientific based research method.  It is not about producing your theory it is about applying critical thinking to your theory as to why it can be wrong.   Testing software is similar in its approach it is very difficult to inform someone, who matters that the software is working. We can provide useful information about its behavior and what it actually doing.

As a tester you need to apply critical thinking to your testing and to the evidence you produce.   This is where being able to look at what you are doing and what information you find will a fair degree of skeptical thought.  The scientific method is a useful skeptic tool to apply to your testing and to any other information that people provide to you as ‘fact’.  One approach is the use of FiLCHers:

If you look at each of these headings you can see that it is about trying to find evidence where your theory and experiment could be wrong, acting as a skeptic.

This is a vital skill for testers to possess to ensure that their testing is unbiased and factually correct. If you feel the skeptic is lacking then look at ways you can improve it.

Here are some suggestions to help you become a better skeptic:

• Learn about logical arguments and fallacies
• This page has a substantial list of them - http://changingminds.org/disciplines/argument/fallacies/fallacies_alpha.htm
• This book is a wonderful illustrated book proving examples of fallacies  and bad arguments - http://www.amazon.co.uk/Illustrated-Book-Bad-Arguments/dp/1615192255/

• Practice using skepticism – apply it to your work and the work of others.
• Use James Bach’s’ , Huh, Really, So technique - http://itknowledgeexchange.techtarget.com/software-quality/james-bach-on-critical-thinking-huh-really-so/

• Use reflection to help improve your skeptic skills.
• See my previous post on reflection - http://www.steveo1967.blogspot.com/2015/10/testing-skills-7-reflection.html 

If you have some suggestions of your own to help others in their journey to being a great skeptic please let me know by using the comments section.

The Laws of Sport and Automation

I have had this idea in my mind and on my backlog for quite a while.  It was only after speaking at MEWT in Nottingham that I felt I really should get around to writing it. 

There are many debates in the software development world about ‘test automation’ and how we can ‘automate all of the testing’.  I am in the context of this article ignoring the difference between testing and checking, more details of this discussion can be found here - Testing and Checking Refined . However some of my ideas and concepts will touch on the difference between checking and testing. 

Many have put forward arguments about automating what we know and if we have defined requirements up front then it should be possible to automate these.  My counter to this is that in many sports there are well defined upfront requirements (laws) of how the game should be regulated.  For example the laws of football (Soccer to those outside of Europe) can be found online here: FIFA Laws of the Game.  If this is the case and these requirements are defined upfront then why do we not have automated referees? I asked this question on twitter and some of the responses gave reasons due to the psychical limitations, such as battery power unable to run and so forth.  My line of thought is on how these requirements can, and are, interpreted. 

Looking deeper in to the football laws of the game it can be seen there are many ambiguous statements which given the current state of AI, at the time of the publication of this article, I feel are impossible to automate. For example on page 39 it states the following as a reason for a player to be cautioned.

“unsporting behavior”

What does this mean?  Page 125 attempts to define this with a list of what constitutes unsporting behavior.  One of this in particular I found interesting, it is one based on human nature of trying to con or cheat

“attempts to deceive the referee by feigning injury or pretending to have been fouled (simulation)”

This I feel would be a common sense decision made by the referee. How could an automated system know if is fake or not?  Then again how would the ref know?  It it is a common sense decision, being made depending on a multitude of factors and contexts.

How about this one? 

“acts in a manner which shows a lack of respect for the game”

What would count as lack of respect?  A player who in the last second of the game lets in a goal that allows the opposition to win the title. The player shows human emotion and frustration, there is a fine line between emotion and respect or the lack of it?  

My issue with this automation debate is that at this time it is not possible to automate common sense and multiple contexts in the decision making process that a referee has to go though in their thinking process. 

For example a team is winning 20 – 0 a machine would continue to officiate the game in accordance to the strict letter of the law.  Whereas a human referee would allow some flexibility in the interpretation of the rules.   They will allow some aspects of empathy to be applied to the game.  Is it yet possible to automate empathy? 

James Christie made a valid point on twitter that the reason in the majority of sports they are called laws and not rules is that:

“rules are detailed and specific whilst laws can be based on vague principles, which require interpretation and judgment. “

This makes sense since most countries have courts where lawyers debate how the laws of the land can or should be interpreted.  Then a jury, judge or set of judges make a decision based upon the arguments presented. Another case of were the requirements are listed and known but given current AI limitations would be impossible to fully automate. Even though we know that human beings are flawed in the judgement that are made, would using an automated judgement machine be any less flawed, if at all possible to produce?

Returning back to the laws of sport and how ambiguous those laws are we can look at the laws of Rugby Union

Looking at the beginning of the laws on page 21 there is guidance on how the laws should be applied:

The Laws must be applied in such a way as to ensure that the Game is played according to the principles of play. The referee and touch judges can achieve this through fairness, consistency, sensitivity and, at the highest levels, management.”

How would you automate sensitivity in this context?

According to the Oxford English Dictionary this in this context is defined as:

“A persons feelings which might be easily offended or hurt”

Add into that equation “fairness”, we are now journeying down the automation rabbit hole.

Looking at the laws regarding fair play and the guidance that the document provides for foul play (Law 10) section m gives the following guidance.

“Acts contrary to good sportsmanship. A player must not do anything that is against the spirit of good sportsmanship in the playing enclosure”

What constitutes “the sprint of good sportsmanship”? How do you clarify between intentional and unintentional behavior?   Again I am uncertain if this kind of decision could be automated.

If we look at the laws of Rugby League we can see similar issues in how difficult it can be for the laws to be interpreted. Rugby league was one of the early adopters of video technology to help assist the referee in the game.  This is what Michael and James in their article would define as tool assisted testing.  In this case a video referee can review certain decisions via the use of video technology. 

Looking at the definition of a forward pass.

“is a throw towards the opponents’ dead ball line”

How do you define this in the context of a fast moving game?  Under the section 10 which offers some guidance there is a distinction between deliberate and accidental forward passes.  How do you make a distinction between these two actions? Also would an automated system be able to deal with factors such as the momentum of the player and the wind moving the ball.  Yes they could process information quicker than a human could but would it be right?

This is not to say that referees are not fallible and there are many instances in sport of them making mistakes; however people are aware of this and can accept that fact.  Would people be so willing to accept a machine making similar mistakes based upon our biases that machine are not fallible?

Many sports are implementing some level of automated systems which are used to aid the referees.  

• Tennis has been using Hawkeye since 2002 
• Football has started to implement goal-line technology
• Cricket uses the Umpire Decision Review System 

It is interesting to note that each of these automated systems have had some controversy regarding their accuracy and success especially with the cricket system.

To conclude when people discuss test automation and attempt to automate as much as possible there is a need to step back and think critically. Automation in software development has a place and is a useful tool to use, however, it should not be thought of as an alternative to testing as applied by a human being.  Even when you think you have the requirements nailed down they are words and as such are open to a multitude of interpretations.  Using a mixture of automation, tool assisted testing and human testing in a ratio that adds value to the quality of the product being delivered is a more thoughtful approach rather than the mantra of we can “automate all the testing effort.” Going forward we need to be thoughtful of what machines can do and what they cannot do.  This may change as technology progresses but as of the publication of this article there are big limitations in automation.

Testing Skills #7 - Reflection

What type of learning do you need to engage in today?

Do you need to learn facts?

Or

Do you need to analyse and critically think about what you need to learn or have learned?
Neither of these ways of learning are wrong and each has its place in your learning journey.  Knowing which to use and when is a great tool for a tester to have.

Learning facts is defined as a 'surface approach ' style of learning and writing and thinking critically about what your have learned can be defined as a 'deep approach'.

Reflection is important in software testing and you need to be able to communicate what you have found and uncovered when testing.  If you have no opportunities,  in your organization, to be able to communicate with others then you may find you have a lot on tacit knowledge but little in the way of explicit.  It is vital to set aside time for members of the team to discuss what new information they have uncovered or learned when testing.  This allows them to use reflective reasoning to turn tacit into explicit and gives the person providing the information a sense of purpose and achievement in what they have learned.

To improve your own self-reflection produce a reflective action plan. By doing this you are committing to your self what you intend to do and engage critical thinking skills in doing so. Make sure your plan has goals and deadlines that you can commit to.  Make this deadlines and goals public it encourages you to keep to them.  Using a personal Kanban board can help you achieve this.

"First, the deep and surface approaches are not personality traits or fixed learning styles.  Students adopt an approach which is related to their perceptions of the task."

Marton and Säljö - Student Approaches to Learning - University of Oxford

When you need to think deeply about what you have been studying then writing down you own thoughts and understanding is a good way for you to be able to see what you have remembered.  If you only need to learn information or facts then other models would be more suited.

Writing down you thoughts on what you have been attempting to learn enables you to better remember or apply what has been studied.  Reflection is about doing your own internal self-assessment  of what you have been learning.  This assessment enables you make what you know internally, tacit knowledge, and attempting to make it clear and detailed explicit knowledge.  To do this you need opportunities to talk to others verbally or by writing down what you have studied to invoke critical thinking.

"In general, writing appears to be suitable for tasks where the aim is fostering understanding, changing students' conceptions and developing their thinking skills, but less suitable if the goal is the simple accumulation of factual information"

Conceptualizing and Measuring Knowledge Change due to writing

Schumacher & Gradwohl Nash (1991)

One way in which can improve your learning is to use reflection:

"Reflection is an active process whereby the professional can gain an understanding of how historical, social, cultural and personal experiences have contributed to professional knowledge and practice "(Wilkinson, 1996).  

You learn from your experiences and to make this happen you need to engage in reflection.  If you think about what you are doing or what you have experienced you are engaging in self-reflection. This approach helps you to turn learning into knowledge and it is vital in improving your own knowledge and skills.  Reflection is really about looking back at a situation, thinking about it, critically and learning from the experience, then using that new knowledge to help in future similar situations.  This in many ways is similar to the approach you will taking when engaging in testing activities.

"The process of reflective writing leads to more than just a gain in your knowledge; it should also challenge the concepts and theories by which you make sense of knowledge. When you reflect on a situation, you do not simply see more, you see differently. This different way of viewing a situation is reflected in statements about a commitment to action. Action is the final stage of reflection. "

Learning through reflection(Word doc)?

MEWT4 Post #2 - A coaching model for model recognition - Ash Winter

Abstract:

As part of my role, I often coach testers through the early part of their career. In this context I have noted a pattern in the application and interpretation of models. They are generated internally through various stimuli (learning, influence of others, organizational culture) and then applied subconsciously for the most part, until there is sufficient external scrutiny to recognize them. To this end, I have created a model of questions to help testers to elevate their internal models to a conscious level and begin to articulate them.

To this end I hope to articulate at MEWT:

• Presentation of the model of questions to determine internal models in use, without introducing models explicitly.
• Use of Blooms Taxonomy to visualize a coachees modelling paradigm and the steps towards modelling consciously.
• Practical examples of using this model to assist early career consulting testers to cope with new client information saturation.

Slides for the talk by Ash can be download here - https://mewtblog.files.wordpress.com/2015/10/coaching-model-for-unrecognised-internal-models.pptx

____________________

The first speaker at Mewt was Ash Winter who talked about his experience of coaching and how coaches have their own internal models which still could be wrong.  Ash talked about the issue he and other coaches have experienced with using models and the risk that they can limit your thinking.  He had noticed that some coaches talk about models without really recognizing that they are using a particular model.  This appears to be especially true in the testing domain.

Ash presented a different coaching model based on Blooms taxonom  to provide a framework of asking questions of those you are coaching rather than providing answers.  Ash stated that we should, as coaches, “Build your model on pillars of questions, not answers.  You are coaching”

The levels of Blooms taxonomy can be seen here:

An in-depth look at Blooms taxonomy can be found here.

Ash displayed a different variant of this during his talk:

Ash stated that he felt that Blooms was good for learning and it was useful for coaching as well.  Since Blooms works on the basis that you work towards goals this also then applies to those who coach and utilize coaching models.   

Ash also stated that his model for coaches is for those who are experienced as coaches and who are involved in coaching those who are early in their career as a tester.  As with any other model Ash did point out that he felt this was a new coaching model which was still evolving and emergent and wanted input for the wider community?

During the discussion after Ash has spoken I highlighted that the Blooms taxonomy approach does have some flaws especially in a digital driven learning environment in which we are now situated. 

The hierarchical approach of Blooms does not encourage deep and meaningful learning aided by digital media.

The problem with taxonomies is their attempt to pin down the complexity of cognition in a list of simple categories. In practice, learning doesn’t fall into these neat divisions. It’s a much more complex and messier set of cognitive processes.http://donaldclarkplanb.blogspot.com/2006/09/bloom-goes-boom.html

Issues with Bloom taxonomy further reading:

• https://eppicinc.files.wordpress.com/2011/08/sugrue_bloom_critique_perfxprs.pdf
• http://www.corwin.com/upm-data/13602_Chapter_1_Marzano_Final_Pdf_2.pdf
•  http://www.learningspy.co.uk/myths/challenging-blooms-taxonomy/

There are alternative learning models which appear to overcome these flaws in Blooms and maybe mixing them together will provide a more robust model for Ash to work with.

For example:

“Heutagogy is the study of self-determined learning … It is also an attempt to challenge some ideas about teaching and learning that still prevail in teacher centred learning and the need for, as Bill Ford (1997) eloquently puts it ‘knowledge sharing’ rather than ‘knowledge hoarding’. In this respect heutagogy looks to the future in which knowing how to learn will be a fundamental skill given the pace of innovation and the changing structure of communities and workplaces.” https://heutagogycop.wordpress.com/history-of-heutagogy/

Or

“Connectivism is driven by the understanding that decisions are based on rapidly altering foundations. New information is continually being acquired. The ability to draw distinctions between important and unimportant information is vital. The ability to recognize when new information alters the landscape based on decisions made yesterday is also critical.” http://www.itdl.org/journal/jan_05/article01.htm

At the end of the talk by Ash the group felt they needed to go away and think more about the ideas Ash has discussed.

To finish I will leave you with a quote from Ash during the talk:

A lot of people do not know what models are sometimes they emerge during applied practice

Testing Skills #6 - Speaking the language of business

The following short article is based on a talk given by Keith Klain at both CAST and Testbash

• Talking to C Level Management about testing - https://www.youtube.com/watch?v=Xn-2iIs-VBA - CAST

• How to talk to your CIO if you really have to https://www.youtube.com/watch?v=CurOi7jKJ1M - Testbash

As testers we find it difficult to explain our value when we get given opportunities to talk to senior executives in companies.  We normally end up talking about the technicalities of testing or even worse talking down to them as if they do not understand how really important testing is.  The most important rule when talking to business people about testing is…

“Do not talk to them about testing”

You should instead try to make them feel comfortable in the knowledge that you as the person assigned the role of ensuring testing is done, have it covered.

Instead focus on how the testing approach you use is aligned to the business strategy of the company and how your role help the business be successful.  Talk to them in terms of business and how you align testing to the business.  What value does what you do add or prevent the business from losing money or customers.

Business people are focused on risk and trying to avoid risk that impacts the bottom line. When talking to executives instead of saying we should not be automating everything; talk instead about the risks associated with attempting to automate everything.  The business costs to maintain or the risk of not uncovering information that could cause loss in value to the business.  Talking about checking and testing can be useful to help people understand the value of what we do.  It is important to present a balanced view and explain the benefit of both and how using both can mitigate risk.

Look at providing examples to the executives of the bad things that we are going to do to the customer if we do not test properly.   Ask them how you can help with their decisions to help your clients and protect business value. 

If your company is listed on the stock market, do you read or watch your company financial statements?  This gives useful insights to their important values.  Learning the financial language of your company can be useful when talking.  With this information you can now tailor your discussion around the value your testing provides to the whole organization. Many tester focus on the value that they provide or that the testing provides, instead focus on defining the value of the whole team delivering the product. Explain how the testing is aligned to delivering as a team rather than focusing on testing. Look at the company annual report; it highlights their risks and issues.  Understand what that is and align your testing to this.  

Most importantly, be prepared.  If you know you are going to talk to these people understanding what is important to them, what motivates and drives them. Having this information can help build a relationship around their aspirations and make them feel you understand them and what their needs are.

As Keith states “Focus on the big stuff and work back from there.” that is what the executives are really interested in.

MEWT4 Post #1 - Sigh, It’s That Pyramid Again – Richard Bradshaw

This is the first in a series of posts I plan to write after attending the fourth MEWT peer conference in Nottingham on Saturday 10th October 2015.

Before I start I would like to say thank you all the organizers and for inviting me along and a BIG MASSIVE thank you to the AST for sponsoring the event,

Abstract: 

Earlier on in my career, I used to follow this pyramid, encouraging tests lower and lower down it. I was all over this model. When my understanding of automation began to improve, I started to struggle with the model more and more.

I want to explore why and discuss with the group, what could a new model look like?

___________________________

During the session Richard explained his thoughts about the test automation pyramid created by Mike Cohn in his book Succeeding with Agile and how the model has been misused and abused.

Richard talked about how the model has adapted and changed over the years from adding more layers..

...to being turned upside down and turned into an ice-cream cone.

Images taken from - http://watirmelon.com/2012/01/31/introducing-the-software-testing-ice-cream-cone/

Duncan Nisbet pointed out that this really is now an anti-pattern - http://c2.com/cgi/wiki?AntiPattern.  The original scope of the diagram by Mike was to demonstrate the need to have fast and quick feedback for your automation and as such focused the automation effort to the bottom of the pyramid. Where the feedback should be fast. The problem Richard has been experiencing is that this model does not show the testing effort or tools needed to get this fast feedback.  It also indicated that as you move up the pyramid less automation effort was needed or should be done.  The main issue for Richard was how the pyramid has been hi-jacked and used as examples of the priority of effort should be on automation rather than focus on the priority of both in given contexts.  

Richard presented an alternative model in which both testing and automation with the tools required could be shown on the ice-cream cone diagram.

With this diagram the sprinkles on the top were the tools and the flakes the skills.  He then in real time adjusted the model to say it would be better as a cross-sectional ice-cream cone with testing throughout the cone and the tools across all areas of the original pyramid.  Many attendees liked this representation of the model but some thought that it still encouraged the concept that you do less of certain testing activities as you move down the ice-cream cone.

At this stage I presented a model I had been using internally to show the testing and checking effort. 

Again people thought this indicated that we need to do less as we move up the pyramid and it went back to the original point being made by Richard that the pyramid should die.

After MEWT I thought about this problem and tweeted an alternative representation of the diagram. After a few comments and some feedback the diagram ended up as follows:

With this model the pyramid is removed. Each layer has the same value and importance in a testing context.  It shows that the further up the layers you go the focus should switch more from checking to testing and the lower down the focus should be on automating the known knowns. All of this is supported by tools and skills.  As a model it is not perfect and it can be wrong for given contexts, however for me it provides a useful starting point for conversations with those that matter.  It especially highlights that we cannot automation everything nor should we try to do so.

In summary the talk given by Richard was one of the many highlights of the day at MEWT and inspired me to look further into the test automation pyramid model and its failings.  I agree with Richard that this original model should die especially in the way it is often misused.  Richard provided some useful alternatives which could work and hopefully as a group we improved upon the original model.   Richard did clarify that his ice-cream cone model with sprinkles is not his final conclusion or his final model and he will be writing something more on this in the near future.  His blog can be found here - http://www.thefriendlytester.co.uk/.

Now it is over to you, please provide your feedback and comments on this alternative model.