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.
You can find an extensive list of presentations and courses that I've taught, including the slides and speaker notes for many of them, here.
Highlights from my schedule appear below. If you notice that I'm in your part of the world, drop me a line if you'd like to get together. If you'd like to engage my services and worry that I'm not available, please note that my clients' schedules are subject to change, so mine is too. Please drop me a line in any case.
January 3-6, 2012
Calgary, Alberta, Canada
Rapid Software Testing class (three days) with an extra free day for which the client chooses the agenda.
January 9-10, 2012
Toronto, Ontario, Canada
Rapid Testing training and consulting in Rapid Testing with a corporate client.
January 16-18, 2012
Helsinki, Finland
Rapid Software Testing: a three-day public class, organized by Altom. Information is here; registration here.
January 27-29, 2012
Melbourne, Florida
Workshop on Teaching Software Testing
January 30-February 3, 2012
Palm Bay, Florida
Writing work with Cem Kaner and Becky Fiedler.
February 13-17, 2012
Orcas Island, Washington
In-person development work on the Rapid Software Testing class with James Bach.
March 8-14, 2012
Utrecht, Netherlands
Pencilled-in engagement teaching Rapid and exploratory approaches with a corporate client.
March 15-16, 2012
Munich, Germany
Two days of presentation and particpation in an in-house testing conference for a corporate client.
March 26, 2012
Halifax, Nova Scotia, Canada
A three-day Rapid Testing class, with a free fourth day based on the client's agenda.
April 10-12, 2012
Oslo, Norway
A public offering of Rapid Software Testing.
April 13, 2012
Oslo, Norway
Work for a corporate client.
April 16-19, 2012
Orlando, Florida
A tutorial and a keynote at the STAR East conference.
April 25
Toronto, Ontario, Canada
Corporate in-house training and consulting.
April 30-May 2, 2012
London, UK
Rapid Software Testing public class organized by Electromind.
May 3-4, 2012
London, UK
The UK's first public offering of Rapid Software Test Management, again organized by Electromind.
May 7, 2012
Stockholm, Sweden
I'll be presenting the first keynote and a half-day tutorial at the inaugural Let's Test Conference in Sweden. Alas, I'll only be able to stay the first day of the conference, which runs from May 7 through May 9, 2012.
May 8-11, 2012
Trondheiim & Brønnøysund, Norway
The Norwegian Testing Cruise. So far as we know, this will be the the first boat-based and northernmost testing conference in history.
May 21-23
Utrecht, The Netherlands
A public course Rapid Software Testing class in the Netherlands.
May 24-25
Utrecht, The Netherlands
A public class of Rapid Software Testing for Managers.
June 12-14
Cary, NC
Private training and consulting in Rapid Software Testing for a corporate client.
June 25-29, 2012
Atlanta, Georgia, USA
Private training and consulting in Rapid Software Testing for a corporate client.
July 10-12, 2012
Cary, NC
Private training and consulting in Rapid Software Testing for a corporate client.
July 16-18, 2012
San José, California, USA
Participating in the CAST conference.
September 10-12, 2012
London, UK
A public class of Rapid Software Testing, organized by ElectroMind.
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.