Attending the “Testing Talks 2022 – The Reunion” conference (Melbourne, 20th October)

It was a long time coming (thanks to COVID and the harsh restrictions imposed on Melbourne especially during 2020 and 2021) but, after three years, the Testing Talks conference finally took place at the Melbourne Convention and Exhibition Centre on Thursday 20th October.

Appropriately billed as “The Reunion”, the conference saw over 400 keen testers assembling for the single-track event, one of the largest tech conferences in Australia post-COVID so hats off to Cameron Bradley and his team for making the event happen!

I arrived fairly early and there were already plenty of people checked in and enjoying catching up. I bumped into several familiar faces almost immediately (g’day Paul, Pete and Rob!) and it was lovely to meet up in person again after a long time between conference drinks.

The conference kicked off in the massive Clarendon room at about 9am with a brief introduction by Cameron Bradley, who showed his great passion for testing and community while displaying genuine humility and appreciation for others. An excellent start to the day’s proceedings.

The opening talk came from David Colwell (VP of AI & ML, Tricentis) with “How to test a learning system”. He defined a learning system as any system that improves with respect to a task given more exposure to the task. Such systems are more than just rules, with artificial neural networks being an early example. David noted that many modern learning systems are good at getting the right answers after learning, but it’s often difficult to know why. When testing a learning system, looking at its accuracy alone is not enough and we need to look at where it’s inaccurate to see if small degrees of inaccuracy are actually indicative of big problems. He gave the example of a system which had been trained on data with a small population of Indigenous people that led to significant issues with its outputs for Indigenous people while appearing to be high-90% accurate overall. Inevitably, David used Tricentis’s own product, Vision AI, as a case study, but only very briefly and he mentioned that good old combinatorial testing focusing on the intersections that matter was key in testing this system. His key message was that the same testing techniques (e.g. combinatorial, automation, exploratory testing) and same testing skills are still relevant for these types of learning systems, it’s just a different application of those techniques and skills. David is an excellent presenter and he pitched this talk at a level suitable for a general audience (without turning it into a vendor pitch). I was pleased to see a focus on understanding why such systems give the results they do rather than just celebrating their “accuracy”. An interesting and well-presented opening session, sadly missing an opportunity for Q&A.

Next up on the big stage was Andrew Whitehouse (Wipro) with “Design-driven concepts for automated testing”. He used the analogy of a refrigerator and the mechanism it uses to stop itself from freezing inside. His message was to focus on testing system behaviours and look at interactions to drive design decisions. Andrew suggested the use of contract tests to check that the structure of interactions stays OK and collaboration tests to check that the behaviour of interactions stays OK. The key is to use both of these approaches at scale, under load and over time to reveal different types of issues. He really laboured the fridge analogy and (pun intended) it left me cold. The key message made sense but the construction of the argument around the fridge didn’t work too well and the slides didn’t help either (too many words and poor colour choices leading to contrast & readability issues). There was again no Q&A following this talk.

Morning tea (or coffee in my case, thanks to the excellent St Ali-fuelled barista coffee cart!) was a good opportunity for a stretch and it was nice to bump into more old friends (g’day Erik!). The catering from MCEC was vegan-friendly with clear labelling and lots of yummy choices, much appreciated.

Heading back into the conference room, the next session was “Automate any app with Appium” by Rohan Singh (Headspin). He gave a brief introduction to Appium (which uses the Selenium WebDriver protocol) and then went straight into a demo, in which he installed the Appium Python client, connected to his real Android device and then created a simple automated check against the EBay app. Rohan’s demo was well prepared and went well – perhaps too well as his 45-minute session was all over in about 15 minutes (even including a short spiel about his employer, Headspin)! The very rapid execution left a hole in the schedule so we all headed back out into the open space until the next session.

The only lightning talk of the day wrapped up the morning session, in the form of Matt Fellows (SmartBear) giving an “Introduction to Contract Testing”. It was great to see Matt on stage and I’ve personally appreciated his help around contract testing in the past. He continues to be a strong advocate for this approach, as co-founder of PACTFlow and now through the SmartBear offerings. He kicked off by noting some of the problems with traditional integration testing which – while it exercises the whole stack – is often slow, fragile, hard to debug, difficult to manage in terms of environments, has questionable coverage and can result in build queues. Matt outlined the basics of contract testing as an API integration testing technique that is simpler, requires no test environment, runs fast, scales linearly and can be deployed independently. This was a perfect lightning talk, executed in bang on 10 minutes and providing a worthy introduction to this important topic.

Lunch again saw MCEC stepping up to the plate in terms of vegan options and the leisurely schedule left enough time to enjoy some pleasant sunshine along the Yarra out the front of the exhibition centre before heading back for the long afternoon session.

Laszlo Simity (SauceLabs) had the job of engaging with the post-lunch audience with his talk, “Elevate your testing”, and he was more than up to the task. He began with some history lessons on the development of IT systems and outlined the current pain point: an exponential growth in testing requirements at the same time as an exponential decay in testing timeframes. He said more tests + more people + more tools = brute force, but there is an alternative to this brute force approach, viz. what he called “signal driven quality”:

Laszlo’s idea was to connect information from all of our different types of testing into one place, with the aim of making smarter testing decisions. He outlined a few signals to illustrate the approach:

1. Failure analysis – a small number of failures generally cause most of the test quality issues
2. API testing – validate the business layer with API tests and reduce tests through the UI
3. UI performance testing – to provide early awareness of performance degradation, e.g. using Google Lighthouse
4. Accessibility testing – applying WCAG and using tools such as Axe (axe-core)

Only in his last slide did Laszlo refer to his employer, SauceLabs, and that their solution included all of the above signals into one platform. This was a nicely-crafted talk, taking us on a journey from history into pain points and through to potential solutions. It was an object lesson in how to give a talk as a vendor & sponsor and there was also a good Q&A at the end of his session.

A big name in the Selenium community was up next, with Manoj Kumar (LambdaTest) talking about “What’s new in Selenium 4?”. Manoj mentioned that relative locators, Selenium Grid observability and a DevTools protocol (e.g. to mock geolocation) are all new in version 4 and that WebDriver BiDi (bi-directional) is now available for cross-browser automation. He provided some short demos of the new features in this session, which was (unsurprisingly) very focused on (and pro) Selenium. While this content was probably interesting for the toolsmiths in the audience, it didn’t feel like a talk of general relevance to me.

A short break for afternoon tea (and more delicious vegan treats) was welcome before heading into the home stretch.

The next session, “Interactive Exploratory Testing” by Sarmila Padmanabhan & Cameron Bradley (both of Bunnings), was the one that stood out to me from the programme given my particular interest in all things Exploratory Testing. Sarmila gave the familiar definition of exploratory testing from Cem Kaner and also mentioned context-driven testing! The session then moved onto explaining three “exploratory testing techniques” in the shape of mob testing, bug bashes and crowd testing. In mob testing, a group from different disciplines test the system via one driver working on a single device. The delegates were split up into groups (one per row in the room) to test a deliberately buggy web app using a mob approach, but the groups were far too large and undisciplined to make this work well. Reconvening, the next topic was bug bashes, defined as short bursts of intense usage, using a group of people from different disciplines testing using multiple devices/browsers. Sarmila suggested this was a useful approach for production-ready features. The planned bug bash exercise was abandoned since the previous exercise had basically degenerated into a bug bash. The final topic was crowd testing, where real people in real-world conditions test the same app, as a complement to other types of testing. It has the benefit of a diversity of people and environments (e.g. devices). The exercise for this was to test the testingtalks.com.au site, but it unfortunately crashed under the large load soon after starting the exercise. I didn’t feel that this session was really about exploratory testing as I understand and practice it. The large audience made it too hard to practically run meaningful exercises, with the group becoming somewhat out of control at times. I’d love to see a session specifically on exploratory testing at the next conference, highlighting what a credible, structured and valuable approach it can be when done well.

Another big name in the automation space came next, Anand Bagmar (Software Quality Evangelist, Applitools) talking about “Techniques to Eradicate Flaky Tests”. Anand backpedalled from the talk’s claim right from the off, noting that eradication is likely impossible. He mentioned some common challenges in UI-level automation, such as long running tests with slow feedback, limitations on automatable scenarios at this level, the pain of cross-browser/cross-device execution and, of course, “flaky” tests. Anand outlined three ways to reduce flakiness:

1. Reduce the number of tests – less testing at the UI level, with more at lower levels (and, yes, he mentioned the test pyramid as a model!)
2. Remove external dependencies via Intelligent Virtualization – he recommended SpecMatic as a stub server, describing it as “PACT on steroids”!
3. Use visual assertions – Anand argued that the current approach to testing is incorrect, it’s mundane, tedious and error prone. Testing is about much more than “spot the difference” and we need to “leverage AI” and “replicate human eyes and brain”. He then pitched the VisualAI tool from his employer (and sponsor) Applitools as a way of achieving “perfection across all screens and browsers”. UX using VisualAI then became part of his updated test pyramid.

I liked his closing message to “make automation intelligent but not magic” and he was a good presenter with great audience interaction, but the talk became too much of a pitch for VisualAI towards the end unfortunately.

It was left to Basarat Syed (Pepperstore) to close out the presentations for the day, with “Automating testing web apps with Cypress”. His session consisted almost entirely of demos, in which he built end-to-end tests of a simple MVC “to do” application. His naturally laid back style made for an entertaining session, even if he perhaps chose to cover too many very similar examples in his demo. His takeaway message was to test behaviours and not implementation – and that Cypress is awesome! A short Q&A wrapped things up.

It was then time for Cameron Bradley to return to the lectern to close out the conference with the usual “thank you’s” and formalities. A large number of prize draws then followed out in the open space from the many sponsor competitions held during the day.

For those interested in continuing the festivities, the conference moved on to the nearby Munich Brauhaus on South Wharf for drinks and nibbles. It was good to see so many people turning up to socialize, even if the ability to communicate with each other was compromised by the very noisy pub and its Band Karaoke (which enticed a number of Testing Talks speakers to take the mic!). I enjoyed chatting with friends old and new for a couple of hours over a few ciders, a nice way to end a big day with the testing community.

Apart from the talks themselves, I made a few other observations during the day.

Venue – The venue was excellent, with a good comfortable room, top notch audio/visuals and thoughtful vegan catering. The coffee cart with St Ali coffee was very welcome too (even though it didn’t offer oat milk!).

Audience – As an, erm, more senior member of the Melbourne testing community, it was interesting to see the audience here. While I was in the company of a few friends of similar vintages, the majority of the crowd were young and obviously keen to engage with the sponsors. I was a little disappointed that parts of the audience weren’t as respectful as they might have been, with talking during presentations being common no matter where I sat in the auditorium.

Programme – I generally avoid talks by sponsors at conferences but that was impossible to do here as most of the presenters were from one of the event’s sponsors. For the most part, they didn’t indulge in product pitches during their talks, though, which was good to see. I would have liked to see more Q&A after each talk – there was generally no time for Q&A and, when there was some Q&A, no audience mics were used and the presenters didn’t repeat the question for the broader audience to know what question they were answering.

The programme was very focused on automation/tooling and I would have liked to see more talks about human testing: the challenges, interesting new approaches and first-person experience reports. Given the younger audience at this conference and the prevalence of tooling vendors as sponsors, it concerns me that it would be too easy for them to think this is what testing is all about and then missing out on learning the fundamentals of our craft.

Kudos to Cameron and the Testing Talks team for making this event finally happen. I know from personal experience of organizing a number of testing events in Melbourne how much work is involved and how hard it can be to get a crowd, even in more “normal” times! Cam’s authenticity and desire for community building shone through from the opening remarks to his easy-going conversations with delegates at the pub, my congratulations to all involved in bringing so many of us together for a great day.

Attending the AST’s virtual “lean coffee” (September 21, 2022)

The Association for Software Testing ran another lean coffee over a Zoom meeting on 21st September, designed primarily for the European timezone (in their morning) but also again being convenient for me to attend in Australia.

For anyone unfamiliar with the concept of a Lean Coffee, it’s an agenda-less meeting in which the participants gather, build an agenda and then talk about the topics one by one (usually with a timebox around each topic, which can be extended if there’s energy around it).

After my good experience of their first virtual lean coffee on May 24, I was really looking forward to this session – and it was certainly well worth attending.

This lean coffee was facilitated by new AST board member Trisha Chetani using Miro. We spent a chunk of time at the start of the session getting set up in Miro, suggesting topics for discussion and then voting on them (again a process we had to learn in Miro).

It was a larger group in this session than last time, which had it pros and cons. There were more topics to choose from and more diverse opinions & experiences being shared, but there was also the inevitable Zoom meeting “talking over each other” issue which made some of the discussions a little frustrating. It was good to find myself not being the only Australian in attendance with Anne-Marie Charrett joining the session and also great to see a wide range of tester experience, from newbies to, erm, more established testers.

We covered the following three topics in the lean coffee:

• Teaching developers about testing
• A book, blog or podcast that inspired you recently
• How can a test team show their value?

I enjoyed the session and the topics we managed to discuss. The hour went really quickly and I got some valuable different perspectives especially on the final topic we covered. Thanks to the AST for organizing this session at a time that was reasonable for folks on my side of the world to attend. I’m looking forward to more lean coffees in the future (when hopefully we’ve nailed down the tech so we can focus most of the hour on what we all love, talking testing!).

Note that one of the lean coffee attendees, AST board member James Thomas, has penned an excellent blog which covers the content of the discussions from this session in some detail.

Testing & “Exponential Organizations” (Salim Ismail, Michael S. Malone & Yuri Van Geest)

I’m not sure how I came across the book Exponential Organizations (by Salim Ismail, Michael S. Malone & Yuri Van Geest) but it ended up on my library reservation list and was a fairly quick read. The book’s central theme is that new technologies allow for a new type of organization – the “ExO” (Exponential Organization) – that can out-achieve more traditional styles of company. The authors claim that:

An ExO can eliminate the incremental, linear way traditional companies get bigger, leveraging assets like community, big data, algorithms, and new technology into achieving performance benchmarks ten times better than its peers.

This blog post isn’t intended to be an in-depth review of the book which, although I found interesting, was far too laden with buzzwords to make it an enjoyable (or even credible) read at times. The content hasn’t aged well, as you might expect when it contains case studies of these hyper-growth companies – many of which went on to implode. A new study of ExO’s from 2021 will form the second edition of the book coming later in 2022, though.

The motivation for this blog post arose from the following quote (which appears on page 140 of the 2014 paperback edition):

One of the reasons Facebook has been so successful is the inherent trust that the company has placed in its people. At most software companies (and certainly the larger ones), a new software release goes through layers upon layers of unit testing, system testing and integration testing, usually administered by separate quality assurance departments. At Facebook, however, development teams enjoy the full trust of management. Any team can release new code onto the live site without oversight. As a management style, it seems counterintuitive, but with individual reputations at stake – and no-one else to catch shoddy coding – Facebook teams end up working that much harder to ensure there are no errors. The result is that Facebook has been able to release code of unimaginable complexity faster than any other company in Silicon Valley history. In the process, it has seriously raised the bar.

I acknowledge that the authors of this book are not well versed in software testing and the focus of their book is not software development. Having said that, writing about testing as they’ve done here is potentially damaging in the broader context of those tangential to software development who might be misled by such claims about testing. Let’s unpack this a little more.

The idea that “separate quality assurance departments” were still the norm when this book was written (2014) doesn’t feel quite right to me. The agile train was already rolling along by then and the move to having testers embedded within development teams was well underway. What they’re describing at Facebook sounds more in line with what Microsoft, as an example, were doing around this time with their move to SDETs (Software Development Engineers in Test) as a different model to having embedded testers focused on the more human aspects of testing.

The idea that “development teams enjoy the full trust of management” and “Any team can release new code onto the live site without oversight” is interesting with the benefit of hindsight, given the many public issues Facebook has had around some of the features and capabilities included within its platform. There have been many questions raised around the ethics of Facebook’s algorithms and data management (e.g. the Cambridge Analytica scandal), perhaps unintended consequences of the free rein that has resulted from this level of trust in the developers.

It’s a surprisingly common claim that developers will do a better job of their own testing when there is no obvious safety net being provided by dedicated testers. I’ve not seen evidence to support this but acknowledge that there might be some truth to the claim for some developers. As a general argument, though, it doesn’t feel as strong to me as arguing that people specializing in testing can both help developers to improve their own testing game while also adding their expertise in human testing at a higher level. And, of course, it’s nonsense to suggest that any amount of hard work – by developers, testers or anybody else – can “ensure there are no errors”.

While I can’t comment on the validity of the claim that Facebook has released complex software “faster than any other company in Silicon Valley history”, it doesn’t seem to me like a claim that has much relevance even if it’s true. The claim of “unimaginable complexity”, though, is much more believable; given the benefit of hindsight and the evidence that suggests they probably don’t fully understand what they’ve built either (and we know that there are emergent behaviours inherent in complex software products, as covered expertly by James Christie in his many blog posts on this topic).

The closing sentence claiming that Facebook has “seriously raised the bar” doesn’t provide any context, so what might the authors be referring to here? Has Facebook raised the bar in testing practice? Or in frequently releasing well-considered, ethically-responsible features to its users? Or in some other way? I don’t consider Facebook to be high quality software or a case study of what great testing looks like, but maybe the authors had a different bar in mind that has been raised by Facebook in the area of software development/delivery/testing.

In wrapping up this short post, it was timely that Michael Bolton posted on LinkedIn about the subject matter that is so often lacking in any discussion or writing around software testing today – and his observations cover this paragraph on testing at Facebook perfectly. I encourage you to read his LinkedIn post.

“The Great Post Office Scandal” (Nick Wallis)

I’ve been following the story of the UK Post Office and its dubious prosecutions of sub-postmasters based on “evidence” of their wrongdoings from its IT system, Horizon, for some years.

My mother worked in the Post Office all of her working life and I also used to work there part-time during school and university holidays. There were no computer terminals on the counters back then; it was all very much paper trail accounting and I remember working on the big ledger when it came to balancing the weekly account every Wednesday afternoon (a process that often continued well into the evening).

Nick Wallis’s book covers the story in incredible detail, describing how the Post Office’s Horizon system (built by Fujitsu under an outsourcing arrangement) was badly managed by both the Post Office and Fujitsu (along with poor Government oversight) and resulted in thousands of innocent people having their lives turned upside down. It is both a moving account of the personal costs shouldered by so many individuals as well as being a reference piece for all of us in IT when it comes to governance, the importance of taking bugs seriously, and having the courage to speak up even if the implications of doing so might be personally difficult.

It’s amazing to think this story might never have been told – and justice never been served – were it not for a few heroes who stepped up, made their voices heard and fought to have the truth exposed. The author’s dedication to telling this story is commendable and he’s done an incredible job of documenting the many travesties that comprise the full awfulness of this sorry tale. This case is yet another example of the truth of Margaret Read’s quote:

Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it’s the only thing that ever has.

One of the more surprising aspects of the story for me was the fact that very complex IT systems like Horizon have been considered in UK law (since 1990) to be “mechanical instruments” and they’re assumed to be working correctly unless shown otherwise. This was a key factor in the data shown by Horizon being trusted over the word of sub-postmasters (many of whom had been in the loyal service of the Post Office in small communities for decades).

Jones wanted the Law Commission’s legal presumption (that ‘in the absence of evidence to the contrary, the courts will presume that mechanical instruments were in order at the material time’ [from 1990]) modified to reflect reality. He told the minister, ‘If people found it difficult to prove a computer was operating reliably in the early 1990s, we can only imagine how difficult it might be to do that today, with the likes of machine-learning algorithms coming to conclusions for reasons even the computer programmer doesn’t understand.’

Darren Jones, chair of the BEIS Select Committee, p. 456 of “The Great Post Office Scandal”

It’s now clear that the complex systems we all build and engage with today (and even back when Horizon was first rolled out) have emergent behaviours that we can’t be predicted. The Post Office’s continued denial that there were any bugs in Horizon (and Fujitsu’s lack of co-operation in providing the evidence to the contrary) seems utterly ridiculous – and it was this denial that allowed so many miscarriages of justice in prosecuting people based on the claimed infallibility of Horizon.

Program testing can be used to show the presence of bugs, but never to show their absence!

Edsger W. Dijkstra

Reading this story really made me think about what the onus on testers is in terms of revealing important problems and advocating for them to be addressed. The tragic cases described in the book illustrate how important it is for testing to be focused on finding important problems in the software under test, not just proving that it passes some big suite of algorithmic checks. Fujitsu, under duress, eventually had to disclose sets of bug reports from the Horizon system and acknowledged that there were known bugs that could have resulted in the balance discrepancies that resulted in so many prosecutions for theft. There are of course much bigger questions to be answered as to why these bugs didn’t get fixed. As a tester raising an issue, there’s only so far you can go in advocating for that issue to be addressed and your ability to do that is highly context-dependent. In this case, even if the testers were doing a great job of finding and raising important problems and advocating for them to be fixed, the toxic swill of Fujitsu, Post Office and government in which everyone was swimming obviously made it very difficult for those problems to get the attention they deserved.

Coming back to my anchors that are the principles of context-driven testing, these seem particularly relevant:

• People, working together, are the most important part of any project’s context.
• Projects unfold over time in ways that are often not predictable.
• 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 think part of our job as testers is not only to test the software, but also to test the project and the processes that form the context around our development of the software. Pointing out problems in the project is no easy task, especially in some contexts. But, by bearing in mind cases like the Post Office scandal, maybe we can all find more courage to speak up and share our concerns – doing so could quite literally be the difference between life and death for someone negatively impacted by the system we’re working on.

It would be remiss of me not to mention the amazing work of James Christie in discussing many aspects of the Post Office scandal, bringing his unique experience in both auditing and software testing to dig deep into the issues at hand. I strongly encourage you to read his many blog posts on this story (noting that he has also written an excellent review of the book).

“The Great Post Office Scandal” is available direct from the publisher and the author maintains the Post Office Scandal website to share all the latest news of what is, incredibly, still an ongoing story.

My first virtual “lean coffee” (May 24, 2022)

The Association for Software Testing ran a lean coffee over a Zoom meeting on 24th May, designed primarily for the European timezone (in their morning) but also being convenient for me to attend in Australia.

While I’ve attended Lean Coffee sessions at conferences and other events over the years, this was my first experience of this style of meeting in a virtual format. For those unfamiliar with the concept of a Lean Coffee, it’s an agenda-less meeting in which the participants gather, build an agenda and then talk about the topics one by one (usually with a timebox around each topic, which can be extended if there’s energy around it).

The meeting was facilitated by Joel Montvelisky using Lean Coffee Table and we all learned our way around the tool as we went along. It was a small but very engaged group, and it felt like the perfect size for me to both learn from others as well as feeling comfortable to contribute in (what I hope was) a meaningful way to the discussions.

We covered the following four topics in the lean coffee:

• Why do people want to speak at conferences, and can we support them to get what they need in other ways?
• What one thing would you prefer never to have to do again (as a tester)?
• Working conditions for testers
• Tactics for learning while testing

The virtual experience was of course a little different to an in-person one. Firstly, it was later in the day for me so well past the time I’d want to be drinking coffee! But, more seriously, I think the format lends itself well to the virtual environment and perhaps enables more reserved participants to engage more easily than in a physical meeting.

I really enjoyed the session, the time went really quickly and I felt like I got some interesting different perspectives in pretty much all of the topics we covered. I thank the AST for organizing it at a time that was reasonable for folks on my side of the world to attend and I hope to see attend lean coffees in the future (and also hope to see more Aussies and Kiwis in attendance!).

Note that one of the lean coffee attendees, AST board member James Thomas, has penned an excellent blog which covers the content of the discussions from this session in some detail.

Proof that I can (surprisingly) still be surprised: “Fake Experience on Software Testing”

After 25 years or so in the IT industry, and with the vast majority of my experience being in testing, I rarely find myself surprised by even the most nonsensical stuff that crosses my virtual desk. It often feels like the same mistakes and traps are being made and fallen into by a new generation of testers or the same old things get rebranded as the latest shiny thing.

I’ve seen it come and go with the “testing is dead” narrative. I’ve seen automation via screen comparison noted as a ridiculous idea while now being touted as the next big thing. I’ve witnessed the ridicule around record & playback as an automation technique, while I’m now inundated with marketing for automation tools that magically instruct computers how to do stuff apparently “without any code”. I’ve become conditioned to the nonsense and I’m well aware that everything comes and everything goes, so my attention is rarely distracted away by such obviously ridiculous “trends” in the testing industry.

But I recently came to realise that my capability to be surprised in this industry hasn’t been completely destroyed, it has merely been dormant. Thanks to Eric Proegler posting a link to a YouTube video on the Association for Software Testing‘s Slack, my surprise (and, along with it, a hefty dose of dismay) has been awoken from its slumber.

The video in question is titled “Fake Experiance on Software Testing” by Venkata Krishna (published on February 6th, 2022):

While I’m at pains not to give this abomination any oxygen, the video has already been viewed over 131,000 times as I write so calling it out here seems worthwhile even if it adds another click or two to this incredible view count. It’s worth noting that the video has over 2,700 likes and has received over 270 comments, some (rightly) calling it out as promoting unethical practice but the vast majority sadly praising it as being useful.

The typo in the titling of the video and the fact that it was recorded on a computer running an unregistered copy of Windows gives an indication of the standard of the material to come. Venkata’s introduction sets out his purpose for producing this video:

“how to put the fake experience on software testing… what are all the major challenges you may face and how to overcome those challenges – and how to happily do your work even though you go with fake experience”.

This stunning opening gambit originally made me think that the video must itself be a fake or some kind of joke piece, but alas I was mistaken. Disturbingly, he claims that the video was made in response to requests from his subscribers.

His early advice is to do one “real-time project” for manual and automated testing before claiming fake experience, claiming that “there is no issue” in doing this to get into a company (this claim is repeated frequently throughout the video).

He advises applicants to approach those “good” small consultancies who can provide fake experience documents (and even payslips, bank statements, etc.) to help them clear background checks by employers when applying for jobs (Venkata reminds his viewers not to ask him specifically for the names of consultancies providing such “services”).

Heading into the workplace after clearing any checks using the fake experience documents, he suggests that the tester be careful with the questions they ask or “risk being identified as a fake resource”. He claims that “automation is all about Selenium” and, for any question they might be asked, the solution is “already in Google”. Both “manual” and “automated” testing are described in very simplistic ways and requiring little skill or knowledge to “get by” without arousing suspicion as a “fake resource”.

If the tester can survive two to three months without being found out, then “no-one will stop you” and if they somehow manage to do the work, “no-one will touch you”. He mentioned that there are so many jobs in the US and India with so much demand that it’s easy to use fake experience to land a position.

One of the more obvious challenges of this approach (!) is that “you might not be able to do the work”, in which case Venkata advises relying on friends with actual experience as testers or utilizing a “job support service”. If the tester really can’t do the work, the employer might re-do their background checks and flag you as fake. In this case, he said HR will be the first to start asking questions, such as “is your experience real or fake?”, and the tester should always say their experience is real and suggest that HR should contact their previous employer. Acting confident (while you lie) here is the key, apparently. If HR really do re-check and the tester’s fake experience is revealed, the tester should offer to resign and then leave. There is no problem here, “It’s software, everything is soft, you won’t go to jail”.

While Venkata rightly suggests that it can be hard to find your first testing job (and claims that there are “no fresher jobs” in his market), these facts don’t justify encouraging candidates to misrepresent themselves (essentially, committing fraud). This reflects badly not only on the people following this path, but more generally on the testing industry. The reputation of some outsourced testing companies already isn’t great and this kind of “advice” to fraudulently join them only serves to devalue testing and diminish its reputation even further.

It is on those of us who employ testers to provide entry-level opportunities into our industry, maybe via apprenticeship style models, where keen new testers can learn their craft and not have to be dishonest in doing so. There are excellent examples in India of companies and communities around testing who are treating the craft with care and promoting its value – Moolya and The Test Tribe immediately come to my mind. Publishing blogs, articles and other materials that can point potential new entrants into testing towards better quality resources seems important to me. This blog is a small attempt to do this, but these words are very unlikely to attract 100,000+ readers!

I remain surprised that anyone would publish a video recommending this fraudulent behaviour, along with the many justifications they make for doing so. A job in the testing industry can be varied, fulfilling and intellectually challenging – it’s not a place to live a fake life. For anyone looking to enter the testing industry, I hope you will choose to look for guidance and help from professional testers passionate about their craft rather than doing yourself a disservice by “faking it”.

ER: acting as a Rapid Software Testing Explored “peer advisor” (7-10 February 2022)

A relatively rare scheduling of the online version of the Rapid Software Testing Explored course for Australasian timezones presented me with an invitation from presenter Michael Bolton to act as a “peer advisor” for the course running from 7-10 February.

I had already participated in RST twice before, thanks to in-person classes with Michael in Canada back in 2007 and then again with James Bach in Melbourne in 2011, so the opportunity to experience the class online and in its most current form were both very appealing. I was quick to accept Michael’s offer to volunteer for the duration of the course.

While the peer advisor role is voluntary and came with no obligation to attend for any particular duration, I made room in my consulting schedule to attend every session over the four days (with the consistent afternoon scheduling making this a practical option for me). Each afternoon consisted of three 90-minute sessions with two 30-minute breaks, making a total of 18 hours of class time. The class retailed at AU$600 for paying participants so offers incredible value in its virtual format, in my opinion.

As a a peer advisor, I added commentary here and there during Michael’s sessions but contributed more during exercises in the breakout rooms, nudging the participants as required to help them. I was delighted to be joined by Paul Seaman and Aaron Hodder as peer advisors, both testers I have huge respect for and who have made significant contributions to the context-driven testing community. Eugenio Elizondo did a sterling job as PA, being quick to provide links to resources, etc. as well as keeping on top of the various administrivia required to run a smooth virtual class.

The class was attended by over twenty students from across Australia, New Zealand and Malaysia. Zoom was used for all of Michael’s main sessions with breakout rooms being used to split the participants into smaller groups for exercises (with the peer advisors roaming these rooms to assist as needed). Asynchronous collaboration was facilitated via a Mattermost instance (an open source Slack clone), which seemed to work well for posing questions to Michael, documenting references, general chat between participants, etc.

While no two runs of an RST class are the same, all the “classic” content was covered over the four days, including testing & checking, heuristics & oracles, the heuristic test strategy model & product coverage outlines, shallow & deep testing, session-based test management, and “manual” & “automated” testing. The intent is not to cover a slide deck but rather to follow the energy in the (virtual) room and tailor the content to maximize its value to the particular group of participants. This nature of the class meant that even during this third pass through it, I still found the content fresh, engaging and valuable – and it really felt like the other participants did too.

The various example applications used throughout the class are generally simple but reveal complexity (and I’d seen all of them before, I think). It was good to see how other participants dealt with the tasks around testing these applications and I enjoyed nudging them along in the breakouts to explore different ways of thinking about the problems at hand.

The experience of RST in an online format was of course quite different to an in-person class. I missed the more direct and instant feedback from the faces and body language of participants (not everyone decided to have their video turned on either) and I imagine this also makes this format challenging for the presenter. I wondered sometimes whether there was confusion or misunderstanding that lay hidden from obvious view, in a way that wouldn’t happen so readily if everyone was physically present in the same room. Michael’s incredibly rich, subtle and nuanced use of language is always a joy for me, but I again wondered if some of this richness and subtlety was lost especially for participants without English as their first language.

The four hefty afternoons of this RST class passed so quickly and I thoroughly enjoyed both the course itself as well as the experience of helping out in a small way as a peer advisor. It was fun to spend some social time with some of the group after the last session in a “virtual pub” where Michael could finally enjoy a hard-earned beer! The incredible pack of resources sent to all participants is also hugely valuable and condenses so much learned experience and practical knowledge into forms well suited to application in the day-to-day life of a tester.

Since I first participated in RST back in 2007, I’ve been a huge advocate for this course and experiencing the online version (and seeing the updates to its content over the last fifteen years) has only made my opinions even stronger about the value and need for this quality of testing education. In a world of such poor messaging and content around testing, RST is a shining light and a source of hope – take this class if you ever have the chance (check out upcoming RST courses)!

(I would like to publicly offer my thanks to Michael for giving me the opportunity to act as a peer advisor during this virtual RST class – as I hope I’ve communicated above, it was an absolute pleasure!)

2021 in review

As another year draws to a close, I’ll take the opportunity to review my 2021.

I published 14 blog posts during the year, just about meeting my personal target cadence of a post every month. I wrapped up my ten-part series answering common search engine questions about testing and covered several different topics during my blogging through the year. My blog attracted about 25% more views than in 2020, somewhat surprisingly, and I continue to be really grateful for the amplification of my blog posts via their regular inclusion in lists such as 5Blogs, Testing Curator’s Testing Bits and Software Testing Weekly.

December 2021 has been the biggest month for my blog by far this year with a similar number of views to my all-time high back in November 2020 – interestingly, I published a critique of an industry report in December and published similar critiques in November 2020, so clearly these types of posts are popular (even if they can be somewhat demoralizing to write)!

I closed out the year with about 1,200 followers on Twitter, again up around 10% over the year.

Conferences and meetups

2021 was my quietest year for perhaps fifteen years in terms of conferences and meetups, mainly due to the ongoing impacts of the COVID-19 pandemic around the world.

I was pleased to announce mid-2021 that I would be speaking at the in-person Testing Talks 2021 (The Reunion) conference in Melbourne in October. Sadly, the continuing harsh response to the pandemic in this part of the world made an in-person event too difficult to hold, but hopefully I can keep that commitment for its rescheduled date in 2022.

I didn’t participate in any virtual or remote events during the entire year.

Consulting

After launching my testing consultancy, Dr Lee Consulting, towards the end of 2020, I noted in last year’s review post that “I’m confident that my approach, skills and experience will find a home with the right organisations in the months and years ahead.” This confidence turned out to be well founded and I’ve enjoyed working with my first clients during 2021.

Consulting is a very different gig to full-time permanent employment but it’s been great so far, offering me the opportunity to work in different domains with different types of organizations while also allowing me the freedom to enjoy a more relaxed lifestyle. I’m grateful to those who have put their faith (and dollars!) in me during 2021 as I begin my consulting journey and I’m looking forward to helping more organizations to improve their testing and quality practices during 2022.

Testing books

After publishing my first testing book in October 2020, in the shape of An Exploration of Testers, it’s been pleasing to see a steady stream of sales through 2021. I made my first donation of proceeds to the Association for Software Testing (AST) from sales of the book and another donation will follow early in 2022. I also formalized an arrangement with the AST so that all future proceeds will be donated to them and all new & existing members will receive a free copy of the book. (I’m open to additional contributions to this book, so please contact me if you’re interested in telling your story via the answers to the questions posed in the book!)

I started work on another book project in 2021, also through the AST. Navigating the World as a Context-Driven Tester provides responses to common questions and statements about testing from a context-driven perspective, with its content being crowdsourced from the membership of the AST and the broader testing community. There are responses to six questions in the book so far and I’m adding another response every month (or so). The book is available for free from the AST’s GitHub.

Podcasting

It was fun to kick off a new podcasting venture with two good mates from the local testing industry, Paul Seaman and Toby Thompson. We’ve produced three episodes of The 3 Amigos of Testing podcast so far and aim to get back on the podcasting horse early in 2022 to continue our discussions around automation started back in August. The process of planning content for the podcast, discussing and dry-running it, and finally recording is an interesting one and kudos to Paul for driving the project and doing the heavy lifting around editing and publishing each episode.

Volunteering for the UK Vegan Society

I’ve continued to volunteer with the UK’s Vegan Society and, while I’ve worked on proofreading tasks again through the year, I’ve also started contributing to their web research efforts over the last six months or so.

It was exciting to be part of one of the Society’s most significant outputs of 2021, viz. the Planting Value in the Food System report. This 40,000-word report was a mammoth research project and my work in proofing it was also a big job! The resulting report and the website are high quality and show the credibility of The Vegan Society in producing well-researched reference materials in the vegan space.

Joining the web research volunteer group immediately gave me the opportunity to learn, being tasked with leading the research efforts around green websites and accessibility testing.

I found the green website research particularly engaging, as it was not an area I’d even considered before and the carbon footprint of websites – and how it can easily be reduced – doesn’t seem to (yet) be on the radar of most companies. The lengthy recommendations resulting from my research in this area will inform changes to the Vegan Society website over time and this work has inspired me to look into offering advice in this area to companies who may have overlooked this potentially significant contributor to their carbon footprint.

I also spent considerable time investigating website accessibility and tooling to help with development & testing in this area. While accessibility testing is something I was tangentially aware of in my testing career, the opportunity to deep dive into it was great and, again, my recommendations will be implemented over time to improve the accessibility of the society’s own website.

I continue to enjoy working with The Vegan Society, increasing my contribution to and engagement with the vegan community worldwide. The passion and commitment of the many volunteers I interact with is invigorating. I see it as my form of vegan activism and a way to utilize my existing skills in research and the IT industry as well as gaining valuable new skills and knowledge along the way.

Status Quo projects

I was honoured to be asked to write a lengthy article for the Status Quo official fan club magazine, FTMO, following the sad passing of the band’s original bass player, Alan Lancaster in September. Alan spent much of his life here in Australia, migrating to Sydney in 1978 and he was very active in the music industry in this country following his departure from Quo in the mid-1980s. It was a labour of love putting together a 5000-word article and selecting interesting photos to accompany it from my large collection of Quo scrapbooks.

I spent time during 2021 on a new Quo project too, also based around my scrapbook collection. This project should go live in 2022 and has been an interesting learning exercise, not just in terms of website development but also photography. Returning to coding after a 20+ year hiatus has been a challenge but I’m reasonably happy with the simple website I’ve put together using HTML, CSS, JavaScript, PHP and a MySQL database. Gathering the equipment and skills to take great photos of scrapbook clippings has also been fun and it’s nice to get back into photography, a keen hobby of mine especially in my university days back in the UK.

In closing

As always, I’m grateful for the attention of my readers here and also followers on other platforms. I wish you all a Happy New Year and I hope you enjoy my posts and other contributions to the testing community to come through 2022!

A tester’s critique of “The 2021 State of Software Quality: The View from Enterprise Leaders & Followers”

I really should know better, but I decided to watch a webinar titled The 2021 State of Software Quality: The View from Enterprise Leaders & Followers from MicroFocus and Enterprise Management Associates, Inc. The promo spiel for the webinar read as follows:

The rapid rise of the digital economy became twice as important after layering on a worldwide pandemic. With every company having to become a software company, enterprise application development speed, volume, cost, quality, and risk are key determinants that define who survives and who does not. The pressure on application development teams to build more software faster and cheaper often runs counter to the objectives of software quality and managing risk.

Join Steve Hendrick, Research Director at Enterprise Management Associates, to hear key findings from a recent worldwide survey about software quality. This webinar will look at the characteristics and differences between software quality leaders and followers. Key to this discussion of software quality is the impact that people, process, and products are having on enterprise software quality. Completing this view into software quality will be a discussion of best and worst practices and their differences across three levels of software quality leadership.

While the opening gambit of this promo literally makes no sense – “The rapid rise of the digital economy became twice as important after layering on a worldwide pandemic” – the webinar sounded like it at least held some promise in terms of identifying differences between those “leading” in software quality and those “following”.

The survey data presented in this webinar was formed from 316 responses by Directors, VPs and C-level executives of larger enterprises (2000 employees or more). The presenter noted specifically that the mean enterprise size in the survey was over 11,000 employees and that this was a good thing, since larger enterprises have a “more complex take on DevOps”. This focus on garnering responses from people far away from the actual work of developing software in very large enterprises immediately makes me suspicious of the value of the responses for practitioners.

Unusually for surveys and reports of this type, though, the webinar started in earnest with a slide titled “What is Software Quality”:

While the three broad software quality attributes seem to me to represent some dimensions of quality, they don’t answer the question of what the survey means when it refers to “software quality”. If this was the definition given in the survey to guide participants, then it feels like their responses are likely skewed to thinking solely about these three dimensions and not the many more that are familiar to those of us with a broader perspective aligned with, for example, Jerry Weinberg’s definition of quality as “Value to some person”.

The next slide was particularly important as it introduced the segmentation of respondents into Outliers, Laggards, Mainstreamers and Leaders based on their self-assessment of the quality of their products:

This “leadership segmentation” is the foundation for the analysis throughout the rest of the webinar, yet it is completely based on self-assessment! Note that over half (55%) self-assess their quality as 8/10, 9/10 or even 10/10, while only 11% rate themselves as 5/10 or below. This looks like a classic example of cognitive bias and illusory superiority. This poor basis for the segmentation used so heavily in the analysis which follows is troubling.

Moving on, imagine being faced with answering this question: “How does your enterprise balance the contribution to software quality that is made by people, policy, processes, and products (development and DevOps tools)?” You might need to read that again. The survey responses came back as follows:

Call me cynical but this almost impossible to answer question looks like it resulted in most people just giving equal weight to all of the five choices, so ending up with just about 20% in each category.

It was soon time to look to “agile methodologies” for clues as to how “adopting” agile relates to quality leadership segmentation:

It was noted here that the “leaders” (again, remember this is respondents self-assessing themselves as quality leaders) were most likely to represent enterprises in which “Nearly all teams are using agile methods”. A reminder that correlation does not imply causation feels in order at this point.

The revelations kept coming, let’s look at the “phases” in which enterprises are “measuring quality”:

The presenter made a big deal here about the “leaders” showing much higher scores for measuring quality in the requirements and testing management “phases” than the “mainstreamers” and “laggards”. Of course, this provided the perfect opportunity to propagate the “cost of change” curve nonsense, with the presenter claiming it is “many times more expensive to resolve defects found in production than found during development”. He also sagely suggested that the leaders’ focus on requirements management and testing was part of their “secret sauce”.

When the surveyed enterprises were asked about their “software quality journey over the last two years”, the results looked like this:

The conclusion here was that “leaders” are establishing centres of excellence for software quality. There was a question about this during the short Q&A at the end of the deck presentation, asking what such a function actually does, to which the presenter said a CoE is “A good way to jumpstart an enterprise thinking about quality, it elevates the importance of quality in the enterprise” and “raises visibility of the fact that software quality is important”. An interesting but overlooked part of the data on this slide in my opinion is that about 20% of enterprises (even the “leaders”) said that their “focus on agile and DevOps has not had any impact on software quality”. I assume this data didn’t fit the narrative for this highly DevOps-focused webinar.

Attention then turned to tooling, firstly looking at development tools:

I find it interesting that all of these different types of development tooling are considered “DevOps tools” and it’s surprising that only around half of the “laggards” even claim to use source code management tools (it’s not clear why “mainstreamers” were left off this slide) and only just over half of the “leaders” are using continuous integration tools. These statistics seem contrary to the idea that even the leaders are really mature in their use of tooling around DevOps. (It’s also worth noting that there is also considerable wiggle room in the wording of this question, “regularly used or will be used”.) Deployment, rather than development, tooling was also analyzed but I didn’t spot anything interesting there, apart from the very fine-grained breakdown of tooling types (resulting in an incredible 19 different categories).

The presenter then examined why software quality was improving:

Notice that the slide is titled “Why has your software quality been improving since 2019?” while the actual survey question was “Why has your approach to software quality improved since the beginning of 2019?” Improvements in approach may or may not result in quality improvements. Some of the choices for response to this question don’t really answer the question, but clearly the idea was to suggest that adding more DevOps process and tooling leads to quality improvements while the data suggests otherwise (more around business drivers).

Moving from the “why” to the “how” came next (again with the same subtle difference between the slide title and the survey question):

There are again business/customer drivers behind most of these responses, but increased automation and use of tooling also show up highly. A standout is the “leaders” highlighting that “our multifunctional teams have learned how to work more effectively together” was a way to improve quality.

Some realizations/revelations about quality followed:

There were at least signs here of enterprises accepting that improving quality takes significant effort, not just from additional testing and tooling, but also from management and the business. The presenter focused on the idea of “shifting left” and there was a question on this during the Q&A too, asking “how important is shift left?” to which the presenter said it was “very important to leaders, it’s a best practice and it makes intuitive sense”. But he also noted that there was an additional finding in the deeper data around this that enterprises found it to be a “challenge in piling more responsibility on developers, made it harder for developers to get their job done, it alienates them and gets them bogged down with activities that are not coding” and that enterprises were sensitive to these concerns. From that response, it doesn’t sound to me like the “leaders” have really grasped the concept of “shift left” as I understand it and are still not viewing some types of testing as being part of developers’ responsibilities. The final entry on this slide also stood out to me (but was not highlighted by the presenter), with 17% of the “leaders” saying that “software quality is a problem if it is too high”, interesting!

Presentations like this usually end up talking about best practices and this webinar was no different:

The presenter focused on the high rating given by the “leaders” “adoption of quality standards (such as ISO)” but overlooked what I took as one of the few positives from any of the data in the webinar, namely that adopting “a more comprehensive approach to software testing” was a practice generally seen as something worth continuing to do.

The deck wrapped up with a summary of the “Best Practices of Software Quality Leaders”:

These don’t strike me as actually being best practices, rather statements and dubious conclusions drawn from the survey data. Point 4 on this slide – “Embracing agile and improving your DevOps practice will improve your software quality” – was highlighted (of course) but is seriously problematic. Remember the self-assessed “leaders” claimed that their software quality was increasing due to expanding their “DevOps processes and toolchain”, but correlation does not imply causation as this point on this final slide implies. This apparent causality was reinforced by the presenter’s answer to a question during the Q&A also, when asked “what is one thing we can do to improve quality?”. He said his preference is to understand the impact that software quality has on the business, but his pragmatic answer is to “take stock of your DevOps practice and look for ways to improve it, since maturing your DevOps practice improves quality.”

There were so many issues for me with the methodology behind the data presented in this webinar. The self-assessment of software quality produced by these enterprises makes the foundation for all of the conclusions drawn from the survey data very shaky in my opinion. The same enterprises who probably over-rated themselves on quality are also likely to have over-rated themselves in other areas (which appears to be the case throughout). There is also evidence of mistakenly taking correlation to imply causation, e.g. suggesting that adding more DevOps process and tooling improves quality. (Even claiming correlation is dubious given the self-assessment problem underneath all the data.)

There’s really not much to take away from the results of this survey for me in helping to understand what differences in approach, process, practice, tooling, etc. might lead to higher quality outcomes. I’m not at all surprised or disappointed in feeling this way, as my expectations of such fluffy marketing-led surveys are very low (based on experiencing of critiquing a number of them over the last few years). What does disappoint me is not the “state of software quality” supposedly evidenced by such surveys, but rather the state of the quality of dialogue and critical thinking around testing and quality in our industry.

The webinar can be viewed from https://content.microfocus.com/optimize-devops-tb/2021-software-quality (note that registration is required).

The power of the pause

While writing my last blog post, a review of Cal Newport’s “Deep Work” book, I reminded myself of a topic I’ve been meaning to blog about for a while, viz. the power of the pause.

Coming at this from a software development perspective, I mentioned in the last blog post that:

“There seems to be a new trend forming around “deployments to production” as being a useful measure of productivity, when really it’s more an indicator of busyness and often comes as a result of a lack of appetite for any type of pause along the pipeline for humans to meaningfully (and deeply!) interact with the software before it’s deployed.”

I often see this goal of deploying every change directly (and automatically) to production without the goal being accompanied by compelling reasons for doing so – apart from maybe “it’s what <insert big name tech company here> does”, even though you’re likely nothing like those companies in most other important ways. What’s the rush? While there are some cases where a very quick deployment to production is of course important, the idea that every change needs to be deployed in the same way is questionable for most organizations I’ve worked with.

Automated deployment pipelines can be great mechanisms for de-risking the process of getting updated software into production, removing opportunities for human error and making such deployments less of a drama when they’re required. But, just because you have this mechanism at your disposal, it doesn’t mean you need to use it for each and every change made to the software.

I’ve seen a lot of power in pausing along the deployment pipeline to give humans the opportunity to interact with the software before customers are exposed to the changes. I don’t believe we can automate our way out of the need for human interaction for software designed for use by humans, but I’m also coming to appreciate that this is increasingly seen as a contrarian position (and one I’m happy to hold). I’d ask you to consider whether there is a genuine need for automated deployment of every change to production in your organization and whether you’re removing the opportunity to find important problems by removing humans from the process.

Taking a completely different perspective, I’ve been practicing mindfulness meditation for a while now and haven’t missed a daily practice since finishing up full-time employment back in August 2020. One of the most valuable things I’ve learned from this practice is the idea of putting space between stimulus and response – being deliberate in taking pause.

Exploring the work of Gerry Hussey has been very helpful in this regard and he says:

The things and situations that we encounter in our outer world are the stimulus, and the way in which we interpret and respond mentally and emotionally to that stimulus is our response.

Consciousness enables us to create a gap between stimulus and response, and when we expand that gap, we are no longer operating as conditioned reflexes. By creating a gap between stimulus and response, we create an opportunity to choose our response. It is in this gap between stimulus and response that our ability to grow and develop exists. The more we expand this gap, the less we are conditioned by reflexes and the more we grow our ability to be defined not by happens to us but how we choose to respond.

Awaken Your Power Within: Let Go of Fear. Discover Your Infinite Potential. Become Your True Self (Gerry Hussey)

I’ve found this idea really helpful in both my professional and personal lives. It’s helped with listening, to focus on understanding rather than an eagerness to simply respond. The power of the pause in this sense has been especially helpful in my consulting work as it has a great side effect of lowering the chances of jumping into solution mode before fully understanding the problem at hand. Accepting the fact that things will happen outside my control in my day to day life but that I have the choice in how to respond to whatever happens has been transformational.

Inevitably, there are still times where my response to stimuli is quick, conditioned and primitive (with system 1 thinking doing its job) – and sometimes not kind. But I now at least recognize when this has happened and bring myself back to what I’ve learned from regular practice so as to continue improving.

So, whether it’s thinking specifically about software delivery pipelines or my interactions with the world around me, I’m seeing great power in the pause – and maybe you can too.