Tuesday, 26 January 2010

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.

Thursday, 7 January 2010

Testing Terminology – definition or context?

Hello and Happy New Year

One of my New Year resolutions was to start using twitter more so that I could micro blog some of my thoughts.

One interesting topic that appeared to be going around was one of changing testing definitions and descriptions. This caused quite an animated debate amongst testing twitters.

So I thought I would use more that 140 characters and put across some of my thoughts and views on the subject of testing definitions.

I used to have the view that it was good to have a set of definitions for testing terms such as what is Acceptance testing, What is black box testing etc. The ISTQB has a document for this on their website (www.istqb.org/downloads/glossary-1.2.pdf)

The problem with this glossary is that it applies testing meaning with no context and that is the problem I find with trying to define testing terminology to do so requires context. If I wish to be somewhat controversial I should state that this is the problem I find with the ISEB and ISTQB examinations especially the ISEB foundation level which is based upon multiple choice answers. Some of the questions could in certain situations have multiple answers but ISEB only accept their definitions and do not allow the natural questioning skills of the tester to debate the answer.

For example let us look at the testing term ‘Acceptance Testing’

ISTQB define it as

Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.

However if I would add the following context to Acceptance Testing:

The development team requires some form of automated Acceptance testing (Yes Michael I know if you are reading this it should be checking not testing - http://www.developsense.com/2009/08/testing-vs-checking.html) on the build machine before signaling that the build is suitable for release to the testing team


…would the above definition hold true?