Spice QT-66 Usability Issues

Friends,

Nothing much to write about in this post as this is just a small sharing of information in reference to usability of mobile phones.

Recently, I bought Spice mobile QT-66 just two months back. This is the first time I am using any phone other than Noika. While using spice one, I observed two unusual things both in terms of normal usability and also when compared to Nokia devices. Observations are -

Whenever I disconnect a call without attending it then usually in Nokia devices this goes into RECEIVE CALLS but in my spice device the screen displays MISSED CALL and the entry also goes into the same option (MISSED CALLS)
Second observation is regarding the MESSAGE functionality. Whenever, I reply/type a message and then I opted to end the message screen by pressing the END key then the message gets saved into the OUTBOX folder. Usually it should be in DRAFT folder as per my usage of other devices / messaging software’s

Comments awaited on this…………………

Mobile Application Certifications

There days mobile applications are on real boom specially after the entry of mobile platforms like Iphone/Blackberry/Android. As far as testing of mobile applications is concerned , a mobile app has to be tested on functionality aspects and on other aspects as well. You might have gone through my previous post mentioning major points of consideration while testing a mobile application. In this post, I am concentrating on testing the mobile application on other aspects. One such aspect is vendor certification testing which is done in order to get your application available on different app stores so that end users can download and use it further. Due to the boom and increasing number of mobile applications everyday different mobile technology/platform vendors have provided centralized places from where user can download the available applications such as Apple app store for apple, Windows Marketplace for windows, Blackberry App World for windows, Mobile Shop for BREW. These technology vendors have provided generalized tests, In order to place/release their application to users software vendors has to get them passed through these tests.

So far, following vendors have defined their test process and provided the test cases

- BREW – The process is known as ‘True BREW Certification’ and a set of test cases provide for this is known as ‘‘True BREW Test’ OR TBT in popular.
- Windows marketplace submission criteria for placing the application on Windows market place.
- Java verified program for J2ME applications.
- Symbian signed criteria for getting the application signed by symbian

All these above concentrates on general behavior, stability and functionality of the application. These are not at all related to testing of specific functionality but concentrates on general attributes which every application should posses.

Build Installation Procedure for Brew Applications

When a BREW application build is released for testing, it basically comes under two different folders as follows –

- Arm
- Win


ARM - This folder contains files which are to be loaded on actual mobile device. It should contain following 4 types of files

- .mod
- .mif
- .bar
- .sig

All these files are loaded on actual device for testing. MOD file contains the compiled code of the application for BREW handsets. MIF (Module Information File) contains icon, thumbnail etc of the application. This file is used by the handset to identify the application. BAR file contains resource files like images, text etc and SIG file is digital signature file which is unique for every handset, we can generate it by providing ESN/MEID of the handset. This file and is independent of the application but dependent on the handset.

These are minimum number of files needed to load and run the application on the BREW device. While loading SIG file name should be same as MIF file and the name should be in small letters. Generally the arm folder is renamed the same as MIF file and the whole folder is drag and dropped onto handset once the handset is connected to the PC through BREW apploader. Remember to power cycle the handset after loading the build.


WIN – The content of this folder is basically used when the application is to be tested on emulator. This folder contains minimum three types of files

- .dll
- .mif
- .bar

DLL contains compiled code of the app for emulator/simulator. MIF and BAR are same as above. The process to load the application into the emulator / simulator is as follows –

1. Copy this folder to ‘Examples’ folder of the BREW emulator / simulator which we are using (SDK 2.0.1/SDK 3.1.5) and rename the folder to the ‘Application Name’.
2. Rename the .dll and .mif files to the name same as the parent folder. Make sure that the folder name, .dll file name and the .mif file name should be same.
3. Copy the .mif file to the main folder ‘Examples’
4. Copy the device files / folder (Emulator) to the devices folder of the BREW emulator
5. Launch the emulator and then load the device on which we have to test the application.
6. Launch the AUT for testing.


Happy testing !.......................

Major points while testing a Mobile Application

Article content: Major points while testing a Mobile Application
This is my first blog post and I am sharing some basic points to be considered while testing a mobile application (Currently, I am working on it) are –

• Navigation of the application - We need to verify the whole navigation of the application and need to find out the dead ends . Traverse whole application, every possible path and come back to the starting point. In this way we can find out the dead ends, inconsistency in the navigation and lot other things.

• GUI of the application – Most of the mobile applications are developed for one platform / screen resolution and ported on other platform (Platform Porting) OR on devices with different resolution (Device Porting). In this process , there are many GUI issues which gets introduced in the application. These issues should be reported and addressed carefully.

• Behavior of the application on Call/SMS (Suspend/Resume) especially on entry screen & popup screen – This is one of most important activity while testing a mobile application be it a game / application residing on device OR application using communication protocols. Mobile applications using internet / client server communication needs to be tested for this scenario on the screens / process establishing network connections.

• Behavior of the application on pressing CLEAR key & END key – This is also one of the most important testing activity while testing a mobile application. When implemented default, CLEAR key takes the user back to the previous screen and END key ends the application. It needs to be tested carefully as there are chances of application crash. In my experience, I found one interesting bug for developers with CLEAR key. There was one data entry screen with default letter displayed in the text box. Now when the user taps on the text box and presses CLEAR key to clear the data, type in special characters in the text box the application was crashing.

• Behavior of application when memory is almost full (MaxFileCount) – This test is important when your application is creating any file(s) on the user device. Many times developer does not handles this situation well and the application crashes by giving a unfriendly error message (Exception found.. )

• Behavior of the application on application directed SMS (Syntax is “//brew::”) – This test is one of the most important in BREW applications. By this we test the behavior of application by sending the message to invoke the same application while it is running in foreground.

• In BREW applications apart from functional tested cases prepared we also need to execute standard set of test cases provided by the NSTL.

• Sound functionality of the application (if applicable)

• Timer functionality (specially on Suspend/Resume)