I recently talked with one of the top managers at a highly successful and agile mobile app development company. They generate a lot of revenue from mobile, and mobile is very high on their management’ s agenda. He told me how challenging mobile app development is:
The top challenges for today’s mobile app development:
- The extreme demands for quality across a spectrum of real devices and often global users
- High customer acquisition and marketing costs that will be totally wasted if the app fails, not to speak about development costs that are sunk, if the quality is low. When the app fails, you will not just lose the CPI but also the lifetime value of the user
- Competition is just a few clicks away and moving at a fast pace, the risk of losing a customer is very high
- And the pressure from the higher management not to lose to competition and start to generate revenues from mobile, just like competitors already are.
Even though you have the most brilliant engineers on the job, the result can be like pictured here: The world’s biggest fast-food chain’s app on Google Play which has clearly failed.
When facing these challenges, an ad hoc development approach does not result in very positive outcomes. If your developers are fire fighting and fixing issues coming from crash reports, they are not developing new code that will drive your top line. Does that sound familiar to you?
How do the most successful teams then do mobile development? They do Agile, developers concentrate on delivering new features, rather than debugging old ones and they automate a lot: use of test automation, automated deployment processes and testing on real devices dramatically shorter development cycles.
Most of the mobile app developers are increasingly responsible for much of the actual testing. In Agile, testing and development are one integrated process. In Agile, developers need testing tools that plug into continuous build and integration systems to make a significant impact on day-to-day activities.
Agile projects maintain quality via a continuous testing approach: Unit testing, increased automation, test-driven development or user acceptance Test-Driven Development, and exploratory testing replace manual, prescriptive processes.
Manual testing is not agile, and it slows down delivery. Manual testing is time-consuming and resource-intensive, and expensive. Even scaling up the number of manual testers doesn’t work — neither in-house, outsourced, off-shored or crowdsourced, manual testing simply can’t keep up with daily builds, continuous integration, and the functional and non-functional testing of Agile delivery teams. Many of our customers run between 1000 and 1600 test cases EVERY night! That kind of testing cannot be achieved manually.
Late-surfacing defects will derail projects. The longer a defect remains unfixed, the longer it will take a developer to fix it, with a direct impact on the project deadline. Developers move on to new code and new features and lose the context of the features they’ve delivered. When they come back to a defect that they wrote ages ago, it takes time to re-engage with the old code. Developers need instant feedback on why a test fails so they can debug and fix problems immediately. Late discovery of defects leads to high rates of rework and waste. One of our customers shaved the debug time from a month to hours by using Bitbar Testing in their development process (link to the case).
Unless you achieve a high level of test automation, your Agile development will be held back by repetitive manual testing. There is absolutely no reason to wait for the next release to start saving money and improve your top-line.
With the pressure to shorten time-to-revenue, developers cannot wait until the end of the development cycle to initiate the testing and verification process. Testing and verification should be done continuously:
To be successful in mobile, QA cannot be an afterthought, but integrated with the development.