Up Until now I have discussed what we should strive for in the QA.
How ever one must bare in mind that there is a difference between an extensive testing plan and its actual implementation.
One of the best signs for a QA maturity is the ability to prioritize and plan a head taking into consideration the feasibility of an actual test plan.
In the normal flow the QA engineer will map out the entire test plan covering all the little bits and pieces needed to be tested.
The QA team leader will then take the raw plan and organize it according to time table limitations.
This re-organization can be consisted solely from re shuffling the tests order to allow a better , more effective release picture in a shorter time.
How ever in some case a little more joggling may be called for when the time frame needed for a full test cycle exceeds delivery commitments.
When faced with the second option we as QA will need to perform some risk assessment in order to consider which parts of the tests can be dropped.
The risk assessment process is a very critical phase since it calls for an ability to see the whole system ... a wrong assessment will lead directly to system problems on the costumer system.
The risk assessment can and should involve others except the QA team leader.
In any case the tests which were dropped and the risks taken should be voiced clearly in order to inform all of the interested parties to the compromises made in the test plan.
Subscribe to:
Posts (Atom)
Posts
