Testing the Waterhouse

So I was recently reading this blog post , and it raised some interesting thought processes. I'd never really thought of testing being dead as it states in that article, instead I tend to think of it as evolving, evolving from having a myriad of test cases that need to be run as part of regression, or even as part of acceptance testing, to instead a more flexible approach. I recently worked on a project, which had a massive constraint on time, effectively the business wanted it released to the customer as soon as possible, and it was a high priority project too. This meant that I could go about testing it in a different way to how I would have previously. Instead of writing an abundance of acceptance tests for any features, I'd write GWTs or even perform exploratory testing (documented of course - a pet hate is exploratory testing that isn't really documented, see my blog post here ). The biggest drawback to this "release it as quick as possible" approach wa...

I recently read a presentation on exploratory testing by  +Elisabeth Hendrickson  on exploratory testing, and it came with an interesting solution to Exploratory Testing, one that offers enough guidance, but isn't a test case. The slides are available here . I'll take the pieces that I strongly agree with, and discuss them here. Firstly, defining what exploratory testing is. This is very important, I believe that a number of people view exploratory testing as just randomly using the application under test and trying to break it in any manner possible when in actual fact it should be much more than that, in order to actually be useful. It should be: Targeted Structured Well defined In order to execute some exploratory testing, I think there needs to be some knowledge of the system under test, how it should behave, and the dependencies of the systems. The tester learns about the system as they begin testing, this information can be fed into the next test, and so on. T...