Monthly Archives: December 2012

A better name for testing

The word «testing» conjures up images of people manually entering values and clicking on buttons according to a script. The implicit low value of the word contaminates the perception of the activity: testing is donkey work that can be easily off-shored, it is cheap and so should testers.

In a previous post, I offered the following definition for testing: a strategic business project which seeks to confirm the alignment of systems with stakeholders’ expectations for an optimum initial cost in a manner that can sustained or, even better, improved over time.

Focusing on the execution part of the process is a tragic mistake.

What other professions are so poor at selling themselves?

Imagine a world where every profession adopted the same literal approach to naming themselves.

 Instead of We would have
Finance Spreadsheeting
Marketing Fonts Obsessing
IT Cabling
Procurement Purchase Order Processing
Human resources Hiring & Firing
Security Fear Mongering
Sales Contract Signing
Communication Branding & Blanding

Do we use the names in the right column (on a regular basis as opposed to from time to time in fits of rage)?

No, we don’t.

Testing is an engineering process.

What is the desired output of this process?

Quality.

Let’s call it quality engineering then.

 

A specific fishbone diagram for software problems

In 1968 Kaoru Ishikawa created a causal diagram that categorised the different causes of a given problem. The fishbone diagram, as it is also referred to, was particularly well suited for the manufacturing industry where it was successfully used to prevent potential quality defects.

Ishikawa Diagram

One way to look at the diagram is to see it as a recipe: use all the best ingredients and you will be rewarded with a delicious dish, degrade the quality of one our several ingredients and you get a less savoury result.

For instance here is the recipe for bad coffee.

Bad CoffeeIt is very tempting to try and use this diagram in the context of software engineering.

Don’t we all have our own secret recipe for bad software?

Unfortunately, this diagram is not as well suited for software engineering as it was for manufacturing. I have therefore come up with a new version of this diagram for software problems.

Using the recipe metaphor, what are the ingredients required to build great software?

For me it’s clarity, time, motivation, skills and tools.

Clarity (I don’t understand it)

To write good software, having clear requirements is clearly required!

Clarity should be achieved through good requirements management practices such as the ones described in my previous article.

Time (I don’t have the time to do it)

Estimations are the output of planning processes. If not enough time has been allocated for the task then one might be tempted to cut some corners and put the quality of the result at risk.

Motivation (I don’t want to do it)

If all the other ingredients are gathered then the developer can technically do what is expected of him. But will he do it? Will the resulting code be stellar or botched? That depends on its motivation. It’s the project manager’s job to make things happen.

Skills (I don’t know how to do it)

This one covers both expertise and method because one can compensate for the other. An experienced programmer can debug a program in a language he doesn’t know because what he lacks in expertise he can make up for with method. Granted, he will take more time to complete the task than an expert.

Tools (I don’t have the tools to do it)

Tools also have an impact on software quality. Building software on top of a solid framework reduces the amount of code to write and therefore the likelihood of introducing mistakes. Static analysis tools can catch potential issues as code is written and further improve the quality of the code. Lastly, the availability of test assets increases the confidence of the team to improve its code while keeping the alignment with the requirements.

Software Problem Diagram

This diagram can be used for risks identification purposes and thus can guide the actions of the project manager in order to achieve better software projects.