Software Testing

2006-Mar-8 - How to start testing?

My short time in QA and software testing branch and the fact that I was many time confused at the beginnings made me write this blog.

I can say that beginning testing is curious for many of the people in the branch. Coming from inside software programming world, or worse, from outside, you feel confused of what you have to do.

First, I will describe the pre-interview phase with two examples with two friends of mine.

I met soon an old friend who after graduated, worked as a programmer but now he found a good job on testing and wanted to apply for it but didn't knew anything about it. He came to me and asked me many things, but all were pure theory. Of course, theory is good, but how it is applied is more important. I responded to him, that whatever he knows in programming, if the job regards blackbox testing, the employer will try to see how he thinks and not specially what he knows as programmer. Otherwise, his algorithmic should be decisive.

Another friend of mine had to be interviewed for a testing job. He never worked in the field but his studies background are in computer science. He also asked me what should he know and if he had any chances. He showed also the job description and I saw that it was another blackbox one. Knowing that he was a good chess player, I knew he will take the job.

Conclusion: read carefully the testing job description, think what you know, what you don't know and more, what you can do. Never believe that theory is show-stopper. Important is to put in balance all the facts, have trust in your capabilities, do not lie in your CV and be analytical.

Now, that you're employed, what to do?
Every organisation has its specifics, has different kind of internal structures and work ways. So, in your first days inside a testing team, I think is better to:

Learn company's organizational culture;
See which tools are used for testing, reporting, documentation, etc;
Learn or adapt to new work procedures, if implemented;

From now on, you're on your feet. You'll have to do the test cases or test scripts assigned, or worse, in small companies, plan them and then do them.

If you'll have to write a test plan, don't try to find them over Internet. Every project is different. Use your tool for writing them, or if you haven't one, write them using a word processor or a spreadsheet. Important it's not the form, but the content. Think at as many test cases as you can and write each one. Do not ever let anyone outside your test plan thinking that that one is to simple or impossible to happen or useless. For test cases that need a test script, do not hesitate to write it and is better to do it in the moment of writing the test case. It's sometimes hard to remember what is the real test that you wanted to make, and a description or a script can be very helpfull.

If you have only to do manual test cases or to implement automated testing scripts, follow your working procedure and done them. Be as analitical as you can, also, very rigurous and never skip anything from your job. Anything else that maybe make you curious is good, but should be done as extra time (i.e. reading testing books or documents that do not regard your project).

In testing is very important to learn, to be up to date with what is new and what can affect your daily job or your project. So, documenting is very good but pay attention with what you're documenting with. Loosing time with tons of documents which are not interesting or do not apply to your usual testing tasks is useless.

2006-Mar-12 - An Interesting Start

Posted by philk10

this should be a good blog if it carries on like this, good work
I wish the 'tester' where I work had the attitude in your last paragraph

Permanent Link

About Me

my observations from software testing experience

Friends

• philk10
• PeteNairn