Readers respond to TDD x Psychological Safety survey
Is it time to standardise TDD adoption as a requirement?
“The difference between experts and beginners is that experts find more ways to reward themselves while they work. Experts are not more disciplined, they just found more ways to win.” —Alex Hormozi
Editor—Hey, it’s Denis. I’m excited to finally share the survey results with you. We’ve had overall 60 responses, all of them collected in September 2023. So the data is pretty fresh considering TDD is headed to its third decade.
The motivation for this survey was to find root cause issues to help us understand what issues came up during TDD adoption along with the non-technical benefits it provides or exposes on the overall mental well being of an engineering team.
All respondents have a technical background, mostly engineers with a few managers and architects mixed in. Let’s dive in!
Surrounded by identity noise
*Other captures after-by-someone-else / later / never forms of test-writing.
(N=60 humans)
It’s no surprise to see plenty of controversial and unaligned opinions around the topic of testing automation, TDD, “I write tests during development, but I don’t call it TDD” and similar ideas.
Let’s have a look at the identity breakdown:
I consider myself a TDD practitioner (53.3% votes)
My team shares my views on TDD (21.7% votes)🤔
My team’s testing strategy is test-first (21.7% votes)Overlap coincidental
My team’s testing strategy is test-first or during (61.67%) 🚀
My team writes tests as part of development opposed to QA, etc (86.67%)🔥
Luckily, 100% of respondents where their team writes tests first identify as TDD practitioners. Helped me dodge a bullet there with survey analysis.
Actual TDD
The various names that engineers give to their faux-testing practices is nothing short of frustrating. To keep matters simple let us refer to the canonical meaning of Test-driven development that originated with the appropriately titled book from 2000.
For the sake of the survey results themselves, we’ll refer to TDD practitioners based on how the the correspondents claim to identify. I haven’t actually shadowed the teams and watched them over the shoulder to ensure they’re writing testing plans, red-green-refactor, etc.
Blameless culture and responsible testing design
Editor—This is the meat and potatoes of this quarter’s survey. I was quite surprised at the sharp signal even when comparing test during vs. test first. I hypothesised a shift from chaotic, stressful deployments with test later/never towards a more mature, professional environment on the test first/during segments.
With some creative freedom you’ll quickly be able to spot the most common feedback problem in quality assurance and testing automation:
✅ Psychological safety allows questions of “how are we going to test this?”
✅ Addressing the testing issue before or during implementation deals with most unknowns that will pop up as defects
✅ Quick blame-less feedback allows for immediate response by the entire team
✅ The short cycles allow for simpler design
✅ The simpler design allows for easier test-writing and easier deployments
❌ Lack of tests leads to late feedback
❌ Late or no feedback creates pressure at critical points in the project timeline
❌ Pressure leads to last-minute testing and blame-oriented triage
❌ Hacks cause release issues and make design less open to testing
❌ Low coverage and understanding lead to difficulty in writing tests
We discussed a similar parallel to engineering-focused test-writing in the design stages in our live DevOps conversation with Bryan Finster concerning Quality Engineering:
“Ultimately, quality starts at defining how we're going to test it before we start coding.” —Bryan Finster
🍪♻️ Recommendation
Together with
we run the “Our Tech Journey” stream and we will be covering this topic live in a few hours with our guest Jonathan Hall.I’m aware most of you are huge Kent Beck fans as we overlap nearly 40% of our audience! Go ahead and jump over to read it, I won’t be mad 😆👇
Potential biases
Considering how many coaching clients I have that have no automated testing strategy I’m confident the surveyed engineers are skewed towards a testing-enthusiastic audience. We can’t negate for this bias with our sample size so I figured to mention it to you explicitly.
Granted, the findings paint a pretty picture to the benefit of TDD. However, the causality link is inconclusive. The survey shows teams that are open minded and focus on professionally fitness and well-being practice TDD or test-during procedures. However there’s no evidence to highlight whether TDD is creating these tendencies or if it’s a consequence of them.
However, it’s clear that a team that has grown into respecting open mindedness and good design is motivated to adopt and maintain its TDD practice.
There were no significant outliers related to team size.
📊 How has TDD impacted your delivery style?
Slowed me down, not using it (13% votes)
Somewhat helpful but confusing (11% votes)
Very helpful, improved design (50% votes) ✅
Boosted my speed consistently (26% votes)
Recent poll (N=38), unrelated to the survey above
Conclusion
Like it or hate it, test-driven development is here to stay. I’d encourage everyone in the industry who works in crafting software to become familiar with the steps and concepts of TDD even if they don’t practice it at the moment. Especially if you’re stuck on the bottom half of the above list with the red crosses. Learn the craft and be ready, then improve your environment and aim for higher quality when it makes business sense.
From empirical evidence from my coaching practice I dare say that no team that has adopted TDD and benefited from the cultural transformation ever dropped it. That’s not to say every team makes it through this hurdle.
Test-driven development isn’t magic. It’s about testing:
Testing your knowledge
Testing your assumptions
Testing the efficacy of your process
Testing your team’s relationships and communication
There is no self-writing, self-designing voodoo as many tech influencers would have you believe.