There’s a spirited discussion about requirements going on at CAST24×7. Ben Simo visited a store with some requirements posted on the door: “no backpacks, food, strollers, unruly kids or cheap husbands”, etc.
He asks how you would test these requirements? How could you refine them? How do you determine whether bugs need fixing?
The discussion centered largely around how bad these requirements are and how they need refinement. No doubt. But sometimes it’s better not to be a requirements jerk and just get some testing done. It’s a great way to build goodwill.
I wrote:
There are two separate testing problems here – one is related to testing the quality of the requirements, and the other is testing the quality of the implementation (enforcement) of requirements. We have to assume that this is a “waterfall-type” development methodology because such ambiguous requirements already exist. At this point it’s too late for me to provide input into the requirements – the sign is already there on the door! So I can approach this testing problem two ways – one is to be the perverse tester who wants to make a point about what an awful development process this is, and the other is to produce useful tests that the customer cares about.
The perverse tester could easily come up with dozens of test ideas that would show how the requirements are faulty. I could carry in one hand a giant briefcase with food cleverly concealed under a false bottom and a covered thermos of hot drinkable chicken soup in the other. I could come in with my girlfriend (to whom I am not married) and constantly complain about how expensive things are. I could bring in 40 extremely well-behaved school children and have them stand directly in front of the cash register without saying a word. I could go into a dissertation about exclusive vs. inclusive or, and what exactly it means to “be 18 years old or responsible parent”. I could send a 72 year old bachelor in and complain he wasn’t turned away because he’s neither a parent nor exactly 18 years old! I could buy the most clearly defective product on the shelf and then return, demanding a refund – and explain that I’ll buy $200,000 worth of merchandise tomorrow if the exchange it, but otherwise I’m taking my story to the ActionNewsOnYourSideConsumerTeam and they will be swarming the place with cameras tomorrow!
But what does this get me other than a reputation as being hard to work with?
Some of the thinking about the requirements in the comments are useful for guiding my tests… but still, you need to start with the assumption that the requirements are “pretty good” and respect roughly what the product owner wants. So I’d start out with several basic tests (1) person with large backpack, (2) person with large stroller, (3) couple who’s been instructed to fight over the price of everything, with the man playing cheap, (4) someone attempting to get a refund, (5) an adult with unruly kids, (6) an adult with well-behaved kids, and maybe a boundary test with (7) a responsible 17 year old, (8) an unruly 19 year old, (9) someone with a small backpack, (10) someone with covered food.
Then I’d meet with the business owner and report who was let in, how they were treated, whether the enforcer had to think hard about the rules, etc. Maybe ask for clarification about whether they really care whether the cheap one is the husband or the boyfriend or the wife, etc. By doing the obvious tests first and presented that “yes, in general your requirements are correct” or “no, the staff in your store are paying no attention to the requirements”, I’ve opened up the conversation – I’ve shown that I have value as something more than just a complainer, we’ve got some testing done, and we can start to think about the meaning behind the requirements. I don’t think this wastes any time (we’re going to run those tests anyway), but it builds up a lot of good will.
(And as I read it, I think “cheap husbands” is meant to be cute… so perhaps I’d skip the cheap husband test, that seems awfully passive-aggressive to actually test for what is obviously not a real requirement. I doubt this kind of thing happens in software though. Anyone have any examples?)