July 26, 2010 at 11:56What is a tester's job?
- Transfer
Today on Twitter, Melissa Bagai (@melbugai) asked a question: “What is the work of a tester?”. After several attempts at 140 characters to give a concise answer, I gave up and decided to write about it on the blog.
The task of the tester is to make the product better.
I admit that this definition is greatly simplified and will try to better explain what is meant here.
A tester is much more than just troubleshooting. 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 test. Why is this so?
Sometimes this is because testers poorly defend this error. They are not able to convince developers, executives, and stakeholders that a bug needs to be fixed. They try, but ignore them, 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 loss of trust in the tester. They believe that every bug they find, even some extremely intricate restrictions-related bug that occurs when trying to enter 10 million characters in a 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 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 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 regarding the level of skills that can then be trained, trained and which can be improved. The next reason excites me more.
Sometimes things go wrong due to the fact that testers do not consider all these things to be part of their work.
“I just found mistakes. What you do with them is none of my business. ”
I do not like such a detached approach to software testing. It is impossible to train testers of attentiveness to the tested product, responsibility for it. To do this, first of all, you will have to pull their heads out of the dark cavity of the body into which they are adapted.
“But ... but ...”, you try to object. At least by the fact that there is no difference, because they find the same bugs as those testers who care about the project.
Well, probably this is still 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 bugs 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 do not even try to look at efficiency from a more distant perspective. Having done this, such testers would understand that they, like the rest of the development participants, contribute to the common cause.
The tester cannot succeed if the team fails.
Testers who do not make the product better are failures. This may not be entirely their fault: it may be that the organization simply ignored them a lot. Or it may be that the developers are simply narcissistic donkeys who are not able to accept criticism. It may be that managers are unable to distinguish a critical error from a common typo in the end user license agreement. Be that as it may, all this is not important. If, due to all of the above, you fail to succeed as a tester ...
you still fail. You have not completed your work.
The task of the tester is to make the product better.
I admit that this definition is greatly simplified and will try to better explain what is meant here.
A tester is much more than just troubleshooting. 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 test. Why is this so?
Sometimes this is because testers poorly defend this error. They are not able to convince developers, executives, and stakeholders that a bug needs to be fixed. They try, but ignore them, 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 loss of trust in the tester. They believe that every bug they find, even some extremely intricate restrictions-related bug that occurs when trying to enter 10 million characters in a 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 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 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 regarding the level of skills that can then be trained, trained and which can be improved. The next reason excites me more.
Sometimes things go wrong due to the fact that testers do not consider all these things to be part of their work.
“I just found mistakes. What you do with them is none of my business. ”
I do not like such a detached approach to software testing. It is impossible to train testers of attentiveness to the tested product, responsibility for it. To do this, first of all, you will have to pull their heads out of the dark cavity of the body into which they are adapted.
“But ... but ...”, you try to object. At least by the fact that there is no difference, because they find the same bugs as those testers who care about the project.
Well, probably this is still 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 bugs 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 do not even try to look at efficiency from a more distant perspective. Having done this, such testers would understand that they, like the rest of the development participants, contribute to the common cause.
The tester cannot succeed if the team fails.
Testers who do not make the product better are failures. This may not be entirely their fault: it may be that the organization simply ignored them a lot. Or it may be that the developers are simply narcissistic donkeys who are not able to accept criticism. It may be that managers are unable to distinguish a critical error from a common typo in the end user license agreement. Be that as it may, all this is not important. If, due to all of the above, you fail to succeed as a tester ...
you still fail. You have not completed your work.