Peter Marshall posted an interesting set of testing phases/steps for an agile development project. It covers project set up, release planning, development iterations, hardening iterations, and release. Good stuff.

A while ago I answered the following question on SearchSoftwareQuality.com’s Ask The Software Quality Expert: Questions & Answers.

I am a test engineer working on Windows applications. I do manual testing. In the agile world, when things keep on changing every now and then, it's difficult to get well-defined requirement specifications from developers, which disturbs test case writing, traceability, and test execution. What would be the right strategy to make sure we are delivering quality product?

Here is a clip from my answer:

One of the organizing principles for the book Testing Computer Software was how to test without well-defined requirements specifications that always change. Similarly, Lessons Learned in Software Testing has many tips and tricks for dealing with just that problem. If you're not familiar with those two books, I highly recommend them. Aside from those deeper views on the topic, I might share the following.

I've never worked anywhere where the requirements were well defined and/or locked down. I don't really know what it would look like if I did. Some of the project teams I worked with thought they had well-defined requirements, but once development and testing started, that often turned out not to be the case. My perspective has never been to operate under the assumption that I would get requirements that I could trust as the sole oracle for my testing.

You can find the full posting here.