I just got my latest copy of Better Software magazine and found an article about the "worth" of testing (article is "Proving our Worth, Quantifying the Value of Testing" by Lee Copeland).  In it he discusses the "value" we as testers bring to the Software Development equation, and states that our main goal is to provide "information" to all the other parties associated to a project.  I agree totally with this statement.

As testers our main goal is to "find" things out about the system under test and to disemminate the information to the concerned parties on the project.  We are in essence the CSI of the software world; we use deductive reasoning and experiments (tests) to try to determine what is going on and what caused it to happen.  Then we tell the proper authorities about our findings.  As Lee stated in his article, the context and quality of our information is what lends value to the project and that is one of the factors that proves our worth in whole.

Which leads me to the premise of the title of this entry; we (testers) are in the middle of it all.  We are the central focal point, or "hub", on the software project wheel.  A lot of other groups revolve around us and rely on testing to "interconnect" them.  Information flows in and through the Testing/QA group during the project.  Now this may sound a bit self-absorbed and egotistical, but it is the truth.  And it is one of the reasons testing is one of the more politically hot areas on a project.  Testing/QA lives in the limelight and under the microscope, whether we like it or not.  Testing/QA is at the center of the process wheel, or eye of the storm as some would say, and we are responsible for holding together the rest of the groups via the information we provide.  If we are not good at doing that then the rest of the wheel is unstable and will break apart.  And even at times where testing is not responsible for something in the process we still get the blame and heat for it.  Price we pay for being in the middle of it all.

So in conjecture to the article, is it really worth all the headaches and pain associated to the work we do on the project and in the information we try to bring to the table?  Yeah, because we do a "worthy" job and provide "value" to the project.  And in some respects it is fun to be in the middle of it all.

Quality is a perception to a large part.  We can talk about "Good Enough" software quality and other aspects for reasons for higher standards.  But it does all boil down to money.  How much you keep and make, basic economics.

As an example, when I was at Peter Norton Computing we (the manager and I) started the QA/Test group.  PNCI had been in business for 7 years prior and doing quite well without a QA/Test group (developers and others did their own testing).  But they had just lost their market dominance to Central Point Software (PC Tools).  PC Tools had more functionality and variety in its suite.  PNCI management decided to expand product functionality of the Norton Utilities and also expand product line (added Norton Utilities for Mac, Norton Backup, and Desktop for Windows, the Norton Anti-Virus was brought in by Symantec).  They recognized in order to maintain the already high level of 'quality' in the software that they needed to have a specialized group doing the testing and let development do pure dev. work.  They made the investment into the Testing/QA area and supported it fully.  Thus we started cranking out the software.  We implemented basic processes and test metrics to evaluate the 'quality' of the software and aid in decisions for releases.  We set certain 'quality' levels and once we attained them we released the product.  It wasn't 'perfect', but a good bit better than the competion.

This was all done to 'improve' the 'quality' of the software and allow the company to regain its market dominance.  Which it did, the products were winning PC Magazine Editor Choice awards left and right.  Typically one of the aspects they won on was due to product reliability & quality.  Their investment paid back in spades.

Our customers loved us for it, and bought a lot of product.  But at times when the perceived quality went down we got dinged hard for it.  And management made the changes to get things straightened out (didn't lay people off, but did other things to let Test and Dev. produce a solid product).

PNCI/Symantec made and kept alot of money because of this back then (89 to 92).  And the 'quality' of the products was high.  The market told us how much they valued functionality AND quality.

This is one case of management seeing the value of Testing/QA and how it could help them make money.  All during this period of time we (Test/QA) educated management on what was involved with Testing/QA, and they were smart enough to recognize the value and invest in it.

Jim

A few years back I was at a conference and attended a talk that opened my eyes to why the majority of my efforts in trying to get management to "Get It" in regards to the need for testing were failing.  It wasn't them, it was me.

I didn't understand the "language" I needed to be speaking to them with.  I was focused on the technical aspects and implications for the project.  Instead I needed to be focused on the economic implications and impacts to the company.  Management deals in money, dollars and cents for you in the U.S., and how much they will make and/or keep from a project/product.

It comes down to "selling" Testing/QA as a "Cost Containment" mechanism (not Cost Savings, that sets a false expectation).  The cost containment comes in checks and balances to make sure the money being spent is done so properly and that if there is any leakage (rework) that it is kept under control.  Project cost leakage (rework) is one of the top reasons why projects go over budget and over time. 

Probably the best tool to use to sell management on Testing/QA is the Cost to Fix curve.  Basically the curve shows that the earlier a defect is found and fixed the lower the cost.  But here in lies part of the sales job problem, most people only go that far.  What needs to be done is to show the relationship between when a defect is introduced and when it is found/fixed and the associated cost with the rework of the system (a cumulative effect).  This definitively shows the relationship in economic terms that will catch managements attention. 

For example, a defect that is introduced in the Requirements phase and not fixed/found until the Testing phase is expensive to repair (longer time in between) and the amount of rework to remedy the defect compounds the overall cost (initial cost + rework cost  = total cost).  Now if a defect is introduced in the Requirements phase and found/fixed in the Design/Coding phase the cost is lower (flatter section of the curve) and its rework cost is now minimized (containing the leakage).  Even if the defect was introduced during the final stages of Coding and found/fixed in the Testing phase the cost is minimized (a steeper part of the curve, but the cumulative effect is minimal) because the rework cost is minimized too.

Now this information can be shown to impact "hidden" money factors that affect the immedite project and the company in the long run.  This leads to impacts on the Profit & Loss (P&L), EBDCITA (Earnings Before Debits Credits Interest Taxes and Amortization), ROI (Return on Investment) and Revenue Stream (short term and long term).  These impacts can be hard dollars (over budget or not making revenue because product is not selling or cost of rework after release) or soft dollars (future business lost due to credibility issues).  This is what the presenter called getting into the GOOB zone (Going Out Of Business).  Showing this will definitely get managements attention.

So how does Testing/QA help to keep this all under control.  Easy, by providing the service of validation of the system (Testing, from the beginning) and monitoring of the project (QA) with review milestones.  This takes the form of the medical principle of "a pinch of prevention is worth more than a pound of cure".  In money terms this makes the statement that a small up front investment can provide a very large return in the end.  How to leverage that small amount of money to counter balance a large one by shifting the balance point.  This is what management understands. 

What Testing/QA needs to do is "sell" this aspect of our contribution to the project; to change the language we talk in to one that management understands and will "buy in" to.  As the old saying goes "Money talks, B.S. walks!"