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...

When I first started out writing manual tests, I was really keen to do every step in minute detail and write out the expected result for every little step. In an ideal world where time is no constraint, resource is no constraint and updating the scripts is no constraint.. oh and the person writing the scripts didn't get bored.. then this would probably be the best way! However, in the business world, we have all these constraints!! The business want features yesterday, they want these features delivered with the minimal resource within the acceptable time frame and they want new features further down the line that make the old features redundant.  With the above in mind, it's important to address, what makes up a good manual test? As these tests may or may not be around forever.... I think in order to answer the question above another question needs to be addressed, which is: Is it going to form part of a manual regression test pack? Or is it throwaway? ...