Beyond the publicity and hype about the Internet of Things (IoT), a new term is emerging—the Internet of Everything (IoE). What are people talking about? Should you be interested? What does it mean to testers and development? Paul Gerrard shares his perspective on the scale, variety, ubiquity, complexity, and challenge of this technological wave that many believe will dominate our industry into the next decade. Right now, the IoT/IoE is very confusing. Although standards are emerging, many commercial applications are bleeding edge, speculative, or exploratory. While security and privacy concerns dominate the discussion today, significant functional, user experience, integration, and complexity challenges await us. The IoE brings broader societal risks that must be addressed by organizations, individuals, and their governments. Paul presents a seven-layer architectural model to help you make sense of it all. Take back a set of key questions you need to ask and recommendations for formulating your test strategy for the Internet of Everything.
Paul Gerrard
Paul Gerrard is a consultant, teacher, author, webmaster, programmer, tester, conference speaker, rowing coach, and publisher. He has conducted consulting assignments in all aspects of software testing and quality assurance, specializing in test assurance. Paul has presented keynotes and tutorials— occasionally award winning—at testing conferences on four continents. He is a principal of Gerrard Consulting Limited, the host of the UK Test Management Forum, and the Programme Chair for the 2014 EuroSTAR testing conference. In 2010, Paul won the EuroSTAR Testing Excellence Award. He's been programming since the mid-1970s and loves using the Python programming language.
Models exist all around us. To the untrained, models appear rather esoteric. In fact, our brain is a fantastic modeling engine. How do you think we can move without collision, use language, reason, and make sense of our world? Paul Gerrard explains how models underpin the common test methods. We testers can use models at every level of our work—to simplify the testing problem, to scope the testing tasks, to communicate with stakeholders and peers, to inform test design/selection decisions, and to measure coverage or progress in our work. Rather than guessing what to test, models can be the basis of effective test design. Some models come “for free” in documentation—state models, decision tables, and use cases. Sometimes we have to craft our own. Some models are written down; others exist solely in our minds. Join Paul as he explains why test techniques can be difficult to use systematically and how you can model a testing problem to exploit your innate testing powers.