How to start testing ? 
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 article. I can say that
beginning testing is curious for ...
S.E.O. - Search Engine Optimisation is a set of methods aimed at improving the
ranking of a website in search engine listings. The term also refers to an industry of
consultants that carry out optimization projects ...
How To Choose A Domain Name ? A domain name provides an identity to the business.
While buying a domain name you need to note down the name of the website domain names and
its nearest ones so that if you do not get that particular domain name, then ...
Register now and you will be the first one informed about our offer!
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.
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:
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:
1. Learn company's organizational culture;
2. See which tools are used for testing, reporting, documentation, etc;
3. Learn or adapt to new work procedures, if implemented;
2. See which tools are used for testing, reporting, documentation, etc;
3. 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.
