WebRTC/Test Plan

Purpose

This document intends to provide a high level overview of the testing that's needed for testing the entire stack of the WebRTC feature set.

Feature Ownership

Feature	QA Lead
getUserMedia	Jason Smith
Peer Connection	Jason Smith
Data Channel	Jason Smith

Other Resources

Resource	Lead
Security	Christoph Diehl
Automation Development	Henrik Skupin

Testing Scope

In Scope

Functionality

• getUserMedia and Local Media Streams DOM functionality
• End-to-end integration with real cameras/mics across operating systems with getUserMedia
• Peer Connection, Session Description, and Ice Candidate DOM API functionality
• Data Channel DOM API and it's integration with global Peer Connection DOM API
• End-to-end local and remote Peer Connection handshaking, ice candidates, data connections, etc.
• End-to-end local and remote Data Channel integration with Peer Connection and sending of data

Software Qualities

• Security - Fuzzing SDP, the DOM APIs, ordering of handshake, etc
• Performance - Time for round-trip calls, video/audio response time upon input, etc
• Scalability - Scaling to large network topologies - do we hold together without functionality/performance issues?
• Availability & Resilience - Downtime during & after handshake, lame network handling, etc
• Location - location of peers - close? Different country?

Out of Scope

• Actual third-party WebRTC apps using the API (outside of Mozilla-specific needs)
• Android and B2G for now, as we're targeting desktop primarily first
• Other unsupported getUserMedia, Local Media Streams, Peer Connections, and Data Channels DOM API functions we are not targeting for v1 release

Testing Lifecycle

Overview

This section provides an overview of the lifecycle of testing the WebRTC-based APIs for the first release of getUserMedia, PeerConnection, and DataChannel.

getUserMedia Device Integration Testing with No UI Integration

Summary

Testing the integration with real devices (camera, microphones) without the UI hooked up. Focuses on making sure integrated hardware works with real-time media streams received from getUserMedia for playback.

Signoff Criteria

Already signed off and finished.

getUserMedia DOM Testing and Automation

Summary

Testing and writing mochitest automation for LocalMediaStream, getUserMedia API, and integration with media element functionality in the DOM.

Signoff Criteria

Already signed off and finished.

getUserMedia Device Integration Testing with UI Integration

Summary

Testing the integration with real devices with the UI hooked up in the Firefox front-end. Focuses on making sure the full end to end pieces are hooked up with both integrated and USB hardware with real-time media streams received from the getUserMedia.

Dependencies

The testing for no UI integration flows needs to be completed.

Signoff Criteria

Already signed off and finished. For reference, see the Firefox 20 getUserMedia signoff checklist for the testing that was done.

Peer Connection - Localhost and Fake Stream Automation

Summary

Heavy focus on testing the Peer Connection DOM API through mochitests using fake streams. Such areas that will be focused on include - the peer connection handshake, addition of ice candidates, media flow, event handlers, and closing of connections.

Dependencies

The testing of no UI integration flows with getUserMedia needs to be completed.

Signoff Criteria

All issues classified as P1s (automation bustage) and P2s (automation highly needed) in this bug query needs to be completed.

Note: We should still work through P3s (automation want) even with this quality area signed off, but that won't block signoff for this quality area.

Data Channel - Localhost DOM API & Peer Connection Integration Automation

Summary

Focuses on testing the Data Channel DOM API and it's integration with general Peer Connections through mochitests. Such areas that will be focused on include establishing a handshake between two data channels local and remote, event handling, attribute state, closing of data channels, etc.

Dependencies

The basic smoke test automation for peer connections should be completed with a reusable automation framework.

Signoff Criteria

All issues classified as P1s (automation bustage) and P2s (automation highly needed) in this bug query needs to be completed.

Note: We should still work through P3s (automation want) even with this quality area signed off, but that won't block signoff for this quality area.

Peer Connection - Localhost and Real Stream End to End Testing

Summary

Focuses on testing of the Peer Connection DOM API through end to end tests on a local machine with real streams from cameras and microphones. The testing style is similar to how the automation will be developed with fake streams, except the big difference is the focus with real streams and testing areas that are non-trivial to automate. Such areas that will be focused on include - video/audio device integration, call rejection explicit vs. not explicit, call longevity, multiple calls, clean vs. non-clean shutdown, connection loss, flaky connection, etc.

Dependencies

getUserMedia UI integration testing should have basic flows passing and most complex flows passing.

Signoff Criteria

• A smoke test run executed with no major blockers found with localhost real stream peer connection scenarios
• A basic functional test run executed with no major blockers found with localhost real stream peer connection scenarios
• An exploratory test run executed with no major blockers found with localhost real stream peer connection scenarios
• Verify blocker bugs that are possible to verify with localhost real stream peer connection scenarios

Data Channel - Localhost and Peer Connection Integration Testing with Real Streams

Summary

Focuses on testing the Data Channel DOM API with end to end tests and integration with other Peer Connections. Such areas that will be focused on include reliability of messages sent, type of information sent, rate of information sent, and integration scenarios involving many of the areas talked about in the localhost Peer Connection end to end testing.

Dependencies

Basic end to end test scenarios for Peer Connections should be defined and passing for localhost cases.

Signoff Criteria

• A smoke test run executed with no major blockers found with localhost data channel scenarios
• A basic functional test run executed with no major blockers found with localhost data channel scenarios
• An exploratory test run executed with no major blockers found with localhost data channel scenarios
• Verify blocker bugs that are possible to verify with localhost data channel scenarios

Peer Connection - Remote Real Stream End to End Testing

Summary

Focuses on remote scenario testing with Peer Connections with real streams and microphones that both use Firefox. Such areas to focus on include single vs. multiple remote connections, connection loss, lame networks, peer locations, stream performance, type of server being used, explicit vs. not explicit call end, longevity of call.

Dependencies

Localhost peer connection real stream testing has basic flows passing and some complex flows passing.

Signoff Criteria

• A smoke test run executed with no major blockers found with remote peer connection scenarios
• A basic functional test run executed with no major blockers found with remote peer connection scenarios
• An exploratory test run executed with no major blockers found with remote peer connection scenarios
• Verify blocker bugs that are possible to verify with remote peer connection scenarios

Peer Connection - Interoperability Testing with Chrome

Summary

Focuses on interoperability testing between Chrome and Firefox locally and remotely with real streams and microphones. Areas to focus on are basically a summation of the focus areas of the localhost and remote peer connection testing except using differing browsers in the call.

Dependencies

Localhost and remote peer connection testing has basic flows passing and some complex flows passing.

Signoff Criteria

• A smoke test run executed with no major blockers found with interoperability peer connection scenarios
• A basic functional test run executed with no major blockers found with interoperability peer connection scenarios
• An exploratory test run executed with no major blockers found with interoperability peer connection scenarios
• Verify blocker bugs that are possible to verify with interoperability peer connection scenarios

Open Questions

• What's the purpose of the onopen callback on Peer Connection?
• What's proper vs. inproper syntax for an ice candidate string?
• In the configuration parameter when creating a Peer Connection:
  • Can I see an example of usage and a description of what it's doing?
  • What's the difference between specifying a single vs. multiple ice servers?
  • If no configuration is specified, what happens in this case?
• On the Peer Connection object, we currently do not expose or update the following items that are indicated in the spec. What's needed for v1 vs. can be taken care of later? What bugs are tracking the work?
  • signalingState
  • updateIce
  • getLocalStreams
  • getRemoteStreams
  • getStreamById
  • onnegotiationneeded
  • Others?
• What's the proper way of testing a simple end to end flow using MediaConstraints on createOffer, createAnswer, and addStream?
• What's proper vs. improper syntax for a sdp string?

Resources

• WebRTC W3C Spec
• Example WebRTC App
• WebRTC Test Pages
• WebRTC Tutorial
• WebRTC Architecture
• NAT Traversal
• STUN
• TURN
• SDP
• ICE