Archive

Testing

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

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?