Archive

Testing

Two Versions of No Testing

February 18, 2025
Article, Crosby, Culture change, NoTesting, Product development, Software development, Testing
1 Comment

Two Versions of No Testing

Introduction

Welcome to a writing experiment! Below you’ll find two versions of a post about software testing. Both present the same core argument but use different rhetorical styles. We’re curious about how these different approaches affect reader engagement and response.

What interests you more? Which style do you find more persuasive (even if you disagree with the content)? Which makes you think more deeply about the issues raised?

We invite you to share your thoughts in the comments. Consider:

  • Which version held your attention longer?
  • Which prompted you to think more critically about your own views?
  • Which would you be more likely to share with colleagues?
  • How did you respond, emotionally, to each version?

I’m st least as  interested in how the different writing styles affect your engagement with the ideas as your response to #NoTesting itself.

The Imperative Version

Stop Testing and Start Coding Properly

Acknowledge Your Incompetence

Let’s be real: if you need testing and testers, you’re just admitting you don’t know how to build stuff properly. Every test you write is a monument to your team’s own incompetence.

Face the False Comparisons

Think about it. When you’re really good at something, do you need someone checking your work? Does a master chef need someone tasting every dish before it goes out? Does a skilled surgeon need someone double-checking their sutures? No. They’ve mastered their craft.

Reject the Culture of Doubt

But in software development, we’ve normalised this culture of doubt. We’ve created entire roles – TDD, “QC Engineers,” “Test Automation Specialists” – dedicated to proving we can’t trust developers to do their jobs right. It’s institutionalised incompetence.

Stop Writing Tests for Tests

And don’t get me started on unit tests. Writing code to test your code? If you need to write tests to verify your code works, you don’t understand what you’re building well enough to build it correctly in the first place.

Throw Away Your Crutches

The truth is, testing is a crutch. It’s what mediocre developers, teams and businesses rely on because they can’t think through their solutions properly. Real developers understand their systems so thoroughly that they can anticipate and prevent defects from ever occurring in the first place.

Stop Wasting Time

Every hour spent writing tests is an hour admitting you’re not good enough at your job. Every tester hired is a living declaration that your company can’t be trusted to deliver quality work.

Recognise the Amateurs

Want to know if you’re dealing with amateurs? Look for their test coverage metrics. The higher the number, the more they’re compensating for their lack of real skill.

Accept the Truth

It’s time to call this out for what it is. Testing isn’t a “best practice” – it’s a best practice for those who haven’t mastered their craft. Competent people don’t need this safety net. They deliver working products because they know what they’re doing.

The Interrogative Version

Are You Still Testing? That’s Rather Embarrassing, Isn’t It?

Why Do You Need Testing at All?

As James Bach provocatively suggested in his controversial 2018 blog post “Testing is Dead, Long Live Development,” isn’t the entire testing paradigm built on a foundation of mistrust? Bach argued that “every test case written is an admission of design failure.” Mightn’t he have a point?

Do Real Professionals Need Verification?

Sarah Thompson’s infamous Medium article “The Testing Trap” (2021) posed a fascinating question: “Why have we created an entire industry around assuming failure?” Didn’t she demonstrate rather conclusively that organisations with extensive testing regimes actually shipped fewer features than their counterparts?

Have We Created a Culture of Distrust?

The “No Testing Manifesto,” published anonymously on DevRant in 2020, raised a compelling point: haven’t we simply created a self-fulfilling prophecy? When you expect developers to make mistakes, don’t they invariably live down to those expectations?

Why Test Code with More Code?

David Chen’s controversial LinkedIn post “Unit Tests: The Emperor’s New Clothes” (2022) presented fascinating data: didn’t he show that companies spending more than 20% of their development time on unit tests actually had higher post-release defect rates? Mightn’t this suggest we’re solving the wrong problem?

Are Tests Just Props for the Mediocre?

As noted in “The Death of QA” (DevOps Quarterly, 2023), haven’t the most innovative tech companies been quietly scaling back their testing departments? Wasn’t there a telling correlation between reduced testing overhead and increased innovation speed?

How Much Time Are You Wasting?

The “Zero Test Movement” gaining traction in certain Silicon Valley startups claims to have demonstrated a 40% increase in feature delivery speed after abandoning traditional testing practices. Mightn’t this suggest we’ve been approaching quality entirely wrong?

When Will You Face Reality?

Remember what Peter Miller wrote in his piece “Testing: The Great Lie We Tell Ourselves” (2022): “Every hour spent writing tests is an hour not spent improving your core product.” Isn’t that the uncomfortable truth we’re all avoiding?

Rethinking Determinism and Testing in Software Development: A Path to Zero Defects

July 2, 2024
Article, Crosby, Culture change, Quality, Testing
Leave a comment

Rethinking Determinism and Testing in Software Development: A Path to Zero Defects

In the realm of software engineering, we often discuss concepts like determinism, preconditions, postconditions, and class invariants. While these are important, it’s time we challenge some fundamental assumptions about software development and testing. This post explores these concepts and then proposes a radical shift in our approach.

Traditional Concepts: A Brief Overview

  1. Determinism: In a deterministic system, the same input consistently produces the same output.
  2. Preconditions: Conditions that must be true before a method is executed.
  3. Postconditions: Conditions that must be true after a method has executed.
  4. Class invariants: Conditions that must hold true for every instance of a class at all times (except during method execution).

These concepts intersect to form a framework for designing, implementing, and reasoning about software systems and their quality. They promote predictable behaviour, enhance reliability, and facilitate verification and assurance of software correctness.

Challenging the Status Quo

However, it’s time we question some deeply ingrained beliefs in our industry:

Testing Does Not Ensure Quality

Contrary to popular belief, testing does not ensure quality. It merely identifies the presence of defects, not their absence. Quality must be built into the product from the start, not tested in afterwards.

Testing is Waste

All testing is, in fact, waste (‘muda’ in lean manufacturing terms). It doesn’t directly add value to the end product from the customer’s perspective. In an ideal development process, testing would be unnecessary.

Defects are Not Inevitable

We’ve long operated under the assumption that defects are an inevitable part of software development. This belief has led us to accept testing as a necessary evil. But what if we challenged this assumption?

A New Paradigm: Zero Defects through Progressive Refinement

As Phil Crosby Crosby advocates, we can eliminate the need for testing through a progressive refinement of our approach to development. Here’s how:

  1. Perfect Requirements: Start with a flawless understanding and documentation of requirements. This eliminates misunderstandings that lead to defects.
  2. Rigorous Design:Develop: comprehensive design specifications that leave no room for ambiguity or misinterpretation.
  3. Correct-by-Construction: Employ programming languages and techniques that make it impossible to introduce certain classes of bugs (a.k.a. Poka yoke).
  4. Pair or Ensemble Programming and Code Reviews: Use these practices not to find defects, but to ensure that every line of code written is correct from the start.
  5. Continuous Verification: Instead of testing after the fact, continuously verify that the software meets its specifications throughout the development process.
  6. Cultural Shift: Foster a culture where the expectation is appropriate, not some vague “good enough”. Every team can choose to believe that defects are preventable and unacceptable.

The Role of Determinism in Zero-Defect Software

In this new paradigm, concepts like determinism, preconditions, postconditions, and class invariants take on a new role. Rather than being tools for testing, they become part of the specification and verification process:

  • Determinism ensures predictable behaviour, making verification easier.
    Preconditions and Postconditions become part of the formal specification, used to prove correctness rather than guide testing.
    Class Invariants help ensure that objects maintain consistent states throughout their lifecycle.

Conclusion: Towards a Testing-Free Future

By adopting this mindset and progressively refining our development practices, we can move towards a future where testing is unnecessary because defects simply don’t occur. This isn’t just an idealistic vision – it’s a necessary evolution of our field.

Remember, every test we write is an admission that we expect our software to fail. By aiming for zero defects and eliminating the need for testing, we’re not just reducing waste – we’re fundamentally changing what it means to develop software.

The path to this future won’t be easy, but as Phil Crosby reminds us, it’s a journey worth undertaking (Cf. “Quality is Free”. After all, in a world of zero-defect software, the intersection of determinism, preconditions, postconditions, and class invariants isn’t about testing – it’s about guaranteed correctness.

In this new world, we don’t test quality in; we build it in from the start. We don’t hunt for bugs; we prevent them from ever existing. This is the future of software development – a future without tests, because tests have become obsolete in the face of our ability to create quality, defect free software.

Let’s Call Software Testing By Its Real Name

March 20, 2024
Actionable Insights, Article, Testing
Leave a comment

Let’s Call Software Testing By Its Real Name

The Elephant in the Room

Can we have have an honest discussion about software testing? For many years now, we’ve danced around the real reason we dedicate substantial time and resources to testing software before releasing. It’s time to call a spade a spade – what we refer to as “testing” is actually “status determination”.

Status Determination: Reporting on the Current State

Testing, or status determination as I’ll contentiosly refer to it going forward, serves one key purpose: to report on the current status of the software under development. With each test execution, we’re essentially asking “Where are we at? What’s working as intended and what still needs to be fixed or improved?”

A Reflection of Our Development Approach

The need for rigorous status determination is a reflection of the current state of software development practices. If processes were truly stable and predictable, we would already know the status of the product without having to examine it through testing. But the truth is, our development approaches have instability and unpredictability baked in from the start.

Embracing Status Determination

Instead of deluding ourselves, we might choose to resign ourselves to the humiliating reality that status determination is a crutch upon which our development efforts desperately rely. It is a begrudging acknowledgment that teams simply cannot contend with the inherent complexities involved in crafting modern software systems through process and skill alone.

We lack the capability – the fundamental engineering wisdom – to make any credible predictions about how our systems will ultimately behave until we have fully constructed them and exhaustively probed their functions through test execution. No amount of upfront rigour, no depth of planning, no elite cadre of technical talent can circumvent this embarrassing limitation.

Embracing status determination is an admission that our vaunted processes and highly-skilled practitioners are profoundly inept at the core challenge of developing software systems that accurately model their specified behavior from the outset. We are hopelessly beholden to this retroactive “validation” step, owing to our rudimentary inability to wrangle the demons of complexity upfront through our hubris-laden and woefully inadequate practices.

Status determination stands as an unavoidable, perpetual reminder that for all our pontificating about engineering maturity and advancing the software discipline, we remain disappointingly crude in our approaches. It is the ceaseless tax we pay for failing to evolve more predictable, more reliable development techniques befitting a truly modern, professional field.

The Path Forward

Does this mean our development practices are fatally flawed? Pretty much. It means we have to allocate appropriate time and resources to status determination as a key part of our delivery lifecycle. We might better choose to strive to improve our processes. Let’s call software testing what it is – “status determination” – and double down on getting better at no longer needing it.

Training For All The Wrong Skills

September 18, 2023
Article, Attendants, Product development, Quintessence, Software development, Systems thinking, Testing, Training
Leave a comment

Training For All The Wrong Skills

Image

Are We Training People For the Wrong Skills?

In business and software development, we’ve got a misalignment. We’re so wrapped up in perfecting the technical, we lose sight of the human. Developers are trained to churn out code more quickly, code that’s faster, cheaper, and more reliable, but are they learning how to solve real-world problems? Testers are trained to find bugs, but not how to prevent them. The result: technically proficient software that either nobody wants or that arrives late and over budget, or both.

Technical Matters?

Yes, quality code is essential. Yet, it’s by no means the end-all and be-all. A developer isn’t just a code-writing machine; they’re attendants. The fixation on coding and computing skills above all else turns them into technicians rather than holistic thinkers capable of understanding and meeting folks’ needs. When developers are pigeonholed into this role, organisations miss out on the broader impact their expensive developers could be making.

What About Bugs?

Finding bugs is a red herring – what if we could prevent them in the first place? Testers are often pigeonholed into merely identifying issues rather than participating in a more proactive approach. This approach costs time, money, and may even reduce the software’s overall quality because the focus is on fixing, not preventing. The need for speed in bug-finding diverts attention from other valuable forms of contribution, like feature development and needs validation (making sure the product meets the real needs of all the Folks That Matter™.

What’s the Cost?

When we narrow our focus to speed, efficiency, and defect detection, we end up inflating costs and extending delivery times. Software development isn’t just about churning out lines of code or ticking off a testing checklist. It’s a more nuanced art that blends technical skills with an understanding of the needs of all the Folks That Matter™.

Where’s the User in All This?

In the chase for technical mastery, it’s easy to forget the end-user. Products, at their core, are intended to make lives easier, to attend to folks needs. When developers and testers are not trained to master these things, we end up with products that are high on features but low on utility.

So What’s the Solution?

If we’re to correct this misalignment, we need a cultural shift. We might choose to reorient our training and development programmes. For developers, this means less emphasis on speed and more on understanding who matters, and then discovering and meeting these folks’ needs. For testers, a shift from just finding bugs to a more holistic approach to quality via defect prevention (Cf. ZeeDee) would be transformative.

Where Do We Go from Here?

The technical aspects of software and product development are, without a doubt, essential. But they aren’t the whole story. By shifting our focus to include all the needs of all the Folks That Matter™, we can create products that not only work but makes a difference. The first step? Acknowledging that we’ve been training for all the wrong skills.

Testing the Approach, Not Just the Product

June 5, 2023
Article, Capability development, Culture change, Engineering, Feedback, Testing
Leave a comment

Testing the Approach, Not Just the Product

Are you, as testers, merely policing the final product? Dive deeper into the fascinating, often overlooked realm of testing the software development approach itself. Imagine the possibilities of unearthing hidden bugs not just in the code, but in the entire system of creation itself. Intrigued? Let’s get this conversation started.

Hey testers. You’ve got buckets of expertise in sussing out bugs and finding things that don’t quite work as expected, right? But tell me, how often do you turn those remarkable skills to testing your organisation’s approach to software development itself?

Don’t you reckon that’s equally critical, if not more so, than testing the end product? After all, a well-oiled software development approach might just make your bug-hunting tasks lighter, eh?

Are you taking the time to inspect whether Agile methodologies truly speed up the delivery process for your teams? Or is it that Waterfall’s clarity of scope suits your projects better? Can you confidently say that your approach to software development is truly fail-safe, or are there hidden gremlins waiting to gum up the works?

In those huddles, have you ever discussed how Continuous Integration and Continuous Delivery (CI/CD) is really influencing your development effectiveness? What about DevOps? Are you certain it’s helping bridge gaps between teams, or might it be widening them instead?

How often do you question the chosen development tools? Are they making your job easier, or do they sometimes seem like a square peg in a round hole? And what about the balance between manual testing, automated testing and QA? Have you thoroughly tested the effectiveness of that mix?

Now, let’s not forget the people aspect. Is the team structure working like a charm or does it sometimes feel like everyone’s marching to a different drum? Are folks getting their voices heard, their ideas tested?

Do see where I’m getting at? Software development isn’t just about creating quality products; it’s also about refining and testing the methods that get you there. And you, dear testers, are perfectly poised to lead that charge. So, what do you say?