Some other reasons for low automation takeup.
1) The software is expensive, typically too expensive for a single project
to afford
2) It does take longer to automate. If the testing project timeframe is
tight, then automation can be eliminated immediately.
3 Automation paradox: Any rapid development may never be stable enough to
justify the time to automate it, until later releases. The cost of
automation and time required may prevent it being done in a later release,
especially if the life of the product being tested is uncertain.
4) Any automation is a complex mini-project that comes with a risk of
failure. If a test or project manager has to guarantee a tested product, it
is safer (and faster) to go the manual road.

One of the solutions is the one raised already by Erik Meade, "Add
an acceptance testing task to every story". Give a healthy estimate for it,
and argue that it is the only sensible way for a customer to ensure that
they can check that their app works over time, with the cost effectiveness
coming in the long term.
I would argue that the automation team needs to be a closely managed
sub-project, with staff dedicated just to the automation. with a good
people-person manager to liase with the customers. It is too easy for a
developer to decide that their priorities lie in polishing the automation
programming, rather than working on the real app, or for a tester to decide
that they will learn to program by overworking the automation.
cheers,
Erik

Software Testing Consultant
ANZ Banking Group
Australia


> -----Original Message-----
> From: Lisa Crispin [mailto:lisa.crispin@...]
> Sent: 09 November 2001 05:28
> To: agile-testing@yahoogroups.com
> Subject: [agile-testing] Re: testing non-web GUI
>
>
> My experience is like Ron's in that many organizations I'm familiar
> with do not automate at all, or very little, possibly for
> load testing
> and nothing else. This includes organizations who say they are doing
> XP. Some potential reason:
>
> 1. A lot of testers do not have a programming backround so it can be
> difficult for them to learn how to create automated test scripts and
> they have a lot of fear about it.
> 2. Capture/playback tools alone don't help, see 1.
> 3. Lack of support from management and even from development: "just
> get the testing done so we can launch". This is worst when you have
> testing on the "back end".
> 4. Lack of understanding of the value of automating tests other than
> unit tests, even among developers on XP projects.
>
> Some things that can be done about it (although I admit to struggling
> in this area myself):
> 1. Put testers and developers on one team
> 2. Make the whole team responsible for executing and for automating
> acceptance tests
> 3. For each release, if you have any automated tests at all,
> document
> as best you can what value they added (time saved, bugs found)
> 4. The getting support from management and development one is hard,
> but find someone who sees the value of test automation and
> get them to
> help champion the cause
>
> Other suggestions? Because these are working some for me, but
> sometimes I get discouraged fighting the same battles all the time.
> -- Lisa
>
<snip>
> > I might mention that in the projects I visit, even the ones that
> have
> > large and presumably competent QA departments, few (usually zero)
> > tests are automated. That seems to be very much the wrong proportion
> > to me. What do folks here think?
> >
> > What is the cost of automating a test that doesn't need it? What is
> > the cost of NOT automating a test that DOES need it?
> >
> > Ron Jeffries
> > www.XProgramming.com
> > Life tough is. Then die you do. --Yoda (personal communication)
>