The posting is not a cheap shot against testers; it’s more of a shot (cheap or not) against insufficient critical thinking on someone’s part. The page may have been developed without the participation of anyone called a tester; there may have been testers who dazzle themselves with test automation and won’t use their own eyes; there may be a bug in one (well, both) of the browsers that I used. From the outside, we don’t know, and we can’t know. But note that as of this writing, the problem has been, uh, fixed. And, apparently, still not looked at with a sufficiently critical eye.

“Testing” problems like this are usually management problems in a flimsy disguise.

—Michael B.

Automated unit tests are a wonderful thing; they have been since the 1950s, when the machinery wasn’t so reliable, even though programs themselves didn’t change very quickly. Now the hardware is very reliable, but the software can be changed so quickly and easily that we have a different motivation for unit tests.

For higher levels (as you may know), I’m an automation skeptic. (Note that skepticism is not a rejection of a belief, but a rejection of certainty.) I completely agree that the barest involvement of a thinking human would have spotted that problem, were that human modelling the test space to recognize that many, many people still run on 1024×768 displays.

In the Rapid Testing Course, we teach people that “No user would ever do that” really means “no user that I’ve thought of, and that I like, would do that on purpose.”

—Michael B.

Testing in agile will work when there is a clarity on the functionalities that are devloped in an iterative method but when the story is not finished in one sprint and no one looks after that for the future sprint then the project is bound to get doomed.

Testing in agile will only work with the outstanding management support and importance being given to the complete story rather then developing the functionalities in bits and pieces.

Keep up the good blogging.

Maybe all Agile Conference actors use IE browser(*) and they don’t care if it doesn’t work with FF.
You may replace IE by Chrome, Opera…

I too owe a respect for the community and people who work for Testing with Agile methodology. And, wish to say the same words of yours i.e.,
>>I have great enthusiasm and respect for those who have advocated the role of testing in Agile projects. But in order to push these ideas forward, let's make sure to test our stuff, to make sure that it doesn't accidentally bring discredit to the ideas.

I enjoyed the tests on the URL http://agile2009.agilealliance.org/user/register

Some of the basic features (more rightly behavior) were not meeting in those tests which was a needy one to any of the application. I am not able to add the pictures of those test here, hence I am not able to put them.

The register page of Agile conference 2009, have the bugs. (Might be the web page could have been designed by followig the Agile process itself.. I Don't Know.) I did not test any other pages of the http://agile2009.agilealliance.org, except register page.

This shows whatever the process or methodology we follow ("no best practices, but it is only the practices fits for the context's being working on" – as said by few of our testing community personalities, as of my knowledge. Please, rephrase this heuristic.), each methodology or process and its deliverable's needs to be QUESTIONED with not agile (Moving quickly and lightly) way, but with more detailed thoughts and thinkings.

Questioners are always in need!
Therefore, TESTERS will be needed until where there are no bugs present in the shipping application (which is not at all possible, since bugs are always present), whatever might be the process followed for SDLC.

Let me know thoughts, Michael, on the above said..

Ravisuriya

Just to make sure I’m thinking through this I have an idea of three other things it could be:
1) You found it ironic and humorous and wanted to comment on it.
2) This example served as a way to make your point about a common pitfall of Agile thinking.
3) You have knowledge of how much testing was allowed and/or what the test plan was for that website, thus you can say for sure that the testing was of a lower quality than you would advocate.

I now wonder why I had my initial reaction to the post. I think it is because at my company I hear comments from our internal users about how unintuitive and buggy our applications are and that it must not have been tested very well, yet I know for a fact that many of the concerns that users are bringing up are the exact same things I was advocating for 3 years ago. I find it so interesting that the testers are blamed when it could maybe should be the project manager and development teams who are held more responsible for the quality of the product.

Your question is resonantly echoistic of the past with other development methodologies. In my opinion test engineers will always be needed regardless of any development methodology; including past, present and those simmering to be unleashed.