Those tests case should be automated.

Then, it doesn't matter how many of them they are.

So, you will still be confident that the new build doesn't break a previously fixed bug. This also gives increase the developer's confidence, since he knows that if he make a mistake, there are good chances it will be catch by those regression tests.

Yes, but… Actually one of problems with test cases is that you can hardly keep them up-to-date. If you’d like to generat test case from each bug you find you’ll be soon overwhelmed with a number of test cases.

For me the second poing you bring is especially important. That’s exactly looking at the application via user eyes. And you look at the whole flow, not just one particular function.

Let’s take an example.
You test the signup page in your web application and notice that even if you don’t enable the checkbox “I agree with the terms and conditions” you still get your account created.

You mark it as a bug and write down how to reproduce it – that’s a test case. On the next build, you go through the test cases you wrote and check if they pass.

I see no other way of being able to do this regression testing, unless you write down these test cases.

1. Delivery to offshore testers, particularly if development is onsite

2. Test Design, it helps you design how you will test the product, much like a developer who is designing how he or she will program the software

3. Repeatible process, particularly useful if bringing in a new tester

Good post, I agree. QA Test plans derive most of their value from the initial writing, the thought processes that go into that writing, and the first iterations through the code while writing the test cases.

Blindly running through older test cases is one of the main causes I have seen for missing obvious product bugs as people who blindly follow the test plans often put aside the creative aspects of testing.

John