In testing everything is about being logic, organized, critical and seeing everything that’s wrong. And that could be anything.
Just the other day my colleague who is a developer/QA/BA and a friend of mine comes to me and says:
- You know, I made this dress myself! And she looks at me very proudly.
- Wow, I didn’t know you could do that, I said.
- Yes. When I was in the university I used to sew pants, dresses…with this one I still have to properly do the hem, it’s not quite finished yet…
- Well, C., I can see that the sides are longer than the mid section; did you do that on purpose? I said.
She wanted to say something but she hesitated and she just looked at me smiling. Then I realized that I could have shut up, why did I have to make that remark?
But what can I do, I am a tester, I see everything and I can't shut up. Or at least, that’s the reason I like to give when I put my foot into my mouth.
I was reading an article the other day (sorry, I don’t have the link, but will look for it) where the author says that after being a tester for a while you develop this habit of looking for errors and the negative all the time. And this reflects in your relationship with people, you’re analysing too much, you’re criticyzing all the time, you find faults, or you try to find the “root cause” of the problem.
And I thought ‘Oh, my, that’s very true’, I do that all the time, just ask my husband:)))))
I wasn’t like that when I started my career in testing but now I have to admit that I have a very developed sense of observation and I can spot mistakes or inconsistencies right away.
What about your sense of observation? Can you spot any errors in my article? :))
** ** **
Photo credits: Dan Zen on flickr.com - thank you!
Friday, August 1, 2008
Being and Testing
Posted by
Georgia Motoc
at
10:31 PM
0
comments
Software Testing, Canada functional specifications, Georgia Motoc, Panamo, QA, quality assurance, requirements, software testing, SQA, Toronto QA courses, trainer, training
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
Posted by
Georgia Motoc
at
2:24 PM
2
comments
Software Testing, Canada business, case, cases, functional, george, georgia, motoc, QA, requirements, specifications, test case, Tester