Intertwined SFDPOT & CRUCSPIC STMP Rikard Edgren
I hope many of you are using SFDPOT (James Bach) and CRUCSPIC STMP (thetesteye.com) in order to investigate what to test. SFDPOT describes elements of the product, and CRUCSPIC STMP describes sought attributes of the system. They are very powerful ways to identify things to test, plus to be able to communicate it effectively.
Both are very rich, and could incorporate each other, e.g. SFDPOT could be a part of Capabilities, and CRUCSPIC STMP could be a part of Operations (often inverted as a risk) There are more connections, as seen here:
I still recommend using both as separate activities, they stimulate thinking in different dimensions (and that’s why testers are needed, right?) That they blend is not a problem, it is the thinking that matters, so just put the stuff where it makes most sense.
If this makes almost no sense to you, interpret as a hint to try both!
There are also connections for each combination, at least they can inspire new test ideas.
Example: Is the data easy to use?
Compatibility over time?
Charisma in the structures?
Platform testability?
If this is in your taste, I recommend creating a pair of Shmuel Gershon’s Exploratory Dice, http://testing.gershon.info/201108/the-big-exploratory/
Rickard,
Nice post. I like how it creates a quick bunch of potential areas to explore.
I think I’ll try experimenting with this in two ways.
First, I’ll discuss the complete list (below) with colleagues and say: “let’s identify half a dozen or so areas out of the list of 72 that warrant further investigation.”
Second, I’ll weed out some of the combinations from the 72 below that I’m not interested in, and – with the shortened list – stick those next to the next set of tests (or testing missions) we execute. In other words, using items from the list to create potential combinations of ideas along the lines of: “Test number 1 calls for a tester to sign in as an admin user and do X and Y with the expectation that Z will happen.”… Combining it with the ideas in the list below, we’d get a quick way to look deeper where it makes sense to do so. We’d “re-write” this test 1 to now read:
“Sign in as an admin user and do X and Y with the expectation that Z will happen. And while you’re doing that, think about the implications of ‘structure & capability.’ Sometimes the tester would think: “Hey, that brings up an interesting thought! I wonder if…” / Other times, the tester would think… “Hmmm, I can’t really think of how that combination would apply to this particular test… I’m just going to ignore that combination this time.” Which would be fine; the goal would be to spur additional useful thoughts (which it would no doubt do), not to force round pegs into square holes (which we’d want to avoid).
PRODUCT ELEMENTS QUALITY CHARACTERISTICS
1 STRUCTURE CAPABILITY
2 FUNCTION CAPABILITY
3 DATA CAPABILITY
4 PLATFORM CAPABILITY
5 OPERATIONS CAPABILITY
6 TIME CAPABILITY
7 STRUCTURE RELIABILITY
8 FUNCTION RELIABILITY
9 DATA RELIABILITY
10 PLATFORM RELIABILITY
11 OPERATIONS RELIABILITY
12 TIME RELIABILITY
13 STRUCTURE USABILITY
14 FUNCTION USABILITY
15 DATA USABILITY
16 PLATFORM USABILITY
17 OPERATIONS USABILITY
18 TIME USABILITY
19 STRUCTURE CHARISMA
20 FUNCTION CHARISMA
21 DATA CHARISMA
22 PLATFORM CHARISMA
23 OPERATIONS CHARISMA
24 TIME CHARISMA
25 STRUCTURE SECURITY
26 FUNCTION SECURITY
27 DATA SECURITY
28 PLATFORM SECURITY
29 OPERATIONS SECURITY
30 TIME SECURITY
31 STRUCTURE PERFORMANCE
32 FUNCTION PERFORMANCE
33 DATA PERFORMANCE
34 PLATFORM PERFORMANCE
35 OPERATIONS PERFORMANCE
36 TIME PERFORMANCE
37 STRUCTURE IT-BILITY
38 FUNCTION IT-BILITY
39 DATA IT-BILITY
40 PLATFORM IT-BILITY
41 OPERATIONS IT-BILITY
42 TIME IT-BILITY
43 STRUCTURE COMPATIBILITY
44 FUNCTION COMPATIBILITY
45 DATA COMPATIBILITY
46 PLATFORM COMPATIBILITY
47 OPERATIONS COMPATIBILITY
48 TIME COMPATIBILITY
49 STRUCTURE SUPPORTABILITY
50 FUNCTION SUPPORTABILITY
51 DATA SUPPORTABILITY
52 PLATFORM SUPPORTABILITY
53 OPERATIONS SUPPORTABILITY
54 TIME SUPPORTABILITY
55 STRUCTURE TESTABILITY
56 FUNCTION TESTABILITY
57 DATA TESTABILITY
58 PLATFORM TESTABILITY
59 OPERATIONS TESTABILITY
60 TIME TESTABILITY
61 STRUCTURE MAINTAINABILITY
62 FUNCTION MAINTAINABILITY
63 DATA MAINTAINABILITY
64 PLATFORM MAINTAINABILITY
65 OPERATIONS MAINTAINABILITY
66 TIME MAINTAINABILITY
67 STRUCTURE PORTABILITY
68 FUNCTION PORTABILITY
69 DATA PORTABILITY
70 PLATFORM PORTABILITY
71 OPERATIONS PORTABILITY
72 TIME PORTABILITY
– Justin
(Incidentally, your fantastic comment to Michael Bolton’s post http://www.developsense.com/blog/2012/09/premises-of-rapid-software-testing-part-2/ brought me back here today). Your comment there, about teaching to verbs vs. teaching to nouns, has definitely given me something to thing about.
Thanks Justin.
I have previously thought of the combinations (I use the dice) as inspiration for “the whole”, but sticking them to tests to execute is definitely an idea I’ll try.
/Rikard