By Peter Walen

The value in testing is an intangible item that people may not easily grasp and some may refuse to acknowledge.  We don’t make the software people will be using.  We don’t always detect and report every bug that is hidden within the software.  We may not have the same perceptions and views of others on the project team or in the greater organization.  This is a problem we have as testers and is inherent in our calling.

When organizations direct their test teams to focus on the verification of the documented requirements, the chance of changing the views of testing is minimal.  When budget cuts come, the areas with little or no perceived “value” will be directly impacted.  We have seen this over the last several years time and again.

Scripted tests that are aligned with documented requirements are at the heart of work of this nature.  Still, context aware and context driven testers may find themselves in situations where part of the context involves these scripts.  In what way can we add value?

Where does value come from?

Our value, as professional thought workers, comes in our ability to think clearly and ask questions of people in the project.  We add value by raising issues and concerns that others have not.  We add value by building on our understanding of the business intent of the software solution, not merely the documented requirements.

When objections are raised to bug reports we write that we are not looking at the “right things,” or we are doing things “wrong” have we stumbled upon a failure in understanding of ours, or of others in the project team?  When the bugs are dismissed as “not technical” or “business created content” that hasn’t been finished yet, how is something “not technical” resolved?  How is the content of the page, what people will see when working with the system, not a concern to the readiness of the system?  How does one help others understand the state of the software by ignoring these components?

We do not ignore them.  We talk about them in public with the project team.  We explain their impact on the usefulness of the software.   We demonstrate what the software looks like and how it appears right now.

By doing these things, I have found that the value in testing is not found in bug counts, nor pass-fail ratios nor in defect-detection and removal rates.  The value from testing is found in the satisfaction of the business stakeholders who chartered the project in the first place, and in the comfort and ease with which our customers can use our applications.

We don’t make the software.  We help people make it better.