Hi!
Bernd Eilers wrote:
Why not mix it?
I forgot something:
As described in the "tool support for life-cycle testing" in "Software
Test Automation", Mark Fewster & Dorothy Graham, Addison Wesley, 1999,
ISBN 0-201-33140-3, on page 7, the "tool support is available for
testing in every stage of the software development life cycle". As they
did not mixed them we also should not do it because they have different
views (e.g. testing =! debugging, so a debugging tool =! test tool).
We are talking about differnt tools:
- Coverage tools (Unit tests)
- Debugging tools (Unit tests, integration tests)
- Dynamic analysis tools (Integration tests)
- *Test execution and comparison tools* (between integration-
and system tests)
The last stage is what we're talking about here.
It is not the last stage at all in the V-model. 'Accpetance test' is the
last one but is near to the customer and the costs, hardware resource
and time consumption is very high (the software application has to be
completely build and <sometimes only in parts> installed) that highest
level of automation makes sense to get these work done.
At OOo QA community they are already using this execution test
automation to get the work faster done but the full automated test
process is only being done by QA inside Sun where a defined IT
environment helping to get this done. The tests are being executed by QA
engineers and software test automators but these resources are very
limited (we have less testers than developers and less test automators
than testers).
The goal for Joerg was and is (and we support this idea) to abandon any
manual work by the limited testing resources on the test execution in a
well defined environment (like tinderboxes) and to do that in front of
the QA process (maybe together with the build tinderboxes) to save the
resources there for doing deeper functional testing of newly introduced
features.
The test automators would have to put their workflow from the MASTER to
the CWS to support the deveopers if they change the behaviour of the
office application which would break tests. We, the test automators,
would fix the defects in test scripts there where they have been created
first time. The new MASTER would be free of that defects and creating
CWSes on that base will be much more fun.
Upps, now I have described it again but hopefully it helps to share the
view that we do not want to make something new, we just want to automate
a nearly full automted process and put it from the MASTER to the CWS.
Cu,
Jogi
http://qa.openoffice.org/qatesttool
http://wiki.services.openoffice.org/wiki/User:Jsi
--
Sun Microsystems GmbH Joerg Sievers
Nagelsweg 55 Quality Assurance Engineer
20097 Hamburg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
