Two-minute guide to determining software testing coverage
By: Michael Kelly
Deciding what to test really involves two different questions. The first is a question of scope: "Out of everything that I could possibly test, which features are the right ones to test?" There will always be more to test than you will have time to test. The second is a question of technique and coverage: "For each feature I am testing, how do I want to test that feature?" Different quality criteria will lead to covering different product elements and different testing techniques.
In this two-minute crash course, I'll provide some details on how I answer those questions and how I structure my test execution to ensure I'm testing for the right risks at the right time.
2:00: Figure out the scope of your testing
For the question about scope -- what features should we test -- I like using Scott Barber's FIBLOTS mnemonic (which he presents in his Performance Testing Software Systems class). Each letter of the mnemonic helps us think about a different aspect of risk. Here's a summary of how I apply FIBLOTS when thinking about scope:
* Frequent: What features are most frequently used (e.g., features the user interacts with, background processes, etc.)?
* Intensive: What features are the most intensive (searches, features operating with large sets of data, features with intensive GUI interactions)?
* Business-critical: What features support processes that need to work (month-end processing, creation of new accounts)?
* Legal: What features support processes that are required to work by contract?
* Obvious: What features support processes that will earn us bad press if they don't work?
* Technically risky: What features are supported by or interact with technically risky aspects of the system (new or old technologies, places where we've seen failures before, etc.)?
* Stakeholder-mandated: What have we been asked/told to make sure we test?
1:33: Understand the ...
... to read more articles, visit http://sqa.fyicenter.com/art/