How do unenlightened test managers usually build the testing process?
They try to test everything. They try 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 entered. The team worked hard at night and on weekends.
The main functionality does not work.
Why is this possible?
1. The establishment of all mistakes in a row prevents development. Developers spend their time correcting minor errors and introduce new ones, often more serious ones.
2. The time spent on trivia 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 were continuously falling.
4. The dead fish design pattern played its part: all team members were well aware that it was impossible to test everything, and this could not but affect the quality of work. Nobody set realistic goals for them ...
What do enlightened test managers do differently?
What will they change first?Priorities!
At the very beginning of the 20th century, Charles Schwab, president of Bethlehem Steel, met with public relations and management consultant Yves Li, because he wanted to improve the productivity of his company. “We know what we should have done,” explained Schwab, “but if you can show us the best way to achieve this, then I will be happy to listen to you and pay any amount within reasonable limits.”
Lee said he could help and that it only takes 20 minutes. He handed Shvabu a blank sheet of paper and said: “Write the six most important things you have to do tomorrow.” Schwab did as he was told.
"Now number them according to their importance to you and the company." When Schwab finished, Lee continued: “Now put this paper in your pocket, and the first thing you have to do tomorrow morning is to pull out this sheet of paper and look at item number 1. Do not look at other items - only at first, and start work according to him and until it is fully implemented. Then proceed in the same way to clause 2, then clause 3, and so on, 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-designed system, you probably would have spent ten times more time completing them — and, perhaps, would not have performed them in order of importance.
Do this every work 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 for as long as you want, and then send me a check for the amount you think 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 learned. And very soon after this, Bethlehem Steel became the largest independent steelmaker of its time.
This simple idea helps to save on large projects much more than $ 25.000!
1. Always document the priority of the functional, 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 is a release, and everything is in a parking lot, nobody will remember the verbal agreements, and a high-speed 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 the deadlines. Cut them into pieces, prioritize and determine the sequence. Otherwise, you risk again to face the chaos and the pattern of “dead fish”, shifting the responsibility on employees.
5. Create a set of acceptance tests. What should work with the release, what MUST work, and what - only desirable? Thus, you can always estimate the labor costs for testing the release build - and not the time to aimlessly click through the interface.
6. With prioritized checks, you can always count on a productive dialogue with management about staff expansion. Instead of the words “We do not have enough employees”, you can say “We do not have enough X man-hours to check the tests with priority Y”. The management rarely hears such intelligible statements, so your chances will increase significantly ;-)
The result of the work is not determined by the time spent on it. Moreover, the effort and the result are not related at all, especially in testing.
Work on the result, not on increasing the amount of work. And prioritization of tests is the first and most important step in this direction.