EXPERT RESPONSE
There really is no notion of phases in any "agile software development methodology" that I am familiar with. This isn't to say that you may not have run across a development methodology that someone refers to as being agile that uses phases, but generally agile processes are heavy on developer testing, always having a working build of the software, and include very frequent user acceptance testing (UAT), which in an agile environment is more of a feedback loop where end users and stakeholders tell the developers what they would like to see added or changed in subsequent builds.
There are as many differences in testing phases/processes as there are people willing to answer that question times the number of different methodologies they have experience with. The notion of best is almost as vague. The only notion of "best" that I know is the one that happens to work well for your particular team on any given project.
|
|
 |
Personally, I tend to prefer projects that are more agile than pre-planned and rigid. I'm sure this is my preference because of the same personality traits that make me grumpy when I'm expected to wake up at a certain time every day, take the same route work every day, or even to make travel arrangements more than a few days in advance. I get bored very quickly when I know what I'm going to be doing too far in advance, and when I'm bored with something, I tend not to do a very good job at it. I do much better work when I am continually reacting to new information. As a tester, I am happiest when my "test plan" involves at the completion of each test asking myself "What test or testing task can I do right now that will add the most value to the project."
I know other extremely talented testers who become very stressed and ineffective in environments where the testing is not pre-planned to a greater or lesser extent. Basically, I don't believe that there is a best. I don't even believe that any one methodology is generally any better than any other methodology. Some methodologies, I do believe, work better for certain teams on certain types of projects, that that is judgment that each team needs to make for itself.
|
