Testing embedded software and systems for the Internet of Things has to involve physical, sensory and emotional interactions says Gerie Owen, a Business Solutions Analyst from Northeast Utilities.
Gerie Owen will give a workshop about Testing the Internet of Things: The Human Experience at the International Conference on Software QA and Testing on Embedded Systems. At the same conference Peter Varhol from Aras Corporation will give a talk on Testing in the M2M World.
InfoQ interviewed Gerie and Peter about how testing differs for the internet of things and embedded software and systems, and on dealing with the expectations and experiences of people in testing.
InfoQ: You will be talking at QA&Test about testing the Internet of Things (IoT) and Human Experience in testing. Can you briefly explain what the internet of Things is?
Gerie: The Internet of Things (IoT) is an overarching term for a world in which objects, animals and people are connected wirelessly, encompassing machine-to-machine communication and wearables. Kevin Ashton, co-founded of the Auto-ID Center at MIT, which created a global standard system for RFID and other sensors, coined the phrase "Internet of Things" in 1999.
InfoQ: How does testing embedded software and systems differ from testing desktop and web applications?
Gerie: Mobile and embedded software and systems are more closely related to the user. Mobile and embedded devices, more than any other technology, are an integral part of our lives and have the potential to become a part of us. This generation of mobile and embedded devices interacts with us, not just awaits our keystrokes. They operate in response to our voice, our touch, and the motion of our bodies.
InfoQ: The way user interact with mobile or embedded devices matters. How does that impact testing?
Gerie: Since all of these devices actually function with us, testing how the human experiences these devices becomes imperative. If we do not test the human interaction, our assessments and judgments of quality will be lacking some of the most important information needed to determine whether or not the device is ready to ship. Why is “human experience” testing so important to mobile and embedded devices? What makes this different than what we have done in the past? Because when a mobile device is physically attached to us and works with us and through us, the more important the results of the interaction or collaboration becomes to us emotionally and physically. The user, a human being becomes a part of the “ internet of things”
InfoQ: People can have different expectations and experiences when using smartwatches or other wearables. Doesn't that make testing very difficult?
Gerie: Absolutely! “Human Experience” testing has the following components of human interaction with the device. We must test all things physical, including sizes, shapes and genders of the users. We must test all sensory reactions including sight, sound, and touch. Orientation, or the interaction with human movement is an incredible crucial part of the test.
We must plan for testing in various geographical locations, different weather conditions and contexts. Finally we must consider value and most thoroughly test in terms of the users perceptions, mindsets, biases and emotions when interacting with the device.
InfoQ: Can you recommend some on-line resources for testers or things that they can do if they want to learn more about testing for the Internet of Things?
Peter: More on testing the Internet of Things. That’s a tough one, as few are doing this right now. I think most testers aren’t thinking in this direction yet. Regarding Gerie’s approach, I would recommend that testers look at their own experiences with their Internet-connected devices. If you are in some way dissatisfied, you need to question if the dissatisfaction is due to the device itself, or how it works with you. Chances are that the device wasn’t built with you in mind, even if it is a human-centered solution. I think Gerie has it exactly right, in that bringing the person into the equation makes the focus one from testing to requirements to testing for the target audience, which often isn’t the same thing.
