Quality Assurance and Testing of J2ME Programs for Mobiles Phones

Quality Assurance and Testing of J2ME

Quality Assurance and Testing of J2ME Programs for Mobiles Phones

Name: Héctor Menéndez

CS-Id: hdm09u

Subject: G53QAT

Introduction:

Java 2 Micro Edition was born in 1999 as a programming resource used for limited devices.

Inspired in the original purpose of Java, J2ME tries to be a reference programming language for this devices using the concept of Java: “write once, run anywhere”. For this purpose every operative system implements the Java Virtual Machine (JVM) which run the bytecode generated in the Java compilation.

J2ME is divided in two sets:

• CDC (Connected Device Configuration): Used by systems that are always connected with its source: GPS, TV decoder, etc.
• CLDC (Connected Limited Device Configuration): Used by system with restrictions of memory and processing capacity. These libraries belongs to CDC.

Figure 1. Java sets. [5]

CLDC integrates some libraries called MIDP (Mobile Information Device Profile). Mobiles applications created with these libraries are called MIDlets.

A MIDlet can be interpreted as a process with three states:

-Active: The program is running.

-Paused: State used when the device have to pause the MIDlet and free resources.

-Destroyed: Final state of the MIDlet.

Figure 2. MIDlet states. [6]

Now this report will try to analyse the development process of MIDlets that work with mobiles phones.

Life Cycle:

One of the most difficult decisions is the development model. A good model could be a mix between Object Oriented Model (because is an object oriented language) and Prototype Model (because it is necessary created a prototype version before the testing phase).

Planning:

Limits of J2ME:

When a development team tries to created a J2ME application for mobiles phones, they have to consider the limits of CLDC 1.0 and CLDC 1.1 according with the costumers' specifications.

• No floating point support (Supported in CLDC 1.1).
• No finalization of Objects.
• Limited error handling (specially runtime errors).
• No Java Native Interface (JNI) (security reasons).
• No user-defined class loaders (security reasons).
• No support for reflection.
• No thread groups or daemon threads (but it supports multithrearing).
• No weak references (Supported in CLDC 1.1).

These limits include ROM and RAM memory limits that depends of each device.

Contract Reviews:

Costumers' requirements

At this point, we have to divide the applications in:

• User Interface Oriented: the costumer predetermines what kind of aesthetic is necesary and a basic functionality. This applications are normally games or entertainment programs.
• Enterprise applications: the costumer wants to integrate mobiles devices into a bigger system, for example, house automation.
• Functional applications: the application have been created to offer a service, for example, a dictionary. The costumer must define the functionality of the application and give all the information that development team could need.

Alternatives approaches

For J2ME programming it is always important to have some ways for solve the same problem because the memory limits and the velocity of processing could become a relevant problem in the testing phase.

Development risk

A complete development team of J2ME needs a big infrastructure specially in testing phase. It's important to have some mobiles emulator (some of them are expensive), specials mobiles phones like touch screen mobiles, PDAs, phones with GPS, pocket PC, mobiles phones from different companies, etc.

If the development team wants to use a framework they will have to paid the development license of it. For example, a J2ME Polish's framework license costs 1000$ for each application (15000$ for life).

Another important risk is the agreement with the costumer. We have two difference kinds of agreements:

• The costumer pays the cost of the project complete.
• The costumer pays a percentage of the profits of the product.

In both cases but specially in the second is really important to know if the costumer is trusted.

Project resources and timetable adequately estimated

It is important to know the scope of the application because the team will have to determinate the testing process. General applications need more tests than a concrete application.

Normally, a general application testing phase cover the 75% of the development. Depending of the contract it is interesting define how much time it is necessary for the tests.

1st Design and prototype implementation:

Design:

Once the costumer has specified the project, the development team creates the UML diagram for determinate the parts of the development process.

In this moment, it's easy to know the manpower needed by the project and its resources.

When the UML has been defined, the development has to begin. In this case, the team have to know what kind of interface has to be used. High level interfaces are more portable than low level interfaces based in Canvas class that are painted at pixel level. It means that it's necessary adapt it to differences screen sizes.

Implementation:

It is really useful to have an IDE compatible with J2ME like Netbeans, because it has special tools for developer that help in a lot of processes. For example, there are tools that create versions of the projects for different platforms and devices and assign different emulators.

The program size is really important when the device needs to work in several mobiles (specially games). CDLC 1.0 allows 160KB, and 32KB of RAM memory. CDLC 1.1 allows 192KB, but this is tentative because each mobile phone has its own memory limits (usually higher).

1st Prototype:

The first prototype has to fulfil the basics specifications of the project. This prototype will be tested in some devices, it means that the compilation must be general for all devices that could use the program.

The prototype has to cover some product operation factors:

• Correctness: It's important to control specially the availability and completeness of the program. These points going to be controversial because limited devices need to balance between them.

• Reliability : If the program has a big distribution, as entertainment applications, it is almost impossible to guarantee it. However, a good testing process helps to do it, specially when the development team designs several versions of the program.

• Efficiency: Depends of the JVM and the hardware of the mobile phone. A high level interface application will be more efficient that a low level interface.
• Integrity: Keeps personal information of the user safe and protects the connections (specially bluetooth).

1st Testing:

After the development team finishes the first prototype, it's necessary to test it in several devices (specially games and functional applications).

In this first test is really useful to implement white box testing.

Typical Errors:

The only way to find errors in MIDlets is to emulate the application (with a debugger) in differents emulators. Depending the emulator, the error could be produced or not. We can define different kinds of errors:

User Interfaces errors

Interface errors can be divided in two different types:

• Canvas errors: problems with the screen's size, loading images, etc.
• Command errors: problems interpreting the orders of the user. This mistake is usual when predefined constants of the Java's classes are being used by the programmer.

The only solution is to have different versions.

Memory errors

This is the most frequently error of J2ME programs. Each device has memory limits. These limits produce an “Out of Memory Exception”, because RAM memory has been overloaded, or can produce that the program would not be installed because ROM memory does not have enough capacity.

Programming errors

As in every programming language is normal have some mistakes, but specially if you are coding with several restrictions.

Automatic diagnostic helps to find these mistakes, too. It's interesting to prepare it for testing.

Synchronization errors

Synchronization errors can be divided in:

• Thread errors: J2ME is multithreading, it means that you have to control some threads at the same time, but you can not destroy it. It is also difficult to debug it.
• Connection errors: This errors are related with Bluetooth, HTTP connections, WPA, SMS, etc. Normally, this kind of errors could be only tested with a real mobile phone but there are some tools to emulated events that are useful for check it.

Mobile Emulators:

Some companies have emulators of its mobiles that implements a JVM. This emulators are really useful for the first testing because it is faster to test a program that with real phones and the result it's almost the same, except in special devices.

The IDE allows to synchronize the emulator with the debugger. It gives you flexibility for correct mistakes.

Every mobile platform contains some libraries that are used in the compilation process, specially when we want to develop for a special platform. Some examples are: Nokia, Motorola, Sony Ericsson, Blackberry, Sangsung, HTC, etc.

These platform have a emulator that can be integrated in the IDE and use for debugging process.

Real Mobiles:

Real mobiles testing is slowly but some mistakes that can be found with real mobiles are not found with emulators, for example, management of files, databases, reaction time, etc. It is useful when we want to know if the interface is functional or is difficult for the user.

Must be done by someone not connected with the project, because it's important to know if the tester can understand the flow of the program and the commands options.

Testing in real phones is useful for touch screen phones.

1st Review:

The first review must be based in the errors of planning and general errors in the flow of the program. It would be good try to find interfaces errors because it could help to the portability of the application to different platforms.

2nd Design

Once the prototype has been tested, the development team has to create some different versions of the programs according to the specifications of the platform and the errors that had been reported about the platform which they want to work.

Different version for each size of screen:

If the program has been done with a low level interface (Canvas classes), normally it's necessary to adapt it for different screen size, specially the image that have been used with the canvas classes.

Special version for diferent mobiles:

For functional devices it's important consider to created light applications specially when it must be as fast as possible.

It is important create a version for touch screen mobiles, too, and to assure that the commands related with the dial works.

2nd Testing

The second testing is concentrated in how the application works with different devices. It supposes that the prototype works and tries to test the usability of the program in the different devices. This test has to show the portability of the software version into the devices where it is supposes to run. The hardware interaction is more important in this test because the development team has to guarantee the functionality of the code in all the devices.

List of mobiles phones and characteristic:

In this part it is important to prepare a list of devices in which the application works, because it will be used in the distribution. Normally, mobiles of the same company have common characteristic and there are lists of mobiles phones that can be useful to catalogue them.

2nd Review:

This review is based in problems that different platforms can produce to the application.

Maintenance:

Documentation:

There are many useful tools for create automatic documentation like doxygen, javadoc, etc. This tools are really useful and allow to create the documentation with the comments of the code. It's very important to have a good documentation of every method and attribute.

Programmers manual:

The programmers’ manual must contain the UML diagram of the application, the basic code of the first prototype (functionality of the program, algoriths, etc.), and modification for the different devices with some explanation about it.

Reused Classes:

Some classes (especially canvas and functionality classes), can be reused for future programs. It means that it's important to consider a good documentation of each class.

Internal Projects:

Finally, it is important that the development team create new tools to help them to create the applications faster or tools that can automate processes of the testing phase. It is also neccesary to improve the classes that have been used during the implementation process.

Reference:

[1]Keogh, Jim.J2ME: The Complete Reference. Osborne/McGraw-Hill, 2003.

[2]Juntao Yuan, Michael.Enterprise J2ME: Developing Mobile Java Applications. Prentice Hall PTR, 2003.

[3] García Serrano, Alberto. Programación de juegos para móviles en J2ME. 2003

[4]

[5]

[6]

Héctor Menéndez1