How much testing do we need?

Listen everybody, I keep reading about all these people who go to conferences, they are noticeable speakers, have something to say about QA and I appreciate that.

I wish I was like that, but is it really worth it?

I can tell you right now that I wouldn't like to leave everything aside and just go for one week in London, for example. Not to mention the work and time you have to spend preparing prior to that: think about a subject that might interest people, do a nice presentation, buy a ticket, book a hotel room and go through the stress of travelling 9 hours just to present to a bunch of people interested in QA. Yeah, I agree, there is the satisfaction that somebody looks-up at you, asks you questions, you feel important to share your knowledge.

That is cool, I know the feeling, but really, how much more there is to say about QA?

In my opinion, QA can be reduced to a few sentences:
- test if you have a budget
- test intelligently if you have a bigger budget
- be prepared to give a QA status that will emphasize how well you successfully implemented with a limited budget
- people care only up to a point about QA, as long as the application works in production it doesn't matter if you had 30 defects or 100 defects.
- does anybody care that the application sucks? NO. People will continue to use it the way they can.
- does anybody care if I get frustrated while I use this application? NO.
Because in the end we had a successful implementation. And that's all there is about QA.

To be or not to be....on contract?

This is the question that lots of people ask themselves. Especially those who work full time because they've been wanting to switch to contract but they just don't have the guts to do that...

The other day a co-worker told me very bluntly that I don't count, "I'm just a resource" and had I been full time in the company it would have been different.

Why would it be different, I ask myself (I didn't ask her 'cause I was just too shocked with her declaration).

Why are full time people so mean with contract people? Or is it just envy because we get to do a lot of money and to work less?

Contract gives you so much flexibility; you don't like the place, don't like the people you move on to the next contract. Is that easy. The disadvantage is that you're always moving from one place to the next and you never seem to find your place. But eventually when you do you will stay there for years and years....and you make friendships, you build a reputation and you grow with that place.

On the opposite, as a full time worker you will put up with all the b..s...that people give you, have to support all the crazy people who have become managers after they did a wonder course of 3 days, you work on multi projects without getting more money, you get to do your project manager's job and you get to do those quarterly and yearly reviews with somebody who's not even qualified to be called a manager sometimes!

Forgive me, but how is this better?

It's funny how full time people always envy contract people for the money they make and they keep finding us faults - "Oh, you can't be a manager because you don't know how this company works." or "You can't sign timesheets even though I report to you because you are on contract and contract people don't sign timesheets!" or "You don't have any product knowledge because you haven't been here for 10 years, like I've been!"...

What is this, people???? Where did you get these ideas????

I work on contract and I'm very happy where I am in my life because I get to do a lot of money, I leave the place if I don't like it, I can say "No" a lot more and I get to leave work at 5 pm!

And even if I am a contractor I am very good at my work because I have to prove myself in a very competitive environment. And my rate depends on how good I am at what I do, so don't tell me that a full timer is better than a contractor! I'm dissappointed that some people really believe this.

This is totally wrong.

Photo credits: webchicken on flickr.com . Thanks!

Somebody must be happy today...

I got a very good news today: one of my trainees got a job as a software tester!!!!

I knew this would happen, it was only a matter of time.

Congratulations, B.!

Photo credits: Place light-having ideas - thanks!

He worked hard for the money.....

...he worked hard for the money....

Just had a conversation with a fellow-tester the other day around what a tester gets to do for the money.

I was telling him that a friend of mine works as a senior QA and wants to change to a QA lead role because he’s tired of knowing more than most of the managers who’s worked with and not having the authority to take decisions. Another reason was that he would be paid much more money and he thought it was worth it.

Harold told me he is very confident that he will get a QA lead position because his resume is impressive, he’s worked with major financial companies and he also has some experience working as a Business Analyst, which was definitely an asset.

Then my fellow-tester asked me if Harold knew what a QA lead position involved in reality. Project managers will come and haunt him for statuses every morning and afternoon, he would have to write plans and strategies in different formats because one manager likes Visio and another one likes Word; then he would have to justify decisions to people who don’t know anything about testing and sometimes he would even have to do the project manager’s job! Not to mention being a “delivery slave”, meaning being on the barricades, helping with implementations while others have a good night sleep!
…….

I realized that I have to have a discussion with Harold and find out if he knew all this stuff. Did he know what he was getting into?

........
I’ll let you know what Harold did.

Photo Credits: Katie Dureault on flickr.com - thanks!

Being and Testing

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!

My QA course - module 1

Friday I posted an entry about the feedback I got for the QA course I teach.

Testing is a very abstract concept. I remember the days when I was studying for a career in Testing. After days of reading books I still didn’t know what a test case was and how to write one.
How can you make people understand testing without getting into technical terms? How can you introduce concepts like requirements, functional specs, test cases to somebody who never heard of them?

In the opening of my first class, I actually tried two options:
1. I started the first class with a theoretical explanation of testing.
2. Then I tried by opening with this exercise.

Using the exercise was a big success; people understood that testing is not something technical; you don’t have to have technical experience to be able to test a product. One person that was working in a manufacturing plant as a quality controller realized immediately that she could use what she learned in her work and it was much easier to relate her experience to testing.

I use lots of practice in my course. For example I ask the participants to give examples of requirements, functional specs, or test cases. This way, they’re not only learning about test cases, but also about the difference between a requirement and a functional specification. And by actually dedicating a part of the class to this activity they learn by doing.

MODULE ONE
-----------------

A good chunk of the first module is dedicated to the Software Development Life Cycle (SDLC). This is a subject that lots of recruiters and employers ask about on the interview. You must know the different phases of the cycle and where you, as a tester, fit into the big picture. I explain terminology I use throughout the course and how important it is to use this language when going to the job or agency interview.

EVERY DAY IN CLASS ENDS WITH A WORKSHOP
-----------------------------------------------------------

In the second part of the first module we do the workshop – we learn how to write our resume. The resume is your key to the agency door; if you don’t get an agent to call you, you basically have no job interview (that does not mean that you have to wait until an agent calls you, but we’ll talk about this another time). State your experience starting with the most recent. Don’t mix QA skills with other skills; keep them separate. They say that the average time an agent or employer spends reading your resume is 20 seconds. First impression counts, so be sure your resume is clear, concise, and straight to the point.
We also talk about strengths and weaknesses, accomplishments and challenges; these are basic things that you will be asked about. In the course I give examples of each and teach you how to distinguish yourselves from the competition.

Some of the other things I teach you throughout the course are where to look for a job, what is the interview like, working on contract as opposed to full time, how agencies work and many more.

What would you like to know about my course?

Photo credits
Jaye Elle on Flickr.com. Thank you!

Course Feedback Part 1

As I was mentioning in the last post, every Friday I will post an entry where I comment the feedback that I got from the participants to my QA course. The course ran for 1 month, 4 consecutive Saturdays, with 18 participants.

Participants were sent a feedback form and asked to return the form by email after the end of the course.

The feedback form included questions from 3 categories:
1. Quality of Instruction
2. Quality of the course materials and value of the course
3. A number of specific questions where participants expressed their opinions freely.

The form was completed using the following scale: from 1 to 5 with 1 being the lowest (not at all) and 5 being the highest (exceptional).

1. Quality of Instruction
This category included questions about the instructor’s level of knowledge, planning, organization and communication of the material, as well as the availability and willingness to help or answer questions.
The feedback was very positive for this category, participants marked Very good (scale 4) and Exceptional (scale 5).

2. Quality of the course materials and value of the course
Here participants were asked to mark effectiveness of the course materials, usefulness of the take-home materials, how much they’ve learned in this course and how they will apply the newly gained knowledge and practical skills in the future.
Lots of people marked Very good and Exceptional and a few marked Satisfactory (scale 3).


The participants to this course had different backgrounds, with the majority having education in Finances and Engineering and some of them already working as QAs/Bas.

The course was designed for those who didn’t have any QA knowledge and the material was presented as such.

Those who were working in the QA field already knew most of the testing concepts presented but they found out new stuff in the workshop/job search skills part of the course.
In the end it got balanced nicely, the discussions generated were great; QAs were sharing their experience and so everybody was happy.

Would you consider a career switch to software testing in the near future?

Photo credits:
eddiehosa on Flickr.com

Course Review

I decided to give a new structure to my blog.

I’m going to organize it under categories:
1. Review of my QA course – this is the theory part;
2. Review and comment student feedback and participation to the course; lessons learned from those who got to the interview. Review of my training techniques – what worked well and what needs to be improved.

Expect to see an entry each Monday about the course structure and the course itself, by chapters.
Every Friday I’m going to follow-up with an entry about the practical side (the funny stuff)…

I encourage everybody to leave comments on my blog; I’m hoping to create a vibrant community of people who are new in the QA field and don’t know where to start from. Senior QAs who want to give an advice or just to leave their feedback are very welcome to do so.

What would you like to find out in a QA blog?

Photo credits:
saragoldsmith on Flickr.com - thank you!

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

TASSQ

TASSQ e o resursa buna in ce priveste prezentari si meeting-uri la care puteti merge si afla ceva nou.
De asemenea va puteti inspira din prezentarile din archiva cu privire la scrierea resume-ului, job interview si alte subiecte mai legate de testing-ul propriu-zis.
Se intimpla sa lucrez cu presendintele asociatiei, Joe Larizza, care e seful QA department-ului la RBC Dexia. E un tip calm, cu multa experienta care are ceva de spus.
Am fost la una din sedintele TASSQ acum vreo doi ani sa vad despre ce e vorba si mi-a placut. Se face networking, se ia cina, dupa care urmeaza presentarea. Imi propun sa incep sa merg din nou ca un tester dedicat ce sint.
(imi place cum suna "dedicated tester", am o colega care tot timpul ma prezinta asa...)