Getting Creative


It can be difficult to write tests where the user takes strange and unexpected routes through the system, tries bizarre inputs, gets impatient and clicks a button ten times in quick succession, any kind of bad-path test you've identified.

In a way, these tests defy the whole idea of design, because if you can spec them out in advance, they aren't really unexpected, are they? This is definitely an area where you may need to wait for the system to be available and then play with it to get an idea of how to abuse it. These kinds of tests require a lot of creativity; have fun with them.

Sometimes it's tough to even think how to test a particular item. For example, what if a story implements a data model within the database schema but no story uses it in a user interface? It may be that this type of test is better handled by the unit tests it may not even be appropriate to have a separate acceptance test. Consider whether it impinges on the customer in some indirect way, and design tests for that. After all, if the customer really can't tell whether the story has been implemented or not, that should be a pretty quick story to implement, eh? (wink, wink, nudge, nudge).



Testing Extreme Programming
Testing Extreme Programming
ISBN: 0321113551
EAN: 2147483647
Year: 2005
Pages: 238

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net