Well hello there!
Happy new year everybody. I hope you all had a good break, and are well rested heading in to the new year.
I've had a good long time off, getting some rest after a busy 2022. I've found myself really eager to get back to work though, I'm looking forward to what 2023 will bring - I hope you are too!
🙋♀️ The value of dedicated testers
In my last email, I wrote about the importance of engineers testing their work (and not just leaving it for testers).
But this leaves an unanswered question - if the engineer is testing, what is the tester there for?
I've been reflecting on this a lot. Here are three 'value adds' that I think arise from having a specialised tester in a team.
📏 Critical distance
Critical distance is a term that comes out of Rapid Software Testing (I think). It's the idea that it's difficult for an individual to be objectively critical of their own work.
An example would be, asking an author to write a review of their own novel. Even with the best of intentions, it would be difficult to separate themselves from their work and be unbiased.
It's useful to have someone 'distanced' from that work to critique it.
This also plays in to 'System 1' and 'System 2' thinking as described in Daniel Kahneman's Thinking Fast and Slow.
'System 1' is automatic, and lends itself to easy and quick answers. When an engineer has built something, and is testing it, it's common for them to be in 'System 1' mode - looking to prove it works quickly.
'System 2' is the thinking mode that requires stopping and engaging the brain. When it comes to testing, it's the thinking mode that asks the question 'how could this go wrong?' (rather than just 'does this work?')
In my experience, it's difficult (although not impossible) to make this switch from 'System 1' to 'System 2' mode.
Having someone dedicated to providing this 'System 2' thinking, or providing critical distance, can be key to building quality software.
The best teams I've worked in are what is generally known as 'cross functional'. There will be some engineers, maybe with some specialisations (frontend, backend, infra, etc). There will be a product owner or product manager, and a designer, aligned with the team. And, some person with the word 'quality' or 'test' in their job title - a tester.
Because there's only one tester, they share themselves around the engineers in the team, providing that 'System 2' thinking.
This is an advantage.
As the tester spends more time with each engineer, they build up a good picture of what each one is doing, and how all those parts will eventually fit together. This additional context can help uncover risks or problems that may not have been discovered otherwise.
There have been many occasions where I've been testing with someone, and found issues where the work one is doing will impact the other unexpectedly.
Testing is a creative undertaking - its a specialist skill.
I think it's really reasonable for engineers to be asked to test their work, and to know something about the craft of testing.
I think it's unreasonable for them to be experts in testing. The same way I wouldn't expect an engineer to be an expert in multiple engineering specialisations (frontend, backend, infra, etc).
A dedicated tester adds this test expertise to the table - they can answer questions like "what else should I consider when testing this?" or "what is a good way to test this?"
So - hopefully this serves as a 'complementary' thread to my message from December. Engineers can, and should, be testing.
Testers are there to enable that testing by bringing their creativity, critical thinking and contextual knowledge to the table.
As always, I'd love to hear your thoughts - especially as I know this is a subject that can stir up emotion and opinions! In upcoming emails, I'm going to work through some more detail of what a specialisation in testing actually means. Stay tuned!
Build your own web store - free workshop (Online, Jan 27)
Full Stack Dev Auckland are putting on a free half-day workshop on setting up a web store using the JAMstack ecosystem. This looks like a fun thing to follow along with! Hosted by Ben Dechrai from Auth0.
Junior Dev Meetup (Auckland, Feb 1)
This one is all about career - Veronika and Maya will be sharing their Summer of Tech experiences, and then Angela Simpson from Serko will be giving insights on CV screenings.
DORA metrics for testers (Online, Feb 16)
I'm giving a webinar on DORA metrics for The Test Tribe next month. We'll talk not just about the DORA metrics, but why testers should know about them, and advocate for improving them. See you there!
Hi all! It's flooding and cyclones here in NZ, especially those in Auckland. I hope this email finds you safe - if you're being affected by bad weather, please stay inside until this all blows over! COLAB Before we get too deep into it, I'd like to give a small shout out to COLAB. I had the chance to take part in COLABs Equitable Product cohort last year. It's eight weeks of conversation and learning with like talented peers; covering subjects like data ethics, accessibility, inclusion and...
Welp, the end of the year is upon us! It's been a long and busy one. It's definitely been fun, but I'm ready for a break! I've had some interesting conversations over the last couple of weeks about quality, and the lines of responsibility - so - that's the subject of today's email. Enjoy, and see you in the new year! Programmers and Engineers My first job was in a busy office. Our office constantly seemed to have a dirty kitchen - a pretty common office problem. Instead of rinsing their...
Hello! It's pie mail time again! I hope you're all doing well as we approach the end of the year. For me the last couple of weeks have been a mish-mash of team events and Christmas parties. In this world of remote and hybrid work, it's meant that my team(s) had a rare chance to see each other in person. It was a reminder of how lucky I am to work with an amazing bunch of people. Which will probably be the subject for my next email. As for this week, I've been thinking about role models.......