Identifying and documenting edge cases for new features

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  OLMIS-4808 - Getting issue details... STATUS

Below there is the list with common edge cases, split to three sections:

1. General edge cases scenarios:

• what should happen when the user doesn't have required permission (buttons, inputs, tab in navigation)
• trying to save the form with empty mandatory field
• conducting linked actions from two browsers or tabs
• what happens when not all fields are filled, i.e. a user does not have a password or email
• buttons should always describe a specific action (if it is an update it should say "Update", if it is creating new resource it should say "Create")
• when adding items to list what happens if the list is empty?
• what happens if we run out of periods
• creating new records, e.g. users with invalid data (already existing e-mail, username, invalid characters, not enough information)
• removing/editing snapshoted values (orderables, ftaps etc.)
• removing/editing related entities
• quantities going below zero
• something is deactivated (reason, orderable, facility, program)
• default values for previously non-existing fields
• letter casing while searching
• handling null values (e.g. null SOH for any product or no Approved Quantity column)

2. Edge case scenarios for specific functionalities:

• initiating a requisition for a removed facility right after having authorized a requisition with old configuration settings (with the facility option)
• rejecting a submitted requisition for one period, when the second requisition for the second period was also submitted
• approving an already-existing old requisition with old requirements
• trying to skip/unskip products for an already submitted requisition

3. Edge case scenarios for offline mode:

• trying to load data while being offline
• authorizing a requisition that was modified and submitted from a second browser while the first was in offline mode