Thanks! Haha ya, it may be a little misguided, but I think we were allowed to do this partly as busy work to give us something to do between releases. We’re kind of in a transition period, and it’s something to do while my higher ups negotiate contracts for further work, stakeholders and customers prioritize next items for the next release, etc. Admittedly, these transition periods kinda scare me in terms of you never know when you’ll lose work or something, so even if they think it’s busy work, for me it’s shoring up my resume with tech and leadership experience I should already have that the rest of the industry will be looking for just in case the worst happens lol. I think I’ve been working at this place too long now, kinda got complacent, but been more interested in looking around and catching up on what I’ve been missing as the company has been looking to modernize and we’ve been simultaneously approaching the release of this version of their software.
( Funny enough, I was initially hired to work on automated testing since I had done some at my previous company, immediately got placed doing other dev work to catch up on our schedule. Now it’s been years and I’m trying to remember how this all works lol.)
Right now, we’re mostly just doing happy path testing tbh. But that’s a good point that we should look into our tools to see how it signals code coverage and everything. That might be some reading up I have to do. I think it’s a combination of MSTest, or whatever comes with Visual Studios, some Telerik Just Mock and Test Studio tools our company already had licenses for, and Selenium.
You’re right that a story per test is probably a bit too much Jira. I was more thinking of a story per class, but even that’s probably a bit much with how big this legacy application of theirs is now. I don’t want to overwhelm us all in backlog management paperwork, so now I think I’m leaning towards zooming out a bit and doing a story per module.
One day I’ll pull that off…