Justifying a Testing Group

Has anyone had to write up a justification for establishing a testing
unit in an I.T. organization? I would appreciate any kind of sample
writing that you may have. The audience is a head of Finance.

nyeric65 wrote:

> Has anyone had to write up a justification for establishing a testing
> unit in an I.T. organization? I would appreciate any kind of sample
> writing that you may have. The audience is a head of Finance.

Software development will go faster, hence it will cost less per unit of
functionality.

--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]

On Wed, 04 May 2005 20:02:43 GMT, "Phlip" <phlip_cpp@yahoo.com> wrote:

>nyeric65 wrote:
> 
>
>Software development will go faster, hence it will cost less per unit of
>functionality.

Good luck selling that concept with a finance person.  They want to
see ROI (Return on Investment).  Try a few of the following questions
to spark to thought process.

How much does it costs the company today to do software development?

How much of that is spent reworking your product due to customer found
bugs or, better stated for your situation, can you measure lost
company productivity due to system downtime because of untested
software?  For instance, if IT introduced a bug and the entire system
halted and your typical worker lost 80% productivity, you could
establish a "typical" hourly rate and multiply it by the number of
workers and multiply that by the downtime to produce a cost.  You
could also compute this it the bug only partially affected the system
or only affected a part of the organization.

How much is it going to cost to establish the test group (salary and
equipment).  How much will it cost to maintain the test group?

How much will you decrease the lost productivity cost by having the
test group?   How much will it cost to reduce lost productivity?

Summarize:

We spend A$$ in lost productivity/year because of untested software.
Compute this for several years if possible.

It will cost us X$$ upfront to establish the group + Y$$/year to
maintain the group.

We project we will save Z$$/year by having the test group.  "Project"
is the operative word here.  It is your best guess and you will need
to be prepared to justify this.

Computing ROI will be tricky, because the cost will probably outweigh
the benefit.  You might try to come up with a few "intangible" costs
to support your cause.  If you were selling your product, intangible
costs would be projected loss of sales due to poor software
qualilty/poor company reputation, loss of sales due to a product
coming on the market late, etc

Show them the money!





Wayne Woodruff
http://www.jtan.com/~wayne

Thanks. This should be very helpful.

Wayne Woodruff wrote:
 
>
> Good luck selling that concept with a finance person.  They want to
> see ROI (Return on Investment).

"Unit of functionality" means shorter iterations, so you can show (not just
promise) a measurable ROI after the first w.

Embed a pro tester with a team, to write unit tests for their activities.
Don't make a "testing group", meaning a team that receives product over a
wall, tests it, and throws it back over the wall. The pro tester and
developers should all write unit tests as they write code. The tester's job
is to convert requirements to executable specifications, tune the test rig,
and collect metrics.

Relentless testing permits frequent releases of the highest business value
features, so the ROI is measurable. Further, you can start by adding just
one tester to a project. No "group". Get her or him in for contract, and see
if the system sticks.

--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]

>
>Relentless testing permits frequent releases of the highest business value
>features, so the ROI is measurable.

How are you going to show the Finance person ROI?  You are asking the
Finance person for $$, they want to know if and when they are going to
get their money back and how much profit they are going to make on the
investment.

>Further, you can start by adding just
>one tester to a project. No "group". Get her or him in for contract, and se
e
>if the system sticks.

That is a good idea.

Wayne Woodruff
http://www.jtan.com/~wayne

Wayne Woodruff wrote:
> 
value 
>
> How are you going to show the Finance person ROI?  You are asking the
> Finance person for $$, they want to know if and when they are going to
> get their money back and how much profit they are going to make on the
> investment.

Within one w, one tester embedded with one team can show a higher
velocity. If the team is working on high-business value features, they can
demonstrate those features, after one w. The potential value of the
features might not yet exceed the wages of the tester. The point is this is
a _measurement_, not an estimate or promise.

--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]

While I understand and appreciate Phlip's perspective--he's an
Agilista--I'm not sure that a tester embedded with a team will
/necessarily/ show higher velocity--leastwise, not immediately, and not
in so simple and direct a way that a head of finance will see it.
Remember that the Orginal Poster (OP) apparently wants to establish a
testing group, which sounds like there's a paradigm shift about to
happen at the company.  In fact, it would be possible for a tester (for
a while, at least) to slow a development group down while it addresses
the risks and issues that the tester finds.  As Jerry Weinberg says,
"If you don't care about quality, you can meet any other requirement."
Quick time to market is a wonderful thing, but the company might want
to consider /what/ is getting to market in that quick time.

Thus the OP might want to consider an alternative route:  rather than
return on investment (which is very difficult to show), reduction in
risk (still difficult to show, but potentially appealing to the
interests of financial types).  In the kind of testing that I advocate
and teach, testing is strongly focused on identifying and reducing
risk; helping management make informed decisions by providing it with
timely, credible information on the state of the product; thinking
critically about software.  There is considerable downside risk in
untested software.

Note, too, that return on investment comes from /skilled/ testers.
Unskilled testing tends to reveal little useful information, and thus
tends to have little value.

---Michael B.

Developsense:  Software Testing in Plain English
http://www.developsense.com

Michael Bolton wrote:

> While I understand and appreciate Phlip's perspective--he's an
> Agilista--I'm not sure that a tester embedded with a team will
> /necessarily/ show higher velocity--leastwise, not immediately, and not
> in so simple and direct a way that a head of finance will see it.

Totally. If y'all set the goal of "show ROI", but the tester gets sabotaged
in any number of ways, including lack of co-location, including no
permission to change code, including no permission to order developers to
run the tests, then the tester will have to get very lucky...

--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]