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!

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 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!