QA/Browser Technologies/WebAPI: Difference between revisions
| Line 123: | Line 123: | ||
** '''manual test cases''' - stored in Case Conductor. Note that we will be running parallel manual and automated testing efforts so that test coverage is not lost while automation is being built up. Also, it is not generally possible to automate everything. | ** '''manual test cases''' - stored in Case Conductor. Note that we will be running parallel manual and automated testing efforts so that test coverage is not lost while automation is being built up. Also, it is not generally possible to automate everything. | ||
...and ultimately... | ...and ultimately... | ||
'''automated functional testing''' - most likely in a combination of tools like e.g. Robotium and Marionette. The plan is to try to leverage the test pages and test apps/code developed (and manually tested against) earlier. | |||
In addition to functionality, each api may have the following quality targets: | In addition to functionality, each api may have the following quality targets: | ||
| Line 135: | Line 135: | ||
It should be noted Some APIs (and areas of support) however only work in conjunction with other APIs, so these must be combined when writing test apps. | It should be noted Some APIs (and areas of support) however only work in conjunction with other APIs, so these must be combined when writing test apps. | ||
=Environments= | =Environments= | ||
Revision as of 00:50, 9 November 2011
Overview
The Mozilla WebAPI team is aiming at providing all the necessary APIs to build a basic HTML5 phone experience within the next 3-6 months. Most of the known APIs (derived from bugzilla) are listed here.
Blue means the feature has already shipped in a previous version of firefox.
Green means the feature has landed recently, or is landing soon.
Red means the feature is currently a work in progress.
Mozilla will most likely not implement the FileSystem API. For local file access, we have implemented FileReader and plan to implement parts of the FileWriter specification. A file system abstraction can additionally be built on top of IndexedDB.
Team Details
The team is starting out initially as just John Hammink (as more members will be added over time). Also Malini Das will be writing functions within Marionette project to support test automation of Web APIs and B2G.
Team Members and Assignments
| Name | Contact | Availability | Project Assignments |
| John Hammink | jhammink@mozilla.com | MoCo Employee (full time) | Project Lead, Automation |
| Tony Chung | tchung@mozilla.com | MoCo Employee (full time) | QA Team Manager |
Current Status
Projects
This section should contain a list to the active current team project page. The section will be included as part of the top level QA organization page.
| Project | Description | QA Owner |
| [[<link>| XX API Test Plan]] | Description of XX API Test Plan | John |
| [[<link>| XX API Test Plan]] | Description of XX API Test Plan | John |
| [[<link>| XX API Test Plan]] | Description of XX API Test Plan | John |
Overall Approach
Each API must be assured of its robustness and fitness for purpose. APIs must work at Integrationlevels with each other and with external testapps, Application level supporting entire applications, and as part of an end-to-end system.
To that end, the testplan for each API could consist of the following deliverables in each case:
- Integration Tests - Tests for JS interfaces at integration level. These are usually automated and might deploy a framework like Jasmine, Marionette and/or something like Robotium with custom classes, TBD.
- Application Tests - These would most likely consist of
- test pages - Test HTML pages implementing the WebAPI(s) in question
- native test apps - in the case of Android, it should be possible to get api values directly from OS as a basis of comparison
- manual test cases - stored in Case Conductor. Note that we will be running parallel manual and automated testing efforts so that test coverage is not lost while automation is being built up. Also, it is not generally possible to automate everything.
...and ultimately... automated functional testing - most likely in a combination of tools like e.g. Robotium and Marionette. The plan is to try to leverage the test pages and test apps/code developed (and manually tested against) earlier.
In addition to functionality, each api may have the following quality targets:
- Usability
- Reliability
- Performance
- Scalability
- Security
So TBD, there may be additional tests or test strategies deployed iteratively as the project evolves.
It should be noted Some APIs (and areas of support) however only work in conjunction with other APIs, so these must be combined when writing test apps.
Environments
List what's needed for test environments here. links to test cases, test servers, unit tests, etc..
The following matrix which is a WIP will be used as a template for determining device and version support for each api:
https://docs.google.com/spreadsheet/ccc?key=0AhE7m4JB2j6tdEJFZ3NoZkRoRTM3TTRpQll3UjZLYnc#gid=4
Environment matrices for each API or area will ultimately list:
- all supported devices and hardware types
- all supported browser versions
- b2g
Resources
List links to any associated Resources
Meetings
List team meetings, schedule, and dial in time here.
Community Contribution
- list any tips and tricks on how community can be involved