Regression Testing was one of the core phases of traditional waterfall development. It meant that after the (often long) development phase was finally through, all the pieces of the new system or new version were tied together, making sure everything worked. Maybe one or twice a year or once a quarter. Taking a few weeks to do it was ok for that business model. After all "the invoice has to age for 30 days anyway..." (traditional approach and example of challenge).
In Agile development the term 'regression testing' has largely lost its meaning/value. It means little more now than 'run the whole test suite for that stage'. It's not so much that regression testing has gone away - rather the opposite - it's been accepted as just part of development and testing in all 4 agile testing quadrants.
This is a piece of education and change that will often not be identified to take place on teams that come from waterfall. Stopping using a term that has long been an accepted way of how things work is really hard. Changing its meaning even harder. Both require clear communication or discussion or you'll end up with folks with a bunch of different opinions and views on what regression testing should mean today depending on their internal / external experience.
So when developers are writing Unit code and they have the tests and the code for the unit they are working on passing they then make sure all the other units tests works (this could be thought of as a 'unit test suite regression run').
When seeing if all the components work, first test any that were changed and then run all the integrated tests (same as 'regression run') in a integration testing environment. Here you might mess with the time clock and see 30 days go by in an instant...
Same for Automated UI testing, manual testing, usability testing, etc. Run any specific tests for that function and then run the whole suite at that stage.
As with programming, Agile means breaking down testing into many components.
This provides two key returns:
- immediate feedback at the component, integration or e2e level
- ability to fix soon, costing less, going faster ('shift left')
The need to run the whole suite should quickly drive you to automation over manual testing. When you are releasing every few weeks or days or hours you can't run a manual test suite effectively, no matter how many off-shore resources you co-ordinate.
Refer to
The Agile Testing Pyramid
and
The Agile Testing Quadrants
for a (lot) more info. You won't see the term 'regression' much there.
Final Note:
"I mean there is no meaning to run whole automation suite of 1 - 10 sprints on a daily or weekly basis because we change any existing functionalities rarely."
This another example of a process that should change. Actually yes, you do want to run the whole suite, even if you don't think there are any changes. Sometimes there are unexpected consequences to a small seemingly inconsequential change. I have seen a tiny change bring down an entire system. This is what leads to the business requiring an extensive UI test suite whether manual or automated). Following the Agile practices of comprehensive and meaningful Unit and Integration tests means avoiding the old paradigm of eventually checking everything through the UI. Given the number of devices and browsers and versions this hasn't really been practical for a while anyway. In an age of speed you definitely need a small number of smoke and UI tests.
