Software testing should focus on learning and real-world behavior rather than preventing errors, as modern systems operate in unpredictable environments. Shifting to adaptive strategies - like frequent releases and continuous feedback - helps manage complexity, with frameworks like Cynefin guiding problem-solving.

Software Testing Unleashed

Software Testing Unleashed - hosted by Richard Seidl. Different guest per episode. The official Show notes contain a comprehensive overview of the episode. Released as audio and video.

• https://www.richard-seidl.com/en/testing-unleashed
• https://www.youtube.com/playlist?list=PL48Mbm-L0hjB1OdwYi9h7jrq9t352-Zk_

Episode Details

• Show Notes: https://www.richard-seidl.com/en/podcast/complex-vs-complicated-software
• Published: 2026-07-30T04:00:00Z
• Duration: 00:20:47
• Author: Richard Seidl | Software Development & Testing Expert

Overview

The podcast discusses the fundamental nature of software testing, emphasizing that its true purpose is not to prevent errors or achieve perfection, but to generate learning and insights about how software behaves in real-world conditions. It argues that modern software systems operate in complex, dynamic environments - more akin to medicine or weather than traditional engineering - where outcomes are inherently unpredictable. As such, traditional testing methods that assume a single “right answer” are inadequate and often lead to surprises in production, not because of tester failure, but because of a misapplied paradigm.

To address this, the discussion advocates for a shift from viewing software development as a complicated, predictable process to recognizing it as a complex, adaptive one. This requires embracing small, frequent releases, fail-safe experimentation, continuous feedback, and learning from real-world usage rather than relying on end-of-cycle testing. The Cynefin framework is introduced as a tool to help teams categorize problems and apply appropriate strategies, particularly emphasizing the need for adaptive approaches in complex domains. Ultimately, testers and developers must move beyond rigid methodologies and certifications focused on predictability, adopting instead a mindset of inquiry, iteration, and ongoing adaptation to improve software reliability in the face of inherent uncertainty.

What If

• What if you treated your next software release as a learning experiment rather than a perfection target?

  • Move: Deploy a narrowly scoped feature to 5% of users with comprehensive logging and a rollback plan. Spend 2 hours analyzing the behavioral logs, error patterns, and user interactions, then document 3 key insights for the next iteration.
  • Why Now?: Modern software operates in complex environments where full predictability is impossible - delaying feedback only increases the cost of learning. With observability tools widely available (e.g., OpenTelemetry, logging-as-a-service), you can extract actionable data with minimal setup.
  • Expected Upside: You’ll shift from reactive firefighting to proactive adaptation, reduce production chaos by catching emergent behaviors early, and build a personal practice of insight-driven development that compounds over time.

• What if you replaced your pre-release checklist with a set of small, fast feedback loops in production?

  • Move: For your next update, eliminate one major pre-deployment test phase and instead release through canary deployment with automated rollback triggers (e.g., error rate >1%). Monitor for 24 hours, capture anomalies, and adjust the next version based on real-world behavior.
  • Why Now?: The gap between staging and production environments makes traditional testing insufficient. Cloud infrastructure and DevOps tooling now make safe-to-fail experiments accessible even for solo developers. Waiting for “perfect” tests no longer scales with complexity.
  • Expected Upside: You’ll shorten your learning cycle, reduce wasted effort on irrelevant test cases, and increase system resilience by designing for adaptation - not just prevention.

• What if you started tracking what you learn from each release instead of just what passed or failed?

  • Move: Create a simple “Release Learning Log” (e.g., a markdown file or spreadsheet) where after every deployment, you record: 1) one unexpected behavior observed, 2) one assumption invalidated, and 3) one change you’ll make as a result. Review monthly to identify patterns.
  • Why Now?: Traditional testing culture rewards completion and correctness, but complex systems demand learning as the primary output. As a solo operator, your speed of adaptation is your competitive advantage - this log becomes your personal knowledge base for navigating uncertainty.
  • Expected Upside: You’ll build meta-awareness of how your software behaves in reality, reduce repeat failures, and gradually shift your mindset from engineering certainty to evolutionary improvement - aligning with the true nature of complex systems.

Takeaway

• Adopt a “learn-first” approach by running small, frequent releases to production, using each deployment as an opportunity to observe real-world behavior and gather actionable insights.
• Replace rigid test plans with continuous experimentation, implementing automated monitoring and feedback loops to detect issues early and adapt quickly.
• Reframe post-release failures as learning opportunities by conducting blameless retrospectives focused on patterns and system interactions, not individual errors.
• Introduce the Cynefin framework in team discussions to align stakeholders on the inherent unpredictability of software, justifying iterative development over fixed, long-term plans.
• Advocate for managerial flexibility by presenting real-world analogies (e.g., medicine, weather forecasting) to justify shifting from predictive testing to adaptive, complexity-aware practices.