SFDIPOT.... Huh?

One thing last weeks exercise showed me was that while I'm familiar with SFDIPOT, I haven't used it enough to be comfortable with it. So let dive in,  I'll explain what I know (or think I know) about using it and how I plan to use it this week. If I make mistakes,  I fully expect the community to help out and show me where I'm using SFDIPOT wrong, and I'll pass that on to you.  The original blog post about this by James Bach on his blog here. He's mentioned that developed this heuristic from surveying six or seven computer science textbooks to lay the framework for his thoughts on application modeling. 

As I understand it SFDIPOT is a heuristic to use while doing a software tour to ensure that you have a complete understanding of the application.  This is sort of how I use it. I actually do several tours of the application/feature in questions, all very quick and high level while thinking about each of these. I don't do them in the order of the Heuristic simply because I don't really think that way. 

So what does it mean? 

S: Structure, how is the application put together/wired up. These are things like: Uses Mysql as a server, Has a separate authentication server,  Uses memcache and Uses Ajax. Things that can lead you down other vectors that you might not have thought of while doing a simple product tour. You might need to get help/information from the developers and or Documentation for this piece, as such I recommend doing near the end of the heuristic. 

F:  Function, what are the functions of the feature/application. What are the individual things that it does.  This can be a (organized) listing of all of that actions that can be done using the application. These are smaller than the user stories, these are things like "Mark favorite" and "Join mailing list". Stories will come later and will invoke many of these functions. 

D: Data, what are the data types involved in the application. Data types can lead to interesting test cases. Have a look at Elisabeth Hendrickson's cheat sheet for some great ideas on how to test your data types once you have identified them. 

I: Interfaces,  one of the newer letters in this heuristics (and thus harder to get information on), these are the interfaces that the application interacts with the outside world on. Does it have a file based interface anywhere (import/export  functions?)  Does it store intermediate files to a local storage anywhere? Is an api provided? Does one exists that isn't provided? And yes, the GUI is an interface, does it interact in the ways that a user will expect that kind of interface to interact.

P: Platforms,  What are the platforms does this application run on? Is it a java app? Does the version of Java matter? Is it a Web app? Does the browser version or vendor chance the performance or interactions?

O: Operations, What are the operations that the application is trying to accomplish? What is the purpose of this application? What are the mistakes can can happen when trying to do this operation?  I've been asked if these are your User Stories and Test Cases, and the answer for me is kind of. User stories are definitely things that are thought of here, but not just the stories, how those stories can go wrong and or get interrupted.  Test Cases however are part of your test coverage. I'm using this heuristic to create a PCO which will in turn inform the creation of my test coverage.

T: Timings, Another recent addition to the Heuristic, Timings are what are the time based things you will have to think about with this application?  Does your application have to run a specific time? What will happen if it runs on Feb 9th?  Or runs over new years Eve? in 1999? What happens when two actions are done too quickly? Too slowly? A recent conversation with also pointed out to me that these can be environmental. Where is the application? What is happening at the same time? Is it rush hour at that time at that location? 

As you can see, if you run through all of these, you will have a very extensive list of things to think about while designing your test coverage.  As I said in the beginning, this heuristic while seemingly simple does take some practice to use, and that is my goal for the week. To use this heuristic and get better with it. My plan is to use this in my everyday testing, for every feature and bug report from the field that is passed on to me. I realize that this might not align with the it's best uses, but I'm game to try, maybe I'll figure out something new about the heuristic, or  about myself. 

I'll let you know how it's going on Wednesday!

If I have anything wrong or misinterpreted in this, please let me know in the comments below.