- 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.)
- You should always document the priority of functionalities, coordinate it with PMs and analysts. You don’t need to spend much time on features that nobody uses.
- 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).
- 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).
- 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.
- What should necessarily work;
- What should work by release;
- What should work only optatively.
As a result, you can appreciate the efforts required for a release build testing – and not the time spent by aimless interface clicking.
If you’d like we apply our experience and knowledge to make your software better, you might be interested in our software testing service.