I am a product owner on an agile team. I when doing PO acceptance testing I usually make note to try some edge cases. Its not uncommon for me to discover something and then I pass it back to the the devs. I am getting push back from one of the developers when I reject his stories. He says its unfair since I don't specify the edge cases and how the program should respond in the acceptance criteria, as he tends to code for only what I describe in the story. I've encouraged him to ask me as he bumps into any edge cases while coding, but he thinks its not his job to think through the edge cases, its mine and I should make new stories for the next sprint.
In my defense I don't know his design for the story until after he implements it, so its hard to iterate through all the possibilities (will config be in a DB or properties file?). For simplicity's sake, lets say we have a story to add division to a calculator app. In the ideal SCRUM world, would it be incumbent on me to add a "handle divide by zero scenario" to the acceptance criteria or should he be working through those cases as he develops so the app doesn't implode on 5/0? To be clear, in this case I wouldn't accept if the app crashed hard on 5/0, but I would pass if it logs, prints DIV0, or any other way to handle the error… just so long as it doesn't crash.
Best Answer
I think the answer is you both should be thinking about your own set of edge cases. He as the dev should handle edge cases that are data specific such as does the app crash from any given user input, 5 / 0 certainly falls into this part of the spectrum. The dev should ask about you what you think would be an appropriate error message when the input given as part of the user's interaction leads to something invalid.
Your portion of the spectrum is the business side of things. How should the calculator behave if the user's account is not allowed to use the divide button? How should it behave when the account is allowed to use the Mod operation but doesn't have access to the division feature?
The important message I think that you need to convey, and have acceptance from all team members for, is that you are all on the same team. If the product is not complete the product is not complete and the team is to blame, not any given member.