One of my “aha” moments with painting was when I took a gouache class and thought oh this technique is so easy – it’s just like colouring in! But when I tried to teach a friend to do it, the gap in our experiences really showed. I didn’t realise how much I’d learned about drawing just from doing it for so long. Mixing colours, looking at real images in a way that makes them “flat” so that I can transfer them to a 2D drawing – these are things that I learned through years of practice.
A pink beetle I painted. Gouache on paper.
I think testing skill is the same. You can’t really say to someone “just do this and this and now you’re an expert tester”. It’s more like “start by doing this, and do it again and again for years and you’ll get good at it.” And I think that’s why there’s a myth that testing is just some magical “mindset” that some folks are gifted with and others can’t learn. It’s the same when people say art is a talent that folks are just gifted with – it ignores the years of hard work that went into refining that skill, and it prevents people from trying to learn it.
Another of my paintings. Lady in a silk kimono. Gouache on paper.
I hear many developers say that it’s impossible for a developer to be a good tester because it’s an innate talent or mindset. It’s not true at all – it just takes practice. Lots of practice.
I am always surprised at how many software developers I meet who are reluctant to write unit tests. Writing good tests is a crucial part of becoming an expert software developer. The best developers I know all consider writing unit tests a crucial part of software development. All of the most successful software companies consider testing ability a vital selection criteria for promoting or hiring senior developers.
But you don’t have to just take my word for it – I have collected quotes from software developers at top software companies to explain how testing their code made them into the top developer they are today. You can share these quotes with your team as inspiration, or with the world using the tag #testyourcode. Maybe we can make software quality just a little bit better today.
I didn’t know how bad a developer I was until I started writing unit tests. At first, it seemed like a waste of time, but as I started writing more and more I noticed that I was catching bugs much earlier in development, which made them a lot easier and faster to find and troubleshoot. Previously, I would write code, deploy, find a bug, spend ages trawling through logs trying to find root cause, fix it, then redeploy. There’s a lot of wasted time there. I would frequently lose half a day because of typos. After I jumped on board the unit testing bandwagon, the quality of what I deliver has increased to the point that the amount of respect I get from my colleagues makes me feel awkward. They think I’m blessed or something. I’m not gifted or blessed or even that talented, I just test my code.
To me, writing tests is a core part of building features or fixing bugs. Reviewing test coverage is a key part of reviewing a pull request. Ensuring strong test coverage has helped teams at GitHub prevent regressions when building features, fixing bugs, or refactoring, even with a lot of other engineers working in the codebase.
Testing is a necessary part of software development. It ensures the release of high quality and reliable code. Most importantly testing the functionality of your code and ensuring it works as expected is how you maximize customer satisfaction. I’m happy as a developer when I know that the code I ship to the customer is maintainable and it works.
– Susann Keohane, Chief of Staff to the General Manager of IBM Watson Health, and a Master Inventor of 185 issued patents
One of my most formative experiences writing software was an internship I did at Google. I don’t think I’d ever written a test before. We had a project which did about 500 things (had 500 tests) with Firefox. My job was to make those 500 tests pass with Chrome. I learnt very quickly the value of a good test suite; I could see my progress very visibly, I knew when I broke things adding new features. And I got a little addicted to making just one more test pass. Seeing how much having those tests made my life easier, introduced certainty and progress and reliability, had a big impact in the developer I am today.
When I was starting out in my career in software development I had a conversation with a friend who had recently returned from working in the US. He impressed me with having quite a good way of summing up some of the more high-level software engineering skills that really didn’t feature in my degree course at that point. Fresh out of University I really wasn’t thinking too much about the testing software with automated tests and I really felt that coding was the most important thing.
My friend said “Okay; with you with your code how do you know it works?”
And of course I started responding “Well you know I ran it and…” And of course I realised that my new code would interact with previous code, and I would not be able to test it myself as I added more and more code.
In that moment actually realised that he was right with the point that he was making. He was right that in fact I couldn’t possibly know that my code was working just by running it and clicking on some stuff, trying to exercise a few branches. And I realised at that one time that automating that process was the only possible way that actually I could actually know that my lovely code was working like I thought it was.
It seems very simple question. It seems a very simple challenge, but that question “How do you know that it works?” was actually what turned me around from not thinking automated tests were important to suddenly realising that they were vital.
Are you having trouble working out why your automated tests are failing? The next time you find yourself stuck, try my automated test debugging cheat sheet. It lists the most common issues that affect automated end-to-end tests based on my decades of experience dealing with them. I hope it saves you from some headaches.
If you would like to learn how to prevent and solve issues with your automated tests, sign up for my Foundations of Test Automation training course. You will learn how to write automated tests in a way that’s scalable, robust, and easy to maintain.
My friend, mentee and fellow ex-Googler Paulo Lai joins me for this blog post today as we discuss some of the recent books we’ve read and liked. Paulo and I love to read non-fiction books about business, technology, and self-improvement and we’re always sharing book recommendations with each other via email. So we thought we’d share some of our recommendations with the rest of the world.
We read an awful lot of books, so this could be the first in a long series!
The Lost Art of Listening
The Lost Art of Listening, Second Edition: How Learning to Listen Can Improve Relationships
I recommend The Lost Art of Listening even though the focus of the book is on relationships. If you can listen to your parents for example when you disagree, then you can probably listen to most other people.
From that I learned that to listen well, you need to put the other person ahead of yourself, at least while you are listening and that it’s more than ok to say that you’re not ready to really listen yet. Also that nagging is a sign that the other person really wants to be heard and acknowledging them is very helpful. Oh and that I’m not 10% as good of a listener as I thought I was.
Once I found out by accident how powerful really listening to someone can be. I was on a plane and decided to be polite and talk to the woman sitting next to me, without any agenda. I paid attention to what she was saying and shared my thoughts as part of the flow of the conversation. Later she sent me an email telling me how big an impact I had on her and it realized that came about because I focused my energies on listening, not on pushing my point of view. Think about how much helpful that would’ve been for my relationships if it did the same for someone I was close to!
I got most of the way through The Lost Art of Listening and quite liked it. People already tell me that I’m a good listener, so I didn’t expect to get as much out of it as I did. It not only has advice for how to be a better listener, but also advice for how to be heard.
At a recent talk I gave, someone asked me what’s the one piece of advice I would give to CEOs for running their company. My advice was listen. Really listen. This seemed to make a big impact on the audience as half the follow-up discussion after my talk was about this advice. This book has a good description of what I meant by “really listen”.
Here are a few of my highlights.
“Having an understanding attitude doesn’t mean presuming to know a person’s thoughts and feelings. It means being open to listening and discovering.”
“One of the unfortunate things we learn along with being “polite” and not being “selfish” is not to say directly what we want. Instead of saying “I want …,” we say “Maybe we should … ” or “Do you want … ?” When we’re taking a trip in the car and we get hungry, we say “Isn’t it getting late?””
“Listening puts a burden on the listener. We feel the weight of the other person’s need to be heard. Attention must be paid.”
Radical Candor: How to Get What You Want by Saying What You Mean
A must read for all managers. Providing honest, actionable feedback is one of three things you must do well as a manger and this has been the best book I’ve found on how to do it. It explains why it’s so important to provide timely, honest feedback that can’t be misunderstood, ideally while still caring about them as a person. It really helped me understand a lot more about how Google came to manage their engineers they way it does, the flaws with it, etc as well as better understand management in general. For example it explained why you shouldn’t make a fuss about promotions, you need those who are not interested in promotions to continue to work well, and anyone promoted has had enough reward and can do their own private celebrations.
I thought Radical Candor was very good. The examples really helped me understand good ways to give feedback and encourage others to give feedback as well. I had this book in mind when I recently gave a workshop and I really wanted critical feedback from my attendees so I could improve the course. By asking for feedback in the ways described in the book, I ended up receiving a whole lot of really useful critical comments. Not to mention I received some really positive feedback too which looks great on my website!
“WHEN YOU CRITICIZE someone without taking even two seconds to show you care, your guidance feels obnoxiously aggressive to the recipient. I regret to say that if you can’t be Radically Candid, being obnoxiously aggressive is the second best thing you can do. At least then people know what you think and where they stand, so your team can achieve results. This explains the advantage that assholes seem to have in the world.”
“If you’re not one of those people who instinctively welcomes criticism as an opportunity to improve, you’ll of course feel a strong urge to act defensively—or at the least to explain yourself. This is a natural response, but it pretty much kills any chance that you’ll get the person to offer you the gift of candor again.”
Paulo’s bonus book – Accelerate: The Science of Lean Software and DevOps
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
One of the best reference available to help convince others of the value of DevOps, it has some useful comments about how to write great surveys and why they’re often better than direct collection of data as well a run down of some anti-patterns you should avoid within your company.
Trish’s bonus book – The Singapore Story: Memoirs of Lee Kuan Yew
The Singapore Story: Memoirs of Lee Kuan Yew
My Dad grew up in Singapore in the 40’s-60’s, so it was interesting to gain a little insight into what his life was like back then. He said men used to come into his house to sharpen machetes then they would head back out to the riots. It’s hard to imagine that Singapore when all I’ve ever known is the modern, rich, clean, safe Singapore.
Lee Kuan Yew was a master politician, and it made me think about how politics is all about building relationships. I reflected on how it connects to politics in organizations. I might read a book about Obama next.
I bought a copy of the book and its sequel for my Dad for Christmas, at his request. He has already read more than I have. He says the first book is much more interesting, and the second book is great for curing insomnia.
“The people as a whole must have self-respect and the will to strive to make a nation of themselves. The task of the leaders must be to provide or create for them a strong framework within which they can learn, work hard, be productive and be rewarded accordingly. And this is not easy to achieve.”
Our general observations on reading and learning
In our recent emails, Paulo and I reflected on our different reading styles and how we manage to get through so many books so quickly. Paulo prefers audiobooks, while I prefer to read on my Kindle Paperwhite.
Damn, I’m jealous of how many books you get through! I’m slow because I read them on my Kindle Paperwhite and highlight notes as I go. I usually get about 70% through and drop them, but I’m learning to be okay with that since it’s usually enough to get the gist of most non-stop fiction books.
I seem to go through books very differently to you. For me it’s much more to understand a space well enough to know how to ask decent questions later on and less about knowing something deeply. I have less than one highlight per book I’ve read! It’s no surprise that it’s a lot less taxing for me to get through so many, at the same time I’m feel that I do need to get through the whole book, blinkist is helpful, but it’s too concise. I find it’s much better for me to rush through the full book.
That’s probably a good way to approach most books anyway and it’s the reason I only get 50-70% through most of them. By the time I’ve gotten that far, I usually feel like I’ve got what I needed and they’re just reiterating the stuff over and over again in a different way. I have trouble remembering things so that’s why I highlight so much, not to mention that I’d like to be able to use quotes in blog posts and presentations later if I need to. It’s interesting to see how different people learn from books.
This is the keynote I gave last year at Agile Testing Days in Germany. You wouldn’t know it to look at me, but I was so sick with a cold that I literally slept in until midday, got up, gave a keynote, and went straight back to bed. Despite that, I’m really happy with how this talk went and it seems that the audience was too – it received a rating of 4.29 out of 5 stars!
Trish Khoo: Transparency - A holistic approach to software quality - YouTube
When I was invited to give a workshop at Agile Testing Days 2018 (Potsdam, Germany), I wanted to teach lessons in test advocacy and management because I think these are really important skills that can be difficult to learn effectively. I thought about how I learned these skills and it was always through experience rather than advice. I think that’s part of what makes it a difficult topic to teach. So I had a wacky idea – what if I got the class to try out the lessons learned by roleplaying, in a Dungeons & Dragons (D&D) style adventure game?
Then I had an even wackier idea – why not do THE WHOLE THING as a Dungeons & Dragons game?
After that, everything fell into place for me. I’ve been running D&D games as a DM (Dungeon Master) and writing my own campaigns for two years now so designing a workshop in a similar way felt very natural.
Oh for so many reasons!
It’s pretend, so players can take risks that they wouldn’t necessarily take in real life
If it’s done well, it *feels* real
This is all a perfect formula for a workshop. I wanted participants to not just learn what I taught them, but to feel like they had lived through it.
How to write a D&D campaign workshop
Writing a D&D game is not like writing a story book. It’s more like writing the rules for a theme park that your players will explore and interact with. So instead of thinking about what the players will do, it’s better to think about what situations you want the players to encounter, and the consequences of solving or not solving the problems presented.
I thought back to my real experiences working at large organisations as a test manager – what were the situations that led to the lessons I learned? What helped me to win and what caused me to fail? I did my best to simulate a similar environment for my workshop players.
I briefly thought of using a metaphor to guide players through a dungeon and relate it to a difficult workplace, but I thought it best to simulate as close to real life as possible. However, I did want to add a bit of that D&D “epic adventure” feel to it, so I set quests and a sense of urgency to add drama and excitement.
As a side note: I’m so happy with how my slides turned out. I designed them all myself using Canva and some graphic design tools and I think they look super slick.
Then there were the mechanics to consider. I didn’t want my players to be killing everyone in their organisation – it’s neither realistic nor a lesson I wish to teach! However D&D is much more than combat anyway – primarily it is a way to explore a world in our collective imaginations. So combat was just discarded. The mechanics needed to be simple, so that anybody could play the game right away, even if they’d never played D&D before.
I settled on these rules:
Roll a skill check:
Roll a d20 (20-sided die). Add that number to the skill value on your character sheet. That’s your score. The DM will tell you whether that result means that you passed or failed.
If you roll a 20.
That’s called a “natural 20”. You automatically pass with flying colours!
If you roll a 1.
That’s called a “natural 1”. You fail catastrophically!
There’s a concept in D&D called “Difficulty Class” (DC) which is a number that the DM knows that the players have to beat in order to succeed at a skill check. For example, if the players want to test an app then that is a testing skill check. They might roll a 10, and add their testing skill value of 5, bringing them to a total of 15. Is that enough to successfully test the app? Well, that depends on the DC. If it’s a fairly simple app and easy to test, I might set the DC to 10. A 15 beats that so they would have successfully tested the app. But if it’s a really complex app and very difficult to test I might set the DC to 20! In that case, a 15 would not be good enough and the player would fail to test that app effectively.
The advantage of not sharing this number with the players is that it gives a bit of power back to the DM – I can fudge the result if I really need the group to go a certain direction in the story. However, there’s still a chance of natural 20’s and 1’s so it still doesn’t give me ultimate control!
I am a big believer in letting the story go where the players lead it, regardless of how far that takes them off the main path I designed. This lets the players really feel like anything is possible, and encourages more creativity which is something I love to see in a D&D group. However, in a workshop setting I also need to be mindful of time and make sure that we’re actually covering the lesson materials so that my attendees get value from my course! So I designed these mechanics with this balance in mind.
However, one thing I did as a workshop trainer that I would never usually do as a DM is to review at the end of each quarter and try to explain lessons to them as a result of what they’d done so far. This had the effect of keeping them on track with the course materials, as well as making sure there were opportunities for learning even if the group was getting sidetracked in the game.
Everyone is Alex
The biggest challenge was managing a group of 13 players who were all there for the experience of being a test manager. Typical D&D games run with a group of 4-6 players. More than that becomes a bit difficult to manage. I was worried that not every attendee would have a chance to play the game, and only one of them would be able to experience being the hero.
I did a bit of research and there’s a game called “Everyone is John” where every player plays the same character. One player gets to control John, and the others are voices in John’s head vying for control. They gain control with successful dice rolls. I decided to use this idea but to give everyone an equal chance I let everyone take control of the main character (Alex) for 15 minutes each (I know it says 10 in the slide – I changed my mind). That person would be the decision maker. Everyone else could suggest things but that person had the final say on what the main character would do. That person was also in charge of dice rolls.
Even with this game mechanic, I still didn’t feel like the format would fit a group much bigger than 10. I optimistically capped the attendee limit at 12.
Setting it up
I divided the game into four parts, each part representing one quarter of the business year. Each quarter had a theme and a major lesson to be learned.
I handed out the same character sheets to every player – Alex (main protagonist), and two team members. Each player also received an organisational chart. The character sheets listed a description of the character, a list of skills and their values, any current quests, and some items in an inventory.
Each table had a collection of silly hats. The rule was that whoever was the main character had to wear a silly hat for the 15 minutes that they were in charge of Alex. That showed everyone who was in charge, and I hope also reminded the players not to take it too seriously and try some risky things that they may not ordinarily try in their real workplace.
On an overhead projector I showed slides representing non-player characters that they encountered during the game. I had three decks – a main set of slides for the main story, an NPC deck for every character in the game, and an encounter deck for random encounters. It was pretty easy for me to switch among these depending on where the game took us.
There was a big flip chart for us to write on, which ended up becoming very important.
How it went
It was awesome. It sold out!
Right from the start, the group was really engaged and involved with the story. There were naturally some louder voices in the room, but rotating the decision maker meant that everybody got a turn to have a say. Even if the louder folks were still suggesting things during someone else’s turn, sometimes when I deferred back to the decision maker they would just say “No. We’re doing it this way.” and that would be that! It was great to see this happening in such a large group.
The situations were familiar enough that the group was able to understand them, but the problems were different enough that the group still had to think hard about them. I tried to make consequences as realistic as possible, drawing on my own breadth of experiences.
One thing that really took me by surprise was the sheer amount of natural 20’s that were rolled. In two years of playing D&D I have never seen so many natural 20’s. But hey, you have to respect the roll! So at one point in the game the group managed to implement a whole CI system in an afternoon. :)
The dice rolls really added a sense of chance and excitement to the game. There were gasps and cheers when the d20 results were rolled. It was awesome to see everyone so emotionally invested in the gameplay.
Another great sign was that the group was still discussing how to solve the problems when lunch was called, to the point where I had to shoo them out of the room and remind them to eat!
At the end we wrapped up by reflecting on the lessons learned. What was interesting for me as a trainer was that by simulating these experiences, they learned even more lessons than I intended because there were lessons in those experiences that I’d forgotten were there.
Last Saturday I attended DDD Brisbane (Developers, Developers, Developers!) and it was awesome. It was my first time attending this conference (thanks to Emvious), and my first time attending any conference without speaking, organising, and/or hosting at it in years and years. I can’t actually remember the last time I did this. I vaguely remember a conference circa 2008 where I ended up having a massive monologue to a group of people in the breakout room anyway and someone asked “why aren’t you speaking at this conference” and I said, “Er…I don’t know? It DOES seem like I have a lot to say..”
Anyway, it meant I could just spend the whole day focusing on the talks so I decided to try making sketchnotes for the first time. People have made sketchnotes for some of my talks in the past and I’ve loved them! So I thought, this is an awesome way to give something back to the speakers, as well as giving the rest of the world some insight into the amazing talk that they missed.
If you don’t know what a sketchnote is, well, it’s exactly what it sounds like. It’s notes with sketches, basically. Think of it like a rough, on-the-fly infographic. You’ll get the idea when you see a few of them. There are many guides and courses out there to taking sketchnotes (Google it) and I was too lazy to read any of them. Some of them look amazing, and I’m glad that I didn’t look at any of those because it looks really intimidating. But I’ve seen some sketchnotes before so I got the gist, plus I’m an artist and a visual learner so how hard can it be?
My first-ever sketchnote was made early in the morning (I am not a morning person so 9am is early for me) before my coffee had time to kick in. So not only was it a little rough, but you can see the fast deterioration of my own self-confidence as the sketchnote progresses. At some point it ceased to be a visual representation of the talk I was watching and digressed into a disturbing output of the negative meta-analysis of my pre-caffeinated mind.
I felt really bad about these notes especially because I tried to draw Jessica at the top and I gave her one massive ear accidentally, then I tried to cover it up with hair and it looked really weird in the end. So I wrote an apology next to it and hoped for the best.
I think it was a good talk. If I’m honest, I couldn’t tell you for sure because I was too busy making a sketchnote. But I do remember being really impressed by Jessica’s mis-matching unicorn socks and her hand-written visuals in her talk. Super points for style.
This went a lot better. I decided that circles are too hard to draw so I drew boxes instead. Boxes rock. My brain also woke up and I really liked this talk! I love learning about psychology and UX. I think all the sketchnotes I’ve seen in the past just summarise the talk but don’t have any of the noter’s own opinions in the notes. This seems weird to me, because they’re still my notes – if I just wanted a summary of the talk I could probably refer to the slides. Capturing my experience as a listener seems like an important part of note-taking to me. So I tried to keep a bit of that in my notes.
I noted a lot of terms that I want to look up later for my own interest, and I also noted down a couple of books I’ve read that relate strongly to the content of this talk:
By this point I was starting to feel faster and more comfortable taking notes but I still felt like I was missing bits of the talk because I had to shift focus back to making my sketchnotes prettier now and again. I do think these notes look great, and adding little whales and other pictures made it look cool. The flow-diagram style was pretty easy for me to use so I kept using that in the following talks.
I liked this talk because I have worked with teams that use Docker effectively but I have never had to set it up myself. It’s interesting to see what that journey is like. It’s also massively validating to see someone as experienced as Damian having the typical frustrations involved in setting up this kind of infrastructure.
I came in late to Larene’s talk because I got caught up talking to someone in the hallway between sessions. I worry a bit that with sketchnotes, if I miss or misinterpret something then I’m misrepresenting the speaker’s talk on social media. But I think I did okay because when I came in Larene was explaining her weekly meetup feed in Slack, which is something I’m already familiar with.
I like the simplicity of this sketchnote. Instead of trying to capture every little thing in the talk, I just went for the points that I thought were most impactful to me. I also waited towards the end to add more pictures, instead of trying to do it during the main part of the talk, and I think that helped me focus on the talk itself.
I really loved that this talk was merging technical skill with diversity goals, and I thought it was so great to see that the room was full for a diversity talk. The audience was really engaged with the content, and the advice in the talk was really practical.
At this point I really felt like I was getting the hang of this whole sketchnoting thing. I was leaving enough room for adding new elements, and I had a good feel for how to use the space for a half hour talk. By leaving more space around the elements I added, I could come back later and organise them a little better too with borders and titles.
There were some good points made about feedback which I hadn’t heard before, but some of the advice reminded me of the book Radical Candor. It was a good reminder to me to finish reading this book.
Sammy’s talk was really great because she’s a professional expert in recruiting women in tech, so it was great to see her answers to really common questions on this topic. As a woman, I get asked these types of questions all the time as if I should be an expert myself just because of my gender. And after a while I start to think maybe I *should* be an expert because everyone treats me like one. But seeing a talk like this reminds me that there are real experts out there who have put in a lot of work to get statistics and studies and other evidence, and it’s really good to know who that I can refer future questioners to her work when they have a question again.
This one’s gone back to a simple style, and I think a lot of the reason for that is because I already knew a lot of the content of the talk so it didn’t compel me to take a lot of detailed notes. I think that’s a really interesting part of sketchnoting – you’re seeing the talk through the sketchnoter’s eyes so someone with less experience in the topic might end up taking many more notes and gaining more insights than someone who’s been working in the field for a long time. But then, maybe the more experienced folks can bring more interesting perspective to their notes by adding their own meta-insights rather than just transcribing the content of the talk? Something to think about.
This was Jamie’s first-ever talk and she did really well. I could see that the developers in the room were interested in what she had to say, and she presented her tips for designing in a way that was easy to digest. I liked her big message on focusing on the user experience and I’d like to see her give another talk where she just gives repeated examples on starting from there and following through to design insights.
There was actually a lot of content in this talk which isn’t captured fully here because Joseph went into a lot of detail about systems 1 & 2 styles of thinking, which is information captured in the book Thinking Fast & Slow. As I’ve read this book, I just kind of summed up the high level bits of it with a nod to the book title since I know I can always find more information by reading the book again. Once again, notes that are mainly only valuable to me! Perhaps I should have explicitly called that out in the notes.
After this talk I had a really bizarre conversation with some of the attendees about whether or not the human race was still evolving. I tried to refer them to the evidence presented in Sapiens: A Brief History of Humankind, but they insisted they had their own opinions based on evidence such as which finger millennials use to push the elevator. Perhaps we were all just tired and hungry at the end of the day. Let’s go with that.
This last lot of notes was a real mess because I was tired, hungry, in pain (I was suffering from awful neck and shoulder pain the entire day) and the talk was one of the most technically in-depth talks of the day. So I was finding it really hard to follow. I’m pretty sure the talk was about agile practices and continuous delivery but you wouldn’t know it at all from my notes. I could have just given up on sketchnotes for the day but I thought it would be fun to try to capture my mental process at that point in time for artistic and humour reasons.
Essentially I just ended up apologising profusely. And no, I didn’t win a prize.
Reflections on sketchnoting
Like any skill, sketchnoting was tricky at first but became easier with practice. I would definitely do it again because it’s fun and I think in the end it actually helped me focus on and retain the information from the talks I watched. I think next time I will try to be more true to my actual thoughts and insights from the talk rather than trying to capture all of the information for other people to see. That sounds more interesting to me.
I might use a nicer pen next time too, like a gel ink pen or even a thin felt tip. Pencil might be good too. I think it would be really tricky to use multiple colours without a desk available, and it would take my focus off the talk.
Reflections on DDD Brisbane
I’ll definitely be back for DDD Brisbane next year if I can get a ticket! They sell out lightning-fast, and this year the only reason I was able to attend was thanks to Emvious – a community for women in STEM. I was awarded a ticket from their pool reserved for underrepresented folks in tech and I really appreciated this opportunity.
I was really impressed by the amount of women both speaking and attending this conference, and it was clear that the organisers had done a lot of work to get this to happen. One of the things they did was a gender-blind program (instead of writing “Vanessa Love” they would write “V. Love” so it’s harder to tell the gender of the speaker). One male attendee later tweeted that he was happy to say that he ended up watching 100% female talks by the end of the day, purely by choosing by topic!
Another thing that impressed me was the efforts in environmentalism. All of the plates, cups and cutlery were compostable and there were compost and recycling bins around everywhere. The swag bags were really cool – they were all handmade from cloth scraps and each one looked unique. There was a prize draw for anyone who brought a keep cup instead of using a disposable coffee cup. Lanyards were collected for reuse at the end of the day.
Lastly, the software developer community itself was really great. The talks were mostly voted-in and it was awesome to see so many talks that made it through on topics like diversity and design. I’ve been hanging out with this crowd on Slack for a couple of years now and for the most part have found it to be a really welcoming and friendly community.
This November I’ll be in Potsdam, Germany to give a keynote and a workshop for Agile Testing Days. I’ve never been to Agile Testing Days before but I’ve heard it’s awesome so I’m really excited. Last year they had about 400 attendees of which a quarter were speakers! The speaker lineup this year looks just as huge and just as great. I am really looking forward to meeting some of these people who I have only ever spoken to online, as well as catch up with some amazing testers who I have not seen in person in quite a while now.
Agile Testing Days is also setting a great example for other conferences by having a healthy percentage of female speakers – over half the keynoters are women this year! So don’t listen to anyone who says it’s impossible to do.
I will be giving a keynote called Transparency: A holistic approach to software quality. This is a concept I’ve been mulling over for about 5 years now and I’ve been using this model in my training work to teach testers how to successfully analyze and improve software projects. I have found that using this model gives testers a new perspective on their work and opens up many new directions for their work.
The workshop I am running is called Build a super testing team and it’s designed for managers and team leads. A common problem I find is that nobody outside of a testing team understands the value of the testing team. This makes it difficult to negotiate resources, time and headcount for your team. Testers often find themselves constantly justifying their own roles, and being held accountable to dangerous metrics. In the past I have taken undervalued teams and built them a solid reputation for results that other managers understood and respected. In this workshop I will teach you how to do the same in your own workplace.
As this involves many people skills, the practical exercises I have devised will be done in the form of a fun Dungeons & Dragons game – no prior experience necessary. :)
Register now for my one-day tutorial and my Tuesday keynote.
Interested in hearing me talk about test automation, test management and more? Well, it’s your lucky week!
Listen to me chat about all things software testing with Gem Hill on the “Let’s talk about tests, baby” podcast. This episode is called Testers are the canary down the coalmine. I had so much fun chatting to Gem, especially about tester roles, skills and strengths within a development team.
If video is more your thing, check out my “Ask me anything” session hosted by the delightful Simon Tomes for the Ministry of Testing Dojo. I logged on at 6am to answer community questions about test management. We had about 320 people log on to the live webinar where I answered the questions with the most votes. There were some really great questions and we even powered through the slight technical difficulties. #bugmagnet
If you’ve got a spare 15 minutes, do fill out Practitest’s#StateofTesting survey. It provides useful data for the software testing industry and the results are always interesting. It’s a great reference for talks and blog posts too, when you need to cite evidence of current trends.