Revision 34 as of 2013-09-26 13:16:52

Clear message

Warning /!\ W.I.P. Warning /!\

Touch Test SWAT

Welcome to the testing page of the Touch Testing SWAT. These pages provide up to date information of current testing activities for Touch until the release of Saucy, check back frequently.

Test coordination

  • Mailing List - The quality mailing list is used to coordinate testing activities with all participants.

  • IRC - join the Ubuntu QA in #ubuntu-quality and and Ubuntu Touch #ubuntu-touch IRC channels on freenode.

Test process

This describes the daily process of testing. We will flash our devices, look for bugs, then look to write autopilot tests for any fixed bugs to prevent that bug from re-occurring.

Daily Image Testing

Install the current stable image

Flash your phone to the latest stable image (note: we want the "current" image of touch_ro). If you have not yet bootstrapped or unlocked your phone's bootloader, see the install page for more information.

  $ phablet-flash ubuntu-system

In order to wipe clean and start fresh with the latest current image:

  $ phablet-flash ubuntu-system --no-backup

Perform a system update

Alternatively, once you are running the ubuntu image you may perform a system update from the device itself. To do this, select 'system-settings' application, then click update. Press the download button, and once the download is completed, the install button. Note, currently there is a lack of visual feedback while performing this process, see Bug 1227110

Visual Walkthrough of updating

Example of no updates found

Check to see what's changed

A list of changes between stable images can be found here. The list contains the list of changing packages.

Use these changes to drive exploratory testing below.


* Run through the list of new features and changed areas of the phone, paying specific attention to spot regressions and verify the features are working.

* Perform smoke testing on a specific packageset of the phone.

* File bugs against any issues encountered

* Remember this is exploratory testing, so try and break things!

Report Bugs

See the Reporting a Bug section below for details.

Add a testcase for reported bugs

Once testing is completed, review the list of reported bugs with the touch-needs-autopilot tag. Pick a testcase to automate using autopilot that tests the bug to ensure the same bug doesn't reappear. So we can track work happening on these bugs, follow this process while writing the test;

  1. Remove the touch-needs-autopilot tag from the original bug

  2. Open a new bug against the same project, tagged with qa-touch-automated

  3. Assign yourself to the bug and update progress as usual. When you release the test, close the bug with fix released.

Confirm an existing bug

Not finding any bugs yourself? Look at the Triaging link below and confirm bugs others have found.

Reporting a bug

All bugs filed should use the avengers tag. Omer has made available a tool to help with the process of filing a bug report. Please ensure you add the 'avengers' tag when filing. If you think the bug you are reporting is a good candidate for an automated test to prevent future regressions, you may also add touch-needs-autopilot to the bug.

What package should I file against?

File against the ubuntu source package for the failed component. See this page for a full broken out list of components.

Filing the Bug

Using Omer's tool

This is the recommended way to file bugs

Omer has created a tool to allow you to report a bug from your desktop, provided the phone is connected via usb cable. Download and save this file. Via the command line,

wget -O filephonebug
chmod +x filephonebug

To run, pass the package name as the only argument. The tool will connect and grab logs from your device, and open a new bug in your desktop browser to file the bug.

For example if the phone dialer is causing issues you would do the following:

  • Connect the phone via usb
  • Run the tool against the dialer-app package. Unsure of which package? Check this list

./filephonebug dialer-app
  • Apport will run and collect logs and ask you 2 questions. Answer 'S' to send the report, and then '1' to launch a browser to file the report. The output will look like this:

$ ./filephonebug dialer-app

*** Collecting problem information

The collected information can be sent to the developers to improve the
application. This might take a few minutes.
182 KB/s (14785 bytes in 0.078s)

*** Send problem report to the developers?

After the problem report has been sent, please fill out the form in the
automatically opened web browser.

What would you like to do? Your options are:
  S: Send report (14.1 KB)
  V: View report
  K: Keep report file for sending later or copying to somewhere else
  I: Cancel and ignore future crashes of this program version
  C: Cancel
Please choose (S/V/K/I/C): s

*** Uploading problem information

The collected information is being sent to the bug tracking system.
This might take a few minutes.


*** To continue, you must visit the following URL:

You can launch a browser now, or copy this URL into a browser on another computer.

  1: Launch a browser now
  C: Cancel
Please choose (1/C): 
  1: Launch a browser now
  C: Cancel
Please choose (1/C): 1
  • The browser will launch and display a ready to file bug report. Finish filling in the description of the issue. When filing, make sure you include the steps needed for others to reproduce the issue, and what the result was versus what you expected the result to be.

There is a crash file in /var/crash

If the bug is a crash and there is a crash file in /var/crash, you can report it with apport.

1. Connect to the device with adb

  $ adb shell

2. Check for any crash file in /var/crash

3. Report a bug with apport:

  $ apport-cli /var/crash/name_of_crash_file.crash

4. Follow the instructions

5. To the question "What would you like to do? Your options are:", answer "S: Send report"

6. Wait for the upload to proceed

7. Upon upload you'll be presented with a prompt like:

*** To continue, you must visit the following URL:<UUID>

You can launch a browser now, or copy this URL into a browser on another computer.

  1: Launch a browser now
  C: Cancel

8. Copy the URL to a browser running on your desktop/laptop, it is more convenient than running a browser on the phone to report bug and proceed with the bug reporting process in launchpad

9. Then follow the usual tagging plan and triaging process

There is no crash file

1. Connect to the device with adb

  $ adb shell

2. Find the right package (TODO: Document difference between preinstalled dpkg based packages and click package)

  $ ubuntu-bug maliit-framework

3. Wait until data collection is done.

4. At the question:

What would you like to do? Your options are:
  S: Send report (4.3 KB)
  V: View report

Press 'S' or 'K' if you want to copy the report to another machine (for example if networking is not enabled on the device).

3. If you're reporting from the device, on your local machine, click on the link or copy/paste it into your browser.


Once bugs have been filed they need to be confirmed, and ideally, have a defined scenario for recreating in order for developers to fix them. To help with triaging, simply read a bug report from the list below and try it on the latest build for your device. If you can recreate it, mark the bug status as confirmed.

Needs work

Completed work

List of all reported Bugs


Tags are used to keep handy lists of the work being done. It lets us see the status of bugs and testcase automation.

What does each tag mean?




Used for filing bugs found during exploratory testing of ubuntu touch images


Used to tag bugs that are candidates for automation to prevent recurrence once fixed


Used to tag bugs that are being automated with autopilot

Tips and Tricks

Here are some helpful hints that will come in handy while testing; feel free to add more!

Switch from RO to RW

  • Switch from RO to RW (to install additional packages for example):
    • Remount RW

    $ adb shell
    $ mount /dev/loop0 / -o remount,rw
  • or touch writable_image

    $ adb shell touch /userdata/.writable_image
    $ adb reboot

Take a screenshot

This is helpful for bug reporting. Note this WILL NOT work if you are running Mir.

   $ adb shell /system/bin/screencap /data/screenshot.png
   $ adb pull /data/screenshot.png ~/screenshot.png

You can resize with convert from package imagemagick:

   $ convert screenshot.png -resize 50% screenshot.png

Which build am I running?

  • Find out what build you are running

   $ adb shell cat /etc/media-info

Enable MIR by default

   $ adb shell touch /home/phablet/.display-mir
   $ adb reboot

   to switch back:

   $ adb shell rm /home/phablet/.display-mir
   $ adb reboot
  • MIR is running if no surfaceflinger process is running and the socket /tmp/mir_socket is present

Enable gprs if it doesn't come up automatically

  • GPRS A simple work around while this is not working is to do:

   $ adb shell restart network-manager

Turn back on intro

  • Turn back on the initial demo that instructs how to use the phone via swiping

dbus-send --system --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User32011 org.freedesktop.DBus.Properties.Set string:com.canonical.unity.AccountsService string:demo-edges variant:boolean:true

Retracing a crash on phone

  • currently ARM crashes cannot be retraced by Ubuntu retracers, a way to generate nice stack trace from crash files in /var/crash/ and usable by developers is to use apport retrace directly on the phone.
    1. Switch the device to RW mode
    2. Install apport-retrace:  apt-get install apport-retrace 

    3. Enable ddebs repository to install debug symbol packages

    4. Run apport-cli on a crash files in /var/crash, for example:

  $ apport-cli /var/crash/_usr_lib_arm-linux-gnueabihf_upstart-app-launch_zg-report-app.32011.crash
  • 4.1. To the question Send problem report to the developers? answer E: Examine locally

    4.2. To the question This will launch apport-retrace in a terminal window to examine the crash. answer 3: Update /var/crash/_usr_lib_arm-linux-gnueabihf_upstart-app-launch_zg-report-app.32011.crash with fully symbolic stack trace

  • Let apport proceed ...
  • You can then submit the report to launchpad the usual way.


* Add link to reference documentation (how to flash, specific testing like MIR, how to troubleshoot, ...)

* Add list of who's testing which feature sets / areas