I am a test manager, and in the 3 years in the job I learned that when deciding whether to write a particular test or not, it is beneficial to look at the following:
- What is the occurrence of the scenario? The more frequent the scenario that more important is to have a test that covers it.
- What is the impact to the user if the scenario breaks? Things like crashes or data loss have high impact and should be tested. Things like misaligned buttons or sub-optimal translations, even if occur in frequent scenarios, have a low impact and usually should not be tested.
- What is the probability that a bug will be found in this scenario? If the functionality was tested multiple times already and few changes were made since you probably don't need to write a test. If bugs are common in this functionality or if the underlying software infrastructure is problematic, then you probably should write a test.
So my current methodology is to write tests with the highest scenario frequency, impact and probability of finding a bug, and then moving downward in this 3D matrix until no time is left for testing.
Before I add this to the curriculum for new employees, would you care to comment on it? Maybe I missed something important, or maybe I am looking at this incorrectly.
Note: Here I am talking about manual tests that are only run in the final verification cycles.