Let’s imagine that a person has successfully passed a job interview, completed a test assignment and an employer is ready to offer him/her the job of a software tester.

A trial period is near the end and you think that you’ve already got the job of a QA engineer but a boss comes and says that you’re likely not a good fit for them and a company wants to hire another worker instead of you.

The first question that comes to your mind is: so fast? You have studied the main basics of the job, read several books, followed the tips of new coworkers. And here comes such news…

This article is dedicated to analyzing the reasons a person may easily lose his/her job even if he/she is executing his/her responsibilities properly, and suggesting the tips to make this never happen to you.

There are various reasons a company may not offer you a full-time job, therefore, the criteria of such selection can be divided into certain parts.

Human inattentiveness

When you join a new quality assurance team, you’ll strive to show everyone your best sides.

Right these wishes make some workers work till the night, ask for additional work, and sometimes even not do their work. This happens because they are not very attentive.

A tester shouldn’t do such a mistake since every QA engineer should be completely attentive and focused on the work he/she is doing. Otherwise, how can his/her manager be sure that this worker is useful during his/her work time and a company can rely on him/her in the most critical moments?

Example:

A tester was given the task to build the table with the values, adding a short description to it. Instead of executing the set task (not exceeding the established requirements), he/she created the table of extended format with numerous extra fields. As a result, the work is not executed properly, and much precious time was spent on doing this.

Tips on improving the attentiveness:

1. Execute one task, don’t try to simultaneously do two and more tasks at once. Multitasking is a great skill but complex tasking is a headache for every company;
2. Absolute concentration. Thoroughly study the requirements of the task before its execution since 85 % of tasks include the method of their solving;
3. Do only what is required, try to avoid unnecessary steps. It’s very easy and clear: a manager gave you a task to decompose the software functionality, then simply decompose it;
4. Write down the completed tasks. Human memory may not always be reliable, so you should have the list of minimum urgent and medium-urgent tasks, executing them step-by-step.

Absolute trust

It seems to be one of the most popular qualities of new testers.

[highlight dark=”no”]Never stop being critical, think, and analyze.[/highlight]

What result will be correct in the end? Do you want to reach it? Maybe, you should ask an analyst or a developer for advice?

It’s because specifications always include numerous mistakes that will move to the functionality in development.

Why should you test specifications if this document is the basis of every project? It’s because this is the first thing that a tester will look at in case of any technical inconsistency.

If a person sees that a technical assignment is illogical, its sections contradict themselves and its content is not accurate, he/she should immediately go to the analytics department and find out how everything should actually look.

[highlight dark=”no”]A golden rule is to never trust the developers.[/highlight] If they swear that they will fix a bug in 5 minutes and ask you to not add it to a bug-tracking system, then in 70% of cases the error will stay unfixed, and then directors may blame you in missing the defect.

To not become a naïve tester inside a team, you need to follow just several simple rules:

– Recording even the slightest and not critical bugs;
– Don’t be afraid to ask the analytics department if you have found a big contradiction between the created functionality and a technical assignment;
– In the informational world of the 21st century, there shouldn’t be any undocumented tasks;
– Frequently recheck the tasks that were previously completed by developers since the tester’s validation is a final step of quality assurance.

Issues related to the correctness of using a bug-tracking system

A tester can create up to a hundred thousand bugs, be a leader in this regard but if a defect is improperly documented, then there is no use of so many bugs.

The most popular problem of new testers lies in using the same title for documenting at least 4 similar tasks. And it’s really bad!

A developer should understand what happened, by studying the content of a bug-tracking system, and know where to search for the error, by analyzing the reproduction steps.

It’s very hard to imagine how much time a developer can spend if a bug report contains illogical records and incorrect description of the simplest and not complex bugs.

Right for preventing such situations, QA engineers use a great method of “What, where, when”.

Its meaning is the following:

What?

What exactly happens or doesn’t happen, according to a tester, when he/she is testing software?

Where?

In what place of system architecture was the bug found?

When?

In what moment of software functioning can we find the issue?

If a bug report of a new tester doesn’t contain such conditions, it’s a very bad bug report.

One more mistake that is in some way related to a bug-tracking system is the complete absence of specificity. The complete absence of informativeness is in the records that are full of abstract words and expressions – some, many, sometimes, and so on.

A developer expects absolutely exact conditions and tasks from a tester and in his/her view, some and many are absolutely different expressions with a completely different meaning.

By documenting the bugs without exact informative data, that will be used in the future for bug reproduction, a tester just waste not only his/her time but also, the time of developers.

And this ticket is likely to return to a tester for refinement or complete substitution. And we know that time is very precious in testing!

Conclusion

Each of us can sooner or later start making even the simplest and obvious mistakes. You shouldn’t be afraid of this.

Human mistakes can be even a good thing, in some way since they help to study and gain precious professional experience.

But if a person constantly makes the same mistake – this should be analyzed and this will give your boss a sign that you can (or even must) be replaced by another specialist.

A trial period means for a tester just a first step of development in this job. And to make everything run smoothly, you just need to follow the requirements given by a boss, don’t worry and always ask experienced coworkers for advice and don’t be afraid to make even the slightest mistakes.

Remember: your mistakes are your experience!