Hey everyone, I’m part of a company that’s been trying to modernize. Our team has switched to Agile, switched to some cloud storage, and is slowly trying to add automated tests to its various legacy applications. I know normally automated tests would just be done with the user story as part of the definition of done, and while going forward I want to do that with future user stories, I still I want to be able to keep track of the large amount of work to do with adding automated tests to cover the huge parts of the code already done. It will be kind of a large development effort by itself done by at least 2-3 devs/juniors, and me kind of leading this effort but pretty new at it myself lol.

We’re using Azure DevOps which has organized things from big to small with Epics, Features, User Stories, and Tasks. We’re trying to decide how to frame and track the work within this context. So even though user stories aren’t the best way to illustrate this from what I’ve read because it isn’t user driven functionality, it’s the best way to track with what we got, so with that context, here are the ideas so far.

1. One person suggested an Automated Test Feature, sticking it in this Global epic we have for miscellaneous structure and framework work. Then make one user story each with all automated tests a module has, giving each individual class and pages to test within those modules with a task, and writing within the description the individual tests for each page/class. They don’t want the backlog diluted with too many of these automated test stories I think.

2. Another person suggested creating an Epic for automated tests user stories created up to now, then a feature for each module, then a user story for each class/page to be tested, then a task for each test the developer has to make for each one of those. This person was me, I thought it felt more organized and you can see what dev is working on what piece, but I can see how it balloons the backlog with a ton more user stories for this effort. Although it’s at least all in one Epic folder that’s easy to ignore.

3. Our QA wanted one only user story for all automated tests to really prevent clutter, but also was okay with the first idea when I kind of pushed back on it. Since all user stories are usually tested by them and this is kind of superfluous stuff mostly for devs at the moment that isn’t application functionality, so I can see why they want it as small and out of the way in the backlog as possible.

4. Another person just suggested creating a user story for each test, but instead of putting them all in one place, placing them in the proper Feature category that the originating story is kind of testing went in. I get the logic of this, too, but I was afraid of it being confusing for it to track being all scattered around, and user and system driven functionality mixed with tests. But then, I guess we also categorize things in sprints, so maybe this wouldn’t be as confusing as I first thought.

Anyway, if anyone had any suggestions or a better way to organize it than these, let me know!