This website uses cookies to help improve your user experience
This sixth article of the series Software Development Team Roles is about QA-engineers. Former posts were dedicated to PHP Developer, .NET Developer, Project Manager, Head of Marketing and a Mobile App Developer. This time we’ve altered the layout a bit and the story will be delivered by the team members themselves.
The position of a QA-engineer in a software development team is quite new on the Belarusian market and is still being shaped. To learn some particulars and about the ups and downs of the profession we asked our specialists to share their own stories. This article is what has come out of that.
“A QA-engineer background comprises some logic, some common sense, and a great deal of life experience.” — folk wisdom
I told a story at work once about how as a child I persistently took apart all my toys wanting to learn what there was inside. My colleague who happened to be a developer admitted the same thing.
Then, I asked him why he became a developer and not a tester. He said it was because he could put them back together after that.
The QA main priority is providing quality. At least three types of specialists are engaged in achieving it:
A QA-engineer is a specialist who devotes time and skills to improving the application development process, prevent defects, and identify errors in the product performance.
A QA-engineer position is one of the most important roles in IT as it is a QA-engineer who makes the final decision as to whether a product is ready or not.
Quality assurance is an investigation, another way of thinking, an ability to change a product and realize your own ideas in it, it’s persistence and patience, it means being on the look-out for a user’s interests, and it implies flexibility.
The Quality Control process, which covers product quality control, is distinguished within general QA. QC-specialists analyze the testing results and are responsible for the identification and elimination of defects in a project.
A software tester is an even more specialized profession within QA/QC. These specialists look for plausible inconsistencies and failures in the application performance, modeling diverse situations that can emerge while using the program and later describe the found flaws and the precise ways to reproduce them.
According to dev.by the number of testing and QA-specialists has significantly increased in Belarus as of late.
A typical Belarusian QA-engineer is female (34% women vs. 11% men) and at the age of 25. She has experience from half a year (Junior) to 5 years (Senior) and gets a salary in the range of $500-$1,500.
“Do not believe, just check it” — a tester’s motto
Oxagile QA team has highlighted several advantages of a good QA-engineer:
A typical tester starts his or her career in the following way; they also answer positively to the following questions:
Even a good tester is not infallible. You can come to that conclusion having read some anecdotal stories told by our team members.
Actively accepting a project that was meant for selling video-content, Lorena (who was responsible for accepting the application) started checking the app performance in the Production environment.
She sent a bug with the following description: to log in, open adult content and buy a film. The problem was that on the 8th minute, the film display was interrupted…
While waiting for the troubled 8th minute of the film I managed to catch the attention of all the guys sitting around. Having lost all sense of shame I turned my monitor to one of the project managers sitting beside me and asked him to follow the video and call me at the 8th minute.
Conclusion: the film was reproduced for more than 8 minutes; all the .Net team has taken a lively interest in my projects since then and we realized that Lorena is a professional as she had to see all the videos that included not only gay films but those with animals as well.
We regularly had problems with servers and testing as the set-top box was blocked for a few days.
As a result, I started printing Rabbit-no-way and stuck them to the STB with explanatory notes, for example: “- Still trying to get the stage working? … – No way!”.
All the team liked those cute animals and we managed to overcome over all the project ups and downs. Unfortunately, the precious pile of stickers was mercilessly thrown away by our office manager several years later when she was desperately trying to bring some order to my upper shelf.
Rush deadlines were quite tough in one of the projects and we often had to stay late in the office. To hint at our indignation to all those present during the Acceptance testing we turned on music for everybody in the office to listen to and enjoy. The earlier we were provided with a release, the merrier and quieter the music performance was.
Any delays in the necessary bug fixes, testing environment deployment or things of the kind had a significant impact on the music, changing it for the worst. Once we finished our work late at night listening to some brutal death metal. It was our (maybe a bit strange) method of fighting the system.
Working on the project from the very beginning until the very end in a team that included 5 developers and me, a software tester, I faced very serious communication trouble. We all know that if you constantly point at a person’s mistakes you will be treated biasedly.
That’s why I started building bridges with developers: providing yummies ;-), reporting on their working achievements, praising the decreasing number of bugs or speedy fixes. I reminded of a partial attitude to the project, and asked them to tell me about any discovered bugs.
We got carried away with the project and our team even received a nickname and there were jokes that only our team members could understand and share. I remember our office manager often getting nervous when arriving at our room: we were extremely quiet while working and extremely noisy while brainstorming.
“I will engage in developing until I am good at testing”. — Alexey Platkovsky
Automated software testing – is a part of the testing process in the quality control stage. It implies that automatic tools are used to run tests and control performance results, which significantly shortens and simplifies the testing process.
Nowadays, it is quite a common event: people would rather become testers as they think that their programming skills are not enough to become developers.
First of all, it’s not right to view the profession of a QA-engineer as some revolving door and quite defective in itself. Secondly, such people can find their vocation in automated testing.
That’s a place to enjoy patterns, frameworks, and 1,000+ other equally entertaining techniques and approaches.
Moreover, nowadays it can turn out to be a problem to find a specialist in software test automation with good programming skills and the market average on their salaries in comparison with those of developers can differ 1.5-2 times in favor of software test automation professionals.
The career of an automated testing engineer has an array of advantages:
If a developer implements machine logic, then you come with the logic and behavior of a common user who is much more devious and wicked. 🙂
It is a widely accepted statement that a real developer will be fed up with writing automated tests in two weeks. Yep, we in Belarus are lagging behind the times.
By the way, a specialist in software test automation at Google for instance, is a position equal to a developer. They can write some dull code and at the same time they are able to construct continuous integration systems and sometimes even know more than developers – as they work simultaneously on several projects that have absolutely nothing in common: neither domains nor target audiences or programming tools.
I hope we will appreciate these specialists in Belarus in the long run. Nobody will say then: I will engage myself in testing until I excel at developing. Maybe it will be vice versa: I will engage in developing until I am good at testing. 🙂
P.S. Thanks for help in writing this article to Oxagile QA consultants, Testers and Engineers who shared with us sacraments of their profession. Given in the article quotes are taken out of their stories.