2. Hardware + Software = Complexity
“Whenever you add complexity to a testing problem …
… you add risk and unpredictability.”
“When you add risk …
… you have to add additional testing to mitigate that risk.”
“But you have to add the right types of tests
… that are specifically designed to asses the added risk.”
3. Integration tests
• Isolated tests drive good design and facilitate debugging,
and integration tests do the opposite, so keep them to a
minimum [1]
• Integration tests should only be motivated by potential
risks related to integration, and designed specifically to
asses those risks [2]
• Testing should be done early and as an integrated part of
the development process – problems found during
integration testing that could have been found earlier add
unnecessary costs
4. Probe – Sense – Respond
• When dealing with complex problems, you should adapt
an exploratory mindset, as relationship between cause
and effect can only be perceived in retrospect [3]
• Don’t just run a predefined integration test suite, see all
the green lights, and go happily about with your life
• Make an initial risk analysis, set a course of action,
inspect the results, and adapt your course based on those
results
5. Hardware/Software Integration Tests
• These are some of the hardware/software integration problems I have
seen in mobile phones and mobile games, in my specific context
• Stability
• Stability problems are archetypical of high complexity products – unpredictable,
intermittent problems which are often hard to find and reproduce
• Performance
• Very difficult to completely assess before hardware integration
• High Hardware/Software Dependency Functionality
• Mobile Camera
• Usability
• Different display sizes and resolutions
6. References
[1] Integration Tests are a Scam
https://vimeo.com/80533536
[2] What is Integration Testing?
http://www.satisfice.com/blog/archives/1577
[3] Cynefin
https://en.wikipedia.org/wiki/Cynefin