The result of work is not determined by the time expended on it. Moreover, labor costs and the result aren’t related anyway, especially in testing.
Work on result rather than on increasing of amount of work. And prioritization of tests is the first and the most important step in this direction.
Tests should always have a priority. The priority of test is defined by importance of the feature and probability of error emergence (which is determined empirically, on the basis of communication with developers, functional changes etc.)
2. You should always document the priority of functionalities, coordinate it with PMs and analysts.
3. If there are tasks with different priority levels, you should always check the task with a higher priority (if it is possible, and if tasks are independent).
4. The tasks should be better done in turn. You need to do one task, to finish it and to move on to the next one (if it is possible). Because:
- there is less overhead by switching between tasks
- a result appears earlier on one problem at least (or else we have 10 tasks, performed 85%, with no benefits).
However, the situation changes if the tasks are interdependent .
5. We put emphasis on the word “document”! .. If the release is the day after tomorrow, and everyone is in hurry, then no one will remember verbal agreements, and a high-speed buttons clicking will begin. It’s more important for you to check the efficiency of the basic functionality.
6. Make it a rule – Big tasks should be divided into smaller ones. Determine their priority and sequence. Otherwise you’ll risk to face a chaos.
Create a set of tests:
- What should necessarily work ;
- What should work by release;
- What should work only operatively.
7. As a result, you can appreciate the efforts required for a release build testing – and not the time spent by aimless interface clicking.
8. If you have prioritized your tasks, you can always say that you don’t have enough X man-hours for verifying the tests with the Y priority.
No comments:
Post a Comment