Sunday, June 1, 2008

Regression Testing

Regression Testing

Usage:

  • All aspects of system remain functional after testing.
  • Change in one segment does not change the functionality of other segment.

Objective:

  • Determine System documents remain current
  • Determine System test data and test conditions remain current
  • Determine Previously tested system functions properly without getting effected though changes are made in some other segment of application system.

How to Use

  • Test cases, which were used previously for the already tested segment is, re-run to ensure that the results of the segment tested currently and the results of same segment tested earlier are same.
  • Test automation is needed to carry out the test transactions (test condition execution) else the process is very time consuming and tedious.
  • In this case of testing cost/benefit should be carefully evaluated else the efforts spend on testing would be more and payback would be minimum.

When to Use

  • When there is high risk that the new changes may effect the unchanged areas of application system.
  • In development process: Regression testing should be carried out after the pre-determined changes are incorporated in the application system.
  • In Maintenance phase : regression testing should be carried out if there is a high risk that loss may occur when the changes are made to the system

Example

  • Re-running of previously conducted tests to ensure that the unchanged portion of system functions properly.
  • Reviewing previously prepared system documents (manuals) to ensure that they do not get effected after changes are made to the application system.

Disadvantage

  • Time consuming and tedious if test automation not done

When to Stop Testing

This can be difficult to determine. Many modern software applications are so complex, and run in such as interdependent environment, that complete testing can never be done. "When to stop testing" is one of the most difficult questions to a test engineer. Common factors in deciding when to stop are:

  • Deadlines ( release deadlines,testing deadlines.)
  • Test cases completed with certain percentages passed
  • Test budget depleted
  • Coverage of code/functionality/requirements reaches a specified point
  • The rate at which Bugs can be found is too small
  • Beta or Alpha Testing period ends
  • The risk in the project is under acceptable limit.

Practically, we feel that the decision of stopping testing is based on the level of the risk acceptable to the management. As testing is a never ending process we can never assume that 100 % testing has been done, we can only minimize the risk of shipping the product to client with X testing done. The risk can be measured by Risk analysis but for small duration / low budget / low resources project, risk can be deduced by simply: -

  • Measuring Test Coverage.
  • Number of test cycles.
  • Number of high priority bugs.

Definition of: deployment

Installing, setting up, testing and running. This military term, which means the placement of troops and equipment in the field, is widely used with computers as an alternate to the word "implementation." For example, "XYZ software deployment" is the same as saying "XYZ software implementation." To "deploy" something is to "get it installed and running."

No comments: