27:08 Miles: Alright Lena, we've covered a lot of ground here—from the psychology of testing to the economics of quality. But I know our listeners are probably thinking, "This is all fascinating, but how do I actually apply this in my work?" Let's get practical.
27:23 Lena: Yes! I love the theoretical insights, but I'm definitely ready for some actionable advice. Where should someone start if they want to improve their testing approach?
27:31 Miles: Great question! The first thing I always recommend is to start with assessment. Before you change anything, you need to understand your current state. Ask yourself: What are you testing now? How long does it take? What kinds of problems slip through? What's your team's biggest pain point?
27:48 Lena: So it's like doing a health checkup before starting a fitness program—you need to know where you're starting from.
1:23 Miles: Exactly! And here's a simple framework you can use. First, map out your current testing activities. Are you doing mostly manual testing at the end of development? Do you have any automated tests? How much time does your team spend on testing versus building new features?
28:07 Lena: That sounds like it might reveal some uncomfortable truths about how much time is actually going to testing activities that people might not be tracking carefully.
3:03 Miles: Absolutely! Many teams are surprised when they actually measure how much time they're spending on manual testing, bug fixes, and rework. Once you have that baseline, you can start making strategic decisions about where to invest your improvement efforts.
28:29 Lena: So what would be the next step after you've done that assessment?
28:32 Miles: I recommend starting with what I call the "low-hanging fruit" approach. Look for the most repetitive, time-consuming testing activities that you're doing manually, and automate those first. These are usually things like regression tests—tests you run over and over again to make sure new changes don't break existing functionality.
24:42 Lena: That makes sense! You get immediate time savings and you can build momentum and confidence with automation before tackling more complex scenarios.
1:23 Miles: Exactly! And here's a specific technique you can try: the "test pyramid audit." Look at your current tests and categorize them. How many unit tests do you have? Integration tests? End-to-end tests? You want to see if your distribution matches the pyramid model we discussed earlier.
29:11 Lena: So you're looking for whether you have a solid foundation of fast, focused tests supporting a smaller number of comprehensive but slower tests?
2:20 Miles: Right! If you find you have mostly end-to-end tests and very few unit tests, that's a red flag. Your test suite is probably slow, fragile, and expensive to maintain. You'll want to start adding more unit tests and reducing your dependence on end-to-end tests for basic functionality validation.
29:34 Lena: What about for teams that are just getting started with testing? Like, they don't have much of anything in place yet?
29:39 Miles: For teams starting from scratch, I recommend beginning with what's called "test-driven development" for new features. Instead of building the feature and then figuring out how to test it, you start by writing a test that describes what success looks like, then build just enough to make that test pass.
29:54 Lena: So you're using the test as a design tool to clarify your thinking before you start coding?
1:23 Miles: Exactly! And this approach naturally leads to more testable code and better test coverage. Plus, it forces you to think about edge cases and error conditions upfront rather than discovering them later.
30:09 Lena: What about tools? There are so many testing frameworks and tools out there—how do you choose?
30:13 Miles: Here's my advice: start simple and focus on consistency rather than sophistication. Pick tools that integrate well with your existing development workflow and that your whole team can learn and use. The best testing tool is the one that actually gets used consistently.
30:27 Lena: So it's better to have basic automated tests that run reliably than sophisticated tests that only one person on the team knows how to maintain?
3:03 Miles: Absolutely! And here's a practical tip: whatever tools you choose, make sure they can run in your continuous integration pipeline. Tests that only run on individual developer machines aren't providing much protection for the team.
30:46 Lena: That's a great point! What about measuring success? How do you know if your testing improvements are actually working?
30:51 Miles: I recommend tracking a few key metrics over time. First, lead time—how long does it take to go from idea to production? Second, deployment frequency—how often are you able to deploy changes? Third, mean time to recovery—when something does go wrong, how quickly can you fix it?
31:05 Lena: So you're measuring both the speed of delivery and the reliability of what you're delivering?
1:23 Miles: Exactly! And here's what's interesting—teams with good testing practices typically see improvements in all three metrics. They can move faster because they have confidence in their changes, they can deploy more frequently because they catch problems early, and they can recover faster because they have good debugging and rollback capabilities.
31:25 Lena: What's one mistake you see teams make repeatedly when they're trying to improve their testing practices?
31:30 Miles: The biggest mistake I see is trying to do everything at once. Teams get excited about testing and try to achieve perfect coverage immediately. They burn themselves out writing tests for everything, including code that's stable and unlikely to change.
31:42 Lena: So it's better to be strategic about where you invest your testing effort?
3:03 Miles: Absolutely! Focus your testing effort on the code that changes frequently, the code that's most critical to your business, and the code that's most likely to have bugs. Don't waste time writing comprehensive tests for simple utility functions that haven't changed in years.
31:59 Lena: That's such practical advice! Any final recommendations for someone who wants to get started this week?
32:04 Miles: Pick one small, well-defined piece of functionality that you work with regularly. Write a simple automated test for it. Make that test part of your development workflow. Once that becomes natural, add another test. The key is building the habit and the muscle memory before trying to solve all your testing challenges at once.