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.
The difference between a software tester and a QA-engineer
“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.
A good QA-engineer
“Do not believe, just check it” — a tester’s motto
Oxagile QA team has highlighted several advantages of a good QA-engineer:
- A good QA-engineer is a good psychologist both for customers, project managers, and developers. That’s why reading books on psychology, body language, and non-verbal communication in general is a good hobby.
- A good QA-engineer knows or at least has read something about memory functioning and different techniques of information memorizing (mnemonics, etc.).
- A good QA-engineer can handle his or her deconstruction ability for the benefit of the project.
- A good QA-engineer understands why he or she is testing a certain project, taking into consideration the final goals (what’s more important: quality or speed?).
- A good QA-engineer is always proactive.
- A good QA-engineer is fully aware of the fact that a developer is not an enemy but rather the closest friend, as a developer is the main source of the project. Without a developer there would be no QA-engineer.
- A good QA-engineer admits his or her mistakes.
- Even lacking a technical background and possessing a typical humanitarian mindset one can become a good QA-engineer, provided that they work hard.
A typical tester starts his or her career in the following way; they also answer positively to the following questions:
- Do you constantly analyze yourself?
- Are you attentive, diligent? Do you like finding things in places where they can’t be?
- Do you enjoy catching your best ever bug in the main functionality of the application?
- Is Jira your best friend and a helping hand?
- Where can you learn such cute phrases: “it’s not all that clear but I’ve fixed it” or “you’ve been kicked off from the app as I logged in under your username” or “it seems to be working but needs testing”?
A naughty QA-engineer
Even a good tester is not infallible. You can come to that conclusion having read some anecdotal stories told by our team members.
Story No. 1
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.
Story No. 2
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.
Story No. 3
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.
Story No. 4
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.
Software Testers and Developers
“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:
- you not only create things, but also destruct them;
- you save hundreds and thousands of man-hours at your department;
- you are engaged in load testing, GUI testing and functional testing and look for optimization and multisequencing methods and many others of the kind and all that should be described in the code;
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-Testers and Engineers who shared with us sacraments of their profession. Given in the article quotes are taken out of their stories.