Configuration changes are updated constantly in mobile application development as development companies try to...
keep up with demand. Mobile app testing, on the other hand, is already complicated by the number of paths needed to ensure a quality product. The process is burdened by testing requirements around screen size, platforms, connectivity and configuration.
With an already full plate, how does a mobile app testing team add in testing configuration changes in a release? Typically, configuration settings are not the highest priority changes, so testing them falls behind other feature testing commitments. You can try a couple of options to see what works for the mobile app testing team's schedule.
The first is random selection. For example, if there are 20 configuration changes pick the top 10 that are most important to clients, or that occur in the most-used features. Or list each by priority or importance and by the popularity of the associated feature and test your way down the list.
Testers also can divide the list between releases. Granted, not all features will be tested in the initial release, but a group can be tested each release until testing is completed. Create rotating test suites and mix them into your regression testing executions. Once each has been thoroughly tested, go back through and mix them at random or by feature and add them to the regression test along with their matching feature.
Another logical option is to test them with the feature they control. If the testing numbers are too high rotate the feature and create small subsets of test suites that cover a piece of each feature. Switch out testing suites each regression cycle. Each testing suite contains a portion of every feature so in this way, full testing occurs over a series of regression testing events but all features are covered to some extent.
Accelerating mobile app testing
Mobile testing criteria