Hey there everyone!
If you're paying attention, you'll notice that I skipped last weeks newsletter. It's the first time it's happened, I hope you are not too shocked.
With TestBash World two weeks ago, and NZ testing conference last week, plus my son's fifth birthday, and a pretty challenging week at my day job... it was just easier to postpone to this week.
Never fear though, your fix is here. On with the show!
🔬 What to do when something "doesn't need testing"
Sometimes, engineers make code changes that they claim don't need testing.
Think about things like:
These things genuinely may not need testing!
But I often feel a tension when I encounter a situation like this. Because... some things might not need testing - but... it's not a sure thing.
I don't want to become a 'gatekeeper' of testing - and I want to be able to trust my engineers to be able to make sensible decisions about what sort of testing needs to happen.
At the same time, a claim that something doesn't need testing can be a hard thing to trust. And - as testers - we wouldn't be doing our job if we didn't ask questions about things that don't "need" testing.
Where do you find the balance between trusting engineers to know what they're doing, and making sure you're not taking too many risks when releasing code to production?
What I find useful, is a simple question: Why doesn't it need testing?
Often, this question will only take a minute or two to answer, and can give a whole lot of information. More often than not, engineers are happy to demonstrate or explain why something doesn't need testing. On occasion, it even turns out that something that didn't appear to need testing... actually does.
Asking this question is useful for other reasons too. A couple of minutes with an engineer to discuss their change gives context for future changes. For example - if they're adding a new database column, knowing why they're adding it will help when it comes time to populate that column further down the line.
The paradox here is that by talking about why something doesn't need testing - we're actually testing! It might not involve using the product, but by asking questions like this, we're putting the same critical eye on a change that we would for other more 'functional' changes.
So, next time someone tells you something doesn't need testing - try asking them why, and test out their claim!
All dates are in NZT
AWS Auckland host Paulo Almeida to talk about all things EC2.
I've mentioned it before, but the day approaches. Always worth a look, this one.
DevOps Auckland are hosting Andrew Sumner and Bruno Lucas to give some insight in to how they're using Azure at scale.
If I'm to recommend one event, this would be the one. Francis Ho gave this talk at TestBash World a couple of weeks ago, and it was excellent. If you can make it, it will be worth it.
Julian Vargas hosts this free workshop on Contract Testing courtesy of Ministry of Testing.
A conference focused on cloud native transformation and technologies. Including excellent speakers from companies like Honeycomb, Portainer, GitHub, Octopus Deploy and more. This looks great.
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...
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...
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...