Greetings

This is the second entry in my blog series on Hopper testing. The blog is targeted at QA engineers familiar with the Microsoft Hopper test.

In this entry, I’ll introduce the Hopper Run model and talk about Hopper test coverage.

QA engineers need to be aware that Hopper is a great test for uncovering defects but that it does not test the complete functionality of the device.

For example, during Hopper:

• The device is not connected. No ActiveSync, no GPRS, no Wi-Fi. Why? Consider the case of if the Hopper.exe application generated a random key sequence that dialed an emergency number like “911” or called the same person 1000 times. It could happen and that’s not what we want to test.

• No hardware configurations can be changed. For example, an SD card could not be inserted during the test. Why? If inserting an SD card auto-launched a program, then it would interfere with Hopper’s random testing.

• No power state (i.e. suspend/resume) transitions are allowed – unit must be connected to AC power. Why? What if the device went into suspend after one hour and resumed until hour twenty-four of the twenty-five hour test period. The device would only undergo random input testing for two hours instead of twenty-five.

QA engineers need to be aware of limitations of what Hopper tests. They need to plan alternate user scenario testing to exercise power management, suspend/ resume, and connectivity (i.e. file transfer over Bluetooth).

In my next blog, I’ll discuss how Chaos Theory is a good model for Hopper.

. . . . . . . . . . . . . . . . . . . . . . .
Mauricio Soto
Senior Software Engineer
Professional Engineering Services
BSQUARE Corporation | Contact Me!