I was recently asked this question on an interview for a "QA manager"
position.

The context was the content of a test plan for a simple program that will:
1. Open a file for writing
2. Replace the first 50 bytes with "0"s
3. Close the file.

My (wrong) answer was that one test case may be enough to cover such simple
functionality. The interviewer was actually expecting a separate test case
for one positive scenario and for each "negative" situation the testers can
think about like:
1. non-existent file
2. file length less than 50 bytes
3. file write protected.
... and so on (a "live" document)

In my SW testing career (10+ years) I don't recall we ever have developed a
test case just for one requirement. The main criterion for a "good" test
plan or procedure was to cover as much requirements (functionality) as
possible in one test case to minimize duplicate descriptions, preparation
and start-up time, etc.

I also argued (apparently not a good thing to do on a job interview :-) that
the above "negative cases" are in fact requirements that were probably
already elaborated during the development of the application. In such case
they become "positive" as now there is a known outcome associated (e.g.
display a warning or increase the length of the file). However, the
interviewer was not interested in my knowledge of other SDLC processes.

I was just wondering, is having a test case for each requirement a common
thing? Can someone enlighten me and explain why would this be more useful
than having one elaborated scenario covering multiple requirements? Note
that as far as I know the organization I have applied is not known for using
agile processes as TDD.

Thanks.
--
View this message in context:
http://www.nabble.com/How-many-test-cases-tf2662862.html#a7426739
Sent from the Agile Testing mailing list archive at Nabble.com.