Product Wants To Use SubTasks to Track SIT and E2E

[Lori Surapaneni]

My Product team does not want SIT or E2E user stories under the Feature. They want us to use sub-tasks. 

Can you share how your team handle SIT (System Integration Testing) or E2E work?

In this example Finance has work to do on their backlog and will not be ready for SIT until 12.2 Sprint 3

System D's work:

  Feature: New Policy Benefit A

    User Story: Configure Policy  (Sprint 1)

    User Story: Benefit API  (Sprint 2)

    User Story: Benefit Webservice (Sprint 2)

    User Story: SIT Send Policy Benefit A data to Finance (Sprint 3)

    User Story: SIT Receive Policy Benefit A data from System D (Finance story in the Finance backlog parented to System D's Feature

My understanding is subtasks: 

Are used as the how of a user story; for the dev team

All subtasks must be done to close the user story 

Points will not be captured if the user story is not done

[Alex David]

Hey Lori, the question I'd put back to the product team is whether a given piece of SIT or E2E work sits inside one story or spans several, because that decides it for you.

If the testing only exercises a single story, a sub-task under that story is fine and that's roughly what sub-tasks are for.

Where your example breaks is that SIT and E2E usually exercise several stories at once, and a sub-task has exactly one parent. So you end up picking an arbitrary story to hang it off, and that story now can't close until integration testing that isn't really about it is finished.

The sprint mechanics are the bigger problem though. A sub-task can't be sprint planned independently at all. Its Sprint field is inherited from the parent and isn't editable, sub-tasks don't appear in the backlog, and they can't be ranked. So if the build work finished in sprint 1 but the E2E only happens in sprint 3, the parent gets carried as incomplete through every sprint in between and all of its points land in sprint 3. Early sprints look slow, the last one looks heroic, and velocity stops being usable for forecasting. Putting points on the sub-tasks doesn't rescue it either, because the sprint report and velocity only count the parent level issue.

What tends to work better for cross story testing:

- Make it a sibling of the stories rather than a child. A plain Task is enough. Give it its own acceptance criteria, estimate and rank, and link it to the stories it covers. Then it can be pulled into the sprint where it actually happens.

- Be careful where you park it. If Feature is your epic level issue type, a Task can sit directly under it. If Feature is a custom level above epic, only epics can be its direct children, so the test item has to go under one of the epics or live outside the tree.

- If it's really a release gate rather than a feature gate, make it an issue with the Fix Version set for that release. A version is a marker on issues rather than a container you can put work into.

- For reporting, a label or component like SIT works, with two gotchas. Labels are free text and global, so one typo quietly splits the report. Components are per project so they won't report across projects, and if the component has a default assignee it will assign issues created with it.

- Worth telling the team that issue links enforce nothing. Is blocked by is documentation, not a gate, and it won't stop the story or the Feature closing.

On the "all sub-tasks must be done first" belief, that's worth correcting while you're in there. Out of the box Jira doesn't stop a parent transitioning to done while sub-tasks are still open. In a company managed project an admin can add the sub-task blocking condition to the parent workflow, which blocks a chosen transition unless every sub-task is in one of the statuses you nominate. It's per transition, so it goes on each transition you care about. Team managed projects don't have that condition at all, so there the equivalent is an automation rule that checks the children and either comments or transitions the parent back.

If you already have SIT and E2E sub-tasks in flight you don't have to recreate them. Move, which used to be called convert to issue, turns a sub-task into a standard issue in place and keeps history, comments and attachments.

The last one is what I'd actually push hardest on. If a story is only genuinely tested weeks after it was called done, the definition of done is what's wrong rather than the issue type. Testing that exercises a single story belongs in that story's definition of done and doesn't need an issue of its own. What's genuinely left over, the real cross story integration runs, is work with its own outcome and deserves to be planned and estimated like anything else. If the answer keeps coming back as "we need somewhere to hold the testing that happens after everything else", that's usually a hardening phase in a Jira costume.

Alex