Skip to content

A lesson in testing from a malfunctioning Key Fob

I bounced down the stairs, eager to get into my car and start my road trip. I fumbled in my purse for my car keys. As I grasped my hand around the familiar clunk of metal, I made an attempt to remotely unlock the doors of my car using the key fob. The remote command seemed to vanish into thin air, midway. I made one more attempt. Still no response. Now I was stabbing at the unlock button perched on the top right corner of the key fob. I tried the other buttons – lock, open trunk, still no response.

I fathomed the key fob had turned hostile on me. It was one of those moments when it was time to make an assessment of what would you expect a high-quality key fob to do.

  • Must have a button, that when pressed, must remotely unlock the doors of a car
  • Must have a button, that when pressed, must remotely lock the doors of car
  • Must have a button, that when pressed, must remotely open the trunk of a car
  • Must have a button, that when pressed, must cause the car to sound an alarm
  • Should be of a size, that can be operated using a single human hand
  • Should allow for the user to issue remote commands to the car when the user is within a certain distance from the car, such as 200 yards
  • Should ensure that remote commands issued to the car, must go into a black hole of the user is outside of the operational range within which the buttons work

You can identify additional test cases that constitute the expected behavior of a high-quality key fob. But now I was holding a defective product in my hand. So instead of dash off to the nearest gas station to fill my car up before embarking on the road trip, I found myself face to face with a representative of the Parts department of the closest dealership from home.

One look at the key fob and he knew what the problem was. The battery was all out. He dismantled the key fob and replaced the battery. Did he proceed to run the above set of test cases to confirm that the key fob was exuding the expected behavior?

He took out a kit from under his desk. He opened the kit to reveal a panel with a small switch on one side and two peppercorn-sized light bulbs. He laid the key fob flat on the green velvet surface of the panel and confirmed that the light bulb blinked green twice. Those were the tests that he ran to confirm that the problem was resolved.

He handed me the key fob and sure enough within minutes I was back on the road.

In this context, if the root cause of the issue is addressed then all that needs to be tested is whether the root cause of the issue has been resolved and one does not need to execute on all of the functional test cases to confirm that the issue has actually been fixed. And the test cases to test whether the root cause has been addressed does not are not necessarily the same as the test cases that will confirm that the product or application demonstrates the expected functionality.

When testing a software application, one of the first things to identify are the nuts and bolts that hold the application together. If these components of the application are not in working order, the application will consequently, not work at all. This led me to identify a new type of testing which for now I will call (for lack of a better phrase), lynchpin testing.

Think of what constitutes the lynchpins of your application. It can be the server hosting the application. If the server is down, the application will not work. Would you include a working server as a pre-condition to the execution of a test case?

The typical construct of a test case includes pre-conditions. However the pre-conditions should be documented to communicate the immediacy of the conditions that need to be met in order to execute the test case, you do not have to start from the very beginning of the evolution of mankind to establish the pre-conditions.

A lynchpin test suite is a set of test cases that confirm that the nuts and bolts that hold the application together are working. It is a mix of unit test cases and integration test cases that confirm that the software application meets a baselined requirements for it to perform its functions.

Published inTesting fable