Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>A good QA department will do several things:</p> <ol> <li>Write a test plan according to the functional specification of the product. This helps flush out the functional spec and find areas where it needs to be improved/changed.</li> <li>Find bugs in the product This one is obvious.</li> <li>Test the usability of the product from a non-developer point of view. This one goes far beyond finding bugs - it doesn't do you any good to have a bug free product if no one can figure out how to use the thing.</li> </ol> <p>As to how they fit into the process:</p> <ol> <li>As soon as the development team feels that the functional spec is complete, it is given to the QA team so they can write test plans</li> <li>When the development team has a relatively stable build with a reasonable amount of functionality, it can be given to QA so they can start looking at it. At this point, QA's focus is just to get familiar with new release and point out any glaring usability flaws rather than hammering the thing to find bugs.</li> <li>Once the developers say "ok, I think we're ready", QA starts the bug finding mission.</li> <li>Developers and QA work to resolve all issues. Bugs are all fixed, dropped, or postponed to future releases.</li> <li>QA has final say on whether or not the release is let out the door</li> </ol> <p>Note that 3 and 4 above can vary a lot depending on whether you're talking about a new product or a release of an existing product. If you have an existing product, and awful lot of testing can be done in parallel with development.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload