 |
|||||||||||||||||||||
|
|||||||||||||||||||||
| January 21, 2008 ___________________________________________ QA Focus: Windows Mobile Hopper Testing This is the third entry in my blog series on Hopper testing. The blog is targeted at QA engineers familiar with the Microsoft Hopper test. A Windows Mobile device, like a Smartphone, can be used in an infinite number of ways. A college student can use it to listen to music, a salesman can use it for its calendar and contacts features, a teenager can use it for text messaging. The Microsoft Hopper certification test tries to replicate those infinite possibilities by randomly pressing buttons and accessing features for 25 hours or until the device fails – whichever comes first. Because of the random nature of the test, debugging a failure can be a tremendous challenge. The test keeps logs for only the five minutes leading up to the failure. The actual cause of the failure may have been something done during that time, but it’s more likely to be the result of a condition triggered minutes – or even hours – before the log started. It’s tempting to try to recreate the entire failed Hopper session, but that’s a monumental challenge that likely won’t pay off. While the Hopper tool allows you to pass a random seed value that would theoretically cause the test to follow the same path, slight timing differences can cause the sessions to diverge. You could waste days trying to replicate a Hopper session and still not yield any clues as to what caused the failure. That’s why Microsoft does not use that approach. Instead, it’s important to learn from chaos theory, which says there’s an order to behavior that appears to be random. Do the failures in respective Hopper runs come at the same point in time? Are there any similarities in the device condition at the time of the failure? Uncovering those patterns will help you uncover the cause of the failure.
. . . . . . . . . . . . . . . . . . . . . . . |
|||||||||||||||||||||
