Today, we start a series of interviews with members of our team. It is a great way to show how we work as a team and as individuals. We hope it will shed light onto some of the important questions people are curious about, but have never asked a professional! It is also aimed at giving each and every team member a chance to speak their heart out and say what they think can be improved and what misconceptions there are that they would have wanted people to know about.
This time, we spoke with Stas — our expert in Manual Quality Assurance. So, Stas, tell us a little bit about yourself?
I work as a Manual Quality Assurance at Movadex. I consider myself as not just a “tester”, but an expert in software quality assurance, because I have seen and closed dozens of projects, and that I am very proud of!
How did you get a job at Movadex? What was your first month here like, and what were your impressions?
I put my resume on Djinni and got invited to the interview. You know, I didn’t actually understand what I was doing in my first month, and what I was supposed to do, what I was expected to do, because I was the only QA expert at that time. The majority of the team members used to work without one, so they have professionally grown accustomed to getting by without any QA whatsoever, so there wasn’t much work.
What has changed since that time, and what are your impressions of the company?
A lot has changed, actually. Especially people. They started to respect my work and never close the projects without my review. Moreover, it is quite often that they ask me for some advice.
What does your usual work day look like?
Usually, my work day starts with a review of our Asana board, where the developers mark the completed tasks. Then I check today’s schedule and start working on test cases if some features or functionalities are already done. After that, I cover all the test cases and make sure that everything works properly. If I find any bugs, I register them in the bug report and pass it over to the development team, who in their turn are responsible for fixing them.
How do you prepare for the testing process? What do you need to start?
I start with a short review of the project I am working on, or a particular piece of it, at least. It is good help if there is any piece of tech documentation to help me sort out the functionality must be there at the testing stage. Also, just a little Mythbusters for you: testing occurs not only shortly before the project is done, but also in the process of development. It is quite often to see the developers oversee the problems in the UI because they are mostly responsible for the formation of the logic, which is also very important.
Manual Quality Assurance is a lot of work. How do you stay focused at tasks at hand and organized in general, are there any tips?
To stay organized, choose the environment that will contain all the tasks, test cases and bug reports. You have to understand the difference between priority and severity to do everything right.
Say, there’s a new project, a big marketplace. Design and development are done, Quality Assurance is needed. You have the task list in front of you. What will you do, and what stages there are, how much time do you need to professionally do your job?
For starters, I will check the tech documentation and design. Then, I will make sure that I have been given all the necessary information to do the testing. It may be a test account or test credit card. Then I will get to writing test cases to the main functions as registration, log in and so on.
What do you do after completing Quality Assurance? Are there any special procedures that need to be followed? How do you mark individual tasks?
After testing, I need to write a test case. Test cases are so called scenarios that describe a certain result that must be achieved after following all of the steps. You need them for other QA experts to be able to follow these steps, because they may not fully know the project.
What setbacks do you usually encounter in the process? Maybe some of them are common, or rare?
The most common problem is that developers often do not report that they have this or that feature already developed locally. In that case, I create a bug report that in reality was not actually needed. This is the most common problem in the team, the lack of communication.
If you compare the designers and developers' work to yours, who has more responsibility for the end result?
Developers have more responsibilities in late stages, because what they get is client-approved design, and they are responsible for making it work to its fullest.
How many projects do you have monthly?
Depends. Usually it’s no less than 3 or 4 projects, sometimes there may be more, if the company is especially busy.
Can you tell us about the most difficult project in your career?
It was a government project. It was meant to help people from countries with low income. It’s structure was the hard thing, as it was built on microservice architecture, which in its turn meant that there were a ton of things that needed to be tested. It goes without saying that there were even more test cases. But the main obstacle was that it was a ready project, and there were two environments: test and production. It meant that there was a lot of work to be done and testing of unsatisfactory quality may bring a lot of problems to the users.
What do you want people to understand about your job?
Not all people understand the importance of Quality Assurance, because they think that it is just clicking your mouse and jotting down what you see. I would be glad if more people understood that there is no good development without testing.
What piece of advice would you give to new Quality Assurance agents?
First, I would like to advise them to spend more time self-educating and self-developing, looking and reviewing a lot of interesting projects. It will help them to correctly and efficiently distribute time and get the job done right.
Describe your work in three words.
Analysis, clarification, processing.
