Problem personalities among testers
- Transfer
The quality assurance department (QA) is looking for bugs in software. Methods differ in different companies, but usually employees who are familiar with the software are involved. They use it in various ways and try to find bugs that developers have missed.
The term QA may refer to the process itself, to the organization, as well as to the individual tester within the organization. Usually, testers in a quality management organization are called “QA”. In this article, for consistency we will use the common abbreviation QA instead of the more accurate "tester of the quality assurance department".
Different companies have different QA responsibility for the overall quality of the product. Sometimes the term “quality assurance” is not entirely applicable to this department if it only searches for bugs and counts their number.
The following are problem individuals in the quality assurance department (QA):
Fire hose
A tester who issues a huge amount of bug reports so quickly that the development team will never finish.
- May mutate into alarmist
- Dangerous in conjunction with a statistics type project manager.
- Probability of correction: high
- Danger for the project: high
Problem
If a bug is found, it is important to make a clear report and immediately assign it to the appropriate developer. However, some testers are able to find bugs faster than the development team fixes them. Because of this, the list of bugs is constantly growing, and all of them can never be closed.
At first glance it may seem that there is a problem with the quality of the product, but this is not always the case. Unlike the usual tester who works with a highly buggy program, the fire hose generates an avalanche of reports with one or several characteristic properties:
- Their reports are poorly detailed, allowing for faster reporting of more errors.
- Many bugs are duplicates of others, as they are only variations of one main reason.
- There is no time to reproduce the error, since writing a report is enough to see it once.
Fire hose testers often appear under direct or indirect pressure from the company: the more mistakes you find, the better you do your job . This leads to the fact that QA testers, who diligently track the actual root cause of errors and report them clearly and briefly, are considered less productive than fire hoses that produce the maximum number of reports per unit of time.
The activity of such testers can cause panic on the project, because it seems that the product is of poor quality, and the project is now behind schedule. Their impact on morale can be immediate and dramatic: the development team is begging to interrupt the flow of bug reports.
Decision
Before fixing the fire hose, it is vital to identify it precisely and not to confuse it with an effective QA that has encountered a very buggy system. The clearest proof is given by the complaints of the developers:
- Most errors are duplicates.
- Many bugs have the same obvious root causes, so they could be reported as one bug.
- Error messages do not contain details.
To remedy the situation, the fire hose should be explained that there is no incentive to report a large number of errors, and the goal is to improve the quality of the system and help the developers. After that, the quality of the product should be improved at the same (or better) pace, but without panic.
Prosecutor
QA, which after every bug found, accuses the developers that they are not testing their program.
- May mutate into alarmist
- Dangerous in conjunction with a statistics type project manager.
- Probability of correction: high
- Project Hazard: Low
Problem
Theoretically, the developer can find and fix any bug before transferring the product to the QA department. Therefore, some testers perceive each error found as further proof that developers are not testing their work enough. This irrefutable argument allows the prosecutor to even more loudly disparaging opinion about the development team.
The prosecutor eats away the morale of the team. Instead of helping to improve the quality of the product, he tries to prove that the development team is not coping with the work. Each mistake is added to a pile of evidence that developers rely too heavily on QA instead of detecting bugs themselves.
Unfortunately, accusers are created as a result of a typical and fairly predictable process:
- Critical error detected in production.
- The tester is blamed for missing this bug.
This happens too often, and therefore QA naturally protects itself by using an irrefutable argument.
Decision
Before correcting the prosecutor, the organization must first stop blaming the QA for production bugs. Whoever does this needs to be taught more productive methods to improve the quality of the software.
When the organization has ceased to reproach QA for the bugs in the production, you can fix the tester-prosecutor by asking him to change his opinion and his attitude.
It should be brought to him that the developers are just people, and all people are mistaken. The QA department should compensate for this natural human property of developers, acting as protection against errors affecting customers. In addition, due to the tedious and tedious coding process, it is very easy for a developer not to see the forest behind the trees: he is so focused on solving a particular problem that he forgets to check seemingly obvious things.
Changing attitudes: we must remember that we all work as a team, Comrades should not blame each other for making mistakes, but should help to correct them for the benefit of the team. For QA, it is especially important to establish partnerships with the development team for the sake of the project, and the uninterrupted process of identifying bugs, reporting and the life cycle of their correction is crucial for the quality of the product.
Alarmist
QA, which states that the whole product has an unacceptable level of quality, while its opinion is based only on a superficial impression.
- May mutate into the prosecutor or fire hose
- Dangerous in combination with a pessimist type project manager
- Probability of correction: high
- Danger for the project: high
Problem
At its core, different functions of the application have different quality. Some may be relatively simple or developed by highly qualified developers, and therefore there are few or no errors. Others are relatively complex or developed by less experienced developers - and, therefore, are full of bugs. Paniker was not lucky to immediately encounter an area of low quality - and without any additional research he declared that the whole product was unfit .
There is a lot of talk about how QA tires developers and waste their time (see a misleading tester like), but there is a double situation. In fact, too often the developer deliberately gives poorly tested software to QA in order to receive remuneration for the work done or to declare that he has met the deadline. When QA starts testing such a system, it immediately encounters a lot of errors that the developer should have seen. Therefore, it is clear that he extrapolates what he saw on the whole product and declares a critically low quality.
The alarmist usually has some authority in the QA department, and his opinion is respected. The higher the level of his authority, the more damaging the influence on the project. A typical scenario is as follows:
- The product is transferred to QA.
- The alarmist begins testing the terrible quality area.
- The alarmist stops all testing and informs the authorities about a serious problem with the quality of the product.
This is a classic case of throwing a baby away with water. Sometimes QA makes the right choice, especially when the development team has a reputation for transmitting untested software to QA. But it happens that the alarm is raised because of one weak developer, whose code was first caught by the alarmist.
Decision
The tester becomes alarmist if he is repeatedly let down by the development team. If she had always supplied high-quality software, there would be no reason for distrust. But if the tester became alarmist, the development team would find it difficult to regain confidence, especially if there are indeed developers in the team who have an elephant in a room and an incompetent one .
As a rule, in large development teams, poor quality code arises due to individual developers, and not the entire team. Therefore, it is imperative that the work of less competent developers be tested as a last resort or that it does not fall into alarmist. However, this hides the true problem that there are developers in the team who negatively influence the project .
Scientist
A tester who spends most of his time documenting errors and not finding new ones.
- May mutate in the oppressed
- Dangerous in combination with a patent- type product manager.
- Probability of correction: high
- Project Hazard: Low
Problem
Finding problems in the system can be as fun as treasure hunting. And when you find this treasure, it is no less interesting to solve the puzzle. It can be argued that a tester who considers the process of finding errors in this way is perfect. But there is a problem if he seeks to carefully document his fascinating journey. Instead of focusing on the main problem, the developer is forced to read a long story with a lot of unhelpful details, trying to select relevant information.
The scientist literally perceives the requirement to “carefully document the bugs”. He describes them in the form of a textual story, rather than a brief description with a clear sequence of steps to reproduce. Reading such reports takes a lot of time, and in the end it is still unclear exactly what the problem is. Typically, such a description includes several bugs, while referring to a wide area of the system, and not to a specific problem.
The main complaint from developers when receiving error messages from scientists is that the signal-to-noise ratio is too low. They spend time sifting through the stream of consciousness, looking for specific details. This is a waste of time for both the developer and the tester.
Decision
A QA scientist is easy to fix by teaching him to write correct reports. Often the correction happens instantly, as soon as he is explained what is required of him. The most effective way to learn the right style is to rewrite one or several reports in the correct format that serves as a model for the future. As a result, an enthusiastic tester will write clear and concise error reports that cannot be made more perfect.
Misleading
QA, which often reports errors inaccurately, leading the developer to the wrong path when he tries to reproduce and fix the problem.
- May mutate into alarmist
- Dangerous in conjunction with a statistics type project manager.
- Probability of correction: high
- Danger for the project: high
Problem
The error report should include the following:
- The ability to determine what is in fact an error
- Ability to determine steps to play the bug
- Holistic description of the error, often with the root cause
- Clear steps to play the bug
At any of these stages, the report can be misleading to the developer, as a result of which he will waste time:
- If there is no error, the developer spends time searching for a problem that does not exist.
- If the error cannot be reproduced, the developer spends time reproducing it.
- If the error is not properly described, the developer spends time searching for a too specific or too broad root cause.
- If the steps to reproduce are inaccurate, the developer spends time trying to interpret them, or may declare a missing bug, although it is
Sometimes a developer gets confused because of a simple tester error. But a misleading tester often generates such reports, causing considerable dissatisfaction among developers. If the situation continues, the tester will eventually lose the confidence of the developers, and they will stop correcting even the real bugs, rejecting such error reports.
Decision
Misleading QA is often good at finding bugs, it only badly documents them. Therefore it is worth the effort to train him.
One of the most effective methods is to observe the developer, who, on the basis of his report, tries to identify the problem. It is enough just to sit next to the developer, who received one of his reports, and calmly observe (without intervention) how the developer is trying to figure it out. This will usually lead to a healthy conversation about how to better report bugs, which will benefit both the developer and QA.
Depressed
QA, which has been beaten by developers to such an extent that it hardly reports any errors for fear of being bullied on their part.
- Can mutate in blithely cheeky
- Dangerous in combination with the developers of the types of prima donna and hostage-taker
- Probability of correction: low
- Project Hazard: Low
Problem
Perhaps there is no greater indulgence than the typical attitude of developers towards QA. In addition, it is often possible to see that aggressive developers openly intimidate the tester, even if he reports a natural error in their code. To counter this, successful QA when dealing with aggressive developers should have the following characteristics:
- Already won a great confidence of developers, so his bugs are always taken seriously.
- Able to show no less aggression and perseverance in a dispute with a developer who does not recognize a bug.
Unfortunately, not many testers have such characteristics, so developers often wipe their feet about them and first of all accuse QA of finding a new bug. No matter how illogical this may seem, but such is the typical picture in the following conditions:
- The developer has a high sense of self-importance (see a developer of a type of diva )
- The developer believes that he knows much better than the tester how the system works (see developer of the hostage-taker type )
After a QA is thoroughly beaten for a long time, it usually avoids confrontation with hostile developers to reduce the level of stress. As a result, the bugs of these particular developers are rarely reported, although they may exist. As a rule, a situation is discovered only when there are problems in production and an investigation is started as to why the testing department did not reveal a bug. The depressed tester will provide any of the following explanations:
- He spoke with the developer, and he said that this was not a mistake.
- He submitted an error report, but the developer rejected it.
- He found a mistake, but "did not think that it was important enough."
A passive character often makes it difficult to recognize a depressed QA. The key will be the analysis of the developers with whom this QA works - the search for obvious signs of hostility.
Decision
Developers often very often mock testers. Thus, they should be treated like any hooligans:
- To demand to immediately stop mocking QA and refrain from aggressive behavior.
- Teach professional communication.
- Dismiss if the developer cannot correct his behavior.
In severe cases, it will be necessary for the personnel department to intervene, especially if the situation has degraded into open hostility.
Sadly, this situation is the norm rather than the exception. The only difference is in the degree of hostility.
Random clicker
QA, which searches for errors by random click method.
- May mutate in fire hose
- Dangerous in combination with a patent- type product manager.
- Probability of correction: low
- Project Hazard: Low
Problem
The search for bugs in the system is carried out by two main methods:
- According to the test plan by the methodical processing of the list of test cases.
- Random walk through the application in an attempt to emulate user actions.
Writing a test plan is a time consuming task, and there is no guarantee that by the time testing starts, the plan will still be relevant after changing requirements. This may lead the tester to completely abandon the test plans, and instead simply interacts with the application in the hope of finding bugs.
Indeed, in case of random interaction with the application, errors are detected, especially at the early stage of product development. However, as the product matures, it will be much more difficult to find errors in this way, since the remaining bugs are hidden in borderline cases. This leads to a false sense of security, as if the application did not have any errors, although it was simply not tested properly.
It is important to remember that random interaction with the application is still a valid methodology, as it can reveal situations that are not documented in the plan. But this is only an addition to the test plan, not a replacement.
Decision
A random clicker may appear in one of two cases:
- He was not taught how to properly test the application.
- He actively avoids writing a test plan.
If the problem is lack of training, then you need to ensure it. However, in this case, the tester can still fall into the second category, not wanting to make a test plan, even if he knows that he has to do it.
To write a good test plan requires a rare level of organization, diligence and concentration. As a result, certain types of people enjoy such work, but most do not. If you are very lucky, the random clicker will show the characteristics needed to write good test plans, but the probability is low.
Carelessly daring
A tester whose reports are so passively aggressive that developers interpret them as rude.
- May mutate into the prosecutor
- Dangerous in conjunction with a developer of the type of prima donna
- Probability of correction: low
- Project Hazard: Low
Problem
Proper error reporting is a time consuming and cognitively demanding process, and some QAs do not want to put in enough effort. As a rule, these are testers with some rights: they believe that they do not have to try and select wordings. They also often look dismissively at the developers and do not consider that it is worth spending time on some kind of error analysis: a general statement is enough for the developers to dash to find out what the matter is.
Typical bug reports from a careless tester contain the following phrases:
- "This does not work"
- “It's broken again”
- “The problem would be obvious if you actually used this function.”
- “I don't know why they missed it.”
- "Check carefully next time"
- "I do not know why we can not properly implement it"
Obviously, the developers are not very happy with the reports, where they use similar phrases instead of steps to reproduce the error. This rarely comes from a professional QA analyst, but it often occurs if an error is reported by another employee of the company who has been asked to search for bugs. This usually happens when there is not enough time left before the release, and there are not enough testers. As a result of such "help", chaos usually arises, since the reports are rejected by the developers, giving rise to even more disputes in the team, which further deepens the indignation.
Decision
In general, professional testers should be engaged in search of bugs. Unfortunately, in the industry there is an opinion that everyone can search for bugs, but this is not so. More precisely, anyone can detect the error, but as a rule, only professional QA specialists can identify important errors hidden in borderline situations and report them in such a way that the developer can immediately understand, reproduce and, therefore, fix this bug.
A carelessly acting tester believes that he has every right to such frivolous reports. If he enters the QA department, he should be warned to correct his counterproductive behavior. If the search for bugs is not in his direct responsibility, then he should be prohibited from reporting errors until he learns to do it professionally.
It is often much more effective to just remove a blithely daring tester than try to fix it. By his actions, he definitely makes it clear that he does not want to engage in testing, so his removal in the general interest.
See also: