Why create test cases in advance? Well, I find that it helps me prepare on many levels, but that is quite a lengthy subject, not to mention that generating tests is in and of itself a form of testing(static). If you can catch defects in requirements, you have stopped them at the least expesive point of the process. I will also note that finding data values on the fly can be extremely time consuming. It helps to find out how dev has layed the tables out, etc. and test writing is a great way of figuring that out.

One other note: I believe that it is inherently not a good practice for developers to have access to the QA tests. Developers should never test the way that QA tests. Also, the prospect of unknown audits can often lead us to do more complete work than if we know the audit will not cover something.

Do you need a dedicated tester on the team? Hmmm…well I just logged 150 defects on a release that was Unit tested before I got it, and this was created by senior developers. If you want to be less accountable for the work you do and you don't mind more bugs going to the end user, then by all means get rid of the people who specialize in it. :)

Having worked in agile teams for a while now, I have to agree with Kelly's response 'the process is largely the same'. Another advantage to writing test cases 'just in time' is that they stay fresh in your mind. How many times have you written test cases, sometimes months up front and by the time you test, forgotten the logic behind them?

You make some very fair points that I know are a concern to a lot of testers getting used to agile.

In part, the point is really a philisophical one. In traditional waterfall projects, a tester has to think of the data to enter to drive out the test scenarios. In agile, the tester still has to think of the same things; just not necessarily *all* up-front, they can do it when they come to execute the test cases for the user story.

Specific data input that drives different scenarios can be captured in the test cases on the user story where appropriate. For example, to test a credit card payment you might have: 1) test visa card, 2) test amex card, 3) test expired card. You could potentially put the data with the test cases, but I’d suggest only including the essential differences in the data that drive it down a different scenario. And only if somehow it’s helpful to do that up-front rather than when the story is ready to be tested.

If you’re using a test management system, further details can be held in there, with each test case scripted in more detail if and where that’s appropriate. At least then it’s repeatable, but in agile testing would ideally be largely automated anyway, so it may not be necessary.

With or without this extra detail, it’s still good to capture the basic test cases before development, as part of getting the user story written.

If you have a requirement to capture evidence of test results for audit purposes, you can still do so in your test management system, when the tests are executed. And you can still use your test management system to see how much of the testing has been covered for the sprint, and how much has passed.

Basically the process is largely the same as in traditional projects. But you do it piecemeal when it is needed, i.e. just in time, instead of all up-front.

Kelly.

We use two types of testing – programmatic tests created by the developers, and acceptance testing, performed on the application by the user after the Sprint review.

I have also seen teams where one of the member’s sole responsibilities is to create tests for the code produced by others. Whether a dedicated tester is absolutely required is debatable, however some teams coming from a more traditional methodology will have one.

Regardless, the development team should be testing to cover the application perspective, and the product owner should test from the user perspective. That way, all bases are covered.

I’m a follower of your blog and I have learnt a lot with it. Thanks for the contribution.

I ‘ve made an odd post at my companie’s blog, and I invite you to watch it too! :)

Hope you have fun!

http://www.seatecnologia.com.br/blog
or
http://www.youtube.com/watch?v=g_Y-eHsADrw