Learnings from #TestBash Australia 2018
I was very happy I was able to attend the first #TestBash Australia two Fridays ago at UTS with a couple of colleagues. I was one of the few developers who attended, and it was a good to be able to attend a conference that’s focused on Testing and viewing it from a development perspective.
A lookback — My Experience on Testing so far
Coming from a development background, I am constantly amazed how dealing with quality and testing has changed since I started in the industry back in 2005. Attending the conference really made me reflect on Quality as part of the whole Software Engineering process.
Back then — we have Development and QA roles separately, and while we are within a team / project, with the, erm, waterfall approach, as the development team focuses on translating the program specifications into shippable code, the QA team focuses on writing their test plans that they would execute and “tick the boxes” once we hand over the piece of program we’ve implemented.
As a developer, you’d do as much developer testing / “dev-test” as you can as you code, but the final seal of approval comes from QA when they finish performing the plan they’ve drafted. Hand over back to us developers if there are any issues, then the process is repeated until all boxes are ticked.
I remember the analogy of “construction” vs “deconstruction” mindset we had then. The developers are in charge of building it, and the testers are in charge of breaking it to make the build better.
Side Note: there is no particular reason why I chose Superman and Batman as Developer and Tester respectively in the photos above and below other than availability — scrambling to find a figure I have at home and these 2 keychains presented themselves as immediate options. :)
This approach did get the job done, but a lot of tension has surfaced, especially and most notably during crunch time where bugs are crawling up the surface and the deadline is looming and you find the devs “defending” the build on a test case that the testers are very passionate about.
But now — we still have Development and QA roles as part of the team — but what has changed?
The terms “shifting left” / “everyone is accountable for the quality” / “testing must start at the beginning” have definitely been the trend I’ve been seeing lately. With development team being accountable with quality, the QA team is now focused on providing coaching to ensure the devs have quality in mind and having the time to do automation and prioritisation of what is risky or not.
But what is Quality, really?
Coming into the conference and having discussions with people from other companies the night before in the Pre-conf meetup, I had an idea on what to expect from the conference. While I was particularly happy that our team at Gumtree Australia are heading towards a similar direction in terms of testing with the rest of our peers, I was pretty excited to learn more from leaders of the testing industry.
One particular segment that I thought was really thought-provoking was Paul Maxwell-Walters’ discussions on the abstraction that is Quality.
Quality is an abstraction. It is relative.
In his talk, he challenged the idea of what we really thought Quality was.
I remember having a similar question asked by me by the ever awesome Mine Ogura, Continuous Improvement lead from Marktplaats from the Netherlands. She asked me what I valued the most in terms of leading the team, and I told her Quality.
Of course, she dug deeper and asked what does it mean to me. I think I responded with something like, “having the confidence with what we release and is done as automated as possible through unit testing, all the way to the end where having the facility to monitor what’s happening while it’s live.”
Paul explored the definitions. Sharing his learnings from Gerald Weinberg’s Agile and the Definition of Quality, he enumerates classic examples:
- High quality code is having zero defects
- High quality is comformant to the requirements
- High quality is getting it right the first time
He then quotes again Weinberg to surface an inherrent problem with such definitions:
Unless your requirements come directly from heaven (as some developers seem to think), a more precise statement would be: “Quality is meeting some person’s requirements.”
What stuck with me most then is reconciling what I’ve answered previously about how I understood what Quality was and what was presented. Given that quality is relative, what we think the metrics attached to it is also an abstraction and relative. I personally particularly loved the indications of quality shown, as the three D’s:
- Is it Desirable
- Is it Dependable
- Is it Durable
I absolutely loved that way of thinking — it gives a way of prioritisation as well in terms of how you look at it. Thinking of testing a feature in production? Learn fast first, discover and check if it’s desirable. Once you’ve proven it is, deliver it in such a way that it is dependable and durable.
Becoming Quality Champions
When I looked at the scheduled talks for the day, I was particularly excited about Pete Bartlett’s talk on how to guide developers into becoming quality champions. He didn’t disappoint — he was pragmatic in his ideas, and there were key takeaways I took that I definitely want to apply into my team.
There are many ways to inspire developers into becoming champions of quality. Everything though is rooted to a way of thinking. Pete suggests that the developer starts asking things like:
- In an inquisitive mindset, ask a co-team member how they tested a feature they are working on
- Ask a team member and discover what is it that makes it difficult to test and verify a change
- Discuss and come up with an actionable and acccountable plan to make it easier to develop and be confident with the work they’ve done
- Ask a team member what they think is the riskiest part of it and how they’re considering it in their process
Other Pitfalls preventing us from striving towards higher quality
Some other potential pitfalls to keep in mind that I’ve learned throughout the day:
- Conversations converting into a programming exercise and not looking at the big picture (the 3 D’s).
- Forgetting that “technology does not solve a problem that doesn’t exist.”
- Stopping from looking at the process to learn fast and test an idea first
- Non-deterministic tests due to the lots of variations in existing testing / flows in production
- Giving up to impatience
Whew, I obviously learned a lot from that #TestBash event. Very happy I did attend. Thanks to Ministry of Testing and to the rest of the people and companies who made the event possible.
For Tago Fabic’s portraiture work / blogs — visit https://www.portraitures.photo.