Optimizing Regression Testing: Strategies, Processes, and Performance Considerations

Categories: EngineeringScience

Abstract

Regression testing is basically one of the testing strategies introduced to test and evaluate each of the modules and submodules individually. Major application of this technique is when one wants to test and evaluate any particular newly actualized module or an updated part of already tested working software project. Regression testing is found to be costlier compared to other known techniques for testing though regression testing assumes a noteworthy job to survey the nature of an item that is changed habitually in usefulness or software having frequent updates as expected by the end client of the software.

Whenever normal unit testing is not working properly and software is giving some unexpected behavior then software tester needs to write some out of box special test cases those are called regression tests. In this paper I will briefly discuss such cases and this phenomenon which is termed as Regression Testing and its advantages, complexities, expenditures and everything related to the same strategy.

Get quality help now
Marrie pro writer
Marrie pro writer
checked Verified writer

Proficient in: Engineering

star star star star 5 (204)

“ She followed all my directions. It was really easy to contact her and respond very fast as well. ”

avatar avatar avatar
+84 relevant experts are online
Hire writer

Introduction

Regression testing is a basic part of QA in numerous situations, including when a noteworthy element or new form of the application is being discharged, and when a basic bug has been as of late fixed. To benefit from regression testing, regression test suites ought to be executed much of the time to guarantee that bugs are gotten rapidly. Since every arrangement conveys a danger of presenting new regressions, regression testing is critical for associations who practice CI/CD, Agile, and other advancement procedures that use visit deployments.

These groups begin doing regression testing from the get-go being developed and keep on executing tests after each form.

Get to Know The Price Estimate For Your Paper
Topic
Number of pages
Email Invalid email

By clicking “Check Writers’ Offers”, you agree to our terms of service and privacy policy. We’ll occasionally send you promo and account related email

"You must agree to out terms of services and privacy policy"
Write my paper

You won’t be charged yet!

So question is what was the need of such new technique when we were having many testing procedures already available; the answer is as earlier discussed whenever any software behaves abnormally and any traditional testing strategies are not working out to resolve issues tester need to identify regression testcases by which this issue can be resolved using regression testing as defined.

In vast and open undertakings, regression tests are expected to guarantee the planned conduct held somewhere between all libraries and working frameworks and machines those are used. Besides, this will in general be a major issue for worldwide software utilization. In a Libre Software venture, your software being usable crosswise over numerous OS conveyances is probably going to be your primary objective. Unit testing is somehow origin of this testing technique so some broadly identified unit testcases to resolve all king of behavior of the software can reduce the chances in which we need to take regression testing into consideration.

Researchers found that more than half of the cost of software development is in it’s testing in which regression testing has 80% part in cost. To keep up the adequacy (cost, inclusion, blame) of test suite in regression testing, analyzer may decrease size of test suite, number of experiment execution, experiment execution time, select a subset of experiments that have just been executed on the framework under testing (SUT), or viably organize the experiments.

The rest of the paper contains,

Definition and Terminology

  • Definitions notations and terminology

Regression Testing Process

  • Problems associated
  • Testing models
  • Procedures

Performance

  • Where used
  • Why used
  • When used
  • Testcases prorogation and ordering
  • Conclusion

Definition and Terminology

Let’s say we have developed a software ‘S’ now regression testing includes following:

Update S to S’

Test S’ for all newly added updates and changes

Regression testing on S’ to make sure the code used from S is working flawlessly in S’ as well

To reduce the cost, reuse the tests of S and modify it if needed

Conclude S’ as subset of S

Release S’

Thus, Regression Testing is portrayed as a sort of software testing to attest that a progressing venture or code change has not unfairly impacted existing features. Regression Testing is just a full or fragmentary assurance of authoritatively executed trials which are re-executed to ensure existing functionalities work fine. Regression Testing is only a full or fractional determination of effectively executed experiments which are re-executed to guarantee existing functionalities work fine. This testing is done to ensure that new code changes ought not adversely side-affect the current functionalities. It guarantees that the old code still works once the new code changes are finished.

Now if we consider terminology, Regress means going back to last stage or previous stage in case of this test it is usually the worse case in which we are stepping back. Thus, term regression testing includes portion of cases’ cycles and updated software S’ with some of the previous testcases with modifications according to the update applied on software.

Regression Testing Process

1) Test revalidation:

  • Checking which tests for S stay substantial for S’
  • To guarantee that just test that are material to S’ are utilized amid regression testing.
  • How can we naturally recognize Obsolete experiments?
  • Three different ways that an experiment may wind up out of date:
  • Program alteration prompts (presently) off base info/yield connection
  • If P has been changed, some experiments may effectively indicate the information/yield connection, yet may not be testing a similar build.
  • For model, the adjustments from P to P' change some equality classes. t∈T used to practice a limit, which is never again a limit. t∈T is outdated as it does never again test a build (limit) of intrigue.
  • A basic experiment t∈T may never again add to the auxiliary inclusion of the program.

2) Test determination

  • Whether we choose and implement all tests in T or not
  • Test only modification
  • traversing tests?

3) Classification of tests:

  • Re-testable: ought to be run again
  • Reusable: should not be run again
  • Tests are either one of them and obsolete

4) Minimizing test

  • Discards tests apparently excess concerning a few criteria
  • Purpose: decreasing the quantity of tests to execute for regression testing

5) Prioritizing tests

  • Prioritizing tests dependent on certain criteria
  • Context: after revalidation, choice, minimization, one may in any case have too many experiments (can't stand to execute them all).

6) Comments

  • Minimization and prioritization can be viewed as choice procedures
  • Minimization and prioritization procedures can be utilized amid testing P (not really amid regression testing).

Determination of Tests

Problems for selection:

Suppose a software S has been tested with testcases say TC and testcases are tested for specifications say D (for details) and now S’ has been created adjusting S (updated S to make S’); Now, there will be two possibilities, one is S and S’ both are same and second is S is subset of S’ which is commonly the case. Now real problem is to find testcases TC(RT) which are tested over S’ to certify it as proper update of S having all S’s modules still working and new once added (if any).

Regression testing selection techniques:

Regression testing just affirms that adjusted programming hasn't unexpectedly changed and it is commonly performed utilizing any blend of the accompanying procedures and those are following this,

Retest All: A retest all training, means to re-test the whole programming suite or whole code of the program is changed. Much of the time, mostly whole testing is really robotized utilizing grouped apparatuses and test-driven improvement rehearses, since it's neither plausible nor efficient for people to perform such a gigantic amount of testing. Be that as it may, this absence of human mediation can likewise be tricky, so it's basic to have a reinforcement plan like a blunder checking instrument, which will guarantee whatever gets lost in an outright flood is gotten and managed.

Regression Test Selection: As a somewhat conditioned down option to retest all, regression test choice urges the group to separate an agent determination of tests from the full test suite that will inexact the normal experiment of the whole testing suite all in all. The essential preferred standpoint to this training is that it requires far less time and exertion to perform. This sort of regression testing is in a perfect world dealt with by human analyzers.

Experiment Prioritization: The objective here is to organize a constrained arrangement of experiments to such an extent that the more possibly significant tests are executed in front of all fewer basic tests. The demonstration of how your group organizes experiments is outside the extent of this article, however a large number of the procedures utilized amid deformity triage are appropriate amid experiment prioritization.

In light of authentic information: Another methodology is the examination of information created by trials, regardless of whether from runs, deficiencies, experiments, alteration logs which are ready to decide causal connections. Granularity ranges from documents to techniques or capacities; exactness and granularity factors are considered so as to give a product quality methodology. According to the researchers with 10% of a source code it is conceivable to anticipate with a certainty interim from 73% to 95% the infused issues. In any case, utilized projects are not delegate; henceforth, the outcomes are difficult to sum up to different settings. In these procedures, the nature of expectation relies upon the nature of the put away verifiable information.

Significance:

In the realm of programming quality affirmation, a term that is important is known as programming regression on which this whole thesis is, that essentially alludes to a product bug causes some sort of unintended non-usefulness so we call them non-functionality when the framework is somewhat changed, or let’s say, a fix or new discharge. There are three basic classifications of programming regression

  • Local
  • Remote
  • Unmasked

Local is basically bug or problem due to which the software is not working and it resides within the part of software where developer has updated something.

Remote is bug or problem due to which the software is not working and it does not reside within the part of software where developer has updated something. The bug is within non-updated portion or module of the software code.

Unmasked, as name suggests, it was already present but the case is just it was not revealed or it was not discovered by the tester.

Performance

HOW:

Form many practices followed for regression testing. Few general techniques are discussed as follows:

Maintaining a strict and mandatory testing schedule throughout the whole lifecycle or process of software development. This will also guarantee the final product to be enough tested and certified to be reasonably good and reliable.

Unless your present programming venture is a straightforward self-created side undertaking, odds are you'll have such a bounty of tests, that following each will be well past the capacities of a solitary individual or a spreadsheet. Fortunately, there are various test the board apparatuses available intended to improve the way toward making, overseeing, following, and writing about every one of the tests in your whole testing suite.

Let’s assume there are many more testcases than normal so they cannot be discriminated using single parameter say name or value. So the task of sorting them all or ordering them all would be way difficult to arrange. The arrangement is to classify tests into littler gatherings dependent on whatever criteria is fitting for your group. Most test the executive’s instruments will give the methods for arranging or labeling tests, which will make it less demanding for everybody in the group to recognize and reference a particular sort of test.

Organize Tests Based on needs and requirements of clients: So, basic idea is to manage the arrangement in such a way that all the requirements of client is satisfied and at the same time the end user is getting best experience of using the product as their day to day routine so it is good to arrange or sort the testcases in order to achieve these goals.

WHERE TO USE THIS:

One-line answer of this question is pretty simple: everywhere where developer and tester can afford to use this testing procedure!

As stated earlier, the method is way expensive than other methods of testing so it is near to impossible to use this in each and every developing procedure.

To show the test of choosing when and where a test ought to be included, consider a basic application that contains only two content boxes, every one of which can hold a number up to 20 characters long. Upon accommodation the two numbers are included and their entirety is yield to the client. It doesn't get a lot less complex than this, yet how about we currently think about how we'd approach testing for what appears to be a straightforward situation.

We could compose a test that just begins emphasizing through numbers and checking the outcome without a lot of inconvenience. The issue here is that PCs are quick, yet they simply aren't that quick. Regardless of whether we could blast through ~550,000,000 numbers each second, it would at present take a great many years to go through each conceivable substantial number — and this doesn't represent the blend of including numbers together. Presently clearly, we don't go to these boundaries for most applications since it's commonly expected that if a capacity can effectively include two numbers together it can likely do likewise with an alternate pair of numbers.

Thusly, the conspicuous arrangement here (which can be connected to regression testing as a rule) is to make a delegate test of tests that will inexact the bigger accumulation of conceivable or hypothetical qualities. On account of our two numeric content boxes, we'd most likely test outrageous qualities (- 2,147,483,648, - 2,147,483,647, 0, 2,147,483,647, 2,147,483,648), exceptional qualities (Infinity, NotANumber, invalid etc etc), and afterward perhaps a bunch of randomized qualities to guarantee solidness between test executions. In 99.99% of situations, we can securely expect that this dimension of test inclusion will get the job done, and there's no compelling reason to test every one of the 99 quintillion qualities we could hypothetically enter.

Regression testing ought to be performed after any change is made to the code base. Moreover, regression tests ought to likewise be executed whenever a recently found issue has been set apart as fixed and should be confirmed.

Your group should choose the regression testing plan that best addresses your issues, yet most associations think that its helpful to perform regression testing on an exacting timetable. This might be toward the finish of each work day, week by week, fortnightly, or even after each and every store submit is pushed. The more frequently your group can perform regression testing, the more issues can be found and fixed, which will prompt a progressively steady and utilitarian bit of programming toward the finish of advancement and driving into creation.

All things considered, it's essential not to depend solely on your regression testing practices to get all mistakes or potential bugs. Regardless of how persistent you and your group might be, a few deformities will in the long run get lost in an outright flood, so ensure you actualize an additional layer of security past testing, for example, Airbrake's mistake checking programming. Airbrake ensures that your group won't have to stress over forgetting about generation mistakes, since Airbrake gives ongoing blunder observing and programmed special case detailing for all your improvement ventures. Airbrake's best in class web dashboard guarantees you get nonstop notices on your application's wellbeing and mistake rates. Regardless of what you're chipping away at, Airbrake effectively incorporates with all the most mainstream dialects and systems.

Furthermore, Airbrake makes it simple to alter special case parameters, while giving you unlimited authority of the dynamic blunder channel framework, so you just accumulate the mistakes that issue most.

Conclusion

So, the paper was started with what is regression testing and why and how and where and when it is needed and then proceeding towards the selection of testcases and all. As discussed earlier, regression testing is way expensive than any other testing strategies used in software engineering but whenever it is affordable one should always use the same because it guarantees the best product with minimum number of bugs and best user experience as needed.

Major application of this technique is when one wants to test and evaluate any particular newly actualized module or an updated part of already tested working software project so, at the end it is very clear that finding regression testing for any particular update is only efficient if the cost of the same is less than or equal to the cost of entire system testing using any other testing methods.

Acknowledgment

I would like express my gratitude to Prof. DaiwatVyas for suggesting such a good field for research and further guide through the procedure of research and objective of the same and also for sharing knowledge related to Software engineering I would also like to thank Nirma University for providing such courses having interesting research works. Also, to the author of the research papers whose knowledge and research works I may have been used in my paper.

References

  1. A. Aho, R. Sethi, and J. Ullman.Compilers: Prin-ciples, Techniques and Tools. DorlingKindersley(India) Pvt Ltd, 2nd edition, 2008.
  2. Mathur, A.P., “Foundations of Software Testing”, Pearson, 2008
  3. Leung, K.N., White, L., “Insights into Regression Testing”,Proc. IEEE International Conference on Software Maintenance (ICSM), pp. 60-69, 1989.
  4. Rothermel, G, Harrold, M.J., “A Safe, Efficient Regression Test Selection Technique,” ACM Transactions on Software Engineering and Methodology, 6(2), pp.173-210, 1997
  5. G. Rothermel and M. J. Harrold. “Analyzing regression test selection techniques,” IEEE Transactions on Software Engineering, vol. 22, no. 8, pp. 529-551, 1996.
  6. IEEE Standard for Software Maintenance. IEEE Std 1219-1998. Oct 1998.
  7. M. J. Harrold, D. Rosenblum, G. Rothermel, and E. Weyuker. Empirical studies of a prediction model for regression test selection. IEEE Transactions on Software Engineering, vol. 27, no. 3, pp. 248-263, 2001.
  8. T. L. Graves, M. J. Harrold, J.-M. Kim, A. Porter, and G. Rothermel, “An empirical study of regression test selection techniques,” ACM Transactions on Software Engineering and Methodology, vol. 10, no. 2, pp. 184–208, Apr. 2001. [Online]. Available: http://doi.acm.org/10.1145/367008.367020
  9. G. Rothermel and M. J. Harrold, “A safe, efficient regression test selection technique,” ACM Transactions on Software Engineering and Methodology, vol. 6, no. 2, pp. 173–210, Apr. 1997. [Online]. URL: http://doi.acm.org/10.1145/248233.248262
  10. Y.-C. Huang, K.-L. Peng, and C.-Y. Huang, “A history-based costcognizant test case prioritization technique in regression testing,” Journal of Systems and Software, vol. 85, no. 3, pp. 626–637, Mar. 2012. [Online]. URL: http://www.sciencedirect.com/science/article/pii/S0164121211002780
  11. K. Huang, M. Yue, P. Chen, Y. He and X. Chen, 'A Cluster-Based Watermarking Technique for Relational Database,' 2009 First International Workshop on Database Technology and Applications, Wuhan, Hubei, 2009, pp. 107-110. doi: 10.1109/DBTA.2009.38 URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5207802&isnumber=5207612
Updated: Feb 19, 2024
Cite this page

Optimizing Regression Testing: Strategies, Processes, and Performance Considerations. (2024, Feb 19). Retrieved from https://studymoose.com/document/optimizing-regression-testing-strategies-processes-and-performance-considerations

Live chat  with support 24/7

👋 Hi! I’m your smart assistant Amy!

Don’t know where to start? Type your requirements and I’ll connect you to an academic expert within 3 minutes.

get help with your assignment