Category Archives: Uncategorized

“Turn the Ship Around!” (L. David Marquet)

After seeing a number of positive reviews and recommendations for this book, I asked the Melbourne Library Service to procure a copy – they agreed and I’ve recently enjoyed reading the fruits of their investment.

Marquet is a former nuclear submarine commander and the book details his moves to change the leadership on a poorly-performing submarine from leader-follower to what he calls “leader-leader”.

He starts out by describing what leadership meant in the (US) Navy, quoting from the “Naval Academy leadership book”:

Leadership is the art, science, or gift by which a person is enabled or privileged to direct the thoughts, plans, and actions of others in such a manner as to obtain and command their obedience, their confidence, their respect, and their loyal co-operation

As he points out “leadership in the Navy, and in most organizations, is about controlling people. It divides the world into two groups of people: leaders and followers.” His solution to the leader-follower pattern is the leader-leader model:

The leader-leader structure is fundamentally different from the leader-follower structure. At its core is the belief that we can all be leaders and, in fact, it’s best when we are all leaders. Leadership is not some mystical quality that some possess and others do not. As humans, we all have what it takes, and we all need to use our leadership abilities in every aspect of our work life.

The leader-leader model not only achieves great improvements in effectiveness and morale, but also makes the organization stronger. Most critically, these improvements are enduring, decoupled from the leader’s personality and presence. Leader-leader structures are significantly more resilient, and they do not rely on the designated leader always being right. Further, leader-leader structures spawn additional leaders throughout the organization naturally. It can’t be stopped.

Marquet details his journey of building the leader-leader model during his time turning around the flagging fortunes of the Sante Fe submarine. His passion, guts and honesty in making the changes he did shine through the narrative and results in a really simple but powerful model for changing the way we view leadership in organizations.

He argues that “the core of the leader-leader model is giving employees control over what they work on and how they work. It means letting them make meaningful decisions. The two enabling pillars are competency and clarity.”

One of the first things Marquet noticed on joining the Santa Fe was their focus on avoiding mistakes:

What happened with Santa Fe…was that the crew was becoming gun-shy about making mistakes. The best way not to make a mistake is not to do anything or make any decisions. It dawned on me the day I assumed command that focusing on avoiding errors is helpful for understanding the mechanics of procedures and detecting impending major problems before they occur, but it is a debilitating approach when adopted as the objective of an organization.

This observation led to his first mechanism for clarity: achieve excellence, don’t just avoid errors.

His discovery of the processes around signing off sailor’s leave led to his first mechanism for control: find the genetic code for control and rewrite it:

The first step in changing the genetic code of any organization or system is delegating control, or decision-making authority, as much as is comfortable, and then adding a pinch more. This isn’t an empowerment “program”. It’s changing the way the organization controls decisions in an enduring, personal way.

I like this idea of “Don’t move information to authority, move authority to information” in this area too.

The next control mechanism Marquet came up with was: act your way to new thinking:

When you’re trying to change employees’ behaviours, you have basically two approaches to choose from: change your own thinking and hope this leads to new behaviour, or change your behaviour and hope this leads to new thinking. On board Sante Fe, the officers and I did the latter, acting our way to new thinking.

The next control mechanism rings very true in software development, especially when adopting agile practices: have short early conversations to get efficient work:

Supervisors needed to recognize that the demand for perfect products the first time they see them results in significant waste and frustration throughout the entire organization. Even a thirty-second check early on could save your people numerous hours of work… a well-meaning yet erroneous translation of intent [could result] in a significant waste of resources.

In his mission to turn passive followers into active leaders, a “minor trick of language” turned into an effective means of control: use “I intend to…” Marquet would “avoid giving orders. Officers would state their intentions with “I intend to…” and I would say “Very well”. Then each man would execute his plan.” It turned out that this simple change “profoundly shifted ownership of the plan to the officers.”

Another control mechanism follows: resist the urge to provide solutions. This is a really hard habit to break and I’ve been working on this personally during my coaching and mentoring activities. I can see how it breaks down the leader-follower mentality, but it takes a deliberate effort to stop yourself from stepping in and solutionifying!

Marquet’s next control mechanism is: eliminating top-down monitoring systems:

Supervisors frequently bemoan the “lack of ownership” in their employees. When I observe what they do and what practices they have in their organization, I can see how they defeat any attempt to build ownership.

Worse, if they’ve voiced their frustrations out loud, their employees perceive them as hypocritical and they lose credibility. Don’t preach and hope for ownership; implement mechanisms that actually give ownership… Eliminating top-down monitoring systems will do it for you. I’m not talking about eliminating data collection and measuring processes that simply report conditions without judgement. Those are important as they “make the invisible visible”. What you want to avoid are the systems whereby senior personnel are determining what junior personnel should be doing.

More control follows in the shape of: think out loud:

When I heard what my watch officers were thinking, it made it much easier for me to keep my mouth shut and let them execute their plans. It was generally when they were quiet and I didn’t know what they would do next that I was tempted to step in. Thinking out loud is essential for making the leap from leader-follower to leader-leader.

Regular inspections were part of Navy life and Marquet and his crew decided to “be open and invite outside criticism”, in a control mechanism he calls: embrace the inspectors.

Embrace the inspectors can be viewed as a mechanism to enhance competence, but I think it fits even better in the discussion of control because it allowed us not only to be better submariners but also to maintain control of our destiny.

[It] also turned out to be an incredibly powerful vehicle for learning. Whenever an inspection team was on board, I would hear crew members saying things like, “I’ve been having a problem with this. What have you seen other ships do to solve it?” Most inspection teams found this attitude remarkable.

While Marquet started off by pushing decision making and control to lower and lower levels in the organization, he found that control by itself was not enough and he also needed to bolster the technical competence of his crew if this approach was to be successful.

The first mechanism for competence he outlines is: take deliberate action. Following an incident where a circuit-breaker was mistakenly closed on the submarine, the idea of taking deliberate action arose following a postmortem:

“Well, he was just in auto. He didn’t engage his brain before he did what he did: he was just executing a procedure.”

I thought that was perspective. We discussed a mechanism for engaging your brain before acting. We decided that when operating a nuclear-powered submarine we wanted people to act deliberately, and we decided on “take deliberate action” as our mechanism. This meant prior to any action, the operator paused and vocalized and gestured toward what he was about to do, and only after taking a deliberate pause would he execute the action. Our intent was to eliminate those “automatic” mistakes. Since the goal of “take deliberate action” was to introduce deliberateness in the mind of the operator, it didn’t matter whether anyone was around or not. Deliberate actions were not performed for the benefit of an observer or an inspector. They weren’t for show.

This particular mechanism reminded me of the ideas in Daniel Kahneman’s “Thinking, Fast and Slow” book.

The next competence mechanism is easy to relate to: we learn (everywhere, all the time). Embedding the idea that everyone in an organization needs to be constantly learning is a very good thing, be it in a military setting like Marquet’s or a software engineering setting. I actually think folks in IT are generally on board with this idea due to the high rate of change in technology, programming languages, etc. and the popularity of IT-related meetup groups, for example, are an indicator of a willingness to continue learning outside of the scope of the day-to-day in the office.

His next mechanism for competence is: don’t brief, certify.

A briefing is a passive activity for everyone except the briefer. Everyone else “is briefed”. There is no responsibility for preparation or study. It’s easy to just nod and say “ready” without full intellectual engagement. Furthermore, the sole responsibility in participating in a brief is to show up. Finally, a brief, as such, is not a decision point. The operation is going to happen and we are simply talking about it first.

We decided to do away with briefs. From that point on we would do certifications.

A certification is different from a brief in that during a certification, the person in charge of his team asks them questions. At the end of the certification, a decision is made whether or not the team is ready to perform the upcoming operation. If the team has not demonstrated the necessary knowledge during the certification, the operation should be postponed.

Another competence mechanism is presented next: continually and consistently repeat the same message:

Repeat the same message, day after day, meeting after meeting, event after event. Sounds redundant, repetitive, and boring. But what’s the alternative? Changing the message? That results in confusion and a lack of direction. I didn’t realize the degree to which old habits die hard, even when people are emotionally on board with the change.

This mechanism is one I’ve employed frequently in coaching testers around the world and it’s surprisingly effective (I say “surprising” since it surprised me that it is both necessary and valuable to do it).

Marquet’s last competence mechanism is: specifying goals, not methods. This arose from a fire drill in which the team members followed a prescribed response but failed to extinguish the fire within the safe time limit:

…[now] the crew was motivated to devise the best approach to putting out the fire. Once they were freed from following a prescribed way of doing things, they came up with many ingenious ways to shave seconds off our response time [to fires].

The problem with specifying the method along with the goal is one of diminished control. Provide your people with the objective and let them figure out the method.

Lovers of “best practices” please take note!

The third and final set of mechanisms Marquet introduces are around clarity:

As more decision-making authority is pushed down the chain of command, it becomes increasingly important that everyone throughout the organization understands what the organization is about. This is called clarity.

Clarity means people at all levels of an organization clearly and completely understand what the organization is about. This is needed because people in the organization make decisions against a set of criteria that includes what the organization is trying to accomplish. If clarity of purpose is misunderstood, then the criteria by which a decision is made will be skewed, and suboptimal decisions will be made.

His first mechanism for clarity is: building trust and taking care of your people:

It’s hard to find a leadership book that doesn’t encourage us to “take care of our people”. What I learned is this: Taking care of your people does not mean protecting them from the consequences of their own behaviour. That’s the path to irresponsibility. What it does mean is giving them every available tool and advantage to achieve their aims in life, beyond the specifics of the job. In some cases that meant further education; in other cases crewmen’s goals were incompatible with Navy life and they separated on good terms.

The next mechanism for clarity is: use your legacy for inspiration. This one helped to provide organizational clarity, explaining the “why” for the crewmen’s service:

Many organizations have inspiring early starts and somehow “lose their way” at some later point. I urge you to tap into the sense of purpose and urgency that developed during those early days or during some crisis. The trick is to find real ways to keep those alive as the organization grows. One of the easiest ways is simply to talk about them. Embed them into your guiding principles and use those words in efficiency reports and personnel awards.

Another mechanism for clarity comes next: use guiding principles for decision criteria.

Leaders like to hang a list of guiding principles on office walls for display, but often those principles don’t become part of the fabric of the organization. Not on Santa Fe. We did several things to reinforce these principles and make them real to the crew. For example, when we wrote awards or evaluations, we tried to couch behaviours in the language of these principles. “Petty Office M exhibited Courage and Openness when reporting…

Most of you have organizational principles. Go out and ask the first three people you see what they are. I was at one organization that proudly displayed its motto in Latin. I asked everyone I saw what it meant. The only one who knew was the CEO. That’s not good.

I’ve personally seen these working well within Quest – we have a set of Core Values and we refer to them regularly at all levels of the organization.

Another mechanism for clarity is: use immediate recognition to reinforce desired behaviours. I really like this one, it’s simple but easy to forget to do:

When I say immediate recognition, I mean immediate. Not thirty days. Not thirty minutes. Immediate.

Look at your structures for awards. Are they limited? Do they pit some of your employees against others? That structure will result in competition at the lowest level. If what you want is collaboration, then you are destroying it.

A mechanism for organizational clarity comes next: begin with the end in mind.

As you work with individuals in your organization to develop their vision for the future, it is crucial that you establish specific, measurable goals. These goals will help the individuals realize their ambitions. In addition, you as a mentor have to establish that you are sincerely interested in the problems of the person you are mentoring. By taking action to support the individual, you will prove that you are indeed working in their best interest and always keeping the end in mind.

His final mechanism for clarity is: encourage a questioning attitude over blind obedience. He asks “Will your people follow an order that isn’t correct? Do you want obedience or effectiveness? Have you built a culture that embraces a questioning attitude?” Reinforcing that asking questions is a good idea is so important in what we do as software testers (I recently heard Nick Pass define “QA” as “Question Asker” during his talk at the TiCCA19 conference) and there are sometimes personality and cultural barriers to overcome in encouraging people to question (the latter I have much experience of while working with our teams in China).

In summary, Marquet’s set of mechanisms for Control, Competence and Clarity are as follows.

Control

  • Find the genetic code for control and rewrite it
  • Act your way to new thinking
  • Short, early conversations make efficient work
  • Use “I intend to…” to turn passive followers into active leaders
  • Resist the urge to provide solutions
  • Eliminate top-down monitoring systems
  • Think out loud (both superiors and sub-ordinates)
  • Embrace the inspectors

Competence

  • Take deliberate action
  • We learn (everywhere, all the time)
  • Don’t brief, certify
  • Continually and consistently repeat the message
  • Specify goals, not methods

Clarity

  • Achieve excellence, don’t just avoid errors
  • Build trust and take care of your people
  • Use your legacy for inspiration
  • Use guiding principles for decision criteria
  • Use immediate recognition to reinforce desired behaviours
  • Begin with the end in mind
  • Encourage a questioning attitude over blind obedience

There are so many useful takeaways in this book; it’s a short but engaging read and the direct applicability to the way we manage the people in software development projects is very clear – especially if you’re aiming for truly self-organizing agile teams!

I highly recommend reading Turn the Ship Around to anyone interested in genuinely empowering people in their teams.

Advertisements

Testing in Context Conference Australia 2019

The third annual conference of the Association for Software Testing (AST) outside of North America took place in Melbourne in the shape of Testing in Context Conference Australia 2019 (TiCCA19) on February 28 & March 1. The conference was held at the Jasper Hotel near the Queen Victoria Market.

The event drew a crowd of about 50, mainly from Australia and New Zealand but also with a decent international contingent (including a representative of the AST and a couple of testers all the way from Indonesia!).

I co-organized the event with Paul Seaman and the AST allowed us great freedom in how we put the conference together. We decided on the theme first, From Little Things Big Things Grow, and had a great response to our call for papers, resulting in what we thought was an awesome programme.

The Twitter hashtag for the event was #ticca19 and this was fairly active across the conference.

The event consisted of a first day of workshops followed by a single conference day formed of book-ending keynotes sandwiching one-hour track sessions. The track sessions were in typical AST/peer conference style, with around forty minutes for the presentation followed by around twenty minutes of “open season” (facilitated question and answer time, following the K-cards approach).

Takeaways

  • Testing is not dead, despite what you might hear on social media or from some automation tooling vendors. There is a vibrant community of skilled human testers who display immense value in their organizations. My hope is that these people will promote their skills more broadly and advocate for human involvement in producing great software.
  • Ben Simo’s keynote highlighted just how normalized bad software has become, we really can do better as a software industry and testers have a key role to play.
  • While “automation” is still a hot topic, I got a sense of a move back towards valuing the role of humans in producing quality software. This might not be too surprising given the event was a context-driven testing conference, but it’s still worth noting.
  • The delegation was quite small but the vibe was great and feedback incredibly positive (especially about the programme and the venue). There was evidence of genuine conferring happening all over the place, exactly what we aimed for!
  • It’s great to have a genuine context-driven testing conference on Australian soil and the AST are to be commended for continuing to back our event in Melbourne.
  • I had a tiring but rewarding experience in co-organizing this event with Paul, the testing community in Melbourne is a great place to be!

Workshop day (Thursday 28th February)

We offered two full-day workshops to kick the event off, with “Applied Exploratory Testing” presented by Toby Thompson (from Software Education) and “Leveraging the Power of API Testing” presented by Scott Miles. Both workshops went well and it was pleasing to see them being well attended. Feedback on both workshops has been excellent so well done to Toby and Scott on their big efforts in putting the workshops together and delivering them so professionally.

Toby Thompson setting up his ET workshopScott Miles ready to start his API testing workshop

Pre-conference meetup (Thursday 28th February)

We decided to hold a free meetup on the evening before the main conference day to offer the broader Melbourne testing community the chance to meet some of the speakers as well as hearing a great presentation and speaker panel session. Thanks to generous sponsorship, the meetup went really well, with a small but highly engaged audience – I’ve blogged in detail about the meetup at https://therockertester.wordpress.com/2019/03/04/pre-ticca19-conference-meetup/

Aaron Hodder addresses the meetupGraeme, Aaron, Sam and Ben talking testing during the panel session

Conference day (Friday 1st March)

The conference was kicked off at 8.30am with some opening remarks from me including an acknowledgement of traditional owners and calling out two students who we sponsored to attend from the EPIC TestAbility Academy. Next up was Ilari Henrik Aegerter (board member of the AST) who briefly explained what the AST’s mission is and what services and benefits membership provides, followed by Richard Robinson outlining the way “open season” would be facilitated after each track talk.

I then introduced our opening keynote, Ben Simo with “Is There A Problem Here?”. Ben joined us all the way from Phoenix, Arizona, and this was his first time in Australia so we were delighted to have him “premiere” at our conference! His 45-minute keynote showed us many cases where he has experienced problems when using systems & software in the real world – from Australian road signs to his experience of booking his flights with Qantas, from hotel booking sites to roadtrip/mapping applications, and of course covering his well-publicized work around Healthcare.gov some years ago. He encouraged us to move away from “pass/fail” to asking “is there a problem here?” and, while not expecting perfection, know that our systems and software can be better. A brief open season brought an excellent first session to a close.

Ben Simo during his keynote (photo from Lynne Cazaly)

After a short break, the conference split into two track sessions with delegates having the choice of “From Prototype to Product: Building a VR Testing Effort” with Nick Pass or “Tales of Fail – How I failed a Quality Coach role” with Samantha Connelly (who has blogged about her talk and also her TiCCA19 conference experience in general).

While Sam’s talk attracted the majority of the audience, I opted to spend an hour with Nick Pass as he gave an excellent experience report of his time over in the UK testing virtual reality headsets for DisplayLink. Nick was in a new country, working for a new company in a new domain and also working on a brand new product within that company. He outlined the many challenges including technical, physical (simulator sickness), processes (“sort of agile”) and personal (“I have no idea”). Due to the nature of the product, there were rapid functionality changes and lots of experimentation and prototyping. Nick said he viewed “QA” as “Question Asker” in this environment and he advocated a Quality Engineering approach focused on both product and process. Test design was emergent but, when they got their first customer (hTC), the move to productizing meant a tightening up of processes, more automated checks, stronger testing techniques and adoption of the LeSS framework. This was a good example of a well-crafted first-person experience report from Nick with a simple but effective deck to guide the way. His 40-minute talk was followed by a full open season with a lot of questions both around the cool VR product and his role in building a test discipline for it.

Nick Pass talks VR

Morning tea was a welcome break and was well catered by the Jasper, before tracks resumed in the shape of “Test Reporting in the Hallway” with Morris Nye and “The Automation Gum Tree” with Michelle Macdonald.

I joined Michelle – a self-confessed “automation enthusiast” – as she described her approach to automation for the Pronto ERP product using the metaphor of the Aussie gum tree (which meant some stunning visuals in her slide deck). Firstly, she set the scene – she has built an automated testing framework using Selenium and Appium to deal with the 50,000 screens, 2000 data objects and 27 modules across Pronto’s system. She talked about their “Old Gum”, a Rational Robot system to test their Win32 application which then matured to use TestComplete. Her “new species” needed to cover both web and device UIs, preferably be based on open source technologies, be easy for others to create scripts, and needed support. It was Selenium IDE as a first step and the resulting framework is seen as successful as it’s easy to install, everyone has access to use it, knowledge has been shared, and patience has paid off. The gum tree analogies came thick and fast as the talk progressed. She talked about Inhabitants, be they consumers, diggers or travellers, then the need to sometimes burn off (throw away and start again), using the shade (developers working in feature branches) and controlling the giants (all too easy for automation to get too big and out of control). Michelle had a little too much content and her facilitator had to wrap her up at 50 minutes into the session so we had time for some questions during open season. There were some sound ideas in Michelle’s talk and she delivered it with passion, supported by the best-looking deck of the conference.

A sample of the beautiful slides in Michelle's talk

Lunch was a chance to relax over nice food and it was great to see people genuinely conferring over the content from the morning’s sessions. The hour passed quickly before delegates reconvened for another two track sessions.

First up for the afternoon was a choice between “Old Dog, New Tricks: How Traditional Testers Can Embrace Code” with Graeme Harvey and “The Uncertain Future of Non-Technical Testing” with Aaron Hodder.

I chose Aaron’s talk and he started off by challenging us as to what “technical” meant (and, as a large group, we failed to reach a consensus) as well as what “testing” meant. He gave his idea of what “non-technical testing” means: manually writing test scripts in English and a person executing them, while “technical testing” means: manually writing test scripts in Java and a machine executing them! He talked about the modern development environment and what he termed “inadvertent algorithmic cruelty”, supported by examples. He mentioned that he’s never seen a persona of someone in crisis or a troll when looking at user stories, while we have a great focus on technical risks but much less so on human risks. There are embedded prejudices in much modern software and he recommended the book Weapons of Math Destruction by Cathy O’Neil. This was another excellent talk from Aaron, covering a little of the same ground as his meetup talk but also breaking new ground and providing us with much food for thought in the way we build and test our software for real humans in the real world. Open season was busy and fully exhausted the one-hour in Aaron’s company.

Adam Howard introduces Aaron Hodder for his track

Graeme Harvey ready to present

A very brief break gave time for delegates to make their next choice, “Exploratory Testing: LIVE!” with Adam Howard or “The Little Agile Testing Manifesto” with Samantha Laing. Having seen Adam’s session before (at TestBash Australia 2018), I decided to attend Samantha’s talk. She introduced the Agile Testing Manifesto that she put together with Karen Greaves, which highlights that testing is an activity rather than a phase, we should aim to prevent bugs rather than focusing on finding them, look at testing over checking, aim to help build the best system possible instead of trying to break it, and emphasizes the whole team responsibility for quality. She gave us three top tips to take away: 1) ask “how can we test that?”, 2) use a “show me” column on your agile board (instead of an “in test” column), and 3) do all the testing tasks first (before development ones). This was a useful talk for the majority of her audience who didn’t seem to be very familiar with this testing manifesto.

Sam Laing presenting her track session (photo from Lynne Cazaly)

With the track sessions done for the day, afternoon tea was another chance to network and confer before the conference came back together in the large Function Hall for the closing keynote. Paul did the honours in introducing the well-known Lynne Cazaly with “Try to See It My Way: Communication, Influence and Persuasion”.

She encouraged us to view people as part of the system and deliberately choose to “entertain” different ideas and information. In trying to understand differences, you will actually find similarities. Lynne pointed out that we over-simplify our view of others and this leads to a lack of empathy. She introduced the Karpman Drama Triangle and the Empowerment Dynamic (by David Emerald). Lynne claimed that “all we’re ever trying to do is feel better about ourselves” and, rather than blocking ideas, we should yield and adopt a “go with” style of facilitation.

Lynne was a great choice of closing keynote and we were honoured to have her agree to present at the conference. Her vast experience translated into an entertaining, engaging and valuable presentation. She spent the whole day with us and thoroughly enjoyed her interactions with the delegates at this her first dedicated testing conference.

Slide from Lynne Cazaly's keynotelynne2Slide from Lynne Cazaly's keynote

Paul Seaman closed out the conference with some acknowledgements and closing remarks, before the crowd dispersed and it was pleasing to see so many people joining us for the post-conference cocktail reception, splendidly catered by the Jasper. The vibe was fantastic and it was nice for us as organizers to finally relax a little and enjoy chatting with delegates.

Acknowledgements

A conference doesn’t happen by accident, there’s a lot of work over many months for a whole bunch of people, so it’s time to acknowledge the various help we had along the way.

The conference has been actively supported by the Association for Software Testing and couldn’t happen without their backing so thanks to the AST and particularly Ilari who continues to be an enthusiastic promoter of the Australian conference via his presence on the AST board. Our wonderful event planner, Val Gryfakis, makes magic happen and saves the rest of us so much work in dealing with the venue and making sure everything runs to plan – we seriously couldn’t run the event without you, Val!

We had a big response to our call for proposals for TiCCA19, so thanks to everyone who took the time and effort to apply to provide content for the conference. Paul and I were assisted by Michele Playfair in selecting the programme and it was great to have Michele’s perspective as we narrowed down the field. We can only choose a very small subset for a one-day conference and we hope many of you will have another go when the next CFP comes around.

There is of course no conference without content so a huge thanks to our great presenters, be they delivering workshops, keynotes or track sessions. Thanks to those who bought tickets and supported the event as delegates, your engagement and positive feedback meant a lot to us as organizers.

Finally, my personal thanks go to my mate Paul for his help, encouragement, ideas and listening ear during the weeks and months leading up to the event, we make a great team and neither of us would do this gig with anyone else, cheers mate.

 

Pre-TiCCA19 conference meetup

In the weeks leading up to the Testing in Context Conference Australia 2019, our thoughts turned to how we might sneak in a meetup event alongside the conference to make the most of the fact that Melbourne would be home to so many awesome testers at the same time.

Thanks to the conference venue – the Jasper Hotel – giving us use of one of our workshop rooms for an evening and also food & drink sponsorship by House of Test (Switzerland), the meetup became feasible and a bit of social media advertising coupled with a free Eventbrite campaign led to about twenty keen testers (including a number of TiCCA19 conference speakers) assembling at the Jasper on the evening of Thursday 28th February.

Some pre-meetup networking gave people the chance to make new friends as well as giving the conference speakers a chance to meet some of their fellow presenters. After I gave a very brief opening, it was time for the content to kick off in the shape of a presentation by well-known and respected Kiwi context-driven tester, Aaron Hodder. His talk was titled “Inclusive Collaboration – how our differences can make the difference” in which he explored how having a neurodiverse workforce can give you a competitive edge, and how the workplace can respect diverse needs and different requirements for interaction and collaboration to bring out the best in everyone’s differences. This was a beautifully-crafted talk, delivered with Aaron’s unique blend of personal connection to the topic and a smattering of self-deprecation, while still driving home a hard-hitting message. (Aaron also shared some great resources on Inclusive Collaboration at https://goo.gl/768M0u).

Aaron Hodder addresses the meetupAaron Hodder addresses the meetupThe idea of "My user manual" presented by Aaron Hodder

A short networking break then gave everyone the chance to mingle some more and clean up the remains of the food, before we kicked off the panel session. Ably facilitated by Rich Robinson, the panel consisted of four TiCCA19 speakers, in the shape of Graeme Harvey, Aaron Hodder, Sam Connelly and Ben Simo. The conversation was driven by a few questions from Rich: How have you seen the testing role change in your career? How do you think the testing role will change into the future? Is the manual testing role dead? The resulting 45-minute discussion between the panel and audience was engaging and interesting – and kudos to Rich for such a great job in running the panel.

Graeme, Aaron, Sam and Ben talking testing during the panel sessionGraeme, Aaron, Sam and Ben talking testing during the panel session

We enjoyed putting this meetup on for the Melbourne testing community and the feedback from everyone involved was very positive, so thanks again to everyone who made it happen.

A year off giving conference presentations

Having just received a rejection from my only pending CFP submission, 2019 will likely be the first year since 2013 where I don’t give a conference presentation.

It’s always disappointing when the effort of crafting a talk in response to a CFP doesn’t result in the opportunity to give the talk, but my strike rate over the last few years has been pretty good and I’m grateful for the awesome opportunities I’ve been afforded by events in New Zealand, Sweden, Estonia, Vietnam, US and Australia.

As anyone who’s prepared and given a conference talk will know, there’s a lot of time and effort involved – from crafting a CFP submission, to refining the story, building a slide deck, performing some practice runs, travelling to the event (especially from somewhere as a remote as Australia!), and actually delivering the talk. In the absence of this work, I’m looking forward to putting more effort into my community projects as well as kicking off a new testing-related personal project very soon.

In the short term, though, my focus is on the Testing in Context Conference Australia coming up in Melbourne at the end of February. It’s great to be working with Paul Seaman and the Association for Software Testing on this event and I’m really looking forward to putting on a great show, as well as meeting up with old friends from the testing community and hopefully making some new ones as we come together to learn, share and enjoy the company of great testers from around the world.

(There’s still plenty of time to register for the conference and the pre-conference workshops, all the details can be found at http://ticca19.org.)

 

2018 in review

I’ll briefly look back on 2018 to close out my blogging for the year. I published 19 blog posts in 2018, down a little from 2017 (with 22 posts). My target cadence remains one post per month so I feel like I’ve done “enough” over the year and hopefully provided some valuable and interesting content along the way. The stats indicate almost exactly the same number of views of my blog as during the previous year, but with a slight increase in the number of visitors. If there are topics you’d like to see me talking about here (especially to encourage more new readers), please just let me know.

Conferences & meetups

It was my quietest year in a long time in terms of conference attendance. I made it to just two conferences (both specific testing events), co-organizing one and co-presenting at the other.

My first conference of 2018 came in February with the Association for Software Testing‘s second Australian conference,  CASTx18 in Melbourne, for which I was Programme Chair and local organizer. The conference went really well, with a great programme (well, I would say that!) and lots of good vibes from the delegates. The Langham Hotel was a fine venue for the event and the success of the conference led the AST to commit to the 2019 conference (and beyond) – more on that below!

My only speaking gig of the year came in October up in Sydney, co-presenting with Paul Seaman at the inaugural TestBash Australia conference. This sold-out conference featured a good single-track programme and it was great to meet up with so many friends from the testing community there. Our presentation went well and the topic (our volunteer work running a software testing training course for young adults on the autism spectrum) seemed to resonate with many people in the audience. It was an enjoyable gig all round and we appreciated the opportunity to broaden awareness of the EPIC TestAbility Academy.

In terms of meetups, I only made it to those running alongside conferences. I organized a meetup before the CASTx18 conference and Katrina Clokie drew a good crowd, with fantastic hospitality courtesy of the Langham. The pre-TestBash Sydney Testers meetup in Sydney saw a presentation from Trish Koo and a decent bunch of testers turned up at the impressive Gumtree offices in the CBD.

Work stuff

Quest under private equity ownership continues to do well. I again managed to visit our major Engineering locations during the year, namely in China, California and Czech Republic (those three locations within about two months actually!), and the opportunity to travel and work with people from different cultures remains one of the most enjoyable (and challenging) aspects of my role.

I was promoted during the year, to “Director of Software Craft” (previously “Principal Test Architect”), giving me a broad remit to help the Engineering teams across the world improve the way they build, test and deploy their software.

Community work

My community efforts through 2018 were directed in two main ways, viz. the EPIC TestAbility Academy (ETA) and the AST’s conference.

ETA – a software testing training course for young adults on the autism spectrum (in association with the not-for-profit disability organization, EPIC Assist) that I present together with Paul Seaman – continued in 2018 after the good start we made in 2017. Although we originally planned to run the course twice during the year, we only managed to run it once and I was absent for a large portion of it due to work and personal travel commitments (with Michele Playfair doing an outstanding job of covering for me). For the first time, we had a couple of students finding placements at the end of the course actually doing software testing so that was incredibly rewarding. We hope to continue with ETA in 2019 if EPIC Assist can find a way to staff and fund the programme.

At the CASTx18 conference, I was asked by the AST to more formally take on responsibility for the ongoing organization of their Australian conference. It was not an easy decision to take on this responsibility, but I was honoured to be asked and decided to accept on the basis of jointly working with Paul Seaman to organize their conference from 2019 onwards. Paul and I decided to rebrand the conference and so “Testing in Context Conference Australia” (TiCCA) was born. We enjoyed coming up with a theme, inviting our keynote speakers (viz. Lynne Cazaly and Ben Simo), running a call for proposals, and selecting our speakers. Registrations are ticking along and we’re looking forward to running the two-day conference at the end of February at the Jasper Hotel. (More details on the conference and registration packages can be found at the conference website, http://ticca19.org).

Other stuff

I got the opportunity to appear on two different podcasts during the year, something I’d never done before. The first one was for the New Zealand-based SuperTestingBros podcast where I talked about neurodiversity and ETA with Paul Seaman.

The second one was a long-distance affair, chatting with Johan Steyn from South Africa for his Careers in Software Testing podcast.

These were both good experiences, quite different in flavour but hopefully of general interest and I look forward to opportunities to do more podcasts in the future.

I feel like the year has been a good mix in terms of developing professionally while also giving back via a couple of community-focused projects in ETA and TiCCA. I’m sure 2019 has challenges in store and I have a new (personal) testing-related project hopefully kicking off early in the New Year, so watch this space for more details on that!

In the meantime, all that remains for me to do is wish you all a very Merry Christmas & Happy New Year, and I hope you enjoy my posts to come through 2019.

In response to “context-driven testing” is the “don’t do stupid stuff” school of testing

I blogged about the Twitter conversation that ensued from this tweet from Katrina Clokie:

One of the threads that came out of this conversation narrowed the focus down to “schools of testing” and, in particular, the context-driven testing community:

There’s a bit to unpack here, so let me address these replies piece by piece.

“Divisive rhetoric from some of the thought leaders in that camp”

I can only assume that Rex was referring to the more vocal members of the CDT community, such as James Bach. I haven’t personally experienced anyone trying to be deliberately divisive in the CDT community, but I acknowledge that passion sometimes manifests itself in some strongly-worded comments. Even then, I wouldn’t see this as “rhetoric” as that implies a lack of sincerity or meaningful content. The CDT community, in my experience, attracts those who are sincere about improving software testing, the way it’s done, and the value it delivers.

The use of the term “thought leaders” is also interesting as I don’t see anyone within this community referring to themselves or anyone else as thought leaders. There are obviously more prominent members of the CDT community but also many doing great work in advancing the craft of software testing in line with the principles of CDT behind the scenes (i.e. not so vocally via avenues such as social media).

“CDT is more accurately called the “pay attention” or the “don’t do stupid stuff” school of testing”

I’m not sure whether Matt Griscom’s response was designed to provoke CDT community members or stemmed from a genuine misunderstanding of the seven principles of CDT, which are:

  1. The value of any practice depends on its context.
  2. There are good practices in context, but there are no best practices.
  3. People, working together, are the most important part of any project’s context.
  4. Projects unfold over time in ways that are often not predictable.
  5. The product is a solution. If the problem isn’t solved, the product doesn’t work.
  6. Good software testing is a challenging intellectual process.
  7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

I agree that we should all be paying attention as testers (or as any other contributor to a project). Paying attention to the broader project context is really important if we are to do a great job of testing, but it is still overlooked and too many testers seem to think the software in front of them is the most important (or, worse, only) aspect of the context that they need to care about.

The seven principles of CDT may well also help to decrease the chances of testers spending their time doing “stupid stuff”, but that seems like a good thing to me. Working in alignment with these principles is, to me, a better approach than following standards or “best practices” that fail to account for the unique context of the project I’m working in. I’d argue that many best practices or recommendations from other “schools” actively promote what would in fact be “stupid stuff” in many contexts.

“the value of the phrase “context-driven””

I don’t see “context-driven” as a phrase – we have a clear statement of the seven principles backing what “context-driven testing” is (see above) and the value comes from understanding what those principles mean and performing testing in alignment with them. Rex replied on Matt’s request for enlightenment, saying “”Marketing” is the value enjoyed by a small few testers. “Schism” is the price paid by all other testers.” I don’t agree with this and the use of the term “schism” is exactly the kind of divisive language Rex was accusing CDT community members of using. Does anyone “outside” of the CDT community really “pay a price” for the existence of that community? I just don’t see it.

(The domain that Matt refers to is http://context-driven-testing.com/ and it’s not being actively maintained as far as I’m aware, but it does at least give us a reference point for the principles. )

There – obviously – remain challenges for the context-driven testing community in communicating the very real value and benefits that come from testing viewed via the lens of the CDT principles. It’s great to see the continued efforts of the Association for Software Testing in this regard, with their most recent CAST conference having the theme of “bridging between communities”. I’m also proud to co-organize the AST’s Australian conference, TiCCA19, and look forward to delivering a great programme to a broad representation of the local testing community, with a focus on CDT and the value that approaches built around CDT principles offer.

On the testing community merry-go-round

This tweet from Katrina Clokie started a long and interesting discussion on Twitter:

I was a little surprised to see Katrina saying this as she’s been a very active and significant contributor to the testing community for many years and is an organizer for the highly-regarded WeTest conferences in New Zealand. It seems that her tweet was motivated by her recent experiences at non-testing conferences and it’s been great to see such a key member of the testing community taking opportunities to present at non-testing events.

The replies to this tweet were plentiful and largely supportive of the position that (a) the testing community has been talking about the same things for a decade or more, and (b) does not reach out to learn from & help educate other IT communities.

Groundhog Day?

Are we, as a testing community, really talking about the same things over and over again? I actually think we are and we aren’t, it really depends on your lens as to how you see this.

As Maria Kedemo replied on the Twitter thread, “What is old to you and me might be new to others” and I certainly think it’s the case that many conference topics repeat the same subject matter year on year – but this is not necessarily a bad thing. A show of hands in answering “who’s a first-timer?” at a conference usually results in a large proportion of hands going up, so there is always a new audience for the same messages. Provided these messages are sound and valuable, then why not repeat them to cover new entrants to the community? What might sound like the same talk/content from a presentation title on a programme could well be very different in content to what it was a decade ago, too. While I’m not familiar with developer conference content, I would imagine that they’re not dissimilar in this area, with some foundational developer topics being mainstays of conference programmes year on year.

I’ve been a regular testing conference delegate since 2007 (and, since 2014, speaker) and noticed significant changes in the “topics du jour” over this period. I’ve seen a move away from a focus on testing techniques and “testing as an independent thing” towards topics like quality coaching, testing as part of a whole team approach to quality (thanks agile), and human factors in being successful as a tester. At developer-centric conferences, I imagine shifts in topic driven frequently by changes in technology/language and also likely shifts due to agile adoption too.

As you may know, I’m involved with organizing the Association for Software Testing conferences in Australia and I do this for a number of reasons. One is to offer a genuine context-driven testing community conference in this geography (because I see that as a tremendously valuable thing in itself) and another is to build conference programmes offering something different from what I see at other testing events in Australia. The recently-released TiCCA19 conference programme, for example, features a keynote presentation from Lynne Cazaly and she is not directly connected with software testing but will deliver very relevant messages to our audience mainly drawn from the testing community.

Reach out

I think most disciplines – be they IT, testing or otherwise – fail to capitalize on the potential to learn from others, maybe it’s just human nature.

At least in the context-driven part of the testing world, though, I’ve seen genuine progress in taking learnings from a broader range of disciplines including social science, systems thinking, psychology and philosophy. I personally thank Michael Bolton for introducing me to many interesting topics from these broader disciplines that have helped me greatly in understanding the human aspects involved in testing.

In terms of broadening our message about what we believe good testing looks like, I agree that it’s generally the case that the more public members of the testing community are not presenting at, for example, developer-centric conferences. I have recently seen Katrina and others (e.g. Anne-Marie Charrett) taking the initiative to do so, though, and hopefully more non-testing conferences will see the benefit of including testing/quality talks on their programmes. (I have so far been completely unsuccessful in securing a presentation slot at non-testing conferences via their usual CFP routes.)

So I think it’s a two-way street here – we as testing conference organizers need to be more open to including content from “other” communities and also vice versa.

I hope Katrina continues to contribute to the testing community, her voice would be sorely missed.

PS: I will blog separately about some of the replies to Katrina’s thread that were specifically aimed at the context-driven testing community.