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.

🧠 Context

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.

✨ Specialisation

Testing is a creative undertaking - its a specialist skill.

There are multiple books, conferences and online communities dedicated to doing testing well.

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!

---

🖥 Neat stuff from around the internet

📖 Read

• Dennis Martinez on why "Developer vs Tester" memes might be more destructive than funny.
• Stay SaaSy coins the term Management Debt, a parallel to Technical Debt. It's a thought provoking read.
• ​Managing your career without a manager - an article about career growth from Saswati Saha Mitra
• A bit of a retrospective at the end of the year is a good thing to do - like this reflection from Konstantin Tchernov. Some good food for thought.

​

🎧 Listen

• Lenny Rachitsky and John Cutler on high performing product teams. It's a long one, but worth it.
• An old one from Corey Quinn that has resurfaced, Why I turned down an AWS job offer - this one is pleasantly short.

​

📺 Watch

• CIO.com interview Josh Robb on his role as CPTO at Tend - ​some really good stuff about leadership and feedback.

​

🎮 Play

• An online VIM editor where you can get lost in VIM and then just refresh to your hearts content.
• ​DittyToy can let you make music in JavaScript. Like All I Want for Christmas is you.
• Another fun game from Nick Ng - BoxClicker.

​

---

🎟️ Events coming up

​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!