- Agile Testing Quadrants
- Challenging the Quadrants
- Using Other Influences for Planning
- Planning for Test Automation
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Using Other Influences for Planning
There are many useful models and ideas for helping us in our test planning, and we shouldn’t throw them away. As Tim Ottinger and Jeff Langr have said (Ottinger and Langr, 2009b), a mnemonic for thinking about what are called nonfunctional requirements is still useful. The FURPS model (see Figure 8-5) was developed at Hewlett-Packard and was first publicly elaborated by Grady and Caswell (Wikipedia, 2014f); it is now widely used in the software industry. The + was later added to the model after various campaigns at HP to extend the acronym to emphasize various attributes.
)
Figure 8-5 FURPS+ flash card (Ottinger and Langr, 2011)
James Whittaker developed a methodology he calls the Attribute Component Capability (ACC) matrix (Whittaker, 2011) to help define what to test based on risk. ACC consists of three different parts that define the system under test: Attributes, Components, and Capabilities. He defines these as:
- Attributes (adjectives of the system) are qualities and characteristics that promote the product and distinguish it from the competition; examples are “Fast,” “Secure,” “Stable,” and “Elegant.”
- Components (nouns of the system) are building blocks that together constitute the system in question. Some examples of Components are “Firmware,” “Printing,” and “File System” for an operating system project, or “Database,” “Cart,” and “Product Browser” for an online shopping site.
- Capabilities (verbs of the system) describe the abilities of a particular Component to satisfy the Attributes of the system. An example Capability for a shopping site could be “Processes monetary transactions using HTTPS.” You can see that this could be a Capability of the “Cart” component when trying to meet the “Secure” Attribute. The most important aspect of Capabilities is that they are testable.
Creating a high-level matrix using this model can be a simple way to visualize your system. Figure 8-6 shows an example of what such a matrix might look like. Gojko Adzic agrees that exposing system characteristics and providing more visibility is definitely a good idea (Adzic, 2010a), though he cautions that while we can learn from other fields, we should be careful about using them as a metaphor for software development.
)
Figure 8-6 ACC example
Use heuristics such as Elisabeth Hendrickson’s “Test Heuristics Cheat Sheet” (Hendrickson, 2011) or tried-and-true techniques such as state diagrams or truth tables to think of new ideas for attributes. Combine these ideas with models like the Quadrants so that the conversations about the system constraints or usability can extract clear examples. Using all the tools in your toolbox can only help increase the quality of the product.