Advice for a beginner QA that starts a new job

 Ask for reading material before you even start working

I mean here, there is less reference to test scripts and more to product and development documents. I am sure that the manager will be able to recommend the relevant material. You may not remember everything, but key concepts and names are possible.


  1. It will help with the explanations you get when you actually start working there.

a. People tend to introduce internal concepts without explaining, but you will be ready.

b. Understand the explanations about the product in the context of what you learned about the system.

2. Yes, this will impress your managers and co-workers.

 Test Cases

When starting to work, perform existing test cases, even if it's on the production version, if there's time. There is nothing like running tests to learn about the system (and you will probably find many things to update in the doc and/or new bugs, which is by itself an important contribution).

Avoid 'I'm smarter' questions

I have often encountered new employees who get explanations about a specific application and start asking questions like 'Oh, but wouldn't it be better if you have done <in a way I suggest> instead?' Or more blatantly 'But if you did it that way (IOW my way) it would have been better!'

It can be understood: you want to show you are bright, but the truth? it's annoying

  1. It prolongs the explanation;

  2. Might cause antagonism (no one likes smartass);

  3. Usually unproductive.

Sure, any system can be improved, and a "new eye" may see things differently, but:

  1. Do you understand the system enough to ask?

  2. Do you understand the system constraints?

  3. Are they all 'slow' and just waiting for you to come to show them the light? Probably not.

Do you have any questions about the why? Write them down, and when you feel you know enough, read them again. If there is something worthy there - raise it, with technical understanding. Now it will be heard.

Do ask about how

You'd better concentrate on understanding the system. Here, when you are explained, you should ask to understand and also to show you understand some parts. If you just nod in your head, the instructor has no idea if you've understood anything at all.

Write it down!

Do not pretend like you can remember everything. Write down anything that matters, because:

  1. It actually shows seriousness.

  2. There is nothing more annoying to a tutor than repeating terms or processes that were explained only the day before. At one stage or another, he'll just get tired of it.

Courage is important, as is a coordination of expectations

Schedule a meeting with the principal, and ask her:

  1. What expectations do you have?

  2. What is important to you in my work? What to emphasize?

  3. What will you say in three months - six months: 'We did a good recruitment? '

With this information, it will be easier for you to figure out what is important.

And the environment ... is it supportive (I)?

This refers to computers, tables, etc. If something does not work well, on a level that will interfere with work, you should report it. If you can't do your job properly because of a slow computer, it will not help you later to say I did not get the job done because the computer is weak... It's not an excuse because you'll get an answer right away: so why didn't you say something?

On the other hand, if the cable of the screen is not HDMI, wait with it, man.

And the environment ... is it supportive (II)?

This refers to members of the team. Yes, you have a million questions and everything seems important. Interrupting them at work, on the other hand, every moment with a new question, may not be the coolest idea you've ever had. Write down the questions and ask them in one session.

Do not get stuck when you do not have to!

Let's say there is something that is not clear without which you can't continue. If possible, check with Google first. He doesn't know everything, but quite a lot. If it doesn't, remember you have a mission you want to accomplish, ask your team/manager. You don't want to be asked in the evening what you have done and the answer will be: listen, you do not understand...

Do not start grading

Yes, politics. There is a tendency sometimes to tell the manager (even in response to his question), not only what I learned and from whom, but how much the trainer was good/bad. This might prove not to be the best thing to do. If you say the trainer is great and has a lot of knowledge, it might not be what your manager thinks... Remember the trainer always knows more than you know on the first day. Same thing if you think the trainer is not good, while he was just having a bad day, or your manager's best friend. You also may give compliments to your manager's opponent.

Know the product well, even parts you will not test

Install the product on your devices, and run a little Recon Session to have context in your tests.

Good luck!