The mission of the Browser Testing and Tools Working Group, part of the Testing Activity, is to produce technologies for use in testing, debugging, and troubleshooting of Web applications running in Web browsers.
|End date||31 December 2013|
|Initial Chair||Wilhelm Joys Andersen|
|Initial Team Contact
(FTE %: 10)
|Usual Meeting Schedule||
IRC-only meetings: On an as-needed basis, up to once per week.
Teleconferences: On an as-needed basis, up to once a week.
Face-to-face meetings: On an as-needed basis, up to twice per year.
The scope of the Browser Testing and Tools Working Group includes:
For the purpose of automating testing of Web applications running in browsers, there is a specific need to simulate user actions such as clicking links, entering text, and submitting forms. The Browser Testing and Tools Working Group will produce a specification for a “Web Driver” API to meet that need.
For the purpose of troubleshooting and debugging Web applications, many Web browsers provide either a built-in set of “developer tools” or have a set of such tools that are available as a plug-in. Examples include:
The purposes of these developer tools include:
Those developer tools sometimes expose APIs that give
developers programmatic access to certain parts of the
development environment. For example, many expose
console API which, among other things, enables
developers to programatically control logging of particular
messages to an error console.
The Browser Testing and Tools Working Group will produce a specification for such a “Console” API, as well as consider any other potential APIs useful in performing troubleshooting and debugging of Web applications.
In order to advance to Proposed Recommendation, each specification developed by the Browser Testing and Tools Working Group is expected to have at least two independent implementations of every feature defined in the specification.
The Browser Testing and Tools Working Group will deliver the following W3C Recommendations:
Other deliverables that the group may also consider developing include a normative specification for a protocol for use in remote debugging of Web applications.
Furthermore, the group may produce any number of non-normative documents, such as:
|Note: The group will document significant changes from this initial schedule on the group’s home page.|
|Console Interface||October 2011||May 2012||June 2012||Dec 2012||Feb 2013|
|Web Driver Interface||October 2011||May 2012||June 2012||Dec 2012||Feb 2013|
To be successful, the Browser Testing and Tools Working Group is expected to have ten or more active participants for its duration. The Chairs and specification Editors are expected to contribute one day per week toward the group. There is no minimum requirement for other participants.
The Browser Testing and Tools Working Group will also allocate the necessary resources for building Test Suites for each of its specifications.
The group encourages questions and comments on its public mailing lists, as described in Communication.
The group also welcomes non-Members to contribute technical submissions for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under the W3C Patent Policy.
Any Browser Testing and Tools Working Group teleconferences deemed needed will focus on discussion of particular specifications, and will be conducted on an as-needed basis, up to once per week.
The Browser Testing and Tools Working Group primarily conducts its work on the public mailing list firstname.lastname@example.org (archive), and on the #testing IRC channel on irc.w3.org:6665. The public is invited to post messages to that mailing list and to participate in discussions on that IRC channel.
Information about the group (deliverables, participants, teleconferences, etc.) is available from the Browser Testing and Tools Working Group home page.
In accordance with the W3C Process Document (section 3.3), the Browser Testing and Tools Working Group will seek to make decisions when there is consensus and with due process. The expectation is that typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required. However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation—using, for example, email and/or web-based survey techniques) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available.
Any decisions or resolutions made by the Browser Testing and Tools Working Group will be made in a way that allows for remote, asynchronous participation—using, for example, e-mail and/or Web-based survey techniques.
This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.
The Browser Testing and Tools Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.
For more information about disclosure obligations for W3C working groups, please see the W3C Patent Policy Implementation.
This charter has been created according to section 6.2 of the W3C Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.
$Id: browser-testing-charter.html,v 1.31 2012/09/27 16:50:04 mike Exp $