Building a testing community of practice

I’m a regular visitor to China where Quest has a large R&D facility in Zhuhai in the Guangdong province. My responsibility extends to a group of 50-60 testing-related people in that office and so there is always something new and interesting going on, whether I’m “on site” or working with the teams remotely.

Many of these testers were lucky enough last year to attend three days of training in their office with Rob Sabourin and his infectious enthusiasm immediately paid great dividends across the group. One of the excellent side-effects of bringing testers from different teams together for the training was their realization of the benefits of sharing knowledge between each other. The teams are all working in a Scrum style with testers embedded into teams and this had resulted in the common problem of a lack of knowledge sharing around testing practice.

Striking while that iron was hot, I decided to establish a Testing Guild, essentially a community of practice around testing for the people in this group. Thanks to great local management support, this initiative got going quickly and the Guild now meets every two weeks to discuss and share knowledge around testing. They are documenting their meetings and discussions so I get a feel for what’s going on – but the Testing Guild really belongs to them and they set the direction. I occasionally act as “guest speaker” and will of course participate when I’m in the office.

After the Testing Guild had been running for a few months (based on some initial ideas I had – inspired by the so-called Spotify Model – and local management input), I thought it would be wise to learn more about how others recommend building such communities of practice. For no other reason than it looked like exactly the kind of content I was after, I bought the succinct (70-page A5) Building Successful Communities of Practice book by Emily Webber, an Agile consultant and coach from the UK.

The reasons that Emily cites for having a community of practice closely match with my intentions, viz. sharing knowledge & building better practice, breaking down organisational silos, accelerating professional development across the organisation, happier & more motivated people, and hiring & building a better team. Obviously some of these reasons are longer-term benefits but I believe we’re already seeing some of these benefits in our Testing Guild.

She also covers the different stages of development of such a community, how to create the right environment for it and some different models of leadership. Emily discusses how to work out who belongs to the community – in our case, this was very straightforward and we decided that everyone with a testing-related role in our part of the organisation should be part of the Testing Guild.

She discusses becoming a community, getting value from it, using the community to identify skills gaps in its members, growing the community and making it self-sustaining. The idea of using the Testing Guild to identify skills gaps wasn’t something I’d thought about and this will be a useful takeaway from this book. Emily packs a fair bit of content into a small book and it’s good general advice about how to build a community of practice with some first person experience of how to make them successful. Most of the content helped reinforce that we’re basically on the right track with what we’re doing in the Testing Guild in Zhuhai.

I’m looking forward to my next trip to China soon to experience the Testing Guild firsthand and actively contribute to one of their sessions while I have the chance. It will be interesting to see how it develops and changes over time too, certainly worthy of a future blog post!


2017 in review

It really is that time again as another year comes to a close and I take some time to look back on 2017.

In terms of this blog, I wrote 22 posts in 2017, coincidentally exactly the same as 2016! This remains well in excess of my (internal) target cadence of one post per month and my blogging was much more regular in 2017. The stats indicate that Twitter was again the main driver of traffic to my blog and it received about the same number of views in 2017 as in 2016, so if there are topics you’d like to see me talking about here (especially to encourage new readers), please let me know.


I made it to four conferences during the year: two specialized testing conferences and two agile-ish ones, and I presented at two of these four.

My first conference of 2017 came in February with the Association for Software Testing‘s first conference outside North America, in the shape of CASTx17 in Sydney. This was a good testing conference and was successful enough for the AST to bring their conference back to Australia in 2018, more on that below! A review of this conference appears in a previous blog post.

It was another trip to Sydney for my next conference in June, the enormous Agile Australia event. There was no testing-related content in sight here, but there were some decent talks (especially the keynotes) that made it worth enduring the mass commercialism of this conference. I blogged about my experience of attending Agile Australia here.

My first speaking gig of the year came at the end of June, co-presenting with Paul Seaman at the LAST (Lean, Agile, Systems Thinking) conference in Melbourne. This community-focused event had a massive range of speakers and talks over two days and it was a good chance to share our story of building and running a software testing training course for young adults on the autism spectrum (much more on this to come below). It was an enjoyable gig and marked the first time I’d co-presented, so also served as handy presentation experience (see a previous blog post for details).

My last conference of the year in August provided my second speaking gig, at the AST’s main event, CAST held in Nashville. This small conference was very enjoyable to attend, with a lot of great talks from people with an interest in context-driven testing. My talk – A Day in the Life of a Test Architect – went well with a very active “open season” of questioning following my presentation. It was also great to catch up with so many familiar faces including my mentor, Rob Sabourin, and the chance to explore this part of the US some more after the conference was too good an opportunity to miss (including experiencing the total solar eclipse from the Great Smoky Mountains national park). My experience report of attending and presenting at CAST previously appeared on this blog.

I only made it to one testing meetup during the year, that being the Sydney Testers event held around CASTx17. This well-attended meetup was a great experience and the large membership base of this meetup group continues to reflect a vibrant testing community in Sydney.

Work stuff

It’s been a good year following the sale of the Dell Software group to Francisco Partners. We’re back under the name of Quest and our first year as a standalone company has gone well with my role thankfully not really changing as a result, so I’m still lucky enough to get to work with some amazing people all around the globe. Our big pockets of testers continue to be in China and the Czech Republic with a few others in the US and Australia. I expect to visit most of our overseas offices during 2018, having only been to the Zhuhai (China) office once in 2017.

Community work

My community efforts through 2017 were all directed to a new venture, offering software testing training to young adults on the autism spectrum with the help of the not-for-profit disability organization, EPIC Assist. Together with Paul Seaman, we have built the EPIC TestAbility Academy and completed our first run of the 12-week course. It’s been an incredibly rewarding experience, with a lot of learning opportunities both for us as presenters and the students on the course.  We both give our time for free and it’s nice to give back and share our knowledge in the hope of securing meaningful employment for some of these young people. We’re also looking forward to running the course again, starting early in 2018. The programme has received a lot of interest and Paul & I have been happy to present about it at the LAST conference, within the offices of Seek and Locomote, and also at an ANZTB SiGIST event.

Other stuff

My community work on the EPIC TestAbility Academy led to a couple of co-authored articles with Paul Seaman during the year. The first appeared in Women Testers magazine and the second in Testing Trapeze magazine, so thanks to these two publications for the opportunity to share our story with the broader software testing community.

In May, I was offered the chance to be Program Chair for the AST’s second conference in Australia, CASTx18 in Melbourne. I was very happy to accept their invitation and it’s been a busy few months organizing the call for papers and ultimately selecting a programme from the submissions we received. I announced the programme in November and it’s an excellent collection of local and international talent, all headed to Melbourne for the event running on February 28 and March 1 at the Langham Hotel on Southbank – I hope to see some of you there!

It’s been a busy year professionally and no doubt 2018 has some exciting opportunities in store. In the meantime, I wish you all a very Happy New Year and hope you enjoy my posts to come through 2018.

The CASTx18 conference programme is live!

Back in May, I was asked by the Association for Software Testing to be the Program Chair for CASTx18 in Melbourne and it’s been a busy six months or so since then in getting to the point where the full line-up for this conference is now live.

After coming up with a theme with an Australian bent – “Testing in the Spirit of Burke & Wills” – it was exciting to open up the call for proposals and then watch the proposals trickling in, that trickle turning into a fast-flowing river as the CFP closing date approached!

The response to the CFP was very pleasing, with a broad range of proposals from all over the world, from first-time presenters to some very seasoned campaigners. My thanks go to everyone who took the time and effort to put forward a proposal.

Helped by my Assistant Program Chair, Paul Seaman, it was a time-consuming process to select content to fill just eight track session slots available on the conference day. It was always our intention to provide a balanced & diverse programme and hopefully we’ve achieved that:

  • The tracks cover a broad range of topics – from automation to working as a lone tester, from continuous delivery to running bug bashes.
  • We have a brand new voice, Monica Diaz, giving her first conference talk as a result of opening up a track session slot to the Speak Easy programme (for which I am also a volunteer).
  • Across the conference day line-up, we have 4 female speakers and 5 male.
  • It’s a truly international menu, with speakers from Australia, New Zealand, Canada and the UK.

It gives me great pride to announce our complete line-up, as follows:

Keynotes (March 1st)

Tracks (March 1st)

  • Adam Howard with “Automated agility!? Let’s talk truly agile testing”
  • James Espie with “Community whack-a-mole! Bug bashes, why they’re great and how to run them effectively”
  • Monica Diaz with “Evolution of Testing”
  • Kim Engel with “Journey to continuous delivery”
  • Paul Holland with “Creativity, Imagination, and Creating Better Test Ideas” (workshop)
  • Nicola West with “How I Got Rid of Test Cases”
  • Peter Bartlett with “Flying the Flag for Quality as a 1-Man-Band”



Tutorials (February 28th)

For more details about CASTx18, including the full schedule and the chance to benefit from significant discounts during the “early bird” period of registration, visit

Thanks again to the AST for the trust they’ve placed in me to build the programme and hopefully what’s on offer is not only appealing to a wide audience of testers & others but also adds to the legacy of great CAST conferences.

I hope to see you in Melbourne next year!

“A Practical Guide to Testing in DevOps” (Katrina Clokie)

I was excited to learn that well-known New Zealand tester, Katrina Clokie, had decided to write a book. Her popular blog, Katrina The Tester, already provided plenty of evidence of her ability to write clearly across a broad range of topics of interest to the testing community and so I had high expectations of her book, A Practical Guide to Testing in DevOps (released through Leanpub).

The book starts off with an overview of what DevOps is (and isn’t), along with some opening thoughts around where testing fits into a DevOps culture. The next couple of chapters compare and contrast testing in development with testing in production. While those of us who’ve been in software testing for a decade or more will have been schooled to think of testing in production as a huge “no no”, the move to DevOps (along with the new engineering around it that makes excellent alerting, monitoring and rollback possible) means we need to think differently. Katrina does a great job of balancing how testing can add value during development (highlighting the importance of automation but also the high value of human exploration) and what good testing in production also looks like. This was highly useful content for me and I liked the way she introduced the concepts of A/B testing, beta testing and monitoring in production as actually being “test practices” and the risk mitigation (“exposure control”) that can come from ideas such as staged rollouts and dark launching.

The next chapter focuses on test environments, looking at the way platforms have evolved and the use of infrastructure as code, configuration management, containers and cloud. Katrina offers advice on test practices around these environments and I liked the idea of testing the infrastructure as being a part of the overall test effort in a DevOps environment (and this was something I hadn’t read about anywhere else).

A highlight chapter for me comes next in the shape of seven industry examples. Real world examples are a good way to set context and there are a broad range of industries and project types reflected here. Each case study is short but focuses on just one aspect of their DevOps journey, e.g. A/B testing or using Docker.

Just when I thought this book had peaked in its content and usefulness, the final chapter – “Test Strategy in DevOps” – proved me wrong! There is some directly applicable material in here for anyone who is currently facing the challenge of defining test strategy in a DevOps environment. The section on rethinking the test pyramid is particularly noteworthy I think, presenting the idea of a “DevOps Bug Filter”, a simple graphical representation of the way in which bugs might find their way through our various levels of testing. This looks like a very simple but effective way to communicate around a test strategy in a DevOps environment and I certainly intend to make use of it!

In her preface, Katrina says:

This book is for testers who want to understand DevOps and what it means for their role. It’s also for people in other roles who want to know more about how testing fits into a DevOps model. I hope to encourage people to explore the opportunities for testing in DevOps, and to become curious about how they might approach quality in a different way.

She’s achieved this mission, but also so much more in my opinion. This book offers so much practical content, much of which I feel is applicable to a wide variety of software development projects and not just those “doing DevOps” – I actually see it as more of a manual for what software testing looks like in the modern world.

Katrina’s book is a steal at the suggested Leanpub price of $15 (and, to her credit, she is also making it available for free), a worthy new addition to the essential toolkit for anyone involved in software development and testing.

(A quick plug for the CASTx18 conference coming in Melbourne early in 2018 (for which I’m Program Chair), Katrina is both a keynote speaker and a tutorial presenter so this conference offers a great opportunity to hear more from her.)

“Mindset: The New Psychology of Success” (Carol S. Dweck)

The second of my recent airport bookshop purchases has made for an excellent read over the last week. In Mindset: The New Psychology of Success, Carol Dweck explores the influence that the way we think about our talents and abilities has on our success.

The key concept here is that of the “growth mindset”, as compared to a “fixed mindset”. A fixed mindset is “believing that your qualities are carved in stone… [and] creates an urgency to prove yourself over and over” while a growth mindset is “based on the belief that your basic qualities are things you can cultivate through your efforts, your strategies, and help from others…. [and] everyone can change and grow through application and experience”.  She notes that all of us have elements of both mindsets.

She notes that a “fixed mindset makes people into non-learners” and, while failure still can be painful with a growth mindset, “it doesn’t define you; it’s a problem to be faced, dealt with and learned from”. I liked this question as a way to think about growth vs. fixed mindsets: “Is success about learning – or proving you’re smart?”

The role of effort in the growth mindset is highlighted throughout the book:

The fixed mindset limits achievement. It fills people’s minds with interfering thoughts, it makes effort disagreeable, and it leads to inferior learning strategies. What’s more, it makes other people into judges instead of allies. Whether we’re talking about Darwin or college students, important achievements require clear focus, all-out effort, and a bottomless trunk full of strategies. Plus allies in learning. This is what the growth mindset gives people, and that’s why it helps their abilities grow and bear fruit.

It’s an interesting section of the book when Carol moves away from the individual to the organizational level:

Clearly the leader of an organization can hold a fixed or growth mindset, but can an organization as whole have a mindset? Can it have a pervasive belief that talent is just fixed or, instead, a pervasive belief that talent can be and should be developed in all employees? And, if so, what impact will this have on the organization and its employees?

She goes on to cite some research in this area:

People who work in growth-mindset organizations have far more trust in their company and a much greater sense of empowerment, ownership, and commitment… Those who worked in fixed-mindset companies, however, expressed greater interest in leaving their company for another… employees in the growth-mindset companies say that their organization supports (reasonable) risk-taking, innovation, and creativity… Employees in the fixed-mindset companies not only say that their companies are less likely to support them in risk-taking and innovation, they are also far more likely to agree that their organizations are rife with cutthroat or unethical behavior.

A reference to an excellent diagram by Nigel Holmes is a handy summary of the messages in this book:

Fixed compared to Growth mindset (thanks to Nigel Holmes)

This is a book with great messages and is of broad interest. Carol cites lots of research to back her claims and the book is made very readable thanks to the excellent examples from the business world, school, and sport.

Thinking about the book’s key message around the growth mindset in the context of software testing, it strikes me that much of the testing industry is actually stuck in a fixed mindset and the benefits of continuous learning and growth are not as valued as they could be. The idea of certifications in testing doesn’t help with this (although you could argue there is learning involved in attaining them), especially when you can take an exam to become an “Expert” level tester.

It’s personally very rewarding to be active in a part of the testing community that does genuinely value learning and growth (that’s the context-driven testing community) and where having “a bottomless trunk full of strategies [and] allies in learning” are the norm.

“Changing Times – Quality for Humans in a Digital Age” (Rich Rogers)

It’s always good to see someone from our community of software testers taking the plunge to write their first book, as Rich Rogers has recently done with “Changing Times – Quality for Humans in a Digital Age” (available in both paperback and electronic formats).

The book is written in an easy to read style, with a story about a journalist called Kim running throughout. Her daily engagements with technology – as both positive and negative experiences – are described as she goes about her work and personal life. The story line makes it very easy to relate to the topics and Rich follows each chapter of her story with an exploration of its themes around quality and technology. It is these regular dives into the quality aspects of Kim’s experiences that makes his narrative so engaging and easy to consume.

Rich uses a model called the “Three Dimensions of Quality” and illustrates each dimension again by reference to Kim’s experiences. The three dimensions are Desirable, Dependable and Durable and he identifies a number of aspects within each dimension for further exploration (for example, “Dependable” is broken down into accurate, available, clear, private, protected, reactive, stable and tolerant).

For testers, I think this is a worthwhile read as it draws everything back to thinking about quality. But the book makes for a very enjoyable read for a much broader audience, from those with no real experience of the “nuts and bolts” of producing IT systems to anyone with an interest in “quality” and how we can improve it in the software we help to build. Well done, Rich!

The No Asshole Rule (Robert Sutton)

One of the few joys of long haul travel for business is time to browse that staple of airports everywhere, the bookshop. During a few hour stopover at Dallas Fort Worth airport recently, a couple of new paperbacks ended up in my hand luggage ready to help with the sixteen hour flight back to Australia. Though neither of the books actually made an appearance during the flight, I’ve managed to get through one of them since I got home, in the shape of The No Asshole Rule by Robert Sutton.

The author makes a distinction between “temporary assholes ” (people who are having a bad day or a bad moment) and “certified assholes” (persistently nasty and destructive jerks) and details the kinds of behaviours and damage done by them (not only to their direct victims, but also to bystanders, themselves and their organizations). He recommends implementing a “no asshole” rule and enforcing it, by “linking big policies to small decencies” (e.g. hiring and firing policies).

Tips for surviving nasty people and workplaces are also provided here: look for small wins, limit exposure, build pockets of safety, support & sanity, and fight & win the right small battles.

Robert also acknowledges the virtues of assholes, with Steve Jobs being used as a classic example of motivating fear-driven performance and perfectionism. These virtues are dangerous though given that the “weight of evidence shows that assholes, especially certified assholes, do far more harm than good”.

He also encourages us to look at ourselves and encourages us to find ways to “stop your “inner jerk” getting out”. I liked this mantra: “be slow to label others as assholes, but quick to label yourself”.

A couple of quotes sum up most of what this book is all about for me:

We all die in the end, and despite whatever “rational” virtues assholes may enjoy, I prefer to avoid spending my days working with mean-spirited jerks and will continue to question why so many of us tolerate, justify, and glorify so much demeaning behaviour from so many people

We are all given only so many hours here on Earth. Wouldn’t it be wonderful if we could travel through our lives without encountering people who bring us down with their demeaning remarks and actions?

This book is aimed at weeding out those folks and at teaching them when they stripped others of their esteem and dignity. If you are truly tired of living in Jerk City – if you don’t want every day to feel like a walk down Asshole Avenue – well, it’s your job to help build and shape a civilized workplace. Sure, you already know that. But isn’t it time to do something about it?

I’ve only worked for two employers in my twenty-odd years in the IT business and, after having read some of the stories in this book, I consider myself pretty lucky not to have encountered too much in the way of asshole behaviour. There have been a number of “temporary assholes” along the way, but I can only think of two “certified assholes” that have unfortunately crossed my path.

One was a manager who definitely went on the certification course and was only removed after a group of people were brave enough to “out” their awful behaviour (sadly, this person continues to be a people manager in a different company.) The other was a developer on a team for which I was the only tester and he let it be known that if I raised another bug against his work, he’d be waiting for me in the car park to exact his revenge. At the time, this was both amusing and of course somewhat frightening – and management did a good job of making sure he wasn’t with us too much longer.

While my own experiences are overwhelmingly positive in the IT industry, it’s obvious that many people (especially females) have a really hard time and at least some of the terrible behaviours are being publicly called out (e.g. the recent Uber stories). Closer to home, my good friend Paul Seaman recently wrote a blog post, The Standard You Walk Past , in which he clearly details the actions of what Sutton would deem a “certified asshole”.

We all deserve a safe and comfortable workplace, so it’s contingent on us to call out asshole behaviour whenever we see it (and that includes anyone who works with me!). This simple statement from the book says it all: “treat the person right in front of you, right now, in the right way”. That’s something we can all do to help make our workplaces and the world at large just that little bit better for everyone.