Talk:Use case: Difference between revisions

From FreeMind
Jump to navigationJump to search
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)