Monday, February 18, 2008

Business requirements / Functional specifications / Test cases














The most common documents a Software Tester works with: business requirements - functional specifications - test cases.

My hubby, who is a senior tester with engineering and accounting background, had a great idea on how to introduce these concepts to a student who never heard of them.

So I took one of my 2-year-old son's toys to the course.


In front of the class, I pressed the button, and the gears on the toy started turning, a little melody was playing out, and there were flashing lights under each gear.

And then I asked the students:
"What do you think the designers of this toy wanted it to do?"

Then I wrote the answers on the flipchart:
"Swing the gears when the baby is pressing the button."
"Play a little melody while the gears are rotating."
"Display some flashing lights while the melody is playing."
"It must have a battery compartment at the back to supply the power for lights, engine and music."

I said: "These are the business requirements."

** ** **
Then I asked the students:
"Let's think of the battery compartment for this toy. What do you think the conditions are for this compartment to work?"

Again, wrote the answers on the flipchart:
"It must allow 2 batteries in."
"The batteries must be AAA."
"It must be secured with a cover fastened with 4 screws."

I said: "These are functional specifications."

** ** **

Finally, I asked again about the battery compartment:
"When they put this toy into mass production, how do you think they were sure there is no danger for a baby to use it? Think of the battery compartment only."

Flipchart:
"They check to see if the batteries' cover holds up if 1 or 2 screws are missing."
"They shake the toy to find out if the screws are not coming out."
"They leave the toy ON to check if the batteries heat up too much."

And I said: "These are test cases."


*** ** **
Indeed, these are the core documents in the life of a Software Tester.

** ** **
Example:

Business requirement: we need to open a file from within this screen.

Functional specifications:
1. Open file via menu
1.1 Display a menu including the option "File"
1.1.1 Display an option within the File menu, named "Open file..."

2. The "File" menu has a shortcut access key.
2.1 The shortcut key is "F'"
2.2 The shortcut is accessible by key-ing "Alt+F"

3. The file-open functionality is accessible via a mnemonic
3.1 To open a file using a mnemonic, type in Ctrl+D

Test Cases:
TC1: verify that the menu bar contains a File option
TC2: type in Alt+F
TC3: type in Ctrl+D

2 comments:

Anonymous said...

Hi Georgia! Very funny comparation, but effective indeed! The project that I work on doesn't use Functional Specifications, we test based on Business Requirements. Anything wrong with this? Peter Cheung, Toronto.

Georgia Motoc said...

Thanks Peter for your comment! I know projects "skipping" the functional specifications step, and it is so SAD. Writing Func.Specs is actually designing the application. Everybody is using them: business, developers (to know what to code) and QA (to know what to test). A great article about Functional Specifications and their benefits is here: http://www.joelonsoftware.com/articles/fog0000000036.html

Read other posts