Don’t Use Risky Mock Data

Scenario 1

The Scrum team is ending a 3 week iteration developing a custom CRM for your company.  Despite the fact that no one should be writing yet another CRM, the team is excited to show the shiny new forms in Sprint Review.  The one developer who can be cajoled into speaking opens the application and the AJAX-enabled spiny, shiny widgets begin twinkling.

The VP of Sales, who is a deeply religious and proper woman as well as the commissioner of this project, gets all the way to a half smile before scowling and asking in an irritated tone of voice, “And who, pray tell, is Fart Sack McGee?”

And there it is, 3 items from the top of the data grid. A developer has entered a customer named Fart Sack McGee, who apparently  lives at 6969 Pud Pull Circle, Bunghole, New Jersey 66669.

Awkward.

Scenario 2

You are in seated in the back of a room in which your Director of Product Management is presenting a demo of the latest release from the Scrum team to a potential customer.  The application is a front end to the customer’s back end order processing system.

“Here you can see which orders are in progress and which orders have already been filled,” the product manager crows confidently.  He has worked long and hard to ensure that the screen being shown synthesizes complex data into easily understood models.

“One of the orders is duplicated,” the customer mutters as he examines the screen.

“What? No, those are 2 different orders,” says the PM.  “See, if we drill down into the order we can see that there are 2 different tracking numbers.”

“Are you sure the system didn’t duplicate an order?” asks the customer. “No one orders 47 copies the same book, and certainly 2 people don’t.”

“No, see, that’s not real data,” smiles the PM nervously. “The developers just but a bunch of garbage data in there to simulate the process while they are developing the application.”  He sneaks in a scowl at you.

“Are you sure?” the customer asks.  “It looks like a bug to me.”

And now you begin to shift your weight from cheek to cheek and think about getting out of there.

Avoid Looking Stupid

It isn’t enough to avoid profanity and off-color humor in your tests and code comments, that’s the base expectation.  The end game is to avoid looking stupid, which I find far more challenging :).

Actually spending time to think through the domain problem of the users and mocking data appropriate to the task can actually be quite useful.  In the above example it would actually be useful to trap the duplicate order as a warning in the system.  Hearing that feedback from the customer should prompt that kind of thinking.

The bottom line is this; Do not use suggestive or non-domain appropriate meta-data to seed a database under development or test.  While it may cause a chuckle and seem inoffensive at the time you do it, it isn’t work the risk of looking stupid later.