Google‘s virtual keyboard shows you the word, which is being formed while you glide over the keyboard. Both support swipe-control elements or the input of gestures, but they differ in the execution. Let’s take the Gboard from Google and the virtual keyboard OneU from Samsung as examples. So system apps, like the virtual keyboard, can operate with varying results. The manufacturers are able to change the Android operating system within certain parameters. Regarding Android devices we can observe another software fragmentation. With regard to iOS as well as Android devices due to an ever-increasing product range, as well as operating system versions which remain longer and longer in circulation, a kind of natural fragmentation is developing – as shown in the following statistics. The problem of hardware and software fragmentation can also be seen as an argument for the automation on real end devices. Tests on virtual devices provide us with no reliable data regarding this matter. Even if all the features of your application work perfectly, bad performance on the end device may result in your application being unusable. In addition, automation on real end devices enables you to examine the performance of your application. Experience shows also that errors which were found on a real end device could not always be replicated reliably on virtual devices. They use the hardware of the computer on which they are installed. The main reason is that virtual devices don’t have any hardware of their own. One could assume that virtual devices reflect one-to-one real end devices. The first argument for automation on real end devices may sound trivial but is of great significance: due to the fact that your users do not utilize any virtual devices. But why should we run our test automation on real devices? Why not use the virtual devices from the development tools Xcode (iOS) and Android Studio (Android)? These questions are justifiable, because the acquisition of end devices generates additional costs.
0 kommentar(er)
