Skip to main content

How to access files and databases on your mobile device


In this post I'll describe how to access files and databases associated with a mobile app. On the apps that I test we have log files and SQLite databases that are useful to look at when investigating potential bugs. How do you access files and databases on a mobile device? As usual that depends on whether you are testing iOS or Android. App specific files are available on both devices but they way you access them is different for each OS.

iOS

For Apple devices, you can use iTunes to access app specific files.
Open iTunes on your PC or Mac and connect your device. You will see the device:




Select the device icon. This will open the apps page. Under File Sharing you can then select your app to view its associated files.



You can then add files, save files to your PC or delete files on the device.

Android

On Android devices there is usually a folder called "MyFiles". App specific files are stored under that folder. To access them, simply connect your device to your PC or Mac and copy the files across.

When writing up bug reports is often useful to take a screenshot of the issue. To take a screenshot on a mobile device, press the home and the on/off button simultaneously. Remember that the on/off button is located at the top of the device on iOS and on the right side of the device on Android. What's the best way to get the screenshots off the device? For iOS, I find the easiest way is to use iCloud. If you sync your device, the screenshots will appear there. For Android, I find it simplest to email the screenshots to my work email on my PC.

Note that you can also make screen recordings on iPads and iPhones:
Go to Control Centre under Settings on the iPad.
Choose to Customise and add Screen Recording
This will now appear when you swipe down (on RHS of iPad/iPhone screen) and enable you to record what happens on the screen.

So as you can see, it's more difficult to deal with files, databases and screenshots when testing on a mobile device but there are ways to get that information off the device so that you can analyse and report on bugs.

Labels:

Comments

Post a Comment

Popular posts from this blog

Let’s stop writing automated end to end tests through the GUI

What’s the problem? I have not been a fan of Selenium WebDriver since I wrote a set of automated end-to-end tests for a product that had an admittedly complicated user interface. It was quite difficult to write meaningful end-to-end tests and the suite we ended up with was non-deterministic i.e. it failed randomly. Selenium Webdriver may be useful in very simple eCommerce type websites but for most real world products it’s just not up to scratch. This is because it’s prone to race conditions in which Selenium believes that the UI has updated when, in fact, it has not. If this happens, the automated check will fail randomly. While there are techniques for reducing these race conditions, in my experience it is difficult to eradicate them completely. This means that automated checks written with Selenium are inherently flaky or non-deterministic. Maintenance of these automated checks becomes a full time job as it is very time consuming to determine whether a failing check is actuall...
6 comments
Read more

How I got rid of step by step test cases

In my last blog post I told you what I think is wrong with step by step test cases. In this blog post I’ll tell you how I got rid of step by step test cases at the company I work for. When I joined Yambay about 18 months ago, the company was following a fairly traditional waterfall style development approach. They had an offshore test team who wrote step by step test cases in an ALM tool called Test Track. Over the past 18 months we have moved to an agile way of developing our products and have gradually got rid of step by step test cases. User Stories and how I use them to test Getting rid of step by step test cases didn’t happen overnight. Initially we replaced regression test cases and test cases for new features with user stories that have acceptance criteria. The key to using a user story to cover both requirements and testing is to make sure that the acceptance criteria cover all test scenarios. Often product owners and/or business analysts only cover typical scenarios. It...
3 comments
Read more

Automating Regression Testing

In my last blog post I described how we have got rid of step by step test cases but didn’t have any automated regression tests. Since then we have embarked on a test automation journey and we are building up a suite of automated regression tests. In some of my older posts on unit and integration testing I talked about “valuable” automated tests. In summary, a valuable automated test is one which: Has a high chance of catching a regression error Has a low chance of producing a false positive Provides fast feedback Has low maintenance cost The more code that is covered, the more chance there is of catching a regression error. End to End (E2E) tests are good for this but feedback is often too slow. So how do we make E2E automated tests more valuable? They already have a high chance of catching a regression error and a low chance of producing a false positive but they tend to be slow and have a high maintenance cost. How can we improve those two aspects? A good way to do this i...
3 comments
Read more