1. Good planning - Know what you are trying to test for
2. The use of the right test in the right situation - White box, black box, regression
3. Tests that are systematic and through - unit, GUI, field level, functional, integration, end to end and acceptance
4. Clear criterion for knowling when to stop - Decide before hand howmuch testing will be enough
All tests are important, but if you need to restrict testing...
1. Testing a system capabilities (Functionality) is more important than testing its components - Identify things that will stop users doing their jobs
2. Testing old capabilities is more important than testing new capabilities - users expect existing features to keep working!
3. Testing typical situations is more important than testing boundary cases - Normal usage patterns are more important than a typical ones
Critical subsystems should be tested as early as possible!
Critical subsystems are those that: 1. Have high risk 2. address several software requirements (i.e., they implement several use cases) 3. Have a high level of control 4. Are complex or error prone -> high cyclomaric complexity 5. have a specific performace requirements
Note: Regression testing is a must for critical substems!