Regression testing
Introduction
One of the highlights of the quality of software testing is to conduct a so-called regression testing. Often, this group of tests is carried out not in full or not done at all. The purpose of this article – to give a brief description of regression tests, highlight the key provisions of topics.
Definition
Under the regression testing to understand the types of tests are conducted with each new version of the program. In other words, the regression tests – a kind of "old songs about the main." The purpose of these tests is simple – to make sure that the new version does not contain any errors in previously tested code sections. According to foreign authors the number of errors in the code changes (bug fixes, implementing new functionality, etc.) ranges from 50% to 80%. To identify these errors and regression tests can help.
Types of tests of regression
Thus, regression testing – the concept is complex. Consider the main types of tests of regression:
- Verification Test.
Tests verification bug (Bug Verification Test). Represent tests for bug fixes. Here is an example. Assume that the test number 3 has revealed a bug that was zafiksrovano and fixed by developers. After a while you got from the developer a new version of the program, with information about that bug opisnny isparvlen. Your task – to test number 3 again – to make sure that the bug is really no longer appears. In the case of passing the test this bug is marked as Verified, otherwise – as a re-do, as reported by the vendor and sent back for revision. Carrying out such tests is mandatory. Since the reasons for which corrected a bug can remain in the program – set (from an erroneous description, and, perhaps, understand the problem, to an erroneous claim that the correction has taken place).
Tests verify the version (Build Verification Test; Build Acceptance Test, smoke test, quick check). Are a set of tests to check the safety of the main features in each new version. In other words – this is a quick test of all the main functions of the developed software, which aims – to make sure that the program is "working fine", that the basic functionality is not compromised. If at least one of the tests verifying version brings bug – the tester comes back to the previous one (the last "working"), further testing the new version does not meet, and the error information is entered into the database and sent to the developer. Thus Verification tests are a short version of a set of basic functionality tests.
Actually regression tests (or Regression Test Pass). Under this concept, combine those tests that have already been held with previous versions of the program, though successful, is found no bugs were reported (eg, TCM) as a pass (passed). The need for such tests is obvious. Here is an example. Assume that the early tests ¦ 2, which provided a check in the program code section (we call it conditional code-A) did not reveal errors in the program, and was marked as pass. During development it became necessary to change the area code-A (for example, when correcting a bug or some other program or make a new functionality). As a result of this code section requires additional testing that will be done when re-administer the test.
- Among the proper regression tests can be divided into two groups. The first – the tests included in the set (eg, Regression Test Pass with Regression Test Suit), the other – the tests are not included in the set (eg, Regression Test Pass without Regression Test Suit). Significant differences between them are as follows: first – entered into the database and are described, they can and should be set up scripts that can automate the testing process, the second – there are only "head" of the tester and carried out by hand, the reasons may be many – from small-time testing to a lack of the necessary software to automate the process.
- Regression tests on the "closed" bugs. Consider an example. Assume that the test ¦ 3, revealing a bug after fixing a bug that the developer was repeated, with what success. The test has been marked as a pass, a bug – as Verified. This bug is deferred "on the shelf," "case" is closed. This bug will be "closed". Now assume that during development, code segment, where the bug has been fixed has been modified or replaced by a developer who accidentally deleted the "nashlepku" code in correcting this glitch, and showed him an extra, etc. In this case, the bug will appear again. What would prevent such a beta tester from time to time to perform tests that detect bugs earlier in the modified section of code, correcting that already has been tested previously and recorded in the database. This is the regression tests on the "closed" bugs.
When and how?
On the question of when and how to conduct regression testing, which tests and put in first answer is not simple. All software developed by the form, duration of the life cycle, timing of testing, the number of team members.
The following are only general provisions:
- Regression testing is carried out in each new version.
- Begin regression testing with Test validation version. If the program comes from the developer as a full installation, the verification tests begin with a test installation, and then provides a brief set of functionality tests. If at least one test failed, version sent back for revision, regression testing is terminated and returned to the tester to test the latest "working" version.
- Upon successful completion of the verification test version, performed a series of tests verifying bugs.
- Actually from the regression tests performed, only those that involve changes in the new version of the piece of code.
- Similarly (see paragraph 4) are selected tests in a group of regression to the "closed" bugs.
- Regression tests performed successfully (pass) twice considered "closed". Further use is made as described in paragraph 4.
- For our tests, regression, to be held 3-5 times more encouraged to write scripts to automate the process. This applies to vsemgruppam test regression.
- Final selection of tests for regression testing is carried out on the following principles:
- First of all selected tests rejected (failed) two or more times. Including those identified bugs that needed improvement (re-do).
- Secondarily selected tests rejected once, and successfully passed again.
- Next, select all the tests that were completed successfully (pass), but performed only once.
Then carried out all the other tests, depending on the task at hand.
See Also