Testing Smoke Detectors

People rely on software more every year, so it’s critical to test it. But one thing that gets overlooked (that should be tested regularly) are smoke detectors.

As the relatively young field of software quality engineering matures with all its emerging trends and terminology, software engineers often overlook that the software they test has parallels to something they should test regularly at home: their smoke detectors.

A silent smoke detector gives occupants peace of mind; no news is good news. But smoke detectors need to be tested periodically to assure they are still alive and are capable of saving lives. Since humans are relying more and more on software every year, testing is critical. Software bugs can result in a broad spectrum of consequences, from wrong typefaces, to a catastrophic loss of lives.

A smoke detector has essentially three components: a power supply, a smoke sensor, and an alarm unit. Each component is tested in a different manner, individually, and combined. Similarly, modern software is divided into individual modules written by different developers, are constantly changed and replaced, and may not be compatible with each other. 

The power supply, or battery, has a built-in unit test, the LED that indicates the battery has adequate voltage. The user’s role is to habitually verify visually that the LED is on. Modern smoke detectors can throw exceptions, trigger a chirping noise or recorded voice message when the battery is weak. Still, the LED and the low power warnings only test the power supply.

The alarm unit is the main component of the user manual test. An alarm unit emits an audible alarm when it receives an input current.

This is a fairly standard test case. The input conditions are, a smoke detector is ready and installed and equipped with a battery. The input “data” is manual pressure on the test button. The expected output “data” is an audible alarm. The expected output conditions are that the device can be silenced manually and reset, also known as teardown tasks. 

The alarm unit is a black box under test. We are not concerned with how the alarm turns currents into sound, just that it sounds when triggered.

The alarm unit has presumably been unit tested at the factory. When we do a manual test of the smoke detector, we are doing an integration test of the partial system, verifying that two previously tested components, the battery and alarm unit, will function together. The alarm sounding after the test button is depressed verifies that the power supply, the alarm unit, and the connecting wires (the interface between the two units) all function properly.

The test button is not an integral part of the system under test. It is a test harness, that aids in testing. It contributes nothing to the intended purpose of alerting inhabitants of a fire. A smoke detector would function the same without a test button or an LED, we just could not test it.

The aforementioned manual black box integration test still misses one key system component: the smoke sensor. When the test button is pressed, it feeds currents directly to the alarm unit, bypassing the smoke sensor. Hearing the alarm after pressing the button does not prove that the smoke detector will react to actual smoke. A test harness feeds artificial input data, rather than output data from upstream, to a component under test, to observe output. The component undergoes bottom-up testing.

The smoke sensor is essentially a glorified switch that allows currents to pass through when near smoke, and blocks the flow otherwise. We trust the manufacturer to test the smoke sensor for a lifetime of service. A research lab presumably has some sort of “smoke room”, which simulates the structure and air flow of the rooms where end users will place the smoke detectors. Researchers can place multiple smoke sensors around the room and remotely introduce smoke of different types and concentration levels.

It is not necessary here to know how a smoke sensor actually senses smoke; the test is to verify that a smoke sensor will emit an output current when surrounded by smoke. Also, instead of alarm units, the smoke sensors under test are connected to stubs or recorders, and undergoes top-down testing. Using stubs has many advantages over real output components. 

With stubs, many different smoke sensors can be under test at once. Each stub records if and when the sensor under test emits an output current, and directly populates a database for analysis. Also, a human does not have to enter the smoke filled room when the test is underway. Furthermore, the same smoke sensors may be connected to different output devices, alarm units, voice speakers, fire sprinklers, or a direct fire department connection. A stub can be a substitute for any kind of output device. Similarly, a software module under test may be designed to call other modules which are not under test or are yet to be written; these called modules are replaced with stubs, which may be merely a single line of code to print “module xyz is called and run here”.

Of course, this testing with smoke is not to be confused with a smoke test, in which a new component is connected and launched, just to assert it will power on without “making smoke”, to determine if further testing can or should start.

A system test will verify that a complete smoke detector emits an alarm of a certain decibel level, when surrounded by smoke containing a certain carbon monoxide concentration level.

An acceptance test, following a system test, will validate that the smoke detector is suitable to protect a particular household from fire, that the alarm can wake up the residents through closed doors, and ideally will not report false positives when triggered by smoke from cooking, ashtrays, incense, and what not, given the layout of the house and the residents’ lifestyle.

It is cumbersome and dangerous to test a smoke detector with real smoke as few homeowners do this regularly. They do periodic integration tests, and rely on unit tests. Besides, many home smoke detectors get unintended system tests, when smoke from regular kitchen cooking triggers the alarm.

Fred Murphy
Fred Murphy grew up in Menlo Park where he started programming on a TRS-80. He received his degree in Computer Science from Loyola University in Maryland. Fred has done Software Quality Assurance Contracting around Silicon Valley at companies such as: Apple, Intel, Adobe, KLA Tencor, LogiGear, and many others. His hobbies include bicycling, classical keyboarding, and coding in C and Python. Fred currently lives in Mountain View.
Fred Murphy on Linkedin

The Related Post

Introduction Software Testing 3.0 is a strategic end-to-end framework for change based upon a strategy to drive testing activities, tool selection, and people development that finally delivers on the promise of software testing. For more details on the evolution of software testing and Software Testing 3.0 see: Software Testing 3.0: Delivering on the Promise of ...
This article was originally featured in the May/June 2009 issue of Better Software magazine. Read the entire issue or become a subscriber. In my travels, I’ve worked with a number of companies that have attempted to assess the quality of their testing — or worse, their testers — using poorly considered metrics. Sometimes the measurement ...
Introduction Keyword-driven methodologies like Action Based Testing (ABT) are usually considered to be an Automation technique. They are commonly positioned as an advanced and practical alternative to other techniques like to “record & playback” or “scripting”.
Back from more training, I was up at a client in Bellevue and really enjoyed teaching a performance class to a world class testing organization. I found that the students were very receptive to many of the concepts and ideas that the class offers.
Trying to understand why fails, errors, or warnings occur in your automated tests can be quite frustrating. TestArchitect relieves this pain.  Debugging blindly can be tedious work—especially when your test tool does most of its work through the user interface (UI). Moreover, bugs can sometimes be hard to replicate when single-stepping through a test procedure. ...
Introduction This article discusses the all-too-common occurrence of the time needed to perform Software Testing being short changed as specification, development, and unforeseen “issues” cause the phases prior to testing to expand. The result is that extreme pressure is placed upon the testing organization to perform the testing function within a reduced time frame. The ...
Introduction Software Testing 3.0 is a strategic end-to-end framework for change based upon a strategy to drive testing activities, tool selection, and people development that finally delivers on the promise of Software Testing. For more details on the evolution of Software Testing and Software Testing 3.0 see: The Early Evolution of Software Testing Software Testing ...
Differences in interpretation of requirements and specifications by programmers and testers is a common source of bugs. For many, perhaps most, development teams the terms requirement and specification are used interchangeably with no detrimental effect. In everyday development conversations the terms are used synonymously, one is as likely to mean the “spec” as the “requirements.”
LogiGear_Magazine–March_2015–Testing_Strategies_and_Methods-Fast_Forward_To_Better_Testing
Companies generally consider the software they own, whether it is created in-house or acquired, as an asset (something that could appear on the balance sheet). The production of software impacts the profit and loss accounts for the year it is produced: The resources used to produce the software result in costs, and methods, tools, or ...
Internet-based per-use service models are turning things upside down in the software development industry, prompting rapid expansion in the development of some products and measurable reduction in others. (Gartner, August 2008) This global transition toward computing “in the Cloud” introduces a whole new level of challenge when it comes to software testing.
This article first appeared in BETTER SOFTWARE, May/June 2005. Executives and managers, get your performance testing teams out of the pit and ahead of the pack Introduction As an activity, performance testing is widely misunderstood, particularly by executives and managers. This misunderstanding can cause a variety of difficulties-including outright project failure. This article details the ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe