First Assume what is the purpose of mobile handset-then you
will get an idea of what you want to do-then convert those
ideas as test scenarios-then start writing test case for
Example:you use mobile for calling somebody--for that what
you do-you either search from existing contact list or you
just enter number-now what is the flow of action ,write as
Step1:User enters the number by pressing the numeric keys
Expected result:number gets displayed simultaneously as the
user presses the button.
Step2:User then clicks the call green button.
Expected:Connecting symbol should appear on the screen with
simultaneous audio signal and shows connected symbol once
and in this way the flow of steps can be continued
depending on the scenarios defined.
For example take another scenarios of adding contact to
Step1:User presses the menu option or shortkey defined.
Expected:User is taken to menu options
Step2:User selects the address book.
Expected:Address book menu is displayed with sub menu
options as add contact,delete contact,view contact etc.
Step3:User selects the Add contact.
Expected result:Add contact screen is opened requesting
user to enter various fields like Name,number,add picture
Step3:User enter the mandatory fields and clicks on the
ok /chooses the save option button
expected result:New contact is added successfully and
displayed in the contacts list when searched by the various
consider the fact that a large array of handsets come out
frequently; the Android is probably most like this; So
automation comes into play. Consider the Blackberry RIM.
Since it has a tool that allows you to capture screen
shots(called JAVALOADER) this gives you the ability to save
various templates of what screens should look like in
different steps of the test. These types of tests are very
'stateful' in nature, so at least all functions that can be
activated using AT modem commands to dial out, hang up,
reset handset(turn on and configure various modes using
engineering screens), perform WIFI and UMTS packet sniffing
to parse out packets under given test conditions, and many
other functions can be invoked all under program control.
Consider forcing failures and monitor how the handset/tablet
responds. Also, some tests such as battery life / current
drain of handset under test Li-Ion battery can be assessed
using connected OEM electronic test equipment. consider
that FCC / ISO standards tests can also be done in this
manner by providing I/O stimulus. Then, of course, data
sets can be evaluated after subsequent test session run
times to look at statistical variance and flesh out both
desired / undesired trends then compare input test case(s)
against the actual results.
- of course there are manual test cases as well, which
should be considered. it can be costly to create
automation, but once in place and is robust, then it can be
retooled and reused for other purposes down the road
provided that it is designed properly(OOP).
last thing; it is important to record IMEI, handset
firmware versions as well for test session runtime(as well
as peripheral device firmware versions). you get the
handset from the manufacturer with the so called board
support package. the software that goes on top is what
makes it a T-mobile phone or a Verizon phone.
For a functionality 50 test cases are passed and we released
the code with all the test reports etc etc.. But in customer
side all the 50 test cases are failed.
How will you answer for this error to ur manager and Customer?