Archive for September, 2012

PPTs for Cookie Testing:

For  download ppts for cookie testing  Click Here

Data Driven Script:

In MonkeyTalk you can use/create the Data Driven Script by using RunWith action and three files are required for Data Driven Script.

1. Main file– Its extension is .mt.In this main script is written.

Vars * Define user pass
Input username tap
Input username EnterText ${user}
Input password EnterText ${pass}
Button LOGIN Verify LOGIN %thinktime=1000
Button LOGIN tap
Label * Verify “Welcome, ${user}!” %thinktime=3000
Button LOGOUT VerifyNot LOGIN
Button LOGOUT tap %thinktime=5000

you can view tabular form of Tabular form script:


2. Driver script: Its extension is .mt. This script is use to run the main file.

Script RunWith credentials.csv

you can view tabular form of Tabular form Driver script:

3. CSV File:Its extension is .csv.

You can create csv file in your MonkeyTalk project by following below mentioned steps :

Right click on project folder

new >>other >>Click on General >>choose file >> give a name with extension .csv

Now  in this file give values for variables which you are defined in main file/script. In first row of this file mention variables name separated by space which you have define in main file.

user pass

you can view tabular form of Tabular form csv file:

MonkeyTalk Parameterized script:

Passing variable values through driver script. Value for variables can be passed as arguments in a driver script. The only requirement is that they should be provided in the same order as they are declared. We have two scripts here one is the main code (driven) script and the driver script.

In MonkeyTalk form:

# Driven script (

Vars * Define paswords user

Input username EnterText ${user}

Input password EnterText ${pass}

Button LOGIN Tap %thinktime=500

Button LOGOUT Tap %thinktime=3000

You can view the tabular form of driven ( script which i have created:

# Driver Script

Script Run john “mypassword”

Script Run john1 “mypassword1” %thinktime=3000

Driver script in tabular form:

Parametrized script by using default  values:


Vars * Define username=Jyoti  password=test

Input username EnterText ${username}

Input password EnterText ${password}

Button LOGIN Tap %thinktime=3000

Label * Verify “Welcome, ${username}!” %thinktime=3000


17:03:44.664: Started Script Playback

17:03:44.673: Vars * Define username=Jyoti pw=test

17:03:44.681: Input username EnterText jyoti

17:03:45.340: Input password EnterText test

17:03:46.004: Button LOGIN Tap %thinktime=3000

17:03:49.180: Label * Verify “Welcome, fred!” %thinktime=3000

17:03:53.327: Completed Script Playback – OK

when we send the parameters through driver script

Script Run pooja

In this case username argument will take pooja and password argument takes default value i.e. test


17:09:05.839: Started Script Playback

17:09:05.843: Script Run pooja

17:09:05.848: Started Script Playback

17:09:05.851: Vars * Define usr=jyoti pw=test

17:09:05.855: Input username EnterText pooja

17:09:06.614: Input password EnterText test

17:09:07.088: Button LOGOUT tap %thinktime=3000

17:09:07.297: Button LOGIN Tap %thinktime=3000

17:09:10.543: Label * Verify “Welcome, pooja!” %thinktime=3000

17:09:11.158: Completed Script Playback – OK

Steps to record actions from emulator to MonkeyTalk IDE:

1. Open Eclipse.

2. Import project in eclipse and convert it to AspectJ by following steps mentioned on “ “link.

3. Open Emulator.

4. Deploy your application to an Android device or emulator.

     Right click on Android project

     Choose “Run as” option and then “Android Application”

5. Open app in emulator for which you want to record script.

6. Open MonkeyTalk IDE and Click on the connection dropdown button on the tool bar (on initial start up it will be the green android icon).

7. Choose “Android Emulator” or “iOS Simulator”.

8. If connection was successful, a message to that effect should appear in the console.

9. In case record button is not visible to you can try

     Create a new AVD (emulator)

     Install a fresh app in emulator

     Stop and restart the server by:

     adb kill-server

     adb start-server

10. Create a MonkeyTalk project in MonkeyTalk IDE.

11. Then Create script under this MonkeyTalk project and Click on record button.

Installation of any App in Emulator:

Installing App in Emulators need the .apk file which we can find in the sameproject folder.

Path of the .apk file: workspace> project> bin\

There are different ways of installing Android App (.apk file) in emulators as mentioned below:

Way 1: If we are using Eclipse version 3.7.2, then on executing the Android project in Eclipse (without throwing any error) will automatically install the App (.apk file) in emulator (make sure the Emulator is open while executing the Eclipse Android project).

Way 2: We can also install the Android App (.apk file) through ‘adb’ (Android Debug Bridge).

adb is a versatile command line tool that lets you communicate with an emulator instance or connected Android-powered device.

Path of adb: Drive\android-sdk-windows\platform-tools

‘adb’ used for installing any App in Android. As per mentioned command in screenshot is used for installing any app.

Installation Command is:

adb install demo.apk

[adb( command) install (command) demo.apk (path of.apk file of  demo android project)]

have a look on sceenshot for reference:

Note: Emulator should be already opened while installing any App into Emulator

Setup Process for Eclipse and Monkey Talk:

In order to start with Mobile App testing, there are some pre-requisites software/packages which we need to install/unzip on machine.


•   Eclipse setup

•   Android SDK setup

•   ADT Plug-in for Eclipse

•   Monkey Talk Tool (Testing tool for Mobile Apps Testing)

•   AJDT (for AspectJ conversion)


Download Eclipse from URL:

Version: Eclipse Classic 3.7.2 (Windows 32 Bit)

No need to install the Eclipse, just unzip the downloaded folder anywhere in local drive. That will provide the ‘eclipse.exe’ which will open the Eclipse framework.

On opening the Eclipse framework, it will ask for the location of ‘workspace’ folder (‘Workspace’ is the location where the entire Eclipse project will be saved). Make any workspace folder anywhere in your machine and give the location.

Now Eclipse has successfully configured. Now we can open Eclipse, write any program and can save program to workspace folder.

Android SDK setup:

We need to setup and configure Android with Eclipse. Basically it is for development process but in case if we need to check how’s the application behave we can have a look on such the application in eclipse.

Download Android-sdk-windows (android-sdk_r18-windows) from the following URL:

No need to install the Android, just unzip the downloaded folder (android-sdk_r18-windows) anywhere in local drive. That will provide the ‘SDK Manager.exe’ (which will open the Android SDK Manager) and ‘AVD Manager.exe’ (which will open the AVD Manager).

a ) SDK Manager: used for installing the Android packages

  • Run the ‘SDK Manager.exe’ (can be found in the ‘android-sdk-windows’ folder)
  • Android SDK manager will provide the list of package to install
  • Install any of the package (like Android 4.0.3 (API 15))

b) AVD Manager: used for creating the Virtual Device (emulator)

•Run the ‘AVD Manager.exe’ (can be found in the ‘android-sdk-windows’ folder)

•‘Android Virtual Device Manager’ window will be open.

•Click on New> and follow the steps as shown in below screenshot:

Name: name of Virtual device (or emulator

Target: version of Android emulator which you are going to use

CPU/ABI: for Android, use ARM

SD Card ‘Size’: it could be 512MB or 1GB

Snapshot: checked (best practice) [It will keep the track if any activity killed or process crashed, if its enabled we can restore the session ]

Skin ‘Built-in’: HVGA (for Android)

Click on ‘CreateAVD’. It will create the AVD which will be seen in ‘Android Virtual Device Manager’ under ‘AVD Name’ section.

Select the AVD name and click on ‘Start’. ‘Launch Option’ pop-up will be open. Then click on ‘Launch’.  It will open the Android emulator.

ADT plug-in for Eclipse:

ADT plug-in extends the capabilities of Eclipse to let you quickly set up new Android projects, build an app UI, debug your app, and export signed (or unsigned) app packages (APKs) for distribution.

To install ADT plug-in:

• Start Eclipse> Help > Install New Software….

• Click Add, in the top-right corner.

• In the Add Repository dialog that appears, enter “ADT Plug-in” for the Name and the following URL for the Location:


• Click OK

Restart the Eclipse. It will ask for the Android SDK (which is we have already install as above mentioned steps) so Just give the location of Android SDK path.

Now while looking on the Eclipse, TWO newly added icons will be shown.

These TWO icons are for ‘AVD Manager’ and ‘Android SDK Manager’.

Now Eclipse is configured with Android SDK.

Monkey Talk:

Monkey Talk can be downloading from the below address:

Pre-requisit for installing Monkey Talk Agent:

For installing the Monkey Talk Android Agent, first we need to convert Android project into AspectJ.

For doing so, we need to configure AJDT in Eclipse by following steps:

Eclipse> Help> Install New Software > Click on Add…

In ‘Add Repository’ popup:

Name: AJDT


Click Ok. It will configure the AJDT with Eclipse.

Android App Test Cases (UI Related Scenarios):

  • Verified that Alignment should be proper.Expected result: Alignment should be proper.
  • Check each and every buttons, images Pixels as per wire frame/page schematic or screen blueprint.Expected result: Dimensions must be same as defied in wireframe.
  • Verify that Proper images size displayed in well manner with Orientation.
  • Verify that all Spell check are correct on Alert, error popup,Error messages etc.
  • Verified that Spinner (Size, Types) should be suitable as per screen.
  • Verify that application Logo should not be blurred and App title should not be misspelled (Means whole logo text should be displayed))
  • Verify that Font size should be consistent.
  • Verify that any kind of text should not be cutting off.
  • Verify that any kind of graphics should not be blurred, Check with different resolution Devices (Like BB have Different resolution for all devices, iPhone 3Gs or iPhone 4)
  • Verify that application must not perform inappropriate actions while thinking or rendering by making user input while the application or handset is busy processing or rendering.There must be no inappropriate reaction by the Application.
  • Verify that On Taping (Single Tap) Application Logo , Application Splash should display.
  • Verify that Application Splash Should not display More than 4 Second
  • Verify that there is visual feedback when response to any action takes more than 3 seconds.
  • Verify that each screen should be visible for the time necessary to comfortably read all its information by moving between screens of an application. Each screen must be visible for the time necessary to comfortably read all its information.
  • Verify that error messages in the Application must be clearly understandable.
  • Verify that error messages must clearly explain to a user the nature of the problem, and indicate what action needs to be taken (where appropriate).
  • Verify that any function selected in the Application should start within 5 seconds.
  • Verify that there must be some visual indication that the function is being performed like
     – prompting for user input;
    – displaying splash screens or progress bars;
    – displaying text such as “Please wait…”, etc
  • Verify that If the screen requires data entry on a specific field, should identify the required fields with a red asterisk and generate a friendly warning if the data is left blank
  • Verify that If the screen contains dates, numeric, currency or other specific data types, ensure that only valid data can be entered.
  • Verify that If the screen contains text boxes that allow data entry, ensure that the width of data entered does not exceed the width of the table field.
  • If the information in the screen is not self-explanatory to the casual user, should provide onscreen instructions to aid the user.
  • If the screen takes more than 5 seconds to display the results/page, it should contain a progress bar so that the user understands the processing is continuing.
  • The screen look, feel, and design should match the other screens in your application. (Application should match with the Wireframe or design document provided).
  • If the screens contain abbreviations (e.g. Nbr for number, Amt for amount, etc), the abbreviations should be consistent for all screens in the application.
  • If the screen allows changing of data without saving, it should prompt users to save if they move to another record or screen.
  • If a person deletes an item, it is a good idea to confirm the delete. User should be prompted with confirmation alert.
  • If the user interface uses combo boxes (drop down lists), be sure to include type ahead (if there are hundreds of items in a list, users should be able to skip to the first item that begins with that letter when they type in the first letter).
  • Ensure the test cases look for grammar or spelling errors.
  • If the application lists information in table format and the data in the table extend past one page, the scrolling should scroll the data but leave the table headers intact.
  • If fatal errors occur as users use your application, ensure that the application writes those errors to a log file, event viewer, or a database table for later review. Log the routine the error was in, the person logged on, and the date/time of the error.
  • Ensure that error messages are informative, grammatically correct, and not condescending.
  • If the application allows short cut keys for copy/paste etc, should test each and every short cuts
  • Do not show menu items that are not available for the context users are currently in.
  • Use a style guide to document what choices are available for dialog boxes. Application should not have Save/Cancel dialog on one screen and an OK/Cancel on another. This is inconsistent.
  • Ensure that the screen font family matches from screen to screen. Mismatching fonts within the same sentence and overuse of different fonts is not allowed.
  • Ensure that the screen font sizes match from screen to screen. A good user interface will have an accompanying style guide that explicitly defines the font type and size for headers, body text, footers, etc.
  • Ensure that screens do not use different color sets as to cause an guide should define header colors, body background colors,screen background color, footer colors, etc.
  • Ensure that icons are consistent throughout your application by using a common icon set. For example, a BACK link that contains an icon next to it should not have a different icon on one screen versus another. Avoid free clip-art icons.
  • Ensure that narrative text appears at the same location on the screen on all screens.
  • Ensure that narrative text, error messages and other instructions are presented in laymen’s terms but are brief and to-the-point.
  • If your application has links on the screen (e.g. Save as Spreadsheet, Export, Print, Email, etc.), ensure that the links have consistent spacing between them and other links, that the links appear in the same order from screen to screen, and that the color of the links are consistent.
  • If your application has menu items, ensure that menu items that are not applicable for the specific screen are disabled and the order in which each menu item appears is consistent from screen to screen.
  • If your application has buttons (e.g. Submit, OK, Cancel, etc), ensure that the buttons appear in a consistent order from screen to screen (e.g. Submit then Cancel).
  • Tabbing will go onto the next field on the screen

Test cases for android app testing:

Memory Related Scenarios:

1. Fill up the Full phone memory with other files and data, and then try to install the APP on the phone.

Expected Result: The APP should not get installed on the phone and the user should be shown a native warning from the phone OS.

2. Fill up the memory with files and data and leave exactly the same amount of memory required for the installation of the APP.

Expected Result: APP should get installed on the phone, but as you launch the APP the phone should refuse as it doesn’t have even 1 KB of extra space that the APP might require to cache some data.

3. Leave only a small amount (5-7 KB) of space for the app to run. While you are in the app and continuously making server calls this memory will also get filled up.

Expected Result: The app should give a warning stating low memory.

Note: Checking point number 3: Ensure that there is no memory card in the phone. You can fill up the memory using Image files. You can also re size the images to so that 5-7 KB of memory is left out.

Some general Scenarios:

Application start/stop behavior-

1. Start the application by selecting the icon or following the steps outlined in the submission statement. Navigate to the Task Manager and check that the application appears there.

Expected Result: The app should be appearing in task manager.

2. Close the application from within the application UI and then return to the Task Manager. Navigate to the Task Manager and check that the application appears there.

Expected Result: The application must no longer be running and must no longer appear in the task manager.

3. An application which must run in the background does not need to appear in the Task Manager or present a UI.

Note: Developer justifies/Provide this behavior during submission.

Application credentials:

1. With the application running, check the name of the application displayed on the phone. The application must display the same name on the phone as stated during submission.

Expected Result:  The application must display the same name on the phone as stated during submission.

No disruption to text messages:

1. With the application installed and running, send a text message to the test device.

Expected Result:  The incoming text message must be notified to the user as per their alert settings.

2. Read the text message on the test device and choose to reply. Send the reply.

Expected Result: The reply must be received at the second device.

3. From the standby screen on the test device, navigate to the “new text message” option and create a new message. Send the message to the second device.

Expected Result: The message must be received at the second device.

Auto-start behavior:

1. With the application running, find the settings for the application — either within the application itself or from the settings option on the device.

Expected Result: There must be an option which allows the user to enable/disable auto-start functionality.

Note: Depends upon application.

2. Ensure that the setting for auto-start behavior is disabled, and restart the device.

Expected Result: The application must not start on device boot.

MonkeyTalk Command:

MonkeyTalk Commands are very easy to understand. Even non programmer can easily  understands the MonkeyTalk commands.

MonkeyTalk commands are newline terminated and have the following syntax:
ComponentType  MonkeyId  Action  Argumets  Modifiers

These all are parts of MonkeyTalk commands. ComponentType.Action is known as the command name. MonkeyTalk command are terminated by new line.

Description of each part of MonkeyTalk command:


This part ofMonkeyTalk command is required field i.e. mandatory field. In this part you have to mention the type of component on which we want to perform action. For example Button, Slider, Spinner etc. Component types are not case sensitive.


  • This part ofMonkeyTalk command is also a required field i.e. mandatory field. An identifier that is used to distinguish between components of the same type being displayed simultaneously.
  • Monkeytalk ids are case sensitive.
  • MonkeyId can be specified as asterisk (*), which finds the first matching component.
  • MonkeyId’s can also be specified as a 1-based (not zero-based) index of the form #N.


This part ofMonkeyTalk command is also a required field i.e. mandatory field. In this field you have to mention the action to be performed. Examples Tap, Select, Drag, Swipe, EnterText. Actions are not case sensitive.


This part ofMonkeyTalk command is not a required field. It is required according to ComponentType and Action .Arguments are separated by space. If an Argument is required but not specified,it takes on a default value.


It is an optional field. There are three system-defined modifiers:

  • %timeout – how long in ms to continue retrying a command before timing out
  • %thinktime – how long in ms to wait before executing the command for the first time
  • %retrydelay – how long in ms to delay between retry attempts

IMPORTANT POINTS (points to be remembered)

  • MonkeyIds and Args are case-sensitive, but CommandTypes and Actions are not.
  • All tokens are space-separated.
  • Values with embedded blanks must be enclosed in quotes.


Tap on a button with label login:

In MonkeyTalk i.e. in .mt form

Button LOGIN tap %thinktime=3000

In javascript form i.e. in .js“LOGIN”).tap({thinktime:”3000″});

Where button is componenttype, login is monkeyid and Tap is action and thinktime is modifier.