Complete Guide to Hoffman Box Testing in BREW By-Anurag Khode, Copyright 2009-10Overview: While testing BREW mobile application,we always have to under go with Hoffman Box Testing.Giving here all the details of Hoffmam Box Testing and Steps to conduct it. First of all lets start by what is Hoffman Box. What is Hoffman Box?• A Hoffman Box is an enclosure used to secure electrical and/or network equipment, and is used in such things as a protected distribution system. • A Hoffman Box is also a generic, colloquial term used by the mobile phone gaming and applications industry to describe an enclosure used to temporarily shield mobile devices from their carrier signals for the purposes of signal-fade and signal-loss testing in accordance with standards set forth by NSTL, Qualcomm and other certification bodies (i.e, cellular service carriers.) • Most industry Hoffman Boxes are modified faraday cages, built without an opposing electrical field running through them and often not grounded in any form. Hoffman box What is Hoffman Box Testing?• Hoffman box testing is also called as “Loss of Service” test which comes under “Adversarial” in TBT.(True Brew Testing) • Hoffman box testing means testing a mobile application when there is loss of Network. • This test is conducted to test whether application is behaving proper when there is Network problem. • Behaving proper means it should throw proper error message to User when application is not able to access network. • Application should not crash while handling thei situation. • Such type of test is carries out in all type of platforms like iphone,J2ME,SYMBIAN but this test is call Hoffman box testing exclusively in BREW. How to Conduct Hoffman Box Testing? By Conducting this test we have to check whether applcation satisfies following requirement. Requirement:• The AUT (Application Under Test) gracefully handles no-service and loss-of-service conditions. • A no-service condition will result in connection failure when the AUT attempts to establish a connection. • A loss-of-service condition will affect the AUT after a connection has been established. The requirement applies to applications using data services or voice services. Test Cases: Test Case 1: Steps/Procedure:1. Prepare AUT to initiate data call (do not start data call). 2. Place handset in Hoffman Box for 30 seconds. 3. Remove handset from Hoffman Box briefly, ensure no service (via annunciators) 4. initiate data call 5. place handset back into Hoffman box for 1 minute. 6. Remove handset and view AUT. Expected Result:• Ensure AUT handles loss-of-service during call setup. • AUT detects and responds to loss-of-service (e.g. reports error to user). Note:• Normally messages are displayed like “Network error.Please try after sometime.” • Or some times when your server is down message should be displayed like “Server is temporarily unavailable.Please try after sometime” Test Case 2: Steps/Procedure:1. Initiate data call after handset has re-acquired service. Expected Result:• Ensure AUT error handling for loss-of-service does not affect ability to successfully make data call once service restored. • AUT succeeds in making data call and transferring data, functioning as it did during exploratory testing. Test Case 3: Steps/Procedure:1. Initiate and establish data call. 2. As AUT is transferring data across data connection, place handset in Hoffman Box for approximately 1 minute. 3. Remove handset from Hoffman box. Expected Result:• Ensure AUT handles loss-of-service during data transfer. • AUT detects and responds to loss-of-service (e.g. reports error to user). Test Case 4: Steps/Procedure:1. Initiate data call after handset has re-acquired service. Expected Result:• Ensure AUT error handling for loss-of-service does not affect ability to successfully make data call once service restored. • AUT succeeds in making data call, functioning as it did during exploratory testing. Test Case 5: Steps/Procedure:1. Let handset sit idle after transfer is step 4 for linger timer plus 20 seconds. 2. Repeat step 1.(Test case 1) Expected Result:• The intent is to determine how an application handles loss of a connection that is idle or dormant after already successfully transferring data across it. • AUT detects and respond to loss-of-service (e.g. reports error to user). Test Case 6: Steps/Procedure:1. Repeat Test case 1-5 for each AUT screen or function that transfers data across a data connection. Note: The purpose is to evaluate different screens or functions provide by the AUT, not to evaluate different content types on a server that are available through the same AUT screen. Expected Result:See individual test case result Test Case 7: Steps/Procedure:1. Repeat cases 1-6 (as applicable) for an AUT that supports making voice calls. Expected Result: Note-AUTs supporting voice calls will have similar problems with call setup and maintenance. Repeat above steps for voice calls instead of data calls.• AUT supporting voice calls detects and responds to loss-of-service (e.g. reports error to user). Test Case 8: Steps/Procedure:1. Repeat case 1 for AUT that supports sending of SMS messages. 2. Instead of making data call, initiate SMS. 3. Other steps the same as that of case 1. Expected Result:• Ensure that AUT handles inability to send an SMS message. • AUT supporting sending of SMS messages detects and respond to loss-of-service (e.g. reports error to user). Test Case 9: Steps/Procedure:1. Repeat steps 1-8 for each network protocol supported by the handset (e.g. CDMA 2000 1X, IS-95B, EVDO, GPRS, W-CDMA). 2. Differences in underlying networks may affect AUT error handling. 3. AUT detects and responds to loss-of-server for data and voice calls on each underlying network. Summary: In short a Mobile Application Tester should make sure that the Application under test is able to handle Network conditions like Network losss,Weak Network or Server down conditions and so on. User should be notified with proper error messages whenever user face any network related issues. Refrence:• Wikipedia• TBT by NSTL. Document Outline
Add New Comment