Start spreading the news: CAST keynote in NYC

I’m excited to announce that I’ll be giving a keynote at CAST 2014 this August in New York City! The title of my talk is “Scaling up with Embedded Testing”.

The theme of CAST this year is “The Art and Science of testing” and the speaker lineup looks fantastic. I’m really looking forward to spending several days in the company of some amazing and inspiring people.

If you’d like to join us in for CAST in New York City this August, register here. See you there!


Interview at Hack and Heckle – Rise of the “devster”

I’ve been interviewed by my buddy Ben Morgan on his podcast Hack and Heckle. Ben was a pal of mine at university. One of my first memories of Ben was when he confronted my friend Jo and I at the uni pub for running out of his databases tutorial when his back was turned. In our defence, his tutorial wasn’t at all boring – we were just very hungry!

In this episode, we discuss what happens when software developers level up their testing skills. Listen to it here!


Actually moving to San Francisco

For reals this time!

Yes in June I’ll be moving from London to San Francisco. I’ll still be working at Google in much the same role, I’m just moving desks across the pond. I’m excited for the new opportunities that await. And happily, I’ll be about 10 hours’ flying time closer to my family in Australia, with a much nicer timezone overlap.

Thanks London for high tea at Forbes & Burton, drinks in the Science Museum, ducks and geese on every menu, Rebel f**king Bingo, the Tube when it’s working right, the grand scale ping pong bar, the overwhelming temptations of Borough market, daffodils in the springtime, being classed as a “morning person” for being chipper at midday and for doing Christmas season the right way – by being too cold to do anything but stay in drinking mulled wine and eating Yorkshire puddings. And for teaching me the importance of orderly queueing and a good cup of tea. I’ll be sure to visit.

Hey again San Francisco. We both knew this was inevitable. See you soon.


Female technologists, let’s be heard

As I do a lot of public speaking these days, I’m often amused to hear the feedback that I’m a “very natural speaker”. People are always surprised when I tell them that I used to be very shy. Actually “shy” doesn’t even cover it. Two years ago I reunited with my friend Masami, who is like a sister to me. I hadn’t seen her since I was a teenager, when she came from Japan to live with my family for a few years. I told her how I started the Sydney Testers Meetup and how much I loved meeting new people there. She looked surprised and said “What! But you HATE people!” Yes that was me as a child and a teenager – the shy, quiet girl who hated meeting new people.

So how did I get from there to here? At some point in my life, I just found that I was passionate about software and testing, to the point that when I spoke about it the words just flowed out of me. Sometimes partway through speaking I’d realise I was talking and people were listening to me and I’d get self-conscious and trail off. But then it occurred to me that I’d been speaking and people were listening, so I should try it again. And I just kept on doing it.

I was talking to a female scientist at the Google Women Techmakers event last week and she commented on how very few technical women speak at technology events like I do. At events like these, we still have a lot of business women in the tech industry who are speaking, and that’s fantastic, but there aren’t very many women programmers who want to speak publicly. I think there’s a simple reason for this – there just aren’t that many programmers of either gender that are comfortable with public speaking. If maybe 10% for instance are okay with public speaking, then 10% of women programmers is a much smaller number than 10% of male programmers because there are simply more male programmers.

“Maybe we just have to suck it up,” she posited. “Maybe we’re the ones on the front lines.”

She has a point. If we want more female engineers as role models then more of us are going to have to get used to being in the spotlight. And hey, I’ll be the first to admit that’s not easy. I still get nervous every time I go up on stage, and for at least the entire month beforehand. But it does get easier with practice. And every time I’ve done it, it’s proof to myself that I can do it.

And if your excuse is that you just don’t have the same self-confidence as me, well I’ve got that one well covered too. I’ve suffered through clinical depression, been to therapy for low self-esteem and I still get anxiety attacks that paralyse me. Several times in my career I’ve thought I can’t do this, I should just quit and do something completely different. But in my heart I’m a scientist, and if the hypothesis is that I can’t do it, then I need some evidence before I’ll let myself completely believe it. So I set myself a challenge and make myself prove it – can I do this or not? Can I get up in front of 400 people and talk about something I believe in? Or will I back down?

I place bets on myself and so far I haven’t lost. And each time I’m amazed at this, so it still feels like a gamble. But it’s exhilarating. I’ve never been into extreme sports; this is all the adrenaline rush I need.

My cousin Shiloh has absolutely crippling chronic fatigue syndrome. Most days she’s lucky if she can even sit up for a few hours, let alone stand and at one point she was confined to a wheelchair. She’s in constant physical pain. But throughout it all she’s positive, and good, and perhaps the purest spirit I know in this world. Last time I visited her in Brisbane, I bought this artwork from her (above) that reminds me of her strength and her spirit. If I ever need a reminder that I have opportunities and I’m capable of so much in this world, this is it. I can walk, I can even run. I can sit up for hours, I can use those hours to learn so many new things. I can speak, I can even speak to hundreds of people at once. It’s not easy but my god, it’s completely achievable. And it feels so good to do it.

So to women engineers, I urge you to speak. I encourage you to get up on that stage and tell the world how much you love technology. I push you to shatter the stereotype of the white male nerd programmer. I’m not saying you have an obligation just because you’re a woman. I’m saying that you have an opportunity to join us on the front lines and be part of our revolution.

Trust me, it feels great.


Forget developers in test, we need testers in development

Last year I started working on a small team with developers that really value testing and treat it as in integral part of the development cycle. I’ll never forget one of our first planning meetings when we were discussing a feature that we were about to build and a developer frowned and said “Yeah, but how are we going to test it?”. As a result they changed the whole design.

I think I just about fainted with shock, having never heard that in my career. The key part of this was that it wasn’t the team asking me, the tester, how *I* was going to test it. It was a question asked of the whole team – how are we as a team going to test it? How can we build this so that we have confidence that it will work as we build it?

As we built features, the developers would always write tests – everything from unit tests to browser level tests – and have another developer do some manual testing before it was passed to me for testing in a fully integrated environment. By the time it was handed to me this way, I rarely found bugs that were due to carelessness. Most of the bugs I found were due to user scenarios or system scenarios that hadn’t been thought of earlier.

So you might think, as a tester, did I really have much to do on a team like this? My most valuable asset in this process was still the way I thought about the product – from a testing standpoint, from a user standpoint. What I found was that my testing expertise became less valuable at the end of the cycle and much more valuable at the start. The more effort I put into testing the product conceptually at the start of the process, the less I effort I had to put into manually testing the product at the end because less bugs would emerge as a result.

I just want to break that last bit out into a big fancy font quote here because I think it’s quite important.

The more effort I put into testing the product conceptually at the start of the process, the less I effort I had to put into manually testing the product at the end

But the key part of this was that I knew that the development team was testing the product effectively by thinking about testing, writing tests and manually testing as the product was being developed. I could trust that if we had thought of a scenario during planning, it would be effectively developed and tested with automated regression tests in place by the end of the process.

I’ve had a lot of discussions this year around the role of the tester. Let’s put that aside from now and start thinking about the role of a software developer. A software developer needs to be able build a product with confidence that it does what it’s expected to do. Knowing how to do that at a basic level should be critical to the role of a good software developer. For that reason, we need more testing in software development. And it needs to be done by the people building the product.

Having a testing specialist on the team is a valuable asset, but the role of a specialist isn’t to restrict that responsibility to a single person. You might also have a database specialist on your team, but it doesn’t mean that they’re the only person working with databases. The same goes for testing. The specialist can help with the really difficult testing problems, knowing that the rest of the team is capable of dealing with the simple testing problems.

Then it’s shorter feedback loops, greater confidence and faster quality releases for all. Who doesn’t love that?

Special thanks to Chris, Bram, Tom and the rest of the Wildfire team at Google – you guys rock.

Special shout out to Alan Page who’s made me punch the air and yell “hell yes!” every time I’ve read his blog this year. 

750 Tweets

So this was fun. While spending a rather hungover Sunday afternoon following Silicon Christmas, immobile on the couch and learning about Angular.js, I happened to tweet the following:

I received this reply:

I spent almost 750 words forming a semi-coherent answer, until I gave up and James gave me the answer:

To which I of course responded:

A short time later, James sent me a prezi which looked like this:


Inside the “O” was written:

A tweet has 140 characters which divided by 6 for average word length plus space gives about 23 words per tweet. But that will lead to hard to read text. So if we say an average of 18 words per tweet you can comfortably reach your goal in 42 tweets.

I was a little slow.

Of course I did. An hour and a half later, I got this:


Becoming a testing craftsman

test craftsmanship

I recently came back from teaching a day-long workshop at the Eurostar Conference in Gothenburg. My wonderful co-host Jim Holmes and I wanted to talk about becoming a testing craftsman.

Jim was inspired by the software craftsmanship movement to create this workshop. I think the concept from this community that has resonated most with both of us is the focus on continuous learning and improvement. So while we introduced many tools in this workshop, we wanted the main focus to be on the joy of learning and discovery. Now that we have these tools, how does that change our test approach? What other skills could we learn that could change our test approach further?

Because there’s being able to use tools and then there’s craftsmanship. Craftsmanship is about using your tools and experience to create something with integrity. In testing, we’re often not the creators on a project but rather the catalysts. So the thing that we’re creating is an approach. Part of this approach can include the creation of tools, whether it’s a robust test automation framework or a use-once script. But the important part of the approach we create is the combined skill and experience that we bring to apply to the problem at hand. As we increase our diversity of skills and deepen our experience in each one, we are able to refine our craft to create a high quality approach for different testing problems.

It’s about improving yourself as a craftsman, in order to improve the quality of the software you’re crafting. And believe me, even if you’re not the one typing in the code that tells the software how to run, you’re still crafting software as a tester. You still have influence over the shape and form of the end result. That’s why we do this. For the joy of discovery and the joy of creation. That’s how we craft.

The presentation slides.
The Ruby script worksheet.
Mind maps created by Graham Freeburn.
Slide graphics created with Canva, which is my new favourite toy.

Why I’m not going to tell you what I’m building

When I worked at Campaign Monitor, we used a Campfire (a chatroom system) for team discussion. The designers had a “design room” where they would share mockups and ideas. This worked really well as it allowed the rest of the team to provide them with fast feedback of their ideas, even in remote teams, and there was a full transcript we could refer to later.

One day a private room appeared in Campfire called something like “Super Elite Designer Room for Make Good Design”. I asked why it was private and a designer explained to me that it was for brainstorming ideas when they didn’t want feedback on them yet. He explained that as part of the creative process, you have to feel safe and free to talk about ideas without any restrictions.

I believe all creativity is like this. We need that part of the process to explore the moonshot ideas before we’re dragged back down to earth. We need to be able to run with the crazy, stupid and impossible ideas before someone tells us “it’s too expensive”, “it’s been done before” or “nobody will want to use it”.

So a few months ago I started working on a web application and I didn’t tell anybody what it was about. This approach was met with some curiosity and a lot of criticism. One critic said that I should definitely tell EVERYBODY what I was building, because then they would be able to give me feedback on my idea so I could make it better.

That is exactly the reason I wasn’t telling anyone about it.

See, while some things remain subjective, communities tend to form rough consensus on what they think is good, bad, crazy and stupid. If I start creating within the rules of good, bad, crazy and stupid then I’ve already built a strict set of rules around whatever it is I’m building. The shape of my idea has already been laid out for me, ready for me to fill it in with yet another colour. When someone says they’re making my idea “better”, what they really mean is they’re making it conform to the the collective notion of “good”. That’s no way to make anything interesting.

But even without feedback, this is hard mindset to break. As someone who’s lived in the same world as everyone else my whole life, I have hardwired notions of good, bad, crazy and stupid already. So how can I break free of that in my creative process?

So I decided I’m going to create the worst app I can think of. The craziest app I can think of. The stupidest app I can think of. Something nobody would ever want to use. Something everyone would laugh at. Something only a damn fool would make and nobody could even understand but me.

Then I’ll make a beautiful user interface and create a fabulous user experience, because that’s important to me.

But I’m not going to tell you what it is.

Trish Khoo's tech blog