Using Use Cases To Create Test Cases
As part of my "Live from BAWorld: Boston" series, I attended a talk Monday by Matthew Leach of Doreen Evan Associates called "Leveraging Multi-Level Use Cases for Testing and Other Ways to Obtain Greater ROI on your Business Analysis Investment".
His talk went into great depth about how you could use use cases on your project in multiple ways, looking at different levels of detail in use cases. He quoted a study from VokeStream that indicated 76% of people surveyed manually build test cases still.
This is the one point I also wanted to emphasize the importance of: re-use your use cases to generate test cases, particularly user acceptance test scripts (UAT scripts). At some level this seems obvious to me, but I don't think it is all that obvious after all based on the above study, Matthew's experiences, and my personal ones as well! On a recent project I worked on, the business came to us to talk about how awful the integration and unit test cases were - that they just would not work for UAT. My immediate thought was "well of course not, those aren't meant for UAT". Apparently QA had told them to write their UAT scripts from these test cases. That's almost as challenging as writing them from code! So we walked them through how we could take the use cases we had written (which the existing test cases were generated from) and easily translate those into UAT scripts.
If you think of your use case having a happy path and alternative paths, you would want to blow out each of those paths into at least 1 test case each, by adding concrete data to the use case. So for example, if there is a step for the user to input "shipping information", then in the UAT script, you would want to supply actual shipping information including a specific name and address that would be in the test data set. It's important during UAT to also test the alternate and exception paths - to ensure the not-so-happy path and errors are handled to the business' satisfaction. That said, it's also unrealistic to think your users have time to test all possible paths. To mitigate this, I have two suggestions.
- Pick the most important UAT scripts to test. You have to decide what "important" is, but it would be wise to look at the use cases that add the most business value and/or are most frequently used.
- Use your BAs during UAT - particularly for the less important test cases that the users can't it.
Labels: BAWorld, qa, Requirements engineering, software requirements, testing, use cases, users
posted by Joy at 10/21/2009 10:00:00 AM
2 Comments:
Thanks for the interesting post.
We are a company that specializes in model driving your business and have a number of products that achieve this. Our view is very much aligned with your post and hence our tools of choice are Sparx Systems Enterprise Architect which we then automatically generate our test cases from (using use cases and scenarios from the model). We have found that generating test cases from a 'sub-optimal' model will save our team 25% of the scripting time, while generating test cases from well structured use cases saves them approximately 75% of their scripting time. Big savings either way. You may want to check out the SA-EA-ET-JIRA integrated end-to-end solution, you'll be surprised at the value and the number of companies starting to 'join the dots'.
Regards
Bryce Day
www.catchlimited.com
Thanks for the comment! I'm struggling with an environment right now where there is a test tool in place and they are trying to force use cases into it to easily convert to test cases, but they are unreadable once imported. I'd love to be using a tool that integrated and we could just push them over.
Post a Comment
<< Home