Personal tools

B2G/QA/WebAPI Test Plan

From MozillaWiki

< B2G | QA
Jump to: navigation, search

Contents

Boot2Gecko WebAPI Test Plan

Summary

Lead Geo Mealer (irc: geo)
Contributors Martijn Wargers (irc: mw22)

David Clarke (irc: onecyrenus)
Jason Smith (irc: jsmith)

Status Pre-release, approaching Milestone 5
Tracker Pivotal Project
Project Page WebAPI
References Instructions for Contributors

Scope

This test plan covers qualification of WebAPIs developed for or used specifically in Boot2Gecko to interface with mobile devices. It does not cover the entirety of Gecko APIs available. The individual APIs covered are listed below and broken out into their own individual sub-plans.

Currently, only functional testing is being planned. Ultimately, performance and security should be addressed. However, there are too many unknowns at time of writing to adequately plan for them in advance.

Strategy

Functional test strategy will vary between APIs based on whether API effects can be effectively verified via automation, and whether that automation requires an emulator or not.

Broadly, testing will be divided between automation executed in continuous integration, and interactive exercises designed to manipulate APIs directly on-device. The expected amount of time given to each is roughly 75% to planning and CI implementation and 25% to implementing interactive exercises. However, as the exercises will be necessary for final qualification of the B2G stack on-device, those priorities may change closer to the shipping date.

CI-driven Automation

B2G continuous integration will offer two options: mochitest-plain and a new Marionette-based JS harness.

Tests written against the new harness will run only in B2G CI against QEMU, a device emulator. They can set things like orientation or battery status to a known value, which allows for rich virtual device manipulation for fixture setup.

Tests written against mochitest-plain can run in the standard mozilla-central Tinderbox test environment and anywhere else mochitests are typically run, as well as against the B2G codebase. Mochitest will give wider coverage, but will not be able to use the emulator to set up device-related fixtures and is thus significantly more limited.

Interactive Exercises

Some APIs have effects that cannot be verified through unattended automation. One example would be whether a microphone is open and receiving sound. Another example would be whether the phone is actually vibrating in response to an API call. These APIs must be verified interactively.

It would be tempting to use Gaia to exercise the API, but Gaia apps cannot be guaranteed to be using the APIs in a controlled fashion; that would require inappropriately locking in their implementation. So for these APIs, it is best to test using code specifically designed to exercise the APIs in a known fashion. In addition, as CI automation cannot be currently run on a final target device, it may be useful to have exercises even for APIs we address primarily through CI.

One decision is whether these exercises will be implemented as web pages or installable apps. Apps would be closer to how a developer will mostly use these APIs, and some APIs may only work for standalone applications. However, pages are more convenient as they don't require being preloaded onto the phone before testing can occur; they can just be navigated via onboard browser.

Tentatively, the plan is to implement exercises as pages where possible for expediency's sake, but to eventually move them into a standalone app that developers and the testing community can experiment with.

Also see the On Device Test Plan.

API Sub-Plan List

API Description API Status Automation Status
Screen Orientation Screen Orientation notifications and locking Ready First round done
Web Activities Delegate an activity to another application. Ready Developer contacted
Vibration Control device vibration for things like haptic feedback in games. Ready Developer contacted First round done by developer
Alarm Schedule a notification, or for an application to be started, at a specific time. Ready Tests in Suite
Push Notifications Allow the platform to send notification messages to specific applications. Unknown (TEF) Not Started
Geolocation Get current device position Ready Developer contacted
Device Storage Add/Read/Modify files stored on a central location on the device. Ready First Round Completed, Blocked on Outstanding Bug
Contacts Add/Read/Modify the device contacts address book. Ready (Priv) Not Started
Camera Control of front/rear cameras on-device Unknown Not Started
Time/Clock Get notifications about time changes (high priority). Set current time (low priority). Ready Not Started
Idle Get notifications when user is idle. Ready Not Started
Battery Status Information about battery charge level and if device is plugged in. Ready Not Started
FM Radio For FM radio feature. In Progress (Priv) Not Started
WebSMS Send/receive SMS messages as well as manage messages stored on device. Ready (Priv) Planning
Permissions Allow an app to manage all app permissions in a centralized location In Progress (Priv) Not Started
WebTelephony Allow placing and answering phone calls as well as build in-call UI. Ready (Priv) Not Started
Settings Set system-wide configurations that are saved permanently on the device. Ready (Priv) Not Started
Browser Enables implementing a browser completely in web technologies. Ready (Priv) Not Started
Web Bluetooth Low level access to Bluetooth hardware. (Currently headset-only) Ready (Priv) Not Started
Mobile Connection Expose signal strength, operator, etc for GSM and other mobile connections. Ready (Priv) Not Started
Power Management Turn on/off screen, cpu, device power, etc. Listen and inspect resource lock events. Ready (Priv) Tests in Suite
Wifi Info Enumerate WiFi networks, get signal strength and name of current network, etc. Ready Not Started
WebPayment Allow payments for virtual goods Ready Unit test automation present, Gaia UI Test automation currently being investigated

Template for new Sub-Plans can be found here.