What is the difference between real testers and fake?
Today I could not sleep. Heavy thoughts are not the first day darken my mortal existence.
Their primary source (or rather, the catalyst) was the description of the scope of testing on the SQA Testing School website, located in Silicon Valley . In this description, testing is presented as an elementary area, which can be learned very quickly, knowledge is needed for this at least, and in which you can earn very well.
The first righteous thought was: testing was offended!
')
The second was replaced by a second, more balanced one: the described one is completely untrue . It’s easy to get a tester. Being a bad tester without being fired is easy. Not to bring the slightest benefit to the project, and at the same time making good money is easy.
But after all, there are, there are true geniuses of their work who are benefiting, and, despite the “swampy” labor market in the field of testing, they are highly qualified specialists!
Who are they?
How to distinguish real Jedi from fake testers?
The result of thinking was a LIST OF THE TEN DIFFERENCES OF THE PRESENT TESTER FROM THE FALSE.
Real testers are not enemies to programmers. These testers do not aim to "break the product," then slyly rub their hands. Real testers are not happy at all about the presence of problems, bugs, defects and errors!
To bring the project benefits, testing should act as a service. Bugs are not a product that can be released. Bugs are useless. Benefit brings only activity aimed at achieving common goals.
And for this you need:
* take into account the objectives of the project
* adapt to the external conditions (priorities, deadlines, goals, top-level tasks)
* be able to find out: WHAT should NOW do to help the project achieve its goal?
If testing is ineffective, errors are late, and low-quality start-ups, there will be more and more of them: poor localization of defects takes time away from developers, and their establishment of a non-priority order leads to difficulties in correcting.
Therefore, instead of the task “how would I find a bunch of bugs and DDOSit developers,” real testers think: “What does the project need now, in what format and with what priorities?”.
No copying and bydlotesting!
Real testers can design tests. To do this, at least they have jagged the test design bible from Lee Copeland , and as a maximum, they have mastered quality risk control .
Depending on the conditions, testing can be carried out either on test or on test cases, but tests are not done from the “push buttons” but only according to the analysis: what should be tested, in what priority and how can it be done most effectively ?
To do this, any testing begins with a study of the product, factors affecting its work, and their subsequent division into equivalence classes .
First - think, then - test!
To be a real tester, it is not necessary to be an advanced developer. But to understand how to effectively test your application, you just have to know its architecture!
Black-box testing does not allow to thoroughly investigate the product, and testing only “from the user” leads to the fact that many factors affecting the operation of the software are unaccounted for.
Black-box testing is testing in a black box with no windows and eyes closed. You go to the touch, stumble on some rough edges in the product, and make mistakes on it “somewhere in the left corner is something wrong”.
Open your eyes and turn on the light! See what you are testing!
After learning how the software works, you can:
* more efficient to design tests
* provide higher coverage, knowing the factors affecting the operation of the software
* more accurately and intelligently localize errors - and therefore save the time of developers and the project as a whole!
Who, if not testers, have to carry bad news? The worst thing you can do when you discover a defect is to tell the developer, “Well, you and the junkie!”.
We need not just to find and register the defect. We need to do everything to make it easy and pleasant to fix.
Every bug fixed in the software is great, and any developer understands this.
Only if he was not previously told that he was “mowing”, “bajit” and “buggy”!
How to communicate with developers for defects - recording Alexey Barantsev's speech at a meeting of the Moscow Testers Club .
Once I conducted an audit of the testing process in a Moscow company engaged in the development of accounting software. In the opinion of the company's management, testers missed too many defects. The reason turned out to be simple: analysts of the company (2 pcs.) Wrote test cases for the testers of the company (~ 15 pcs.). Testers passed them and recorded all deviations in software behavior from that documented in test cases.
At the same time, they did not even understand what a balance is and on what basis reports are formed!
Naturally, this could not bring high quality testing. Analysts, not knowing the approaches to the design of tests (as this is not their job), could not optimize the test coverage. But unfortunate testers were only looking for differences between continuously aging tests and program behavior. If something went "wrong" and this "wrong" was not documented in the tests, then they didn’t even realize that there was a defect in front of them.
To prevent this from happening, real testers need to know how the product works. They need to know the user, his mental model: how is the product used? In what conditions? How?
If you hear the words “I am a real expert!”, It means that you are not a real tester. Because it is impossible to be an expert in a barely developing industry. Because the methodological base is negligible, and even it changes continuously.
With inexorable speed there are new techniques and approaches. Advanced testers of all directions create it, create it right now!
And how can you be an expert in a field that has not yet been formed? Which is too flexible for something to be called “right”?
"I am an expert!" = "I will no longer develop." And this is NOT about real testers.
How often are tests with negative ROI automated just because automation is “cool” and manual testing is “boring”? How often are tests documented, turning into a heap of useless and awkward pieces of paper, simply because it is “solid”?
In testing (as, probably, in other areas?), Many decisions are made on the basis of “cool”, “interesting” and “but let's try?”.
But the concept of “coolness” is not absolute! Each project, each team has its own working conditions, and effective testing is always determined by the context !
When real testers decide to implement something, they say: "It will be useful for our project, because ...". And these words distinguish a real tester from a fake one more than anything else.
To match the ten declared points, briefly highlight three more:
* Real testers LOVE their work, they always find creativity in it, and they cannot have a routine! Because each new task is performed better, better, more efficient - and therefore more interesting and more interesting!
* Real testers love their products. It is not possible to test software and be destructive. The task of this tester is to reduce the number of defects, take preventive measures, conduct testing at early stages, so that serious defects do not appear at all. And these goals are incompatible with destructiveness, to achieve them the product must not be broken, but love.
* Real testers are constantly evolving. And develop a young fragile industry!
Real Testers will make their own conclusions :-)
And I just want to say to these rare people who can be entered into the Red Book: “THANK YOU!”.
Thank you for not standing still.
Thank you for benefiting the projects.
Thank you for developing the industry!
Their primary source (or rather, the catalyst) was the description of the scope of testing on the SQA Testing School website, located in Silicon Valley . In this description, testing is presented as an elementary area, which can be learned very quickly, knowledge is needed for this at least, and in which you can earn very well.
The first righteous thought was: testing was offended!
')
The second was replaced by a second, more balanced one: the described one is completely untrue . It’s easy to get a tester. Being a bad tester without being fired is easy. Not to bring the slightest benefit to the project, and at the same time making good money is easy.
But after all, there are, there are true geniuses of their work who are benefiting, and, despite the “swampy” labor market in the field of testing, they are highly qualified specialists!
Who are they?
How to distinguish real Jedi from fake testers?
The result of thinking was a LIST OF THE TEN DIFFERENCES OF THE PRESENT TESTER FROM THE FALSE.
1. Real testers with the project at the same time.
Real testers are not enemies to programmers. These testers do not aim to "break the product," then slyly rub their hands. Real testers are not happy at all about the presence of problems, bugs, defects and errors!
To bring the project benefits, testing should act as a service. Bugs are not a product that can be released. Bugs are useless. Benefit brings only activity aimed at achieving common goals.
And for this you need:
* take into account the objectives of the project
* adapt to the external conditions (priorities, deadlines, goals, top-level tasks)
* be able to find out: WHAT should NOW do to help the project achieve its goal?
If testing is ineffective, errors are late, and low-quality start-ups, there will be more and more of them: poor localization of defects takes time away from developers, and their establishment of a non-priority order leads to difficulties in correcting.
Therefore, instead of the task “how would I find a bunch of bugs and DDOSit developers,” real testers think: “What does the project need now, in what format and with what priorities?”.
2. Real testers can design tests.
No copying and bydlotesting!
Real testers can design tests. To do this, at least they have jagged the test design bible from Lee Copeland , and as a maximum, they have mastered quality risk control .
Depending on the conditions, testing can be carried out either on test or on test cases, but tests are not done from the “push buttons” but only according to the analysis: what should be tested, in what priority and how can it be done most effectively ?
To do this, any testing begins with a study of the product, factors affecting its work, and their subsequent division into equivalence classes .
First - think, then - test!
3. True testers understand the architecture of the software being tested.
To be a real tester, it is not necessary to be an advanced developer. But to understand how to effectively test your application, you just have to know its architecture!
Black-box testing does not allow to thoroughly investigate the product, and testing only “from the user” leads to the fact that many factors affecting the operation of the software are unaccounted for.
Black-box testing is testing in a black box with no windows and eyes closed. You go to the touch, stumble on some rough edges in the product, and make mistakes on it “somewhere in the left corner is something wrong”.
Open your eyes and turn on the light! See what you are testing!
After learning how the software works, you can:
* more efficient to design tests
* provide higher coverage, knowing the factors affecting the operation of the software
* more accurately and intelligently localize errors - and therefore save the time of developers and the project as a whole!
4. Real testers are masters of communications.
Who, if not testers, have to carry bad news? The worst thing you can do when you discover a defect is to tell the developer, “Well, you and the junkie!”.
We need not just to find and register the defect. We need to do everything to make it easy and pleasant to fix.
Every bug fixed in the software is great, and any developer understands this.
Only if he was not previously told that he was “mowing”, “bajit” and “buggy”!
How to communicate with developers for defects - recording Alexey Barantsev's speech at a meeting of the Moscow Testers Club .
5. These testers are well versed in the application area.
Once I conducted an audit of the testing process in a Moscow company engaged in the development of accounting software. In the opinion of the company's management, testers missed too many defects. The reason turned out to be simple: analysts of the company (2 pcs.) Wrote test cases for the testers of the company (~ 15 pcs.). Testers passed them and recorded all deviations in software behavior from that documented in test cases.
At the same time, they did not even understand what a balance is and on what basis reports are formed!
Naturally, this could not bring high quality testing. Analysts, not knowing the approaches to the design of tests (as this is not their job), could not optimize the test coverage. But unfortunate testers were only looking for differences between continuously aging tests and program behavior. If something went "wrong" and this "wrong" was not documented in the tests, then they didn’t even realize that there was a defect in front of them.
To prevent this from happening, real testers need to know how the product works. They need to know the user, his mental model: how is the product used? In what conditions? How?
6. Real testers are not experts.
If you hear the words “I am a real expert!”, It means that you are not a real tester. Because it is impossible to be an expert in a barely developing industry. Because the methodological base is negligible, and even it changes continuously.
With inexorable speed there are new techniques and approaches. Advanced testers of all directions create it, create it right now!
And how can you be an expert in a field that has not yet been formed? Which is too flexible for something to be called “right”?
"I am an expert!" = "I will no longer develop." And this is NOT about real testers.
7. Real testers choose targets, not means.
How often are tests with negative ROI automated just because automation is “cool” and manual testing is “boring”? How often are tests documented, turning into a heap of useless and awkward pieces of paper, simply because it is “solid”?
In testing (as, probably, in other areas?), Many decisions are made on the basis of “cool”, “interesting” and “but let's try?”.
But the concept of “coolness” is not absolute! Each project, each team has its own working conditions, and effective testing is always determined by the context !
When real testers decide to implement something, they say: "It will be useful for our project, because ...". And these words distinguish a real tester from a fake one more than anything else.
8,9,10. Real testers love their work, love their products and continuously evolve.
To match the ten declared points, briefly highlight three more:
* Real testers LOVE their work, they always find creativity in it, and they cannot have a routine! Because each new task is performed better, better, more efficient - and therefore more interesting and more interesting!
* Real testers love their products. It is not possible to test software and be destructive. The task of this tester is to reduce the number of defects, take preventive measures, conduct testing at early stages, so that serious defects do not appear at all. And these goals are incompatible with destructiveness, to achieve them the product must not be broken, but love.
* Real testers are constantly evolving. And develop a young fragile industry!
findings
Real Testers will make their own conclusions :-)
And I just want to say to these rare people who can be entered into the Red Book: “THANK YOU!”.
Thank you for not standing still.
Thank you for benefiting the projects.
Thank you for developing the industry!
Source: https://habr.com/ru/post/110476/
All Articles