Past Presentations
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.
Let's meet!
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.
Michael — how about teams that have interesting ways of being alerted when the continuous integration builds/tests fail, such as with Lava lamps? Then you can say that the test is not silent, but screams (in a visual fashion in this case). You’ll reply that it still takes human eyeballs to watch that lamp, or hear that sound, etc., but I think you know what I mean.
Grig
I believe I know what you mean, and your conclusion is correct. I think you’re confusing “the means by which we are notified of some inconsistency” with “knowing something”–confusing the tool with the task. This is a superset of Pradeep’s observation, in a way. The Lava lamp doesn’t find the bug because the test doesn’t find the bug either. The lamp and the tests are media, in the McLuhan sense; things that extend our ability to find bugs (and, when taken beyond their capacity, reverse into not finding bugs).
There is no significance to the Lava lamp or the test until human eyeballs suggest to human brains that we might want to understand something about it. The failing test doesn’t tell you that there’s a bug. It tells you that you might want to investigate something. The results of that investigation could be:
You don’t have a bug in the product. The test fails because it’s an old test that you forgot to remove.
You don’t have a bug in the product. The test fails because it contains its own error.
You do have a bug in the product, but now that you look at it, you realize that the function is redundant anyway, so you refactor it out and remove the test.
You have three bugs in the product. The test only alerts you to one of these–the trivial one–, but on further inspection, you realize that there are two other serious bugs in the same area, bugs for which you had no tests.
It’s this last one that’s the most interesting implication of Pradeep’s statement. My friend Dan Spear–one of the best developers I’ve ever known–was developing a little programming course back in the 90s. Very early on–because it was an assembler course–he introduced us to DEBUG. He pointed out that DEBUG would neither find nor fix our bugs; we had to do that, and often we would see more in the debugger than we had anticipated. Similarly, failing tests aren’t problems; failing tests point to possible problems. The sapient human–not the failing assertion in the test, not the lighting of the lamp–is what finds the bugs.
By the way, here’s one for fun, from Pradeep himself: You have a bug in the product, but the test didn’t find it; the bug is such that when one particular function is executed, it erroneously sends data down the USB port, lighting the lamp.
Thanks for the response, Michael. You’re right, it does take a human being at the end of the day to make sense of any alerts, or failed tests, etc.
My point though, and I believe you’re familiar with it from our crossing swords in the past
, is that the assistance offered by automated tests is invaluable. To me, there’s simply no way that a human being can stay on top of doing regression testing without having automated tests.
That being said, I totally agree with you that manual, brainy, exploratory testing is vital — see my latest blog posting for such an example: http://agiletesting.blogspot.com/2007/09/beware-of-timings-in-your-tests.html
Grig
I feel blessed to have you and James as my gurus.
I want to ensure that every second and minute that you people have spent for me is converted to value addition for you and testing community and at last myself.
My thoughts and ideas are largely influenced by you, James, Jerry Weinberg, Dr Cem Kaner, Jon Bach, Ben Simo, my dear Indian testers and to all those who have spent (and will be spending) their valuable time for me helping me to learn to become a better tester.
I must also mention about great testers who blog and help me think more new ideas, daily. Thanks to people like Michael Hunter, Jon Kohl, Mike Kelly, Karen Johnson, Scott Barber, Shrini Kulkarni, Elizabeth Hendrickson, Harry Robinson… ( there are a lot of people)
I thank you all and God. I hope I become a good value addition to the future of testing community.
Bless again, Michael, and I shall be able to notice the bugs that the Lava Lamps fail to signal me!