Posts Tagged ‘bugs’
Let’s distinguish between systems where the hazards of failure are material (critical) and those that are not. If it bugs don’t matter, they don’t matter. As the question (posed in a LinkedIn forum) asks about safety and security, we’re talking about critical systems.
There is a long standing debate in reliability engineering…
We don’t need a miracle cure for rogue algorithms. More regulation will not prevent them. Proven software engineering and testing will.
Every time I read about another high profile system outage, I wonder what was missed during development and testing.
For example, although an unusual natural disaster triggered the recent Amazon cloud services outage, the root cause was a lurking bug that could have been revealed with a testing strategy that I (and others) have…
Technical Equity is the value that accrues when a software system is well-formed. Instead of burdening you with unnecessary excess cost, your codebase works for you. Technical equity pays dividends: you avoid wasted effort and the consequences of buggy releases, and gain the advantage of releasing sooner and/or with more features,…
This post covers part four of my 2010 talk on testability. White box testability refers to specific programming practices and components that can improve or hinder testability.
Since Dykstra’s 1968 note “Go To Considered Harmful,” practices for producing clean, well-structured, readable, and maintainable software have been the subject of extensive discussion,…
Around December 2011, the millionth mobile app was released. This is is an amazing milestone. It shows how important the mobile space has become and how rapidly it’s evolving.
I wondered, have any of these apps been tested? My guess: probably only a few. So, I know what will happen — once users get…
This post covers part three of my 2010 talk on testability.
Aren’t the dancing hamsters a stitch?
Not so funny if you have to test code whose stability or controllability makes you feel like you’re wearing the hula-hoop.
To reveal a bug, a test must:
Reach the buggy code
Trigger the bug
Propagate the incorrect result to an observable interface
What makes a software system easier or harder to test?
The general aspects are controllability and observability.
This post covers part two of my 2010 talk on testability.
Controllability determines the work it takes to set up and run test cases and the extent to which individual functions and features of the system under test…
My 2010 keynote at the Google Test Automation conference considered the dimensions of software testability and its implications.
Click here for the slides.
Click here to view the video
This presentation is serialized in following posts.
Part 1: Testability: What is it?
Part 2: Controllability and Observability
Part 3: Accidental Untestability
Part 4: White Box Testability
Once upon a time, I had a Software 25 company with a struggling division as a client. They were selling and supporting an integrated enterprise system brought in by acquisition. This product, at version 7.0, was dominant in its market. But, with apologies to Gresham, bad software was driving out…