Deep testing — testing that maximizes the change of finding every elusive bug that matters — is the kind of testing work that engages and motivates serious testers. Developers tend to prefer shallow testing that doesn’t disrupt the developer’s mindset and the developer’s focus on getting the danged product built.
(Before anyone gets too upset, note that the shallowness of shallow testing is a feature, not a bug. There’s lots more about that here.)
In the world around Rapid Software Testing, we often point out that developers aren’t interested in doing or even learning about the kind of testing we’re interested in.
That’s a generalization, but not a completely grotesque one. There are a lot more developers than testers in the world. Most people who sign up for our classes are testers. If developers were genuinely interested in learning about testing, one would think we’d have a lot more programmers and development managers signing up for our classes.
(Are you a developer? There are Rapid Software Testing classes coming up. Prove me wrong!)
Then along comes Marius Francu, a developer and development lead currently at Siemens, who is a prominent exception to the generalization. Marius has acted as a peer advisor and teaching assistant in Rapid Software Testing classes for several years now, both with me and with James Bach. In that role, Marius has acted as a curator of references and insights that add light and colour to the class. He has also contributed perspectives from the point of view of a programmer, a manager, and a systems thinker.
At the South Eastern Europe Testing Conference (SEETest), I had the good fortune to meet Marius face-to-face for the first time. His goal was to interview me for the video series that he has been producing, Testing Voices.
Mary Alton (my wife) nudged us to probe an important issue: why was Marius, a programmer, so galvanized about Rapid Software Testing? The result was a role reversal, in which I became the interviewer. In this video, Marius shares his perspective on why RST is important to him, and why he believes it should be important to other programmers as well.
This is a fantastic articulation of the different mindsets between deep and shallow testing. As a developer who has grown into a test lead, I’ve lived this tension.
Your point about deep testing “disrupting the developer’s mindset” is so true. In an agile environment, the pressure to move fast in CI/CD pipelines often makes developers see test management as pure overhead—something that slows down build time and feature delivery.
However, I’ve found that the right test management platform can actually bridge this gap. It shouldn’t be about adding bureaucratic steps, but about creating a seamless workflow for both deep and shallow testing. A good tool helps structure regression testing so it’s efficient, provides clear test metrics to demonstrate value, and integrates defect tracking directly into the developer’s workflow.
This allows developers to maintain their flow for test execution while giving serious testers the structure they need to perform deep, investigative work and manage their test coverage effectively. The goal is to make the findings from deep testing easily actionable, not disruptive.
For anyone struggling with this, I’ve found that using a well-designed test case management tool like Tuskr test management platform can be a game-changer. It’s lightweight enough for developers but powerful enough for dedicated QA to handle everything from manual testing and test automation tracking to BDD testing and insightful test reporting.
How do you recommend introducing these deep testing concepts to resistant development teams without it feeling like an imposition?
One way is to get people to recognize that testing is not about test cases.
Then I try to help them to drop their addiction to test cases.
I try to help them think about coverage, and learning about the product.
I don’t see how the app you’re talking about changes “the game” at all. Maybe you mention it because you’re writing from the same IP address as the person who wrote the comment from the Tuskr app account.