I've done it n ways to heaven, and none of it can be sold to devs. If devs don't get into automated testing, it can't scale. You have to think of something they'll buy into. For me, that is combined coverage. Add new feats, coverage doesn't regress, stays really high. Then do we have to do all the book keeping? At most we link a Jira ticket to a Cypress Dashboard run on dev. Once it's on master, it's a part of the regression suite and cannot be failing if a new PR needs to be merged. The tests should be self documenting enough.Mapping them to features is only valuable for feature acceptance (this was tested, or covered by something). Always look for opportunities to tweak what test is already existing as opposed to writing partially duplicated tests for new specs. The reason Cucumber / Gherkin is not great is this duplication; if every feature was mapped to a spec, there would be much duplication between the specs. What matters from a test perspective is the beginning state of a test; if reaching that state is common, then it is an opportunity for a test enhancement vs partial test duplication. At which point, the only caveat becomes the test duration for parallelization concerns.