Talk:Use case: Difference between revisions
No edit summary |
|||
| Line 4: | Line 4: | ||
You can write use cases that cover a lot of territory, they don't have to be nearly so detailed as test cases, but they should still be written with the idea of testing them in mind. If a use case calls for something that can't be tested, you can be fairly sure there will be conflict over that issue later on in the project. | You can write use cases that cover a lot of territory, they don't have to be nearly so detailed as test cases, but they should still be written with the idea of testing them in mind. If a use case calls for something that can't be tested, you can be fairly sure there will be conflict over that issue later on in the project. | ||
--[[User:Rben13|Rben13]] 12:32, 14 Oct 2007 (PDT) | |||
Latest revision as of 19:32, 14 October 2007
Use Case Granularity
In my experience as a QA analyst and software designer, the best use cases have been those that do a good job communicating both to the user community and the engineers. They've usually been written in narrative form. The first set developed usually document typical usage of the system. As users, designer, and developers work through the implications of the design, additional cases are written to illustrate corner cases, places where the usual logic can lead to unexpected results.
You can write use cases that cover a lot of territory, they don't have to be nearly so detailed as test cases, but they should still be written with the idea of testing them in mind. If a use case calls for something that can't be tested, you can be fairly sure there will be conflict over that issue later on in the project.
--Rben13 12:32, 14 Oct 2007 (PDT)
