How is regression testing tracked as part of a Sprint? Is it a user story or a task? We always do regression testing as part of a sprint; however, there is question on whether we track as a task attached to one story in JIRA. Or is this a separate user story in each sprint?
Each user-story should be deliverable by itself independently, because this way you can deliver customer value even if you didn't fully finish the Sprint. Atleast this should be the goal, a lot of teams use INVEST to safeguard this goal. This should mean any testing is part of user-story, maybe as a sub-tasks, but it should be finished before the story is finished. It should be DoneDone.
This means if you have 5 stories you will do 5 times your regression test in a Sprint. Hence why most Agile teams focus on automating all the regression testing. Now if you would have the regression testing at the end of your Sprint as a single task/story you might not be able to deliver anything or worse take shortcuts on your testing and deliver lower quality in the end.
On Scrumboards (E.g. JIRA) you could also add an extra column named "Testing" and when ever a story end-up here you do the regression testing. Do make sure it has a low WIP-limit. Still I prefer parallel testing and not postponing it till the end of the story and certainly not the Sprint.
In my personal opinion, regression testing is a task.
- A user story, by definition, is a description of a software feature from an end-user perspective.
Regression testing has nothing to do with end-user.
Having said this, one may argument, from tester point of view, an end-user is a developer or another tester, so it potentially is a user story as well.
Regardless of what it is, the most important aspect is to have everyone within your Agile team to reach an universal agreement whether regression testing is a task or user story and stick with your final decision.
Regression testing is tracked is one of two ways:
By tracking when feature/bug tickets are done and knowing that each one includes the writing of tests that will then remain as regression tests going forward. I consider this the preferred approach as you get much better tests, they are actually written and context switching is reduced. I also recommend dev/qe pairing with test design and writing in parallel with application changes.
By setting aside a separate time for regression testing which can be either manual or (ideally) updating automated tests to reflect the change in functionality.