From enterprise to consumer software shops, development teams are asking, "What's different when mobile enters...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
the application test and QA picture?" Well, it's not tremendously different, but it is different. Developers need new know-how about programming languages like Objective-C and mobile software stacks like Android when developing mobile applications that are both effective and secure.
In a rapidly developing ecosystem, teams cannot afford to make the same mistakes over and over again.
Most mobile platform programming languages are based on the same languages used on server and desktop: iOS – Objective-C, Android – Java, Windows Mobile -- .NET. The biggest change is when a .NET or Java shop takes on an iOS project. Objective-C is a higher-order programming language and has a very steep learning curve for teams more familiar with intermediary languages like .NET or Java. Major testing principles (application functionality, conformance to specification, robustness, etc.) transition well to the mobile platforms. So while a complete retooling isn't necessary, new skills, technologies and techniques are required for teams to successfully test mobile applications. These include:
- Developing a familiarity with the target mobile platform beyond the consumer perspective. Testers in the Windows world are familiar with asking themselves, "What could possibly go wrong?" and are familiar with the weaknesses associated with that platform. For instance, Windows testers know the purpose of (and weaknesses of) the Windows Registry. They understand target installation folders and user profiles and when to use either to achieve security or application design goals. Unfortunately, the same testers can look at an iOS device as a miraculous black box with no visible vulnerabilities. They don't understand the risks in using the iOS keychain, the dangers in storing preferences in non-secure locations, etc. To avoid making simple security and configuration mistakes, testers need to assume responsibility for familiarizing themselves with the target platform and understanding its weaknesses.
- Understanding the tools required. Teams will need to understand the tools used for interacting with applications at a development and test level. Many of these tools require an elevated level of privilege in order to be used, so testers will need to understand how to gain that higher privilege. An example of this would be the use of the Android SDK within Eclipse, allowing testers to interact with an emulated Android device using "root" (or administrator-level) privileges to see how their application interacts with the operating system, as well as how their app is vulnerable on rooted devices.
- Understanding the inherent security schemes within a given operating system as well as how common hacks exploit standard implementations. For instance, learning to proxy mobile applications that leverage common Web service technologies is critical to successful functional and security testing. Burp Suite Pro is a tool long used by testers for proxying web applications to view HTTP traffic between the application and the server, but few testers are aware it can be used to proxy mobile applications as well. Proxying traffic allows testers to modify traffic and introduce unexpected input to probe the application's robustness and security design.
- Paying attention to lessons learned: In a rapidly developing ecosystem, teams cannot afford to make the same mistakes over and over again. They need to learn from others' mistakes. Recently on the Android platform, security researchers published a paper regarding an unidentified ad platform commonly integrated into mobile applications. It caused no small amount of consternation, and numerous applications had to be patched to mitigate serious privacy threats posed by the ad platform's implementation. Teams which leave that lesson as a single, atomic lesson will experience similar failures in the future. Successful teams will apply the lessons learned to future research and development efforts and will prevent issues from surprising them and disrupting project plans.
As teams develop these skills and implement them into their mobile development lifecycles, there will be an initial slowdown in project throughput. However, as they become familiar with the required skills, that slowdown will be reversed. Soon, teams developing secure mobile applications will experience a faster throughput rate because they aren't constantly patching egregious security flaws introduced by poor testing methodologies.