Story as we know in agile is a light weight requirement. It is characterised as independent vertical slices of functionality which can be estimated and tested. So a typical story has a business scenario wrapped up in limitations and acceptance criteria. Acceptance criteria are the happy path test cases, which ensures that when a tester signs-off the story, it delivers what it is intended to.
So as a tester what should we do, just limit our testing to the story? Generally, bug is not in the standalone system, it generally gets discovered when a system interacts with another. Whenever I think of story testing, first thing which comes to my mind is the Pepsodent advertisement. Sounds weird? Let me explain, I consider story as a tooth and when given a perfect piece to you, one may not find any germ (bug in this case). But when a tooth is next to another or let’s say when a story interacts with another story, there is a chance of finding potential bug. Germs always hide themselves in between the walls of teeth. I would term them as “Pepsodent Bugs” 🙂 because they are not on any story, they stay in-between in the stories. We can park those bugs to be fixed in later iterations as we cannot hold any story sign-off but while doing this we are just adding a “bit” of instability to the application.
Testing should not be limited to the acceptance criteria of any story. Testing brings value when we find a bug/limitation which is potentially a business scenario which was not thought of before.