One way to build quality in is to prevent defects from ever happening. Discover how you can avoid defects by figuring out how to test each feature or requirement before you begin to write the code. Clarke Ching offers up an easy, hands-on example you can put to use today.
I looked at my watch. It was almost 5:30, and I figured that I'd be out the door by 6:00 for a change. I glanced at the email on my screen. It was very important that I got it right, and I'd spent much of the afternoon polishing it, trimming it down so it was as clear and concise as possible-not an easy task, but well worth the effort since more than 300 people were going to read it. I read it a final time, added my signature "Steve Abernethy, Director of Software Development," and clicked send.
Before I could power down my computer, I heard a deep voice say "Knock knock." I looked up. Phil, my friend and one of my most experienced developers, was standing at the door.
"Got five minutes?" he asked. I looked at my watch and added thirty minutes-the real equivalent of Phil's five.
"Sure," I said. "I'm busy, but what's up?"
"I want to show you something. I think it is important. Can you open up a blank spreadsheet?"
Strange request, I thought. Phil was not much of a spreadsheet man, but I did as he asked.
"You know how we've been talking with Tim, our testing manager, about how we can build quality into our software development process, rather than test defects out? Remember when he pointed out that his testers found many defects without ever running any tests-just by writing the test scenarios, asking our customers if that's what they wanted, then asking our developers if that's what they'd built, and finally checking to see if the two matched up?"
"Yes," I said. We'd agreed that it would be wise to write the tests as part of the requirements, before we built the code, but we weren't sure how to do it. Tim was thinking about it, and I was skeptical.
Phil smiled his big, famous smile. He had a delightful way of looking at life the way a cat looks at spilt milk. "I've found a way to demonstrate the idea to you, as well as to our staff. Let me show you using your spreadsheet software." He sat at my desk, took the keyboard, and started typing.
"I'm going to write a new function using the spreadsheet's programming language. It'll convert integers into Roman numerals. Look."
He typed in three column headers-integer, Roman, and function-and under them typed 1, the letter I, and then the formula =toRoman(A2).
"The function doesn't work," I said, looking at the error in cell C2.
"I know," Phil replied. "This is my first test, and it won't pass because I haven't written anything yet." He clicked a few buttons and created a new function called toRoman(), which took in an integer parameter and simply returned the letter I. He switched back to the spreadsheet, forced it to recalculate, and suddenly cell C2 said I.
"The test passes," I said, generously-it seemed pretty lame so far.
"Watch," he said, as he typed 2 and II into the next row and copied the function down. The function returned I, not II. So he modified the code so that if the input were 1, it returned I, but if it were 2, then it returned II.
"Wow," I said half-heartedly.
"You do 3 = III," he said, pushing the keyboard to me.
Reluctantly, I added the test data,copied the function down-which failed,of course-and then adjusted the code to make it work by adding another if statement. All three tests passed. I looked at Phil. He looked back. I knew what he wanted me to do. I added the