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.

Agile is.....

This post is inspired by the Michael Bolton post .. testing is...

I am becoming aware of more and more statements being made about the reduction in the need for dedicated testers in software development which follow the agile manifesto and principles. 

There is a growing call for developers to be both a tester and a developer and vice-versa.  Where the mantra is 'Everyone codes and everyone tests'.  I did a brief discussion on this topic in London for Tony Bruce.  In which we discussed the good and bad implications of this mantra.  Hopefully a new post will come out of that discussion at some point in the future.This post looks at what the agile manifesto and principles say in a testing context.  This is my thoughts on what the manifesto and principles of agile mean to testers and feel free to adapt,change, alter for your own purposes. When you come across people stating that there is no need for specialist testers in agile software development teams you can use some of the following:

• Agile among other things - is a word used to describe a manifesto and a set of principles for helping to develop software

• Agile among other things - is about delivering tested working software, which requires testing thinking skills

• Agile among other things - is about satisfying the customer through early and continuous delivery of valuable tested software. 

• Agile among other things - is about using testing thinking skills to discover if the software is of value to the customer. 

• Agile among other things - is about empowering people to do good work, which requires people with testing expertise.

• Agile among other things - is about using testing skills to help deliver frequent working software.

• Agile among other things - is about using tools to support skilled testers.

• Agile among other things - is about people with a variety of experiences & skills working together to create products that customers want.

• Agile among other things - is about testing software so that the delivered software works in ways that a reasonable user expects.

• Agile among other things - is about producing working software where as much information about how the software behaves has been uncovered by skilled testers.

• Agile among other things - is about creating quality products using a diverse team with diverse range of skills and expertise.

• Agile among other things - is about working with people from a variety of backgrounds, programmers, testers, business, help desk, support and trusting them to develop working software.

• Agile among other things - is about testers informing others in the team by means of face to face communication what information of value they found during testing

• Agile among other things -  is about using automation tools to check  what you believe to be true is still true, but it does not replace skilled human testing.

• Agile among other things - is about being successful in delivering work tested software

• Agile among other things - is about embracing changes and having the confidence that the testers will uncover information of value regarding the changes made.

The Importance of Worth

I am going to start this article with a reflection of when we were children.

I want you to imagine that day in school when you was a very young child and you produced your first ever painting.  You took all day to produce it, making careful use of colour and getting exactly how you wanted it to look.  At the end of the day you took your painting home to show your parents.  You were so excited and full of joy and expectations of what your parents would say about all the hard work you had done.  You ran into the living room with your painting in your hand and shouted out “Look Look, what I have done today”.  Your parents come over and take great interest in what you have produced, commenting about how clever you are and how wonderful you are.  They say how proud they are of you and they place your artwork on the fridge in the kitchen where everyone can see it.

Now if you have recalled this scene in your mind and many of you will do so.  How are you feeling?  Did the thought make you happy?  Did you feel pride in what you did?  Are you smiling at this thought?

So now let us zoom toward to present date…

You spend days/weeks/months (Cross out which is applicable) creating test scripts based upon assumptions, writing them up in whatever test case management system you have been told to use.  You put all your effort and thinking into being creative creating these step by step instructions for ‘testing’ the system.

After you have done this you then get ready to start testing using the work you have spent so long creating.  Once you start testing you realise that most of what you have already done upfront, all that effort is not going to be used.   So all these test scripts which you sweated over creating and completing in step by step precise detail, get ignored, never see the light of day, the labour of your work, forgotten and not commented on.

How often when we are told we must follow a scripted testing approach does this happen?  If we are honest it does happen a lot, I know to me in the past over half the scripts I created never got reviewed or used.  Half of the work I did was just forgotten about and left to gather dust in the test case repository.  I should make it clear that I am not against test scripting and that with the correct context they have value but indiscriminatingly forcing people to do something without experiencing it is in my opinion is such a stupid and pointless exercise.

Let us step back to our story from earlier.

Now imagine as a child you rush home to your parents with your painting in hand and once at home your parents take your painting and without saying a word lock it in a drawer and carry on with what they were doing.  How would you feel now?  Place yourself into the mind of your child self and imagine how would you feel?  Upset?  Sad?  Hurt?  Worthless?

So why when we do something as creative as testing do we do this?  We create so much in the way of test scripts but never get the chance to be proud of what we have done, what we have achieved.  We lock it away never to be used again, never to be talked about.  Is it any wonder that so many testers feel sad, unhappy and worthless in what we are being asked to do.  It is a key aspect of human nature that we want to show people what we have done, what we feel proud about, we need feedback to know that the tasks we are performing are worthwhile.  We need confirmation that we are valuable, needed and wanted.  If we continue to carry on with this path of insisting on doing pointless and useless tasks in which we then ignore or and just throw it away then we deserve to feel the way we do.

There are alternatives, using the exploratory testing approach can help prevent this waste; based upon only doing what is necessary at that time, using context.  Session based testing can make sure feedback on what you are doing becomes a key element of the testing approach.

Let us start to feel that we are important to software development and that testers are a worthy addition to this.

Some useful reading:

Session Based Test Management

What is Exploratory Testing 

Exploratory Testing Resources

Principles of Context Driven

Why Testers do not add Value

This is an article I published internally last year when there was a debate going on about the value of testers within the testing community so I thought would re-publish it here for people to have a read.

___________________

This may seem like a strange statement coming from a tester; however the purpose of this article is an attempt at justifying the need for testers on a project. Financial people might use traditional cost/benefit comparison models when recruiting people for a team or project which may not necessarily be applicable when resourcing testers.

What made me think about writing this article was something I happened to read on the Software Testing Zone website by Debasis Pradhan 1 and from Michael Bolton at the Developsense website .2

There are two comments within these articles that appear to come from a developer’s point of view about the role of testers within software projects.

The first is from Debasis blog:

Software Testing is a worthless process. It does not add any value to the project!

And one from Michael’s blog

But testers don't add value to a project;

These comments made me think about the way testers are perceived on projects and whether or not they really do add any value to a project. This led to researching how accurate these statements were and the production of this article.

The problem I have found when carrying out the research for this article is that the term ‘value’ can have different meanings depending on the context in which it is used.

If I were to ask you what is the value of a gift a loved one gave you who is no longer here?

What value would you put on that item?

In money terms it might not be worth that much but in emotional or sentimental terms, to you, it could be priceless. It is very important when reading this to use the correct context for the meaning of value. For the purpose of this article value will be measured in terms of monetary value otherwise your emotional viewpoint may get in the way of what is being said.

So the definition of value for this article will be:

Value implies monetary value.

If we take a look at a typical upfront project and see where costs are attributed and where value is added it may give a better understanding of the statement.

The first part of a project is the initial design and scope where the architect captures and translates the requirements of the customer in to technical solutions and business requirements. The value of an architect is very clear since they are the people who provide solutions to the questions raised by the business. They ensure that the requirements for the customer are met and what the customer asks for is what will be delivered. Those who work within software development may not agree with the final statement since sometimes features requested are not delivered or changes are made that affect part of the delivery. However in the majority of cases what the customer requires is delivered by the architect.

The project manager will then look at these requirements and sees which has the highest business value at the same time assessing the risk of adding the features before making the decision as to what to develop which will give the maximum value.

These technical solutions, risks and business value are then interpreted by the developers and turned into an actual project so their value can be measured in that they build the project. The developers also fix any problems and solve any issues that may occur either from the customer or the test team.

Marketing then can sell that product or may already have sold the product adding value to the company.

Some may say that testers must add value since they find problems before a product is released and as such stop a project costing more in terms of company reputation and actual monetary cost. This may appear true but testers do not actually provide solutions and fix the problems, this is the role of the architect and the developer.

So what does a tester do within a software project?

Testers look at the project being developed and raise questions and report observations as to what may not be working correctly. They look and report on areas which could cause the most risk and most expense to fix. They give priority to the main problems (defects) within the product.

However the people who fix these problems, act upon the observations and answer the tester’s questions are the ones who add value to a project.

This view is based upon a typical style of software development where all requirements are gathered upfront so what about agile style projects?

It is rather interesting that there are very differing viewpoints on this within the testing world, one side saying that if the testers are working directly with the developers and writing the test cases before the code is written then they are adding value to the project. The other side is saying they may write the test cases but they do not actually do any creative design work and as such do not add any real value to the project. My viewpoint is of the latter if the testers are not actually creating code that will lead to a function that will be used by the user in the live system then they are not adding any real value to the project.

The way in which testers could add actual value to the project when using agile is when they have close working arrangements with the actual customer since they can then suggest or inform the customer that if they did this a different way it would have more benefit. This would still not be intrinsic value unless the tester managed to get the customer to sign up for more work at an additional cost, therefore adding to the value of the project.

To conclude testers do not add intrinsic value to software development project but they prevent deprecation of the project value. If you have a project that a customer is willing to pay five million dollars for and you ship that project with x amount of high level problems. The customer then quite rightly demands the problems be fixed free of charge. Then the value of your project could go down from the initial five million to say four million, losing the company both real money and another value that cannot be measured: ‘your company reputation’.

It should be noted that there is the factor of costs of resource on projects and to keep things very simple I have excluded these other costs when making the above statement. Otherwise you would need to include the cost of equipment, building, utilities and so forth.

With testers on the project the majority of the high level problems would have been caught before being shipped to the customer and as such the value of the project would have been maintained.

Therefore testers do not add value but they certainly prevent value from being lost. It should be noted that no tester can guarantee one hundred percent bug free software. Even companies such as NASA who on the Space Shuttle program had a ratio of 10 testers to 1 developer 4 cannot give that guarantee as demonstrated by the tragic accidents that have occurred! The average ratio in the majority of projects is 1 tester to 3 developers5; therefore value will always be lost in some way from a project.

So remember those whose job it is to resource software development projects never skimp or cut costs by using less testing resources and think that you have saved yourself some money. You might just find that the 1 million dollar project you are working on becomes worthless due to lack of testing resource to ensure the value is maintained.

I will leave you with a view from James Bach, who is a software testing author and one of the main contributors in the software testing field.

‘James Bach suggests, testers help to defend the value that's already there, or help to identify ways in which value may be lacking. Testers raise questions and make observations; the people who make decisions based on those observations are the ones who add value. We help them do that, but we don't do it intrinsically on our own.’ (3)

References:

1 http://software-testing-zone.blogspot.com/2008/10/software-testing-add-value-to-project.html

2 http://www.developsense.com/2008/03/breaking-code.html

3 http://www.developsense.com/2008/10/while-back-i-wrote-post-on-breaking.html

4 http://codeidol.com/other/Software-Estimation/Estimating-Planning-Parameters/21.1-Estimating-Activity-Breakdown-on-a-Project/ (table 21-7)

5 http://www.infoq.com/news/2009/01/tester-to-developer-ratio

______________

Hopefully if I get myself sorted my next article will be about how we can learn to improve how we use exploratory testing from watching how children play and learn.