Most Common Reasons Why QA Engineers Get Fired

You have successfully passed the interview and coped with the test task, the employer is ready to offer your first job as a novice tester. And so, you, inspired by your success, raring to go. Because before that, you read a couple of books on software testing, successfully completed an online course, and even read a couple of articles on the Internet about how to be the best tester. And now, for three months, you heed the recommendations and pieces of advice of more experienced colleagues, stay late to understand the complex functionality, introduce millions of bugs and even tire yourself out with overwork.

Finally, the probation period comes to an end, and you are rubbing your hands, confident of your success. However, all of a sudden, the manager hints that they do not intend to continue cooperation and are going to find another tester. But wait a minute, why? You seem to have read books on testing, took courses, and followed the advice of colleagues. Not to mention the millions of bugs introduced and hours of overwork. And here we go.

Well, let’s figure it out together: why, despite the knowledge and efforts, they can fire novice testers, and how not to become one of them?

Just Not Being Attentive Enough

In a new team everyone wants to be liked, make a good impression, and establish themselves. This is exactly why many novice testers are staying late, overwork and, at times, do something completely different than expected. This is all because they were inattentive.

For a team manager, such mistakes are very indicative of professionalism as one of the most important qualities of a tester is his attentiveness. Otherwise, how can we be sure of the quality of their work, if they are not even able to carefully study the task?

Here are some examples from the experience of team manager.

One of the teams is testing a website that provides users with different credit options. The website itself consists of only two screens: a short form and an extended one, where, by setting certain parameters and values, you can get information about the loan, term, interest rate, amount, and more.

So, the manager gave the tester a task: to build a decision table on the screen with a short form. And instead, the tester did the extended one, having spent an unimaginable amount of time (the short form has only 3 fields and 9 values, while the extended one has more than 30 values). As a result, the tester did the work absolutely not required.

Another employee went through a usability checklist, where one of the points was to check the speed of the search engine on the website.

The checklist item sounds like “How fast does the search work”. And a rather simple answer is expected: “it works quickly, the response is within 3 seconds” (which, according to generally accepted standards, is good), but for some reason such simplicity confused the employee and she gave the definition of performance and how to measure it, but did not answer the question. Do you think the manager was delighted with such initiative? The correct answer is “no”. Time is wasted and the result is zero.

Therefore, I always say, dear testers, please be more attentive, because the statement of the problem (question) very often contains a part of the answer. Do not reinvent the wheel where it is not required!

“Then, how can I improve your attentiveness?”, you would ask. Below are a few tips.

• Take only one task. Do not grab more at once. Multitasking is cool, but very labor intensive. Our poor brain does not have time to process several cases at the same time and will definitely let some things take its course. Having received a task for testing, do only that one, and do not talk on the phone with a friend and do not scroll social networks.
• Focus! Carefully and several times read the problem statement, in 90% of cases it already contains a scheme of actions or some kind of hint.
• Do what is necessary while avoiding unnecessary. Everything is simple here: they asked you to decompose the functionality then decompose, they asked to provide a list of defects on the version – provide it, and do not invent anything.
• Write down tasks. Memory can fail you, so keep a list of short-term (for a day) and medium-term (week) tasks, and mark their completion.

Taking Everything for Granted

Perhaps one of the qualities that a tester shouldn’t have is taking everything for granted.

“Well, it was written in the software requirements specification…”, they say. All sorts of things are written in SRS . It does not mean you have to believe everything.

Use your critical thinking and reflect. Did you expect such a result? Which one will be correct? Or maybe you should go to an analyst or developer for clarification? After all, there may be errors in the specification, which is why it is also tested for bugs.

Why is it important to test the requirements specification? Because this is the first place a tester will look for a solution. If you realize that the SRS is illogical, contradictory and contains inaccuracies, feel free to go to the product analysts and figure out how it was supposed to be, and do not take everything written for granted.

Another important rule: do not trust the developers who says: “Don’t make a bug report , I’ll finish my coffee now and I’ll fix everything in 2 minutes”. As a rule, this defect will remain unfixed, and you will be guilty for not reporting it and will not be able to prove anything.

Real experience speaks louder than words. There was a project where the team went through weekly regressions on complex functionality. The regression was quite long and time consuming. One of the employees passed it incredibly quickly, which provoked a lot of questions from the manager’s side. Manager was sure that it was simply physically impossible to go through regression at such a speed. The tester assured that he had passed every single case. As a result, after his tests, bugs began to emerge at the steps where he set the “passed” statuses.

It turned out that this employee, before going through the regression, communicated with the developer, who assured that all steps (from 5 to 22) were “fixed in this version and you can safely set the status as passed”.

The happy tester took the developer’s word for it, or maybe he was just too lazy to double-check. A great candidate to fire, isn’t he?

If you do not want to be considered the most gullible and naive tester in the team, it is enough to remember a few simple rules:

• Document everything, even minor bugs (unless, of course, the opposite is stated in your Service Level Agreement).
• Make your brain think. When you find an inaccuracy between the technical documentation and the implementation of the functionality, feel free to go to the analyst or developer for clarifications.
• Do not accept undocumented tasks. Remember, an undocumented task simply does not exist in our information world. Ask to be assigned or transferred tasks in the task tracker, or, in the most extreme case, sent by e-mail.
• Always double-check the tasks, and do not blindly trust the words of the developers, because it is we, the testers, who provide information about the quality of the tested product. And we are also responsible for the work done. Remember this, and do not let yourself and the team leader down.

Errors Related to Bug Tracking

You can find millions of bugs and be a champion in your team, but if the bugs are reported poorly (inaccurately, incorrectly), then there is no point in their number. The worst mistake is 4 bug reports with the same title: “Error when opening the form”.

By the title of your bug, the developer should understand what happened and where, and when reading the description (steps to reproduce), they should know the line of code that needs to be edited. And what do we get? Not only is it completely unclear from the title of the bug what error in what form and what product is, but also 4 different reports have the same title. Can you imagine how much extra time of the developer and manager you would spend with such bug reports?

To write comprehensive bug reports and to protect the nervous system of team leads and developers, people came up with an excellent mnemonic: “What? Where? When?”

• What? What is happening, or not happening, according to your idea of ​​the normal operation of the system under test.
• Where? Where in the interface or architecture of the system the error was found.
• When? At what point in the system operation, upon the occurrence of what event or under what conditions, the problem manifests itself.

If your bug report does not answer these questions, then it is a bad bug report.

Another, rather common mistake in bug tracking is the indication in the summary of the expected and actual results for each step.

According to the rules, one actual and one expected result is recorded in the bug report after all the steps. Please remember that you are not writing a test case, but a bug report which has its own strictly designated structure:

• title;
• preconditions;
• steps of reproduction;
• actual result;
• expected result;
• attachments (screenshots, videos, logs, etc.).

The next mistake related to bug tracking is the lack of accuracy. Descriptions of defects with abstract words look not informative: several, many, different or suitable (about meanings). The developer is waiting for specific instructions to reproduce the defect and, most likely, his “several” and your “several” are different things. By making bug reports without specific data on how to reproduce the bug, you are wasting not only the development team’s time, but also your own. Because in 99% of cases, such a bug will be returned to you for revision. And as you know, time in testing is worth its weight in gold.

Another, rather serious mistake is when one bug report contains several found defects. Such reports are more like a long sheet of text, rather than the usual description of the error.

Remember, one bug = one report! So they are much easier to fix and, most importantly, they are tracked and retested by testers. It is much easier to check one described situation than 15.

Having seen such bug reports, your manager clearly does not want to lecture you, but simply decides to change you to another specialist, because the ability to make clear and understandable bug reports is one of the main tasks of a tester.

Final words

All humans make mistakes. There is no need to be afraid, especially if you are a beginner. Mistakes are good, because they can help you learn and gain useful and valuable experience. But when the same mistake is repeated all the time, it gives food for thought to your manager and creates a desire to replace you with another specialist.

Right now is the time to stop and think a little: Am I doing everything right? How often do I make mistakes? Am I learning a useful lesson from them? These questions are very important to determine if you are heading in the right direction. Remember that the probation period is not a reason to panic, it is just the starting point of your development as a tester. For that to go smoothly we share the secrets on our courses. You can more learn about testing, its techniques, types, bug reports and so on.