I learned who you were by watching your Google automation talk last year in 2015. Your presentations are really nice. Are you planning on giving any other presentations this year or next year?
My short answer is no.
My long answer is also no because I actually don’t actually enjoy giving presentations at all. I wrote about my battles with anxiety last year and whilst I am 90% better than I was, last year I committed to present three talks in less than two months which resulted in me having panic attacks about giving these talks. This wasn’t fair on my wife or children who I need to support on a day-to-day basis.
Each talk requires a huge amount of preparation and since my personality leans towards perfectionism I wanted to make sure each talk was as good as it could be, so I wrote every word of each talk and (unsuccessfully) tried to memorise these. This resulted in me delivering the talks partly reading what I’d prepared, which I wasn’t happy about as I was comparing myself to others who delivered their talks without notes.
The reason people give talks is that speech is an amazingly effective communications tool – probably the most so – yet it’s a drastically inefficient communications tool – each minute of a talk requires at least an hour of preparation. I much prefer written communication as I find confidence in writing, and I hope with frequent, thoughtful updates to my blog I can reach a wide audience and still be effective in spreading new ideas.
Everyone at the Automattic Grand Meetup is required to give a 4 minute (or less) flash talk about any topic they like. I told a story about how I was stung by a wasp bush walking. This was my talk:
Continue reading “Bush Walking (or how a wasp can destroy your iPhone)”
I gave a talk at the first ever Brisbane Testers Meetup last night. It was a fairly good turn out despite some very climatic conditions (very wet and windy).
Every time I give a talk I try to provide a key message, a key takeaway question and ultimately aim to make sure everyone learns something that will make them capable of kicking ass in some way when they get back to work (hat tip to Kathy Sierra).
My key message last night is that we, as testers, put things on pedestals, and we need to stop doing it; we need to push over those pedestals. We put automated testing on pedestals because it’s about programming. We put programming on pedestals often because it’s about frameworks. And we put frameworks on pedestals as they are overly complicated and complex and offer far more than we ever need.
So I tried to knock over those pedestals by showing how you can write a ruby testing framework from scratch in 15 minutes. Crash. Bang.
My key takeaway last night was “what can you take down from your pedestal?” I personally think we all put things on pedestals, we greatly or uncritically admire things. We need to stop it.
The aim of my coding exercise was to show the 20 or so testers in the room who hadn’t done automated testing but wanted to do automated testing that it’s not that hard. Ignore the frameworks, focus on programming and build the simplest thing that could possibly work. Ignore the complex frameworks, the bar to learning programming and automated testing has never been lower.
My slides are available here if you’re interested in taking a look.
I did a presentation on Einstein the Minesweeper robot at an ANZTB SIGIST in Melbourne this morning. The facilitator of the session was ill so I was asked to host the event as well, so I felt very much under pressure.
I came up with an idea for a quick activity to “awaken our senses” as it was early in the morning where I asked everyone to count how many human senses they are aware of. Most people gave the traditional response of five (or six), and I challenged their views by presenting some additional senses we humans possess. Check out the Wikipedia article if you’re interested to know more.
Unfortunately the first presentation on Context Driven Testing by Mark Richards went well over the allocated time, so I had to rush my presentation to ensure I could catch my 11am flight home: I made it, just.
Being for a group for testers, my intention was to not focus on the detail of the actual Minesweeper robot but what solving a complex problem such as automating Minesweeper can teach use about testing and how to be better testers.
Click the slide below to view the slideshow.
I gave this presentation about changing your mind as a lightning talk in Austin in March.
If you can do one thing this year, I’d encourage you to change your mind on something and share it.
I gave a talk tonight to the Brisbane Special Interest Group in Software Testing (SIGIST). There was a great turnout (tickets went in 24 hours after the announcement apparently), and there was some good interest in Einstein (plus 3 people who had never played Minesweeper, what the?).
Alister will discuss browser automation, using an example of writing a Minesweeper robot. Einstein, his robot, proficiently plays Minesweeper in a web browser and was developed using specification by example techniques using Watir, RSpec and Cucumber in the Ruby programming language.
Alister is an Agile tester who currently works for ThoughtWorks Australia and author of watirmelon.com. He’s been actively involved in the Watir open source project for a number of years and his passions include ruby programming and collecting arid plants.
In getting the slides ready, I actually came up with a reasonable list of things that building Einstein taught me about software testing (and software development in general):
- Break big things down into little things
- Design for testability
- Test in the right places
- Supplement your automated testing
- Build in performance measures
- Change your mind
- Be young, be foolish, be happy
The last two points weren’t really related but I threw them in there for good measure.
Here’s the slides (and a link to the originals):
And here’s that video of Einstein in action:
Watir Day 2011 in San Francisco was a great success. I personally took a lot away from the day including:
- We organized and promoted Watir Day in a very lightweight way, but managed to attract over 60 attendees and 10 sponsors!
- The key to Watir’s success has been its community, focus on building a tool for testers, and not trying to be everything to everyone.
- Watir is seen as a secret sauce for a lot of web companies – they are very hesitant to talk about it publically in case their competitors copy them. But we managed to hear a few of those stories for the first time on the day:
- Watir is a key part of Facebook’s engineering culture: they have been extremely successful with Watir, after failing with Selenium.
- Convio has been so successful with in house open source test automation using Watir that they have phased out outsourced testing altogether, and are hiring more automated test engineers than ever.
- An individual’s involvement in an open source project can be inversely proportional to how happy they are in their job – not happy at work = less commits, more happy at work = less commits (via Bret Pettichord)
- The future is bright for Watir. Using WebDriver technology will enable us to deliver a tool designed for testers to testers, but an increasing range of browser and device support.
The questionnaire results speak for themselves:
The slides are available online.