10.12.2012 Views

Domain Testing: Divide and Conquer - Testing Education

Domain Testing: Divide and Conquer - Testing Education

Domain Testing: Divide and Conquer - Testing Education

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

The material presented in training was mostly about 1-D spaces. So, in many<br />

respects, this problem was a good test in that it required performance at level<br />

6 of Bloom's taxonomy.<br />

Unfortunately, none of the subjects made this conceptual leap. They<br />

tried to treat the problem as if it were two independent 1-D spaces. This led<br />

them to propose tests that I thought were not very powerful.<br />

They did well on the outside boundaries of each dimension, since these<br />

could be tested independently. They did well on the enumerated variables,<br />

correctly identifying each value as something they needed to test.<br />

<strong>Testing</strong> the numeric inputs showed some conceptual problems. Almost<br />

all of the students tested the inputs for field lengths of 5 <strong>and</strong> 32. Nowhere in<br />

the documentation that I saw claimed either one as a limit. The program<br />

seems to enforce 5 as a limit, but whether this is according to any<br />

specification or not, I can't tell. I think this was an invented limit because<br />

they couldn't deal with the concept of an unknowable limit.<br />

When dealing with experienced testers, I think it is a good thing to<br />

write test cases as specifications of constraints that the test cases must fit. I<br />

expect experienced testers to be able to generate good test cases from<br />

specifications. However, when dealing with inexperienced testers, I don't<br />

have that same expectation. Until I see some test cases that they generate<br />

from a specification, I don't know whether a specific person underst<strong>and</strong>s<br />

enough about what makes a test case good to generate good ones.<br />

Many of the subjects wrote more generic specifications for test cases<br />

instead of generating specific values. So, without more data, I can't tell<br />

whether they did this knowing how to translate that into good test cases, or<br />

whether they did it because they didn't know how to write good test cases<br />

<strong>and</strong> could figure out some specifications.<br />

Only one (1) subject wrote test cases with almost all test cases having<br />

specific values. Six (6) wrote them with most values specific, while fifteen<br />

(15) wrote them with few values specific.<br />

For the seven who wrote at least mostly test cases with specific values<br />

instead of specifications, the test cases were good. For the fifteen who didn't,<br />

I have no way of knowing whether they could actually generate good test<br />

cases for those specifications.<br />

McGeeReport v1.doc 2 03 January 2004 09:01

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!