Quantcast
Channel: Articles, Blogs and Press Releases | UniTesting China » china software testing company
Viewing all articles
Browse latest Browse all 35

5 types of regression software testing to try today

0
0

The focus of regression tests should be to find application failures when the code has changed or the application is supported in a new environment. Look for reappearing old defects or new defects in the application.   Sometimes this happens with code changes or upgrades.
Regression testing can also increase user confidence.   You need to make sure that the new version is better than – or at least as good as – the old version of the application. In this way, you provide your users with confidence when you make testing an integral part of the application release.

“Testing after release? We don’t need testing after a release!”

This all seems fine and good, the problem is that some applications don’t get tested after being released. You may test the application before it goes into production, but once it is put into production, it may never be tested again. A reason for this may be that testing resources move on, or they don’t exist any longer. This scenario might be common if you have a centralized testing group because the individual projects don’t have testers assigned to certain applications.

If upper-level management doesn’t see the importance in regression testing, it may not even be part of the testing policies.

There may only be testing policies to test the application before it goes into production. This is probably because regression suites can be time consuming to execute or because maintenance of the tests is very difficult.

Why should you perform regression testing? Developers test their fixes, so why do you need more testing? Even when a fix is good, other issues may be discovered during regression testing. Changes in the environment may also cause issues. Sometimes features don’t work, sometimes defects are brought forward or maybe there is a compatibility problem.

Some common methods used in regression testing include:

Run all of the existing tests

The most widely used regression strategy is to run all of the existing tests. If there is a test that has been written, and it was run before, it goes into the regression suite. But this strategy has a few downsides.  If all those tests are manual – after running the same tests 4-5 times, the testers are going to be bored and exhausted. If the regression suite includes all of the existing tests, it’s going to be enormous. Even when a regression suite contains all of the tests, and they all pass, this doesn’t mean there aren’t defects.

Testing an application 100 percent is probably impossible. Testing 100 percent of an application means testing every single field – every single combination of input, between all of the fields, menu options, output, etc. You typically don’t have time to do that. So, even those “run all existing tests regression suites”, only contain tests on a certain percentage of the application.

Run tests that are high risk

Another method used for regression suites is to run tests that are high risk. The tests you need to run should be prioritized by the business users. Tests that are the most important to the business users are those processes the business users do all the time—and the functionality is critical to them. Remember that as the application changes, the key business processes may also change.  It is important to specify a time limit in your test plan for the high-risk tests. Depending on what else needs to be included in the regression suite, 30-40 percent of your total regression time can be allotted for high risk tests.

High-defect features

The third method is high-defect features. This tests typical areas of the application that are high defect areas or areas that are highly complex. Perhaps it’s just the feature that is complex – it may include intricate calculations or integration with one or more other applications. This also includes functionalities that have had many defects in the past.

Exploratory testing

The final method is called exploratory testing – this is NOT random testing. True random testing can be done by anyone – with no knowledge of the application or testing – it is totally random. Exploratory testing is about doing test case design and execution at the same time. As you create and execute these tests, you discover problems and features within the application. These discoveries drive what is tested next.  Make sure there are enough notes for you and the developer to reproduce any issues. Exploratory testing takes advantage of the tester’s experience and understanding of application testing.

Automation testing

If you have a number of regression tests, automation can be wonderful to decrease the number of tests to run manually. Automation tools, such as HP’s Unified Functional Testing, will execute the tests quickly. Therefore, this reduces the amount of time needed to run the same test during the regression testing phase. A manual test may take five minutes to run, but that same test may take less than a minute to run through Unified Functional Testing. This can help you to get a more comprehensive regression test suite.

However, automation is not a quick fix. Automation scripts take time to develop. You have to allow for time between regression runs to develop and get the tests working. If your environment is changing, automation scripts will need to be updated accordingly.

5 Tips for your regression suite:

+ Re-evaluate every single time what is actually in that regression suite. If you have functionalities that are obsolete – they need to be removed from the regression suite.

+ If you have a test that you have run and it passed the last two versions, is there value in running that exact same test? If you change the inputs and/or outputs it’s a different test. So, is there value in actually running that same test over and over and over again?

+ Don’t run tests that already have defects that have been deferred. By a defect being deferred, that means the defect has not been fixed. You don’t want to produce the same errors because you will clutter the results of the regression test suite. Every error produced during a regression test execution should require attention. Therefore, remove the tests linked to a deferred defect.

+ Remember the users.  Think about what is typical for them to do and what the users consider risky may change over time.

+ High defect areas. Because the defects get fixed, the high defect areas can change every single regression test suite execution. Make sure you re-evaluate.

5 Strategies for your regression suite:

+ Perform regression testing on a regular basis. Regression testing should be done when there has been a code change, defect fix, or new environment – it needs to be done on a regular basis, whatever that is.

+ If issues are found, report it accurately. If issues are found be sure to report them accurately so you can determine if the application is regressing. As new code or features are added, sometimes old defects surface again.

+ Automate if you can. If automation can be used to get more testing done in the regression suite – great – do it!

+ Don’t forget non-functional characteristics. These characteristics include usability, portability, and performance testing.

+ Tests should be changed and updated. Don’t run the exact same tests in the exact same order every single time.

Source: http://h30499.www3.hp.com/t5/The-Future-of-Testing-Blog/5-types-of-regression-software-testing-to-try-today/ba-p/6176809#.Uhv8H_bibNQ


Viewing all articles
Browse latest Browse all 35

Latest Images

Trending Articles





Latest Images