Apparently.
Please don’t misunderstand. I love the principles in the Agile Manifesto (including Robert Martin’s proposal for the fifth, “Craftsmanship over crap.”) 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.
This is a tricky question.:)
I saw some Agile projects were they started building the login screen as most important feature for the first and sometimes the second iteration.
Looking at this screenprint they were able to create that functionality. Perhaps the main requirement was” getting people registered or accounts created.
All the rest is just items which might have worked if the iteration wasn’t that short. 🙂
Another question could be: Why did the automated test passed? or Did we do our automation on the correct level?
Hi, Jeroen…
Thank you for the comments. Your last questions are the ones that particularly interest me, in that it’s quite conceivable that some automated tests did pass, which may have fooled the development team into believing that everything was okay. That’s not to say that those tests were bad; merely that they were insufficient without human evaluation. Note also that there are all kinds of things that the automation can reveal easily, things that would baffle, bore, or overwhelm a human.
As to the notion of building the login screens first, that’s cool. One set of heuristics says “Do the hardest stuff first”; another says “Break the big, hard problems down into little, easy ones.” Nothing wrong with any of that. Whichever way you handle it, it would seem a good idea to do a set of tests focused on the image of the organization before you put out your work live to the world. Image-related questions are often hard to decide mechanically.
Hi Michael,
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. 🙂
My initial reaction to this post is that it is a cheap shot against testers. Perhaps your particular problem was identified (it looks fine on my browser), but it was too time-consuming to fix that problem and instead the team decided to roll out the code so at least some or possibly a majority of people could register and login.
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.
Michael,
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
Are you sure it’s a bug?
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…
Lol. Indeed. Agile projects will always need testers. There is no amount of control we can put in place that will mean zero defects. I’ve just finished an agile project and without a manual tester it would have been pretty un usable.
Keep up the good blogging.
Don’t need automated tests. Some quick compatibility smoke testing would have identified that. Then again, maybe it was found, and not deemed important enough to fix. “Noone runs in 1024×768” you can almost hear the lead developer say…
Well, My experience with agile is not good till date.
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.
Thanks for the comment, Tariq. I'm not sure I agree entirely. I agree with your central point, I think—that management support and collaboration are important, and that the big picture is paramount. But I'm not convinced that developing the project in bits and pieces is incompatible with those ideas. I think that we can have both. That elephant gets eaten one bite at a time.
To Aaron…
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.
To Joe…
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.