Hi Rene,
Rene Engelhard schrieb:
Or imagine such a test run (failing or not) short before a release,
where you have a small CWS fixing a showstopper only. We don't really
want to have a mandatory 3 day delay in such situations, do we?
Best example currently: cws freetypettg. tiny *security* patch.
(As the freetype issue is public anyway I can say this here)
6 days from RfQA to QA approval (running tests?), now we are on the 8th
and miss the release date because rc3 will only be uploaded today/monday
(why do we need a rc3 anyway?) and keep our users one week more with open
security issues.
Even the *current* procedures produce such useless delays, what if we
would have such mandatory things?
Regards,
Rene
It can be just the opposite. In cases where automated test runs are the
reason for the QA time being quite long, the proposed changes also offer
a chance to speed up the process, as the developer now has the chance to
run the automated tests himself on his machine. So if the machine power
of the Hamburg QA for automated tests is the bottleneck, and your CWS
lands in a queue of CWSs to run tests on, you can relieve this
bottleneck and run the tests yourselves.
And in cases where machine power is not the bottleneck, then the
automated tests can be done in parallel to the manual testing. So also
in this case there should not be a significant delay.
Regards,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
