By Dan Smith
Lucky Charms
I turned up to Macās Brewery just after 6 pm, for the first of two TestBash New Zealand meetups. It had been a rough week, with a much loved relative on their deathbed, the ongoing stress of being homeless in my hometown, and the inevitable outsider syndrome of attending a niche event. But I had my lucky Nepalese bracelet on my wrist and felt that things could only get better.
Recently I had returned from a 6-month cycle tour around the Indian subcontinent, I was keen to transition from development to testing, and felt that the TestBash conference was a golden opportunity to meet people in the local scene. But there was no way that I could justify another $700 of credit card debt, so I decided that Iād attend the free meetups and hope for the best.
I aimed for the gaps in the room, and was relieved when people quickly paused their conversations to welcome me and ask about my reason for being there. I soon noticed a few familiar faces, from the Ministry of Testing conference videos and those I had tracked down from podcast mentions.
At the end of the meetup, I was very surprised to be offered a free ticket to the conference proper. I felt guilty of freeloading, but this was the missing part of the puzzle and I was quick to accept. An event sponsor told me that my chances had increased just by putting myself out there, but I secretly knew that it was because of my lucky bracelet.
A Humble but Talented Community
The next day I packed into the Te Papa conference room with hundreds of other people. As the first talk started, my row-mate slouched in his chair and looked bored beyond repair. I imagined that he was reflecting on his own superiority, and I wondered why he had bothered to come to a community conference. His posture didnāt change all day, but when I later talked to him during an interactive session, I found a genuine soul who was down-to-earth and passionate about his work and working with others. Never judge a book by its cover.
And this was a theme that was repeated time and time again. It wasnāt necessarily any easier to approach people, but when they talked to you, they talked with rather than at you. People were happy to stop and explain what they meant. They werenāt self aggrandising or competitive. Perhaps they were just more used to dealing with variety and other people. Plus there were far more women and people of Asian descent. To me, it seemed very different to a typical tech conference.
Presentations
The day consisted of 8 formal presentations, followed by the infamous 99 second talks.
1. "The Mindful and Deliberate Tester", by Karen Greaves & Samantha Laing
Karen & Samantha were a plucky pair of South African women who reinforced the old adage that thereās no such thing as a stupid question. They gave us some great examples of questioning business and user requirements, and encouraged us to embrace a āshow-and-tellā process, giving others equal opportunity to question our solutions. The goal of questions, they said, is not to find the answer, but to develop a shared understanding of the thing that is being discussed.
They also taught us to be humble. Complaints are not a reason to get defensive, but a rich source of information.
They reminded us that automation exists to make our lives easier and that automating repetitive workflows frees up time to do more interesting stuff. Conversely, we should be wary of using automation to test processes (such as logging in) that are already tested by humans as a matter of course.
Finally, they reminded us to keep learning, using micro steps to prevent overthinking and maintain focus.
2. āIntegration Tests: The Test Automation Gap of Mysteryā, by Trish Khoo
Trish exploded on to the stage with infectious energy and unparalleled enthusiasm. She blew away half-assed ideas about what Integration Testing was and explained that it tested the integration between different parts of an application, including 3rd party extensions and microservices. Modern applications were tremendously complex, and there were many different layers that needed to be tested, not just the UI and the API.
Trish was intimidatingly smart, yet at the same time highly practical. She encouraged us to understand what we were testing and why. Small functional scopes were better than long end-to-end behemoths because they avoided blockers and gave us actionable information in the case of failure. When tests provided useful feedback, they earned their place in the development process and gained the trust of the team. They became a core part of both greenfields development and legacy code refactoring.
3. "Setting Sail into the Great Unknown ā How I Got Started in Testing from a Non-technical Background", by Mike Clarke
I was already familiar with Mike from my Ministry of Testing subscription. Heād featured or been name dropped in some of the podcasts that Iād played while strolling around the badlands of Paparangi. He reinforced the truth that you didnāt need to be technical to become a tester.
Mikeās background was In The Navy, and he self-taught his way into a testing job after realising that his career was no longer compatible with his life goals. Clearly a capable chap, he remained humble and my main takeout from his talk was that CVs don't give jobs - people do. Getting out of your comfort zone was the key to personal and career growth.
4. "How to Lead When You're Never in Charge", by Francis Ho
Going into the conference, this was the talk which I was most interested in. As someone who regularly suffers from Imposter Syndrome, I often felt ill-equipped to lead, and, if challenged by an alpha personality, Iād reluctantly step aside every time.
Francis could have started by blaming those annoying alpha personalities for hijacking his right to lead. But instead he remained positive and humble, and focussed on being a role model. Be kind to others. Be there when they need you. Donāt alienate others for the sake of writing better/different code. And have empathy.
You can manage things, but you canāt manage people, you lead people. And you canāt lead them by riding up front, you need to be part of the pack. Donāt focus on what you donāt know, but on being kind. Be less critical of yourself and more supportive of those around you.Ā
None of these qualities seemed to describe my stereotypical idea of a leader, just the kind of all round nice guy/girl that others would enjoy working with - and be inspired to emulate.Ā
It was a convincing argument. For me, a supportive team was far more appealing than a bunch of rock stars trying to out-impress management and one another.Ā
Francis spoke with a confidence and sincerity which betrayed his status as a first time speaker. He didnāt tell me what I expected to hear, but his wisdom made perfect sense.
5. "Learning About Observability", by Katrina Clokie
I hadnāt heard of Observability before - and neither had Katrina - which is why she chose to talk about it! This highlighted the pressure that tech workers are under to keep up to date with trending technology and to separate the wheat from the chaff.
By the examples Katrina gave, I learned that Observability was surfacing large amounts of system metrics - log type stuff - through some kind of interface. Exploratory monitoring of this interface could then be done, to better understand the system and to find repeating patterns. These patterns could then indicate underlying issues, and/or form the basis for new tests or monitoring alerts.
Issues found through Observability were important because they indicated suboptimal system efficiency, which created a barrier to scaling.
The caveat was that your system had to be large and complex enough to warrant the setup costs, ensuring that your various legacy systems, integrations and microservices created logs, in a format which could be consumed by the observability engine. Otherwise, there would be holes in the reporting and this could lead to a false sense of security.
For this reason, Observability wasnāt a technology for everyone, although I did think that startups should build with āObservability In Mindā, as most were keen to scale up as quickly as possible.
6. "The Automation Break Up: Saying Goodbye to Full Stack Tests with Task Analysis", by Mark Winteringham
Mark had a cool diagram which showed the cross-section of an application. At the top was the UI, below that the JavaScript layer, then the API and finally the service. He used this diagram to plot out user flows, showing the points at which they touched the different layers of the application. This was task analysis in action - breaking tests down into their constituent parts to model the system under test.
Armed with this information, he was then able to identify the āactorā or interface closest to each system risk. This had various benefits, including speeding up test time, avoiding blockers, and getting useful information from a failing test. This echoed what Trish Khoo had said in her talk.
Mark also recommended using the right tool for the job. This meant that it was ok to use small, satellite testing tools for testing specific integrations. This was where a CI server shone, allowing tests from different tools to be run in a chain of trust.
Mark also showed a slide portraying the different types of tester. There were about 20 different cartoon caricatures on there, and it was interesting to note that diversity was not just tolerated, but welcomed in this community. Many people had come to testing as a second career, bringing with them all kinds of life and work experiences. This diversity ensured that each tester brought some unique value to the table, and was essential in ensuring that product teams didnāt suffer from a narrow perspective.
7. "Blockchain Testing - Let's Make It Easy", by Kim Nepata
Kim started off by encouraging anyone from any background to get into testing, then focussed on her specialty - blockchain.Ā
She explained to us how blockchain worked, using a live coding example to demonstrate the cryptographic process. Data was encrypted for transport to a userās account, and could not be decrypted without a unique key.Ā
Each cryptocurrency was different and provided its own test environment.
8. "A Fork in the Road - The Uncertain Future of Non-technical Testing", by Aaron Hodder
Aaronās talk was a bit different from the others. Like an episode of Black Mirror, he intelligently entertained and then shocked the audience through some pretty confronting examples of user experiences gone awry. In doing so, he lifted the lid on the social, human and legal risks of software development in the age of mobile and AI.
Many of the conference attendees were already anxious about the new technologies. For them, it was the rise of automation that had them looking over their shoulders, wondering when their jobs would be usurped by technology that they didnāt understand. Recognising this, some of the speakers had encouraged them to face their fears, demystifying their enemy by learning as much about it as they could.
But Aaronās recommendation was different. Like Markās caricature collection, Aaron stressed that there were different types of testers and that socially aware testers were just as essential as their more technically minded counterparts. Both kinds of testers were required to create multi-dimensional teams, which were stronger.
99 second talks
The day ended with a string of the famous 99 second talks. These provided an opportunity for conference attendees to get up and speak briefly on any topic that was on their mind.
Having recently completed a crash course in exploratory testing, I wanted to talk about the parallels that I saw between my expectations before a long, life-changing journey, and the expectations that a testing team might have for a human-facing application.
The topic had been on my mind all week, but I didnāt think I was attending Test Bash and now here I was. Several days of shower thoughts had been rapidly transcribed to Google Docs, but Iād run out of time to whittle them down to the meaningful core, that I knew was there.
It was too late now. Donning my bicycle helmet and stepping on to the stage, I started my speech. It was a tough crowd. My little jokes fell on deaf ears, and after a lengthy intro, and the first half of my speech, the gong went off.
Disappointed, I finished my sentence, handed the mic back to the MC and went back to my seat. Somehow, Iāll be more prepared next time.
What a Tester Needs
This was the first TestBash in New Zealand and it seemed like a professional and well-run event.
Over the course of the day, Iād learned that the realm of testing was vast and that often the tester was carrying a lot of responsibility on their shoulders.
With limited time, they needed to comprehend complex systems to a granular level, design, build and advise on tests to cover a wide range of integrations.
They needed to accurately assess risk so that they had sufficient confidence to sign off on a release. And if they didnāt have confidence, they had to face off against the project owner and try to convince them of the serious risks in going ahead anyway.
They needed to be an effective information pipeline between different groups of people.
And they needed to advocate for testing so that it was always front-of-mind.
In short, they had to be superheroes - and TestBash NZ fit the bill perfectly.
Author Bio
Dan Smith is a disillusioned developer who left his day job to cycle through distant lands. He still works as a developer but occasionally attends testing conferences in the hope of better things.
Ever curious, Dan spends his free time exploring, and occasionally blogs about web accessibility and cycle touring. You can find him at https://dotherightthing.co.nz and https://dontbelievethehype.co.nz.
