This page was created to help teams with identifying edge cases in features that they implement as it is rather easy to implement and test "happy path" scenarios but it is very hard to verify, whether new feature works for more complex scenarios.
How to document edge cases
The best place to document edge cases for new features would be a new section in the ticket description, same way as we are doing it for acceptance criteria. Good edge case criteria should have described a scenario that differs from the main ones and expected behavior to handle that edge case.
When to identify edge cases
We strongly recommend identifying edge cases connected to the feature before working on the implementation. The person who creates the ticket or fills the description should be the first to search for possible edge cases, as it is quite possible that he/she will have the proper knowledge to do so. Regardless if the ticket has some edge cases defined or not, it should be reviewed on both Backlog Grooming meeting and most importantly on Sprint Planning meeting. Depending on the length of your Backlog Grooming meeting there may be not enough time to review ticket carefully, so we suggest to at least to find and mark those tickets with a proper label, i.e. NeedsToIdentifyEdgeCases. Afterward, those tickets could be reviewed in depth on the Sprint Planning meeting by the dev team.
How to identify edge cases
The hardest thing is, of course, to identify all possible edge cases as it is very easy to miss any and there is no easy way to make sure all are found and documented. If the team feels, that given edge case scenario is big enough it is good to move it to separate ticket, it will make testing much easier and it will also help with identifying which automated or manual tests it needs. A good example will be
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
...