Scope

APIs (application programming interfaces) for use in automated testing of Web applications

APIs for use in troubleshooting and debugging of Web applications

APIs for use in automated testing of Web applications

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.

APIs for use in troubleshooting and debugging of Web applications

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:

viewing logs of errors, warnings, and informational messages
emitted by any JavaScript code that accompanies the
document/application, and by the JavaScript interpreter that executes
that code, as well as by other parts of the overall browser engine
(such as the DOM parser)

analyzing and debugging of any accompanying JavaScript code that
accompanies the document/application; more specifically:

setting debug breakpoints, stepping through code,
examining the current call stack and variables

using a provided command-line console/shell
interface—more precisely, a “read-eval-print loop” (REPL)—to
perform a variety of tasks, including directly executing
JavaScript code typed in by the user-developer

profiling accompanying JavaScript code

Those developer tools sometimes expose APIs that give
developers programmatic access to certain parts of the
development environment. For example, many expose
a 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.

Success Criteria

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.

Deliverables

The Browser Testing and Tools Working Group will deliver the
following W3C Recommendations:

The Console API provides methods that allow Web developers to,
among other things, programatically write messages and data to
a developer-tools console component. The messages include
generic log messages, as well as error, warning, and info
messages. The data includes stack traces and interactive “tree
view” representations of objects. Other methods provide ways to
start and stop timers, to clear all content from the console,
and more.

Other Deliverables

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:

Use case and requirement documents

Test suites for each specification

Primer or Best Practice documents, or other types of
how-to/tutorial documentation

Script libraries

Milestones

Milestones

Note: The group will document significant changes from this
initial schedule on the
group’s home page.

External groups

Existing technologies of possible relevance

Participation

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.

Communication

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
public-browser-tools-testing@w3.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.

Decision Policy

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.

Patent Policy

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.

About this Charter

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.

Note: this charter was updated in June 2014 to reflect the new
end date and the update of the milestones.