The Most Popular Testing Strategy is "No testing"
Your team knows they "should" - so why is it still hard?
Self-reported, 2/3rds of engineers don’t have trustworthy test suites outside of a few QA tests.
I found similar reports in my coaching practice. Shocking at first, it dawned on me that most engineers have never had the opportunity to work on a well-functioning project.
The Stackoverflow Developer Survey from 2022 is somewhat more optimistic. 58% of all surveyed professional developers claim to have some automated testing (source).
Yet we have use cases, white papers, reports citing all the advantages of testing, automation, acceptance testing, bdd, tdd… Yet there seems to be a resistance to it.
Have you noticed this on your team as well?
.
.
Why is this?
When your Team Values Testing it Should Cost them
Astute readers of Crafting Tech Teams will know this quote.
I wanted to re-iterate it from a prior article:
What you care about will cost you money. Time. You love travel? Guess where your money is going. You like fast cars? I’m sure you do. How about tech gadgets and a great developer workstations. You’re not reading this from the cheapest PC on the market.
If you truly care about testing, it will cost you. It will cost you sweat and time. It will cost you in expensive tooling and education. But it’s worth it. Not because the CFO crunched the numbers — but because it’s who you are as a tech leader.
Manual Testing
You have all experienced this. You are working on something. I ask you to test it manually before we deploy.
It hits you.
That gut feeling.
I hate testing it manually.
Don’t get me wrong. I love the product. I love automation. But god have mercy I’m not testing the entire application manually.
If you truly care about testing - you will test it manually. But it has to be for something important.
This is the split in the road. Some teams decide to go the other route. Just pray it works.
And often they get away without consequences.
Or so it may seem for a while…
Test Coverage is a bad habit
“Don’t trust a test you have never seen fail.”
A famous quote. I heard it from Kevlin Henney and I’m sure he quoted it from someone else.
Try to remove all your non-testing code so it still compiles. Run your tests.
Do they all fail? This is true coverage.
Do they all fail with messages that are meaningful? These are tests you trust.
Could some other team recreate everything by following them? This is TDD.
You can test everything manually. Or automate it. This is your team’s choice to make. You’ll do one or the other no matter how you decide.
You’ll still do both. Unless you are very disciplined or stubborn.
However, acceleration happens not when tests pass. Instead, your team will see increases in productivity and wellbeing when they have mature plan for handling failing tests.
Test is failing? We trust it? Of course we do. Drop everything and fix it.
There is nothing worse than a team that doesn’t respond to failing tests.
It’s even worse when the tests are manual or from the customer and they still don’t respond to it.
Your busy may be too busy following a plan. Or tidying up JIRA with your perfect 20-field workflow.
Stop Obsessing. Test for Revenue. Then DevEx.
Customers hate when you don’t respond to them. A team that is simply overwhelmed with everything they have inherited has often only one solution. Limit what you test.
Note, I didn’t say don’t test. Instead — be realistic about how busy or overwhelmed you are and focus only on focusing one important thing. The thing that drives revenue. The critical path. A few edge cases. Nothing fancy.
Automate how you usually test it.
Automate how a user uses it. Simple.
Then expand from there.
When coaching teams often what they want is TDD, DDD or jump straight into Test Coverage mandates. They want me to be the drill sergeant or mascot who will enforce it. They are often surprises when I tell them to focus on a few key test routes. They are even more surprised when I start redirecting their attention to their release frequency, support tickets or the way they communicate with other business departments. That’s where the real problems lie. The hard stuff. The soft skills.
Top-down, focus on experience
The experience of brainstorming with your team (DDD)
The experience of building the product (Tactical Agility)
The experience of releasing it (CD)
The experience of testing it (TDD, ATDD, automation)
The experience of sharing the product with your customers (marketing, storytelling)
The experience of celebrating your team and your customers’ success