Posts Tagged ‘code coverage’
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,…
A Chicago Tribune article recounts how a software bug in an infusion pump lead to brain-death for a patient in 2009 (“Medical Industry Taking Hard Look at Software Faults,” Christine Mai-Duc, Chicago Tribune, August 31, 2011, p. 19)
It reports that the US Food and Drug Administration (FDA), which regulates and…
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
Incorrect…
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
Part 5:…
J on 
Bob Binder on 