How many times have you changed a piece of code and later realized that you affected the processing of something seemingly unrelated?
Have you ever fixed something “here” only to break something over “there”? Of course, we have never done that. But if we did, we would want a regression testing tool.
The key elements of Regression Testing:
- Uncovering unintended consequences of code changes
- Repeating tests to see if previously fixed bugs have returned
- Cover all relevant and realistic code branches
Our definition of Regression Testing:
“A testing practice that confirms software that was working in the previous release is still working in the current release.”
Since LoadStorm offers a free full-featured account (Breeze), you can create regression test scenarios for no cost. Running and analyzing the results from those tests costs nothing as well because the only charges for LoadStorm are incurred at increased user load. Your automated regression tests need only one virtual user to confirm that the web app is responding properly.
LoadStorm provides an easy and free way to build quick, uncomplicated test plans for regression test automation. You can run your tests over and over again.
Regression testing for web applications is necessary to check quality throughout the development process – especially before you release a new version to customer use. Each click and form available to a user must be tested through every iteration to confirm stability of the entire code set. The smaller test scenarios must be automated, and once they are successfully run for a low volume of users, then additional test cycles can be executed for larger loads. Same test plan scenarios, only more virtual users. That’s LoadStorm’s specialty.
While LoadStorm probably does not support everything that software engineers may want for regression testing, it is a great way to build simple, flexible, and quick automated test plans and run them as often as you change the code.
Fred Brooks, in his book The Mythical Man Month states:
“Also as a consequence of the introduction of new bugs, program maintenance requires far more system testing per statement written than any other programming. Theoretically, after each fix one must run the entire batch of test cases previously run against the system, to ensure that it has not been damaged in an obscure way. In practice, such regression testing must indeed approximate this theoretical idea, and it is very costly.”