> As for quality, and running long tests, the question I have, is this
> most fiscally responsible way of getting "Good Enough Software"?

by "this" you mean "determine what needs to be tested and the best way to test"?

I certainly can't think of a better alternative! And you're right it
is going to be very context dependent.

wrt "the best way to test", while it is context dependent, there are a
few guildines that I like to consider:

1. the sooner you learn about a problem the cheaper it is to fix,
thus the highest value comes from the test that provides feedback the
soonest. in practical terms this means that tests that run
automatically after a check-in/build will provide more value than
those that require human intervention, and among automated tests those
that run faster will provide more value than those that run slower.
thus my question about "how long does the test take to execute?" -- I
don't want a slow test getting in the way of the fast feedback I could
be getting from other tests; better to buy a separate machine to run
those slow ones.

related note: imperfect tests that are actually running provide
infinitely more value than long automation projects that spend months
writing testing frameworks but no actual tests. 'nuff said?

2. test automation is a skill like any other: you will improve with
time, you will improve more quickly the more time you spend doing it
and you will improve faster the more you push yourself past your
current limits. over time what seemed hard to automate will become
easy, which seemed like it required a long time to run will become
fast (or at least seperable into fast/slow components). Ron often
makes this point and it is a good one. don't accept the assertion, the
assumption that "there's no way to automate it". probe with question
like "is there some way to automate part of it? is there another test
we can automate that would catch some of the same problems?"

3. there is no way to automated judgement. no matter how much
automation you have you still need a real person trying to (at least
periodically) use the software and ask the question "will our end user
be able to accomplish their mission using this software?"

anyway, there's my contribution to the philosophical part of the
discussion and glad to hear you were getting value out of the
conversation.

Jtf

On 3/30/06, ericmnachman <ericmnachman@...> wrote:
> Actually, I am really enjoying this discussion and am learning a
> lot.
>
> But the conclusion I have come up with is that, based on the project
> (context) we have to determine what needs to be tested and the best
> way to test, and get away from the labels of what type of test we are
> running. (Convincing upper management is a different story).
>
> As for quality, and running long tests, the question I have, is this
> most fiscally responsible way of getting "Good Enough Software"? I
> assume that too will depend on the context of application and the
> goal of each release and or iteration.
>
> Eric
>
> --- In agile-testing@yahoogroups.com, "Jeffrey Fredrick"
> <jeffrey.fredrick@...> wrote:
> >
> > well I'm sure eric will have no fear of getting caught up in
> > definitions of testing terms now...
> >
> > Jtf
> >
> > --
> >
> > http://www.developertesting.com/
> >



--

http://www.developertesting.com/