A Software tester who has worked on following projects will really appreciate the fact that regression testing is very challenging and boring at times :-
- Very large project with lakhs of lines of code a and we keep on adding new features to it.
- A badly managed code with lot of bugs and bugs are being fixed on regular basis.
- A software application which has a common code-base but released in various forms
- etc...
In most of these cases challenge is to make sure that new feature or bug-fixes in old code are not breaking any existing functionality. That effectively means retesting things which were already working and can have risk of breaking something.
Knowing code and planning regression testing in optimized way is usually a good practice but Automating such areas give much more confidence. At times regression automation may demand lot of maintenance as tester may need to update the scripts after a particular change in the code, but effort to update existing automation system should be less and easy. Also it depends upon the initial planning for automating test scenarios for a particular project. Better we understand the nature of our project, more time we shall save on maintaining the automation environment.
Another reason which I see is important in automating regression peices is fearless attitude of software team to be open for fixing old bugs to improve overall quality. I have seen teams who have been working on same code-base for last 10 years and it's a big fear to fix a severity-1/2 bug in older code. Why so, because each one in the team knows that time cost of testing that change in legacy code will increase and even after that we may not be able to figure out the side-effect. If such teams maintain a good automation harness, it should be fearless to fix any old problems as if any change impacts, can be caught by automation system.
Regression automation systems should be able to tell the developers that what you have broken by a particular change in older code :)
If you are not able to understand the context of this post, please have a look at http://computersfundamental.blogspot.com/2011/06/why-should-we-automate-our-test.html where it started from the need of Test Automation in a Software Development Team.
- Very large project with lakhs of lines of code a and we keep on adding new features to it.
- A badly managed code with lot of bugs and bugs are being fixed on regular basis.
- A software application which has a common code-base but released in various forms
- etc...
In most of these cases challenge is to make sure that new feature or bug-fixes in old code are not breaking any existing functionality. That effectively means retesting things which were already working and can have risk of breaking something.
Knowing code and planning regression testing in optimized way is usually a good practice but Automating such areas give much more confidence. At times regression automation may demand lot of maintenance as tester may need to update the scripts after a particular change in the code, but effort to update existing automation system should be less and easy. Also it depends upon the initial planning for automating test scenarios for a particular project. Better we understand the nature of our project, more time we shall save on maintaining the automation environment.
Another reason which I see is important in automating regression peices is fearless attitude of software team to be open for fixing old bugs to improve overall quality. I have seen teams who have been working on same code-base for last 10 years and it's a big fear to fix a severity-1/2 bug in older code. Why so, because each one in the team knows that time cost of testing that change in legacy code will increase and even after that we may not be able to figure out the side-effect. If such teams maintain a good automation harness, it should be fearless to fix any old problems as if any change impacts, can be caught by automation system.
Regression automation systems should be able to tell the developers that what you have broken by a particular change in older code :)
If you are not able to understand the context of this post, please have a look at http://computersfundamental.blogspot.com/2011/06/why-should-we-automate-our-test.html where it started from the need of Test Automation in a Software Development Team.
No comments:
Post a Comment