
Well, a very simple idea that increases the effectiveness of testing at times
How do unenlightened test managers usually build the testing process?
They try to test everything. They are trying in vain to test everything. As a result, there is an error in the bug tracker that the program crashes when you click on the most rarely used button 286 times. The error about the strange gray pixel in the lower right corner of the program is also wound up. The team worked in sweat at night and on weekends.
Release
The main functionality does not work.
Why is this possible?
1. The institution of all errors in a row prevents development. Developers spend their time fixing minor bugs and introducing new ones, often more serious ones.
2. The time spent on trifles did not make it possible to check more serious user scenarios and find more critical defects.
3. Feedback on the status of the assembly was provided to developers with a delay: instead of critical defects, minors continuously rained down.
4. The design pattern “dead fish” played a role: all team members understood very well that it was impossible to test everything, and this could not but affect the quality of work. And no one set realistic goals for them ...
What do enlightened test managers do differently?
What will they change in the first place?
Priorities!
This simple idea helps to save on large projects significantly more than $ 25,000!
1. Always document the priority of functionality, and coordinate it with sales and analysts. No need to spend a lot of time on features that no one uses.
2. Always prioritize tests. The priority of the test is determined by both the importance of the feature and the probability of an error (which is determined empirically, based on the results of communication with developers, based on changes in functionality, etc.)
3. Focus on the word “document”! .. If the day after tomorrow release, and everything is in the park, then no one will remember the oral arrangements, and speedy pressing of the buttons will begin. Do you really need to find another 10 minors? Or is it more important for you to check the functionality of the main functionality?
4. Never give employees voluminous tasks that may not meet deadlines. Cut them into pieces, prioritize and determine the sequence. Otherwise, you run the risk of again encountering chaos and the “dead fish” pattern, shifting responsibility to employees.
5. Create a set of acceptance tests. What should work with the release, which MUST work, and what is only desirable? Thus, you can always estimate the labor costs for testing the release build - and not the time for aimlessly clicking on the interface.
6. Having prioritized checks, you can always count on a productive dialogue with management on expanding the staff. Instead of the words “We are short of employees,” you can say “We are short of X human hours to test tests with priority U”. Management very rarely hears such intelligible statements, so your chances will increase at times ;-)
The result of the work is not determined by the time spent on it. Moreover, labor costs and the result are not related at all, especially in testing.
Work on the result, not on increasing the volume of work. And prioritization of tests is the very first and most important step in this direction.
They try to test everything. They are trying in vain to test everything. As a result, there is an error in the bug tracker that the program crashes when you click on the most rarely used button 286 times. The error about the strange gray pixel in the lower right corner of the program is also wound up. The team worked in sweat at night and on weekends.
Release
The main functionality does not work.
Why is this possible?
1. The institution of all errors in a row prevents development. Developers spend their time fixing minor bugs and introducing new ones, often more serious ones.
2. The time spent on trifles did not make it possible to check more serious user scenarios and find more critical defects.
3. Feedback on the status of the assembly was provided to developers with a delay: instead of critical defects, minors continuously rained down.
4. The design pattern “dead fish” played a role: all team members understood very well that it was impossible to test everything, and this could not but affect the quality of work. And no one set realistic goals for them ...
What do enlightened test managers do differently?
What will they change in the first place?
Priorities!
At the very beginning of the 20th century, Charles Schwab, president of Bethlehem Steel, met with public relations and management consultant Yves Lee, as he wanted to improve the productivity of his company. “We know what we should do,” Schwab explained, “but if you can show us the best way to achieve this, then I will listen to you with pleasure and pay any amount within reason.”
Lee said he could help and that it only took 20 minutes. He handed Swab a blank sheet of paper and said, “Write down the six most important things you should do tomorrow.” Schwab did as he was told.
“Now number them according to their importance to you and to the company.” When Schwab finished, Lee continued: “Now put this paper in your pocket, and the first thing you should do tomorrow morning is to pull out this sheet of paper and look at item number 1. Do not look at the other items - just at the first one, and start work according to him and until he is fully executed. Then proceed in the same way to point 2, then to point 3, etc., until your working day comes to an end. Do not worry if you manage to cope with only one or two points. But you will work on the most important. Without them, you still would not have done the rest. And without a well-defined system, you would probably spend ten times as much time completing them - and perhaps you would execute them out of order of importance.
Do this every business day, Lee said. - After you are convinced of the value of this system, advise your employees to try to do the same. Try this method as much time as you want, and then send me a check for the amount that, in your opinion, this idea deserves. "
A few weeks later, Schwab sent Lee a check for $ 25,000 along with a letter stating that this was the most useful lesson he had ever received. And very soon after that, Bethlehem Steel became the largest independent steel producer of its time.
This simple idea helps to save on large projects significantly more than $ 25,000!
1. Always document the priority of functionality, and coordinate it with sales and analysts. No need to spend a lot of time on features that no one uses.
2. Always prioritize tests. The priority of the test is determined by both the importance of the feature and the probability of an error (which is determined empirically, based on the results of communication with developers, based on changes in functionality, etc.)
3. Focus on the word “document”! .. If the day after tomorrow release, and everything is in the park, then no one will remember the oral arrangements, and speedy pressing of the buttons will begin. Do you really need to find another 10 minors? Or is it more important for you to check the functionality of the main functionality?
4. Never give employees voluminous tasks that may not meet deadlines. Cut them into pieces, prioritize and determine the sequence. Otherwise, you run the risk of again encountering chaos and the “dead fish” pattern, shifting responsibility to employees.
5. Create a set of acceptance tests. What should work with the release, which MUST work, and what is only desirable? Thus, you can always estimate the labor costs for testing the release build - and not the time for aimlessly clicking on the interface.
6. Having prioritized checks, you can always count on a productive dialogue with management on expanding the staff. Instead of the words “We are short of employees,” you can say “We are short of X human hours to test tests with priority U”. Management very rarely hears such intelligible statements, so your chances will increase at times ;-)
The result of the work is not determined by the time spent on it. Moreover, labor costs and the result are not related at all, especially in testing.
Work on the result, not on increasing the volume of work. And prioritization of tests is the very first and most important step in this direction.