As a columnist for SoftwareQuality.com, I spend a lot of time thinking about software defects.
I had waited patiently for this activity tracker, a replacement for the FitBit Force, which was recalled when some wearers developed a skin allergy to the wristband. And now, device in hand, I was just a simple setup process away from measuring and meeting my 10,000 steps-a-day goal.
But two minutes into the installation and setup, a software defect brought the process to a halt and offered me no way out. So instead of hitting the trail with the tracker on my wrist, I spent the afternoon wondering what the cryptic error messages "invalid height" and "invalid weight" meant. And I questioned whether the software development team behind the FitBit Charge had done any testing.
After a while, I figured out the only way to complete the installation: enter your height in centimeters and weight in kilograms. Even though a drop-down box let me toggle between feet, inches and centimeters -- and between pounds and kilometers -- the software did not support U.S. systems of measurement. That, apparently, was the reason behind the "invalid height" and "invalid weight" error messages.
So there it was: A software defect significant enough to derail the setup and render the activity tracker unusable. To its credit, FitBit was quick to issue a software update that fixed the metric problem -- and within a day or two my dashboard began charting my progress in miles, not kilometers.
Other than a terse "We are aware of this issue" response to my email outlining my experience, I didn't receive any explanation for the software defect. But the experience got me thinking about all the ways this particular defect -- and software defects in general -- could have been prevented: if the software team behind the FitBit Charge had tested every assumption behind the software under development.
Here is my take on what went wrong.
First, the team failed to specify a crucial requirement at the outset of the project: The software must support both the U.S. and metric system of measurement. I don't know how FitBit's software development process works, but I presume no one at the table -- not the business stakeholders, the developers or the testers -- noted this omission. Catching this oversight required neither line-of-business nor technical expertise. It simply required common sense -- and a mindset that questioned all the assumptions embedded within the project.
Second, as work on the project progressed, it appears that developers and testers accepted the requirements they received at face value, and did not question lack of support for the U.S. system of measurement. Didn't the developers wonder about this before they wrote a line of code -- or wrote the tests that would prove that particular piece of code was working? Did software testers explore what happened when they entered height and weight data in their respective fields? If they had, it wouldn't have taken long to uncover the software defect. Mistakes happen -- but better to catch them before a line of code has been written, before the software has been released to production.
Third, it appears that the team failed to conduct user acceptance testing. If they had, they would have seen U.S. users run into trouble a minute or two into the process, when they attempted to enter height and weight data.
As software pros, it's easy to think that the job is to define requirements, write code or test code -- and usually, some of each. But the most important job of all is testing the assumptions that have been made about the software before us.
Send me a note and I'll get back to you -- just as soon as I've reached my 10,000 steps-a-day goal.