What’s the worst sin a software developer can commit? Off the top of your head, you might say:

  • “Failing to document his or her code.”
  • “Failing to unit-test his or her code.”
  • “Turning in code that doesn’t conform to specifications.”
  • “Using nonstandard naming conventions.”

However, as a technical writer, I see evidence every day of the worst sin of all: Failure to generate appropriate test data. This week, my message is for developers and managers of development teams everywhere: If you create an application without using realistic test data, your colleagues have every right to keep your project out of production and bounce it back to you. Here’s why.

Just key it (the dummy data, that is)
Recently, a small software company hired me to write a user’s manual for a Web-based application designed for elementary school teachers. By the time I came into the loop, the programming had been finished for quite some time—I was not asked to do any testing.

I had just started writing the section entitled “How to enter class rosters” when I discovered the first big bug. The “Middle Name” field looked like it ought to allow up to 15 or 20 characters, but it only allowed one.

So I had to call the developer and ask: “Hey, what’s your intention on this middle name field? If you want users to enter an initial, you need to change the label to ‘Middle Initial.’ Otherwise, you need to fix this field so it allows the user to enter more than one character.”
“You can enter more than one character in that field,” the programmer declared.
“Maybe you’re supposed to be able to, but the program won’t let me,” I reported.

Eventually, under the auspices of “writing the manual,” I turned up a dozen or so other bugs related to data validation. Folks, it was obvious to me that the programmer hadn’t bothered to enter hardly any dummy data into his own database, or he would have noticed the glaring deficiencies in his code.

So how could this developer have avoided the embarrassment and extra work associated with fixing code previously thought to be “bulletproof”? There’s only one way: During unit testing, the developer must enter “good” and “bad” data in every field on each data entry screen. Confirm that validation rules are working properly. For instance, if the Height field is supposed to contain only numbers (as in inches), then it shouldn’t allow the user to type 5’11”.

Some developers are just too lazy to take time to test their own code. Those folks should seek employment elsewhere and stop wasting the valuable time and resources that are required to clean up after their sloppy programming habits.

Keep it real
When you’re testing data entry and update screens, it isn’t enough to enter any old dummy data. You must also enter appropriate data. When I was testing and documenting the reporting features of the school application, I noticed that there were several student records with names like “aaa, aaa” and “bbb, bbb.”

At first blush, you might say, “Well, Jeff, at least the programmer entered something in those fields.” Uh huh. I refused to put screen shots of that kind of sample data into my documentation.

I had a heart-to-heart with the programmer and explained that, in my opinion, his customers deserve to see realistic entries in screen shots, even if they’re all in the Smith or Doe family. The programmer’s response? “Cool. Could you enter some records like that for me?”

Testing to the limit
Of course, there’s much more to testing software than making sure that your developers key realistic test data, but it’s a good first step. If you’re interested in taking the testing process to the next level in your organization, check out these articles by TechRepublic contributor Tom Mochal: “Keep the software testing life cycle spinning” and “Think ahead: Defining your test strategy.”

Test this!

Who generates the test data in your shop? Developers? Testers? Anybody? To share your experience and advice, post a note below or write to Jeff.