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!"

For the new comers there are some things to learn when starting this line of work. 

First, it will be a continuing process of learning.  You will always be in the learning mode in your job, be it learning the technology or how the business works.  Be continually looking for new information on the subject of Testing, it will help you in your efforts because someone else may have already been there and you can learn from them.  Don't re-invent the wheel.  There are magazines, books and other items to read.  Read them!

Second, give yourself a break.  You will not be Joe Stud Tester on the first day.  This work is both craft and engineering, it will take time to get it. 

Third, get used to being in the spotlight under the microscope.  Being in a Testing position will put you at the center of things during a project.  Learn to deal with it and the things that come with it. 

Fourth, don't take it personally or make it personal.  It is your job to find things and point them out.  You will take a lot of heat for it, and don't dish it back out because it will only make things worse for you. 

Fifth, always be inquisitive and trying new things.  By being inquisite/curious and entraprenurial you will keep up the motivation to do the work.  Because at times it can be monotonous and a headache.

Understand that your work involves performing tests.  This includes knowing how to research a test (review specifications / use cases), write up the process (create a Test Plan and Test Cases, define needed data), setup the test (both the environment and the data needed to execute the test), execute the test (run the test and manage its execution), analyze the test (what worked and didn't work and why), report on the results (write defect reports and execution summary reports), and communicate the results of the test (publish your reports and talk to other people about them).

Learn what the technology is and how it works.  You don't have to know it in depth but understand the basics of what is going on.  Know how to get in and get 'dirty' with the technology.  It will help you be more effective and efficient.

Understand programming and how it is done.  You don't have to be a super programmer, but know how to code and why things are done a certain way in the code.  It will help you in your testing effort and later on with automation will allow you to create your own code properly.  It will allow you to understand how to hook the application under test and drive it with the test tool.

Find a mentor to learn from.  They will help you grow in your position and this line of work.  Again, don't re-invent the wheel.  You gain knowledge and experience by working with someone who has knowledge and experience.

More later....

I figured I'd better explain this one.  This came about as a tangent on the "Resistence is Futile, Individuality is Irrelevent" saying of the Borg in Star Trek: The Next Generation.  I came up with this when I met Scott Adams (creator of Dilbert) at a book signing in Denver.  He was promoting his book "Way of the Weasel" and told us if we wanted a saying included with his signing to write it on a sticky note along with the book.  I did it, and I put "Testing is Irrelevent, Shipping is Futile" on the sticky note.  I handed the book to him and he busted up laughing when he read the note.  Everyone else in the line looked at me strangely.

Scott (no we are not on first name basis) looked back at me after laughing and said "You must be in the industry".  Of which my reply was "Yep! And if you want to use it just some how give me a credit.  Oh, by the way could you draw me a Ratbert, he is the official tester for Dilbert."  Needless to say I just got a Dogbert (like everyone else) and his signature only.  Bummer.

But at least I have a claim to fame that I got Scott Adams to bust up laughing, and the book is still in my collection.

Jim

For most people they know the meaning of the title of this entry.  It comes from the Douglas Adams book "Hitchhikers Guide to the Galaxy", and is the answer for all things in the Universe.  A bit confusing to say the least, or is it.

This is what is the catching point about software testing.  The answer could very well be 42.  Software is written by Homo Sapiens (okay some of us do qualify as Cro-Magnon's) and as such we are fallable and it means that software is going to be flawed.  Hey, if it was perfect do you think I would have a job and be here writing this blather?!

Because of this we (the Tesitng community) exist and our job is to find the flaws in the system.  Some people call this pessimistic, I like to think it being optimistic.  I look forward to things going wrong.  I have always been an inquisitive person and my natural tendencies to question things has given me the innate skills to do this line of work.

My educational background is in the sciences, specifically Zoology (pronounced zo-ology, not zoo-ology), and my core studies were in classes that dealt with identifiying things and running experiments (labs) to prove/disprove a hypothesis.  Sound a little familiar?  I used the Emperical Methodology, or better now known as Scientific Methodology to conduct my lab experiments.  This involved researching the subject and gathering the requirements to perform the test, determining what my objective is (Hypothesis), designing my test and construction of the test environment, conducting the experiment, recording the actual results from the test, and writing up my findings and reporting on them.  This should definitely sound familiar.

So what does this have to do with Software Testing, practically everything.  For both Manual and Automated (Functional/Regression and Performance) testing we need to go through these steps/stages in order to do our work.  But a lot of times we forget to do them diligently due to time pressures.  This is what causes us to get into trouble.  Now I'm not saying be dogmatic about it, but you need to follow the guidelines in order to be effective in your work.  Process and Methodology are a good thing.

These are basic common sense things to do, and we need to do them.  This leads into the saying of  "using the KISS method, Keep It Simple Stupid!".  Which is saying use a little bit of common sense, or you might get a nasty surprise. 

Even when the answer is 42, or am I not making sense?

Jim