This can be difficult to determine. Many modern software applications are so complex and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are...
How much of the application has actually been tested (both by unit test and functionally).
One need to assess each potential use case (and parameters for that use case) for likelihood of it actually being used (so you may drop edge cases), complexity (simpler things being less likely to contain bugs, or rather less likely to contain hard to find bugs), cost to test (in terms of time) and potential impact of a defect if discovered in that area (this is where the nuclear reactor vs. blogging platform comes in).
How much of the application has actually been tested (both by unit test and functionally).
One need to assess each potential use case (and parameters for that use case) for likelihood of it actually being used (so you may drop edge cases), complexity (simpler things being less likely to contain bugs, or rather less likely to contain hard to find bugs), cost to test (in terms of time) and potential impact of a defect if discovered in that area (this is where the nuclear reactor vs. blogging platform comes in).
Other Points to be considered are
·Deadlines have been reached, e.g. release deadlines, testing deadlines;
·Test cases completed with certain percentage passed;
·Test budget has been depleted;
·Coverage of code, functionality, or requirements reaches a specified point;
·Bug rate falls below a certain level;
or
·Beta or alpha testing period ends.
·Deadlines have been reached, e.g. release deadlines, testing deadlines;
·Test cases completed with certain percentage passed;
·Test budget has been depleted;
·Coverage of code, functionality, or requirements reaches a specified point;
·Bug rate falls below a certain level;
or
·Beta or alpha testing period ends.
No comments:
Post a Comment