Home >Technology > Full Story

Error-Proofing Mobile Implementations

There are three ways to bullet-proof your mobile applications: test, test and more test

With the speed to market so important today, it is no wonder developers often neglect to create sound fundamental building blocks of their mobile applications before rushing them out to the market.

In their haste, product testing is often compromised. Yet it remains one of the most important routine for any product development.

One of the most important functions of a comprehensive testing phase, as part of the mobile application development cycle, is to ensure that the development team understands the key concepts of risk.

Implementation risks are especially high in a mobile project, largely due to the adoption of state-of-the-art technology. These risks are created by the constant changes in technology, a larger pool of inter-connected components to grapple with, and the lack of technical standards.

Therefore, to manage the risks, developers need to first determine "what" to test, "when" to test and "how much" to test. This is first achieved by identifying each of the tasks from an itemized project plan of all the required tasks within the test phase. Next, would be to create a testing strategy and how best to carry out the testing process.

Testy?

What to test? A project defect is a variance from the intended expectations. Therefore, a defect can be any of the following: bugs in the code (most common), incorrectly-stated requirements, overlooked requirements, incorrect functions, performance problems and cost overrun.

How to test? To start, focus on tasks that are likely to cultivate defects. These problems are likely to be caused by non-functional requirements. To prevent this problem, use system or data diagrams, case models, operational models and source codes.

When to test? As all project defects can be introduced in any of the phases of the mobile development process, testing should begin as soon as the project is initiated. A good strategy is to perform testing throughout the entire project life cycle.

Although this approach appears time consuming, it will in fact reduce cycle time and overall project cost. This is because most defects occur when the project is approaching its end-cycle. Hence any defects discovered at the unit level will help reduce unnecessary work in performing tests to filter the defects at a system, module or program level.

However, it is impossible to totally eliminate defects. Zero defect is not realistic, and even if it is possible, it would be very difficult to justify from a cost perspective. Shoot for near error-free instead, by applying the testing process on each project deliverables during each of the project life-cycle milestone or phase.

One way to keep risks at bay is to perform a risk mitigation process that is based on risk factors and costs. This will allow a quantifiable measurement of risk. Given that risk is derived from probability of occurrence and associated cost, it follows that cost of failure = cost x probability.

From this business equation, we can form a relationship to determine the appropriate level of testing that would be required. From the graph above, based on the risk equation, we can formulate the optimal testing level, so as to avoid "over testing" or "under testing".

Test Strategy

There are generally two types of test strategy which can be applied to mobile development projects, namely "static testing" and "dynamic testing". A mobile test strategy is a high-level description of all major system-wide mobile system testing activities, which is developed during the proposal stage of the project cycle. The strategy outlines the approach to be used in the testing activities. This might include elements and information generic in nature.

Having a sound strategy makes the goal more apparent, and more achievable. It provides a common direction, approach and terminology across multiple organizational structures and various business units. It also helps set the expectations of the outcome. The main steps for setting a strategy is as follows:

1. Define the test objectives

2. Identify and review the business and technical strategy

3. Identify the focus areas within the project cycle and required test details

4. Identify the type of test to

be conducted with the appropriate criteria

5. Define a high-level quality metrics

In particular, static testing deserves special attention since it is largely applied during the crucial early stages of the project. The main prerogative of static testing is to prevent defects from passing to the next phase.

Thus, static testing is very cost effective as it prevents defects from propagating. Some of the more common static techniques are inspection, project reviews, system prototyping and architectural walkthrough.

Results

Finally, the test needs to keep important information about the level of correctness of the mobile system being developed for each module. No defect, however small, that occurs during testing should be ignored. Query the test results with your team. Do the results provide sufficient details to satisfactorily close a test process or is there a need to perform a retest?

If so, make sure to troubleshoot the testing plan and procedure. Testing is tough and often dirty work. But the success of your project often hinges on how thorough your testing procedures are. Don't skimp on it!