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