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.
Box Of Chocolate
* You never know what you’ll get
Firstthought Right
* Don’t keep thinking too long about the possible solution.
Sounds lika a chicken
* Use your senses when describing a problem.
The Genius complex
* The ares coded by the genius are not bugfree.
The Sexy Chick perpective
* Look away from the interesting b(t)its once in a while.
Take prisoners
* Bring “difficult” people into your team
Don’t Feel Stupid
* If you don’t understand – chances are you are not the only one. ASK !
Picture/Film says more then 1000 words
* When reporting use images and videos for describing when words fail.
It’s always the new kid
* A new comer will always mess something up. Test it.
Reverse it.
* Try it doing the opposite way. Think in 180 degrees.
Just try it !
* Even if you are sure it would not work.
Don’t Berate – Automate !
* Well that is selfexplanatory.
The Bathroom Oracle
* Take a break for a fresh view on stuff. ( And for toilet testing @ google.com)
Defects are Gold
* All value of testing comes from found defects. Crap reports give no value.
No bugs no Glory
* Bugs make you happy. Finding bugs is fun. Day without bugs is a waste.
Follow the Rythm
* Projects have speed and follow a steps and patterns. Do not swim against the flow.
Hide and seek
* Find your friends and on the way you’ll find many interesting things. Don’t forget to find your friend.
Tell that yo your cat !
* Would your cat or grandmother understand what your are saying ?
Trust People, not Numbers
* Context : decision about what to tell “Managment”. Get facts to support.
Don’t trust Foreigners
* CMMI levels in different countries mean differents things.
“It is only …”
* Really Means : “I underestimate this problem”
Newcast action !
* when you see a problem videotape it – and broadcast.
Look ! Look – No Hands!
* People ofter use fancy words to hide their incopmetence and for distraction.
There are no problems
* .. Only challanges.
Google Rule
* Your problem is already solved by someone else. If not then make sure it’s not yours anymore.
That WAS a kindly, albeit anonymous, contributor! Thank you very much!
—M.
Michael,
You have put a great presentation there that made me thinking a lot. Also i’ve met some great people there.
You have also mentioned a book about architectural patterns which i’ve failed to note.
Would you mind naming that book here so i, and other people that i’ve met, could go and look for it?
Thank you.
Hi, Anon (please feel free to leave your name and address)…
First, thank you for the kind words. I too met some very interesting people and felt lucky to have interesting conversations with them.
The name of the original patterns book is A Pattern Language: Towns, Buildings, Construction, by Christopher Alexander et. al. At one point, I remarked to Cem Kaner that Lessons Learned in Software Testing seemed to be a book very much in the same kind of spirit, which is one of the reasons that I liked it so much. Both books are collections of heuristic suggestions about their subjects, with some excellent stories to illustrate and emphasize the points.
—M.
Hello Michael,
Thanks for the workshop you gave and time to answer questions.
Although I’m still in the mode over thinking what you had to say. I strongly believe that heuristics can help make complex issues, problems or even understandings easy to define goals. And perhaps define the direction for decisions.
Often I see that time is lost collecting evidence/metrics and based decisions on those figures. My opinion is that it is better to make decisions instead of thinking making them. Decisions make people move and on movements we can act. If decisions are moving in a good direction or when they are going the wrong direction doesn’t matter. It helps us to adapt. If adaptation is done in a proper context, they should help customers better.
At least your words had some impact as they convinced me to trust the test-the-tester-test instead of trusting on certifications.
With regards,
Jeroen
Hi Michael,
Thanks for a great workshop. Just wanted to add a comment on the angle of gaze (i.e. how dogs catch frisbees) heuristic you mentioned during the workshop:
I find it really fascinating that this only seems to have been discovered in the past ten years, because there’s a very similar heuristic that’s been in use in aviation for many years.
Except with this trajectory, you’re not trying to catch a moving object, you are the moving object, and you’re trying to throw yourself at a particular reference point on the ground, to land your aircraft. But the essential heuristic is just the same – if it’s moving up in your field of view, you’re going to fall short, if it’s moving down, you’re going to overshoot. I wonder why nobody ever reversed it?
@Anna…
I also wonder why no one ever reversed it. Except maybe I don't—when you look at it, the whole history of science is filled with people saying, "Wha…? Oh. Right."
Thanks for the kind words.
—M.
If you need some more explanation to the "Stickman" heuristic you can find an small image under
http://blog.markus-deibel.de/uploads/strichmaennchen_heuristik_overlay.jpg
In addition to what is already there you could use the legs as reminder for testing > and < as input (might find bugs in AJAX/XML)
You couldalso give the little fella a big and a small ear as a reminder to test max an min values.