Encouraging project teams to define Edge cases

Question

Can you please give me concrete examples of Edge cases preferably for Financial systems (General Ledger) and STP Settlements to help us kick start the right kind of thinking /approach by both the Business users and the Development teams on our strategic project?

We are already using the Acceptance Test driven approach, However, to date Non-functional testing, and the Edge cases have not been the subject of much practical focus when the Activity cases and Acceptance criteria are scoped in timebox planning. Practical focus meaning that there are cards for e.g. identifying the non-functional capabilities in scope, but due to pressures of team/ breadth of the project the timebox focus never gets down to the granularity of agreeing Edge cases. I think, this is because the capability of the system to handle edge cases is to a greater extent is implicitly assumed by the Business users.

Regarding the Developers, probably they are covering this in their unit testing but we, on the general project team, including the technical co-ordinator, and the test co-ordinator do not have much visibility of this. Therefore, we may be missing out on opportunities to see where the real gaps lie until we go to Production. What has your experience been?

Answer 1

You can think of edge cases in terms of constraints and assumptions.

Examples of constraints might be the maximum field length in a UI, a maximum column length in a database, a maximum or minimum dollar amount, a maximum/minimum percentage. Another example would be the cardinality of relationships, e.g. user A never has more than one checking account or more than one beneficiary. I test these kinds of constraints by using the exact minimum and maximum value (to make sure they work), and a value a little bit less than the minimum or a little bit greater than the maximum (to make sure they are treated appropriately).

An example of an assumption is the model for the temporal order of events. (This is a fertile area for bugs at my company.) When we design software for a process (like an accounting process), we have a particular order of events in mind, an order that corresponds to how we think users behave, or an order that seems reasonable to us, or an order that is easy to understand and explain. If you understand those assumptions, you can test what happens when the assumptions are wrong.

You might try Googling for "testing for edge cases".