Have you ever wondered what a regular day is like in the life of a mobile application developer working on a big project?

Usually everything starts with a request to add a new functionality to a mobile app. The developer has to work with functional and nonfunctional requirements, and therefore the architecture overview and development processes can be hard sometimes. Once those steps are complete, it’s always time for testing. Mobile developers cannot work without testing their progress and results on real mobile devices, and we used to call this a manual functional test.

During manual testing a mobile developer checks to see if a new feature works or not, usually without validation of other features that were developed previously. Afterwards, testers do the same manual check for new features and verify already existing ones. This means additional work and extra costs since developers and testers are partly doing the same job.

How can we change this approach? There is now a very promising method in functional testing, and it was introduced in IBM Mobile Test Workbench, which is part of IBM Rational Test Workbench. It allows you to record everything you’re doing inside the mobile application and then to generate a test based on that recording. After the test is created, you can add custom steps, checks and much more. But the main value, in my opinion, is different: this new era of functional testing allows the developer to have automated testing as a part of his normal development process.

With these capabilities in place, automated functional testing can become part of the bigger process:

1. Development and debugging. During this phase the developer adds new functionality to the application or modifies existing functions. As a part of development, he initially records a test for each newly created function. He is also responsible for packaging and over-the-air distribution of his application.
2. Automated functional testing. The developer launches automated functional tests on multiple devices either manually or automatically, based on the distributed application. Tests include recently recorded and previous ones.
3. User acceptance testing. Testers are no longer responsible for functional testing—this part will now be covered automatically during the previous step. This team focuses on manual testing of an applications’s nonfunctional aspects—user acceptance and user experience—because these cannot be measured during automated tests.
4. Alpha and beta user testing. An over-the-air application is distributed to alpha and beta user groups for further testing. Users have an opportunity to submit bug reports and feedback inside the application, and the application provides automatic submission of crash logs.
5. Sentiment analysis. Based on the gathered information and analytics data, managers and business analysts make a decision to either release the new version of the mobile application or to proceed with further development.

This approach can help the organization to save costs and eliminate the extra work on manual mobile application testing. You can read more about quality management with IBM Rational Test Workbench in the article “Becoming a mobile enterprise: Quality management.”

Have you tried using this approach in your enterprise mobile projects? Let me know in the comments or connect with me on Twitter.

Technorati Tags: IBM Rational Test Workbench, Mobile testing

The post A new era of mobile application functional testing appeared first on IBM Mobile.