Characteristics of a Bad QA Engineer

In the development lifecycle, testing is an important stage before the release of the project. Each application goes through many iterations of testing before it reaches the end user.

Imagine the quality of an app if developers decided to skip the testing stage. It’s not hard to imagine a user’s dissatisfaction – you know that feeling too, right? There is no longer any doubt that application testing is necessary, and it requires “good specialists”. But how do you identify a bad tester?

Characteristics of A Bad Tester

Weak Communication Skills

Since testing begins at the earliest stages of the development lifecycle (even at the stage of requirements analysis), the role of a tester is of great importance, and developers require feedback immediately. For this reason, testers should have good communication skills.

These skills are needed not only at the initial stage but at all of them. The tester must be able to express their thoughts clearly. And here it doesn’t matter whether the communication happens face-to-face or via the internet; whether they communicate with the development team or with another team of testers.

The signs of poor communication skills include:

• lack of enthusiasm for communication;
• fear of expressing their opinion;
• a feeling of vulnerability;
• lack of preparation.

Lack of Technical Knowledge

In addition to good communication skills, the tester must have deep technical knowledge to make a good impression on the parties interested in the quality of the project. If the technical knowledge of the tester is not deep enough, then this, most likely, will raise serious doubts about the quality of the project in general.

Moreover, during a joint discussion, developers often use technical terms, and if a tester does not understand this topic, then their actions can have a negative impact on the development process.

Here is a list of factors that influence the level of technical knowledge:

• lack of self-discipline necessary for training;
• lack of practice;
• lack of energy or enthusiasm.

Writing a Bug Report Without Analyzing the Bug

During the work, the tester must write a bug report immediately after discovering that the actual result does not meet the requirements. A tester must do this as soon as possible but they must also investigate the bug, trying to figure out its cause.

In most cases, the best approach is to investigate the cause of the bug and try to reproduce it twice more. Before making a bug report, a tester must study the problem so that after that it would be possible to describe it in detail and correctly.

The factors to consider before writing any bug reports:

• incorrect testing data;
• unstable testing environment;
• incorrect testing sequence;
• incorrectly formulated requirements.

Refusal to Follow Quality Control Procedures

Each organization has a variety of quality control procedures to ensure the successful implementation of the project under development. Individual and team performance usually depends on following these processes. Testers who refuse to follow them can jeopardize the project, which in turn will lead to client dissatisfaction.

Examples of such deviations from quality control procedures:

• not using the correct templates for test artifacts;
• not following the review processes;
• using older versions of documents due to a lack of version control during testing.

Assumption-based Testing

There are many software-related things that a tester makes assumptions about, and then tests only with those assumptions in mind. They can consist of technical and non-technical aspects of the software workflow, and there is a chance that these assumptions will turn out to be wrong. In this case, the tester will miss a critical bug.

So never test software based on assumptions! Get clear and understandable requirements from developers or analysts. If any specific requirements are not clear to you, ask questions without any doubt. A bug missed due to incorrect assumptions can cost a lot.

Here are examples of assumptions that might arise during testing:

• the developer understands what they want to achieve from the software, so their code is probably correct;
• implementation of requirements that are not referenced by any document;
• some functionality is not tested and this was not discussed nor approved.

Not Following the Principle “To Test Is to Break”

Testing is basically the process of finding bugs, and a real bug is a very well hidden bug. Therefore, every tester must use both positive and negative approaches to testing to detect such bugs.

The tester must also apply this principle when testing the application. Following the test scenarios, they must have time to check situations that are not described by the requirements but may arise during the workflow. If a tester conducts testing only according to the requirements, the “ideal” scenario for working with the application, they may miss a critical bug that lurks in a place that the developers did not even know about.

Here are the factors that prevent you from following the “To Test Is to Break” principle:

• only positive approaches are used to assess the work of the system with the complete exclusion of negative ones;
• research and Ad Hoc testing are not used;
• lack of attention in the testing process;
• testing only ideal scenarios for using the software.

Stagnant Development of Tester Skills

The software development industry is changing every day: new technologies and tools are constantly emerging that can be used in the testing process. It is the responsibility of the tester to regularly update their knowledge of these tools. First of all, it will be beneficial for them, if they can use new developments and approaches in the projects.

Bad testers simply fulfill their “norm”, not wasting a minute of time deepening knowledge, improving language or other technical skills. They are not trying to learn new things or find fresh information about the software development industry.

The following factors can cause stagnation in the development of tester skills:

• unwillingness to improve their qualifications;
• monotony of the working process;
• fear of leaving the “comfort zone”.
• lack of a clear idea of their own career goals.

Lack of Ability to Look at the Application From the Perspective of the End User

It is the responsibility of a tester to ensure that the application is working as required. However, in addition to this, they must be able to look at the application from the point of view of the end user. A bad tester limits themselves to specification and will probably miss the points that are not considered there.

A bad tester cannot figure out exactly what the consumer needs are. They are afraid to ask an extra question about what they doubt. This could be due to a lack of confidence or technical knowledge.

Each tester should clearly see the application from the end user point of view and understand how convenient it is to work with.

Negligence

Sometimes a tester can be just lazy during testing but you need to remember that if this becomes a habit, then they will never become a real professional. A good tester must make sure that they provide the developer with detailed reports, bug reports, and test cases.

Examples of negligence during testing:

• the tester forgot to add a screenshot;
• a bug report has incomplete or incorrect information;
• instead of an exact bug report, the tester wrote long a text without being precise;
• an incorrect test case was written or steps in the current test case were skipped;
• the tester lacks the ability to perceive information via auditory channels, which is why they may miss important points.

Testing Can Be Done by Anyone

If a tester thinks that testing is an easy job and that it can be done by anyone with the minimum required knowledge, then they clearly do not understand the basic concepts of testing. A tester who thinks so is a direct threat to the project.

Testing is, to some extent, a skill that you develop through learning and experience. Each tester must constantly deepen professional knowledge, have good technical and communication skills, the ability to go beyond the usual perception of the world, etc.

The combination of all these qualities makes you a good tester, which allows you to be a valuable employee in any project and organization.

A bad tester usually makes the following assumptions about the testing process:

• testing does not require any special skills;
• testing is an easy job that can be done by anyone;
• it is impossible to achieve career growth;
• testing is monotonous work, and you should not expect anything new in the daily workflow.

How NOT to Be a Bad Tester

There are many signs which can help distinguish a bad tester from a good one.

If you suddenly noticed something like this in yourself, then you, without doubt, can get rid of it. However, you will need a sense of purpose, a willingness to learn, and the ability to concentrate while testing. You can also take additional training and pass certification exams. This, in turn, will help you acquire more knowledge and will be useful when working on a project.

You must go beyond your capabilities and learn to apply new technologies and tools, accumulate new technical knowledge. Many testing tools are available on the software market that you can learn on your own or through short training sessions. Then apply your knowledge to current projects.

To be a good tester, do not hesitate to ask questions, suggest innovative ideas, and create small utilities that use macros or automate the testing process, which will save both your time and the time of your colleagues.

Summing up

We talked about the signs of a bad tester, which are relevant for other jobs too. If you want to become a good tester, then you need to get rid of them as soon as possible.