Greetings!
It's 'Double Header Day' at Quality Sphere as I approach two topic areas at once:
Quality is everywhere:Toastmasters, International, and
Methods to the Madness: Things my mother never told me about UAT
I mentioned in my last article how I wanted to touch upon a quality organization - Toastmasters International (TMI). No doubt on my tombstone will be the motto 'Fran saw quality everywhere'; however, seeing why TMI is such a great organization is easy. But before I extol the virtues of this organization, I would like to address a specific area Quality topic: User Acceptance Testing (UAT).
I recently ran into a possible gray area around how best to defined the following:
End state summary
User scenarios
Use casesUser test cases
To many, and I have to admit that I had my doubts recently as well, struggle as to what are the differences between these terms? Are they just different ways to express the same thing, or are they all just different points in the testing horizon? After some soul searching, reading and on the job experiences (OJE), I believe I have found reasonable answers (notice I didn't say 100% correct answers - I'll leave that to ASQ-BOK gurus to put their stamp of approval on it). I would classify them under two areas:
High level
End state summary: is simply what it says. A summary of where we want to be at the conclusion of Test Effort 'X'. There could be 1 or more 'X's', but nonetheless, it's simply a summary statement. You could also use 'Future state summary' as well.User scenarios: The high level paths that the user is expected to take that will allow them to arrive at the scenario end state.
Specific
Use Cases: Specific action taken in the user path to arrive at the end state. As with any test case, there should be a stated expected outcome and it should be traceable back to the requirement(s).
User test cases: Can be the same as Use Cases, however, the value of these test cases is to tread into areas either expected or not expected to be encountered by the user. And yes, the terms 'black box' and white box' testing could apply here as well. Again, as with any test case, there needs to be an expected outcome and it should be traceable back to a requirement(s).
Simple enough, but then ponder the 'chicken or the egg' scenario. Does one use the high level to drive requirements, or do you develop requirements to drive the high level? This question was presented to me recently, and I am still mulling it over - but would like to hear your thoughts!
Back toTMI ....
I have been a member of TMI since May of 2009. I belong to a great club called the Synergists. What makes TMI a quality driven organization? They exist simply to promote continuous improvement in communication and leadership ability in EACH individual in a very positive, supportive, efficient, and cost effective manner. And, it works very well! .... 'nuff said!
I have been a member of TMI since May of 2009. I belong to a great club called the Synergists. What makes TMI a quality driven organization? They exist simply to promote continuous improvement in communication and leadership ability in EACH individual in a very positive, supportive, efficient, and cost effective manner. And, it works very well! .... 'nuff said!
