My New Experience Working in Quality Assurance

Nataliia is a skilled developer. While waiting for a new project to begin, she was approached with the opportunity to upgrade her skills by working as a QA engineer for a few months. She was excited by the opportunity, which she shares more details about here.

How would I approach the task of doing quality assurance with more than five years of Vue + Node experience? I was surprised when I was asked, but decided why not? While I was waiting for an interesting JavaScript project, why not upgrade my skills?

I enjoyed the practice, so I want to share some of my experience, comments, and impressions.

It should be noted here that I cannot imagine a developer who would not be a tester at the same time. After all, the first person who tests the code is the developer himself. 

The task is quite interesting, the company is large, and the experience will be useful.

Let’s go!

1. Information

So, one still doesn’t know anything except the name of the project, one doesn’t have permissions, and one hasn’t “met” the project yet. This is the perfect time! And no, not in order to sit around waiting for a call from the PM, but in order to find information about the project on the Internet. 

This is one’s first acquaintance, first impression. These are the first questions that one can ask, become more knowledgeable about the issue, and also show interest.

A definite plus!

In my case, I also explored articles about the peculiarities of QA work, the principles and rules of the correct testing process, drawing up reports, and maintaining other documentation.

I needed all this in my further work.

2. Calls/meetings – acquaintances

Almost every project work begins with an introduction to the PM and a brief overview of the project itself. I really like to have video recordings of these meetings so that I can watch it all over again, because often some small nuances are forgotten.

One should prepare for this in advance. If it is not possible to make a recording (for any reason), a pen and a piece of paper will help. Key points arising during the conversation, questions, ideas – all this can (and should) be used in the future.

3. Obtaining permits

In fact, it took me a long time to stop being shy about asking questions. At the beginning of my career, it was quite difficult for me to call someone and say that no, my admission is still not working. It always seemed to me that I did not understand something, that I was doing something wrong, and in general, how could one be so stupid.

So, it’s polite to ask when something won’t open/launch/doesn’t work – THAT’S NORMAL. To sit and wait when they ask how one is doing, and one still doesn’t have a permit – no, not ok.

Do not be shy!

4. Independent familiarization with the project / documentation

And finally, one has all the tolerances and settings. And here another extreme can begin, when a developer/tester/just someone new immediately calls with a phrase like: “Nothing is clear.”

It’s not ok.

Every project has documentation. Some are good and detailed — a whole Wikipedia. Some are worse and chaotic. The first thing to do is to familiarize yourself with the documentation and write down questions. Follow the link, try the functionality, and note the features and unclear points.

5. Call/meet with developers/other testers/PM

Now, with a lot of specific questions, one simply has to ask them. It is normal not to know something at the beginning of working on a project. Such a meeting will be fruitful. This is not about a lack of competence. Quite the opposite. One has spent time and is asking specific questions.

A well-asked question also shows the level of one’s awareness, and it’s a good chance to get to know the team better — especially if everyone works remotely, are located in different countries around the world, and are unlikely to ever meet in person.

6. The first test task

Don’t be afraid to offer new ideas. New team members have new perspectives and ideas – and that’s great! Perhaps this — a new look from the side — was missing for so long. In my experience, even if one’s ideas are not accepted, initiative is always better than eternal silence during meetings.

And, of course, work on mistakes. Did someone give a comment or a suggestion? Was something wrong?

Fix it!

Accepting criticism is a touchy subject for many people, but I have a little secret: if the criticism is constructive, even if it really bothers one, say thank you. Exactly! Smile and say thank you loudly. One will feel how the situation changes instantly. This is experience. This is the opportunity to become better and gain the ability to do the task better next time.

Criticism is wonderful. Don’t be offended! Ask clarifying questions. If one does not agree, say thanks, and appeal. The truth is born in the discussion itself.

Do not be silent! Suggest, discuss, and develop. Share impressions of an interesting article on a professional topic.

You will definitely be appreciated!

I wish you career success and interesting projects!

We appreciate Nataliia sharing about her experiences and advice for other people working in quality assurance. Our team at Swan is amazing! To discover more about how our team can help your team, schedule a free assessment.