What is a job tester?

Today, on Twitter, Melissa Bagai (@melbugai) asked the question: "What is a job tester?". After several attempts at 140 characters to give a concise answer, I gave up and decided to write about it in a blog.


The task of the tester is to make the product better.

I admit that this definition is greatly simplified and I will try to explain better what is meant here.
')
A tester is much more than just a search for problems. I knew testers who are extremely good at finding bugs, but, ultimately, they fail to turn these bugs into significant improvements for the product they are testing. Why is this so?

Sometimes this is because testers are bad at defending this error. They are not able to convince developers, managers and stakeholders that the error should be corrected. They try, but they are ignored, and then they become annoyed when an error is found in the product and begins to annoy everyone else.

It happens that this happens as a result of a loss of confidence in the tester. Such people consider that every bug they find, even some extremely sophisticated constraint bug, which occurs when trying to enter 10 million characters in the text field, is critical and should be fixed immediately. They rush at everyone who tries to calm them down. This happens until everyone is sick of them and all their error reports are ignored.

In other cases, the root of the problem lies in a poor understanding between testers and the development team. Perhaps, they are far behind the developers, and the latter have lost interest in the area of ​​code in which the testing is performed. Or, perhaps, testers are ahead of the development team and check things that it makes no sense to touch in the current situation.

These are all questions about the level of skills that can later be taught, trained and which can be improved. Stronger than I care about the following reason.

Sometimes it all happens because testers do not consider all these things as part of their work.

“I just found errors. What you do with them is none of my business. ”

I do not like this detached approach to software testing. It is impossible to train testers to be attentive to the product being tested, to be accountable for it. To do this, first of all, you will have to pull their heads out of the dark body cavity into which they are adapted.

"But ... but ...", - you will try to argue. At least by the fact that there is no difference, because they find the same bugs as those testers who are concerned with the project.

Well, it's probably not the case. They will not find the same errors. Their testing will focus on showing that they have adequately tested the entire code, rather than focusing on finding the errors that are most important in improving the quality of development and improving the final product.

It is sad to see testers with seemingly good skills, but who are so indifferent to the results of their work, that they don’t even try to look at efficiency from a more distant perspective. By doing this, such testers would understand that they, like the rest of the development team, are contributing to the common cause.

A tester cannot succeed if a team fails.

Testers who do not make the product better - fail. It may not be entirely their fault: maybe the organization simply ignored them a lot. Or it may be that the developers are simply narcissistic donkeys who are not able to perceive criticism. Managers may not be able to distinguish a critical error from a common typo in the end user license agreement. Anyway, it doesn't matter. If you because of all of the above could not succeed as a tester ...

you still fail. You have not completed your work.