Monthly Archives: March 2019

Kevlin Henney at the “Software Art Thou?” meetup (Melbourne, 7th March 2019)

The latest in Zendesk’s excellent “Software Art Thou?” meetup series saw the UK’s Kevlin Henney addressing a packed house (of over 100) in Melbourne on the evening of 7th March.

Kevlin is an independent consultant, speaker, writer and trainer. His development interests are in patterns, programming, practice and process. He is co-author of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series. He is also editor of 97 Things Every Programmer Should Know and 97 Things Every Java Programmer Should Know.

The talk was advertised as follows:

“It’s just semantics.” How many conversations about philosophy, politics and programming are derailed by this thought-stopping comment?

Semantics is all about meaning. If there is one thing we struggle with and need to get better at, it is the search for and clarification of meaning. The world in which a software system lives is filled with meaning. The structure, concepts and names that inform the code, its changes and the mental models held by developers and others business roles are expressions of meaning. The very act of development is an exercise in meaning — its discovery, its formulation, its communication. Paradigms, processes and practices are anchored in different ways of thinking about and arriving at meaning.

But just because we are immersed in concepts of meaning from an early age, and just because the daily work of software development is about wrangling meaning, and just because it’s just semantics, that doesn’t mean we’re necessarily good at it. It takes effort and insight. Let’s talk about what we mean.

Kevlin’s talk was titled “What do you mean?” which he quickly modified to “WTF do you mean?”. He kicked off by talking about abstraction and this quote from Dijkstra:

The purpose of abstraction is not to be vague but to create a new semantic level in which one can be absolutely precise

He pointed out that when we’re criticized for trying to be precise with language with statements such as “It’s just semantics”, we need to remember that this literally means”It’s just meaning” so why wouldn’t we seek that?!

Turning specifically to software development, Kevlin argued that code, tests, scripts, etc. are all “code”, literally the codification of knowledge. Software development, to him, is a process of knowledge acquisition through learning, communication and social negotiation. Software architecture is a model of participation with design comprising synthesis and analysis (which are opposites of each other).

An Ernest Hemingway quote came next:

The only kind of writing is rewriting

Kevlin argued that software development is the production of variation, it’s not manufacturing – kudos to him for this messaging, it’s still all too common to see this ill-placed manufacturing/factory model placed on software development and it leads to nonsense like “Quality Assurance” when we really should be talking about testing. He also made the good point that what we do is straddling natural and programming languages.

Kevlin said that the domain (whatever it is) always looks very different from the inside and that:

Your customer doesn’t mean what they say

They use their terms and context, they leave out significant details (what they don’t say), they make assumptions, and actually don’t know what they want in the first place (it’s just a property of humans)!

As an argument for iterative development and the idea of slowing down to become faster, he quoted Neil Gaiman:

You learn from finishing things

There is a big difference between speed and velocity, with the latter being overloaded by the agile community. He claimed speed often leads to us “building the wrong thing brilliantly” rather than going slower in the right direction.

He made another excellent point as he was close to finishing up around our modern fascination with “prioritizing by business value”, with the suggestion we say “estimated business value” as this judgement of value is itself prone to error.

This was a very professionally-delivered talk, serious in nature but delivered with anecdotes and some dry British humour along the way, supported by a very nice slide deck.

Zendesk always put on a great meetup and this was no exception. Their space is large and airy with excellent audio visual facilities plus they lay on a lot of finger food and a well-stocked (and varied) bar service. The quality of their presenters is also always top notch and, although I wasn’t familiar with Kevlin and his work, this was a really engaging (even after talking non-stop for seventy minutes!) and interesting talk on a topic that gets scant treatment in the software development industry – and also in testing, specifically. Many of us in the context-driven testing community are often accused of playing semantic games but, as Kevlin ably demonstrated, conveying meaning is critically important and genuinely difficult to do well.

“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.

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.