We recently spoke of techniques to make exploratory testing even more efficient among which we mentioned testing comprehensively yet simply, serendipity and the RIMGEA mnemonic. Today we list more techniques to supercharge your exploratory testing, starting with another mnemonic.
San Francisco Depot – SFDPOT
These letters stand for Structure, Function, Data, Platform, and Operations.
Each word represents a different aspect of a software product. By thinking of the product from each of those points of view, you can think of many interesting tests.
So, when asked to test something you haven’t seen before, recite each of the five categories and begin thinking of what you will test.
Structure, or what the product is: What files does it have? What do I know about how it was built? Is it one program or a number of programs? Does any physical material come bundled with it? Can it be tested module by module?
Function, what the product does: What are the product’s functions? What kind of error handling does it have? What kind of user interface does it have? Does it carry out any process or do anything that is not visible to the user? How does it ‘talk to’ the operating system?
Data, what it processes: What kinds of inputs does the product process? What does its output look like? What kinds of modes or states can it be in? Does it come packaged with preset data? Is any of its input sensitive to timing or sequencing?
Platform, what it depends upon: What operating systems does the product run on? Does the environment have to be configured in any special way? Does the product depend on any third-party components, and if so, which are they, and for what reason is there this dependency?
Operations, how it will be used: Who will use the product? Where and how will they use it? What will they use it for? Are there certain things that users are more likely to do? Is there user data we could get to help make the tests more realistic?
The great thing about using the San Francisco Depot trick is that you can quickly get ideas about any product however, this isn’t just about how rapidly you formulate ideas of the product, it’s also about reliability. All too often when we brainstorm we’re just shooting in the dark and what’s worse, have no way of assessing if your analysis is anywhere near complete. Using heuristics and mnemonics such as SFDPO you will have systematically gone through the major and common aspects of a product. Sure you might have forgotten something but at least the major areas are covered and anything that slipped your mind can be added on.
For more on SFDPO refer to James Bach’s excellent post – http://www.satisfice.com/articles/sfdpo.shtml or http://www.testingeducation.org/BBST/foundations/Bach_satisfice-tsm-4p-1.pdf
Use quality attributes as a basis when testing
Use quality attributes that force you to think for yourself. There are many quality attributes and obviously, not every quality attribute can be satisfied by any given system.
Start from the context and select the main characteristics of the system that you are testing. Keep these in mind as ongoing test ideas. The quality attributes work as tools that are free for your use and you will discover interesting things when you start relating to them.
The ISO Standard 9126 defines the following six quality characteristics:
Meanwhile, Microsoft specifies a larger and different set of quality attributes, including Reusability (the capability for components and subsystems to be suitable for use in other applications and in other scenarios), Usability (how well the application meets the requirements of the user and consumer by being intuitive, easy to localize and globalize, providing good access for disabled users, and resulting in a good overall user experience) and Scalability (ability of a system to either handle increases in load without impact on the performance of the system, or the ability to be readily enlarged). Read the whole list here – http://msdn.microsoft.com/en-us/library/ee658094.aspx