Tag Info

Off the top of my head: Memory footprint. Allocations that "rarely" fail on a desktop OS may fail on a mobile platform Battery impact - on a desktop app, it's common to have a thread polling, or a background task. On a mobile platform, activities like this can drain battery pretty quickly Desktop applications often assume reliable network access. Mobile ...

Some ideas for the GPS part, based on my experience testing GPS's: Do field tests, and choose you locations wisely- from totally open skies to crowded tall buildings with limited to no GPS reception, from standing still to driving slow and fast, change heights during the tests (GPS is less accurate in reporting heights), choose different times of day, ...

If you want authoritative, you'll probably have to pay money. Accurate, current and authoritative information for things like this is hard to come by. That said, you should not focus so much on testing it out with specific devices. The mobile segment is so fragmented that even if you manage to test it and get it working well with 50% of the devices, the ...

Actually this is a good testing question because you are evaluating the client/server functionality between a device and a cloud service, and how the mobile client behaves when it changes from one state (eg logged on in cloud w/connection) to another state (logged on with no connection). If the user is "offline" (e.g. changes to airplane mode) or has lost ...

Use a variable attenuator between your device and AP, there are manual and controllable models and it's relatively cheap. You'll have to connect it to the Wi Fi antennas using an RF cable , or put your device into an RF insulated box, which in turn is connected to the attenuator. Your application probably doesn't see the signal strength reports directly, ...

Spid, Do you have Requirements that indicate what the behavior should be in this scenario? If not, then my guess is that after pressing Log Out, the system should behave as it is designed to do in logged-out mode, without regard to online/offline status. But "right behavior" is always defined by Requirements, not by guesses. You should bring the subject ...

I am not a developer of any of these platforms (only iOS), but I can think of one reason: device hardware: Your tests may run on your computer with computer's performance (multicore with few gigs of ram). Most mobile devices (some already do have dual-core processors and up 2GB of ram) do not have such parameters (yet). This way unit tests may be used to ...

Device or simulator to test updates: of course device because simulator does not support some features (f.e. push notifications, camera, …) How to test, simple but important steps: 1) Install version 1 2) Do some actions: open levels, buy something (levels, things, clothes, money, …), pass some turns if it is game or guess something) 3) Install a new ...

Apple recommends that you first install the current app version from App Store. Then install an ad hoc build of the updated app through iTunes. (Do not use Xcode to install or run updates to your app for quality assurance testing.) Reference: Testing iOS App Updates

RIM's website appears to have the simulator's that you would probably be looking for. For thorough testing however, if it's just these two particular devices, you will probably want to get the physical devices to test on as behavior can vary between simulators and the actual devices.

If it's a mobile application, presumably you have the handset to test it on (my old mobile shop had every handset in-house...quite an inventory). You should physically move around to get varying WiFi signal strengths. If you don't want to use your feet, you can begin wrapping aluminum foil around the handset until the signal dies down, or throw it in a ...

Some thing spring to mind: Cellular coverage affects not only your internet connectivity but also loads the CPU Mobile devices CPUs are usually slower Mobile OS's impose a lot of restrictions that doesn't exist in Desktops, for example IOS handling of multi tasking Compatibility is a pain, Android or IOS behaves slightly different on different ...

The answer depends on type of tools you would like to use. If you are familiar with agile software development and want your developers to implement and maintain test automation on UI level that you can consider to use developers focused tools Android: robotium(built on top of Instrumentation) ui automator(from Google) Calabash iOS: UI ...

For iOS ONLY. You can install on your MAC "Network Link Conditioner", it allows you to simulate different connection profiles (3g, DSL, Edge, WIFI average good or lossy connectivity, no connection). Once you select your profile, you need to connect your iOS phone to your MAC (hotspot wifi) and test your app.

Unless you application is an app to accurately measure wifi signal strength then you haven't provided enough information about your app. Do you really expect different functionality from your application if the signal strength attenuated? Or are you trying to assess performance issues? Controlling signal strength accurately (in a controlled environment) ...

I worked at a highly-respected mobile development shop for 6 years. We did not trust automation or emulators as acceptable tools to finalize a build. Each build was manually tested on the actual handset it was targeted for before the build was sent to the customer. That's the problem with mobile development. Unless you find a framework that will run ...

The key to testing is ability to reproduce, so if you're using the real GPS module, you will obviously have several problems that are not solvable: The same tests would pass or fail on different computers, which completely invalidates all tests; The same test may pass or fail even on the same computer, due to minor deviation of GPS co-ordinates returned ...

As others have stated, it's hard to really answer your question. What I would expect is that some local token (ie: cookie, temporary file) would be removed and you would be asked to login when your connection is returned. As for what happens in the UI, outside of what you may already know via your requirements documentation, I would suggest either an error ...

The most authoritative source of information will be your actual results. Once your product is live, you should also monitor actual usage and modify your test matrix accordingly. I know this doesn't help you right now, but afterwards you user base may or may not conform to the market data. I see this affect in the product that I'm working, our user base ...

Great question. Performance is not a serious reason: performance is important, and can differ between devices, but specific performance tests and benchmarks are more effective than test suites. We derive most of the value from plain unit tests that run in a regular environment, not a device or an emulator. We mock out the phone's library (this can be ...

We build our own automated testscripts partially using Robotium and Android's MonkeyRunner we found that this was the best way to maximize the kind of tests we could automate. One thing that is a pain of course is the time it takes to run our tests. We integrated it into our build server, but we run the tests overnight. Running all these tests for every ...

The tricky part of testing any Mobile application is mobility. Although it seems unrelated at first, moving your mobile device can affect running applications. I've seen offline applications crashes when the phone went out of cellular coverage or a call was incoming. What's the solution ? do at least some field testing on real device.

The main idea here is install the new one over the old one and still your credentials and error log must work. It need not be only from App store and itunes, you can configure the device to get the updates from your local server also.. assumed it can be connected from outside. Otherwise what you doing is right.. update from itunes. But be sure the update can ...

In addition to the excellent points already mentioned, data synchronization to a mobile application is a rich source of bugs, and, even worse, of unwise specifications. A bug I’ve seen in many incarnations is that the mobile device can’t handle all of the data in a desktop application, so the programmer limits it in a way that seems reasonable to him, but ...

In many ways, it's more like a PC application than a browser app -- you must test with the expectation that once a user downloads your app, they may never update it, or may not update it as quickly as you'd like. In addition to potentially buggy code in the field, you may also have to test back-end systems against various versions of the app.