Know More About Regression Testing

Know More About Regression Testing

Regression testing software – error detection on sites previously tested code. This type of testing is carried out after adjusting the program, which may include:

  • Correction of the defect,
  • Merging code
  • Migrate to a different operating system or database as well as any other changes.

The main aim of developers becomes verifying that changes made to the software did not lead to undesirable results (in particular, decreased functionality) and the program continues to meet the requirements.

Phases and tasks of regression testing

Typically, regression tests are performed in stages. First, developers need to find out what all the previously found problems corrected. The second – to determine not played any defects corrected again. The third – to check for failure in the functionality of the whole.

Errors discovered after the test source code and software corrections are called regression. To identify them mainly used the same methods as in the previous test system. A series of repeated tests used to confirm that the changes made to the software did not have a negative impact on its functionality and performance.

The main problem to be solved by regression testing :

  • Rapid detection and correction of errors affecting the functional software
  • Verification of compliance with the modified program requirements put in its development,
  • Maintaining the quality of software when it is amended.

Identification and elimination of regression errors are made ??after each modification program. This kind of testing refers to a complex and costly, but absolutely indispensable stages of software development of any complexity. It is used in areas such as automation of business processes , information systems and many other areas.

To test uses special test cases, which are written more in the initial stages of product development and testing.

Software Maintenance

Perform regression testing involves not only checking, but also further support software. To address the identified defects and flaws, as well as further extend the functionality of the program may be carried out three types of support:

  • Corrective,
  • Adaptive,
  • Progressive.

Corrective maintenance is performed, if the detected defects do not require changes to the software requirements specification. Error correction is aimed at maintaining the program operational.

Adaptive maintenance is carried out during the expansion of the functional software change data or runtime.

Progressive support – all treatments aimed at improving the efficiency of software. This type of support is also called improved.

As part of the adaptive and progressive testing system can add new modules. Terms of Reference with the modified. When corrective maintenance modification TK usually not required.

The main volume of tests performed in the development of any software is necessary on regression.Correction of some errors with very high probability leads to the appearance of others, and this is one of the main problems maintaining software.

Turning to the company “Aplana” You can order regression tests for software of any kind. At your request, testing can be carried out selectively or comprehensively.

Software Test Automation Reality

Software Test Automation Reality

Hello Dosto ( Friends ),

Autotests: Myths and Realities – “Automation: why do it?” stressed the importance of preparation and implementation of automated tests. In the same speech about the pitfalls faced in efforts to automate testing. We consider these in more detail.

Myth : Autotest able to completely replace manual testing. Reality : grounds to believe that approval will be exactly the same as to believe that there is no silver bullet . Self-tests can not be a panacea (and prevention) of all bugs living in the software product. Do you believe that stuffed with electronics robot is able to determine all the ailments of the human body and quickly get rid of them? That would be great. But in fact, intuition, experience, thinking the doctor will not replace such a robot. But he is able to deliver Aesculapius from routine actions that can be clearly defined and regulated. The same in testing .

Myth : Acquisition commercial use or develop their own free tool for writing automated tests is a guarantee of success in the field of Test Automation. Reality : The tool is not a strategy or even tactics. A complete understanding of exactly what, how, when and why we want to test . What are the goals we want to achieve in addition “to bugs was not”? Looking for help in TDD? Interested in regression tests? What functionality, at what level (GUI, API, kernel) we want to check the Autotest in the first place? How much time do we have, and will? How many specialists? What experience? All these and many other questions should be answered even if you select the tool. One thing – easily take the first step (“Oh, my program itself fills out the form!”) And stop at a crossroads, and another thing – consistently replenish library autotests that run with each build. You can not automate chaos. Tool – a tool and nothing more.

Myth : Autotest will significantly save on testing. Reality : Yes, allow it, because they do not need to check the same hand dozens of times. However, cheese is not free: the cost of implementing automated tests can be significant. Autotests eat do not ask, but you need to feed their creators :) And another thing: the creation of automated tests should be seen not so much from the standpoint of “invest now – and then save up to test” how to enhance product quality and speed of its development (subject to coverage and basic functionality regular runs automated tests). In other words, investment in automated testing – a movement forward, the desire not so much to save, how much to buy.

Myth : Posted autotests once, and you can use them until the end of the century. Reality : Certainly not. Product changes – changes and self-test. If the self test is tied to the GUI, then the changes in the user interface can lead to malfunction Autotest. A change of algorithms? A new feature in the product or switch to another API? And bugs found in Autotest (surprise)?

Myth : A well-written and updated self-tests are infallible. Reality : Autotest useful and paramount, but behind them need be watched. About traps in autotest we continue to talk to one of the following articles.

How To Select The Test Automation Tools

How To Select The Test Automation Tools

In a duel between the last bugs and developers have the right to choose weapons. Typically, a good fellow (red girls) have three basic choices:

- A commercial product (WinRunner, Rational Robot, SilkTest, TestComplete, etc.)
- Freeware and shareware tools ( Freeware , Shareware )
- own utilities (written in the course of the project)

Consider the advantages and disadvantages of these approaches.

Commercial products


1. Autotest can be used in functionality (modules, procedures, code snippets), which comes bundled product. If to test the application use such methods, this code does not have to write yourself.

2. Usually such tools are supplied with its own development environment that provides good opportunities for writing and debugging automated tests.


1. The cost of such products often exceeds reasonable limits.

2. No access to source code . If the tool detects a bug, its correction by the vendor may take some time. There is no possibility to customize the product quickly to your needs.

3. Often commercial products impose their approaches to testing applications – in accordance with the model on which the instrument was built. This approach is not always acceptable for individual applications due to their nature, well-established practices, human and machine resources.

Own tools:


1. Sometimes these tools are a side effect of creating applications, especially in the case of TDD.

2. Know about them, “and from”, they are easy enough to use.

3. Source code is available.


1. The functionality of such tools may be insufficient for the organization Autotest.

2. Creation and support of such tools can be expensive.

3. Results of such automated tests may be questionable (a sort of “thing in itself”).

Freeware and shareware tools:


1. The reasonable cost of ownership. Price shareware-product is often low. In the case of freeware product is offered free of charge.

2. Requests for fixing bugs and functionality usually find understanding and prompt response – sometimes all in the same free of charge or for a modest fee. In the latter case, the allocated money directly spent on meeting the challenges faced by the user tool, not the “chips” that he does not need.

3. Often have similar utilities available source code.


1. The functionality of such products is insufficient for the task.

2. Risk to remain without support from the developer of the product.

Of course, the list of advantages and disadvantages of these approaches is far from complete and allows for exceptions. For example, commercial products may have a reasonable price and to be flexible enough and own tools can be quite reliable. A commercial product may be unacceptably long period of development, and a shareware product can impose their language. It also happens that the free product is so effective and easy to use, throw up your hands and think what vendors of commercial products want to get their money.

In general, the choice of instrument should be taken into account all the existing factors and application-specific tasks, the possibility and validity of integration of different tools in one system, qualified developers and testers, future plans, technical and financial resources, risks. Selection according to the context will be most effective.

Why We Need Test Automation

Why We Need Test Automation ?

And it is true, why? In his famous article “What is Test Automation” Steve Rowe wrote:

“Test automation is simply an automatic way of doing what testers were doing before”.

A little later, Steve found it necessary to clarify his position:

“I am describing test automation, not testing. The two are far from synonymous. Test automation * is * a replacement for what testers once did, but it isn’t a replacement for all of what testers do. ”

But the genie was out of the bottle of the original article, and shove it back was not easy. Steve publication caused a lot of responses. The most reasonable of them can find the answer, which published James Bach. James writes :

“Test automation is any use of tools to aid testing. Test automation has been around since DAY ONE of the computing industry. And never in that history has test automation been an “automatic way of doing what testers were doing before”, unless you ignore a lot of what testers actually do. ”

James further develops its point of view and finally notes (by the way, comments on articles deserve special consideration)

“Test automation cannot reproduce the thinking that testers do when they conceive of tests, control tests, modify tests, and observe and evaluate the product. Test automation cannot perform sapient testing. Therefore, automation of testing does NOT mean automation of the service provided by the software tester.

In summary, test automation means applying tools to testing … ”

So, according to James, test automation has the use of various tools in the process of testing applications. We agree with this point of view and try to develop this topic.

Software development process can be built on different models . Nabolee known waterfall model , and the most popular at the moment are the so-called “flexible” technology . Each of the models suggests that a method of developing and adding new functionality. Comparison of methods is beyond the scope of this article, so let’s at it.

Waterfall model (in the base case) implies a certain fixed sequence of stages of development (Requirements -> Design -> Implementation -> Verification -> Maintenance.) All requirements for the product to shake down in advance, and testing is given a separate step, which can lay the time required to thorough testing of the application. Looks reasonable, but the world is more complex. Product requirements may change during the process of development and market competition makes it necessary to release updates to the operational products. In such circumstances, agile-technology come to the fore, and product testing to allocate as much time as allocated in the waterfall model is not possible.

But we do not want to sacrifice quality , right? Here come to the rescue and self-tests. Smartly written and debugged autotests allow promptly conduct regression testing product functionality and testers will have the time to test the new functionality for intuitive, creative analysis of the application – to the analysis, those bugs that can not be found in automated testing, but the correction is critically important for the quality of the product.

Note that the regression testing – not only the scope of the Autotest. Performance analysis, stress resistance, product localization – this is not a complete list of stages of development, in which self-tests will be invaluable.