Summary

Websockets is a technology that makes it possible to open an interactive communication session between the user's browser and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply. Implementation of this feature in Firefox is tracked in bug 504553.

Status

People Involved

• Anthony Hughes [:ashughes] (QA)
• Andrea Marchesini [:baku] (Developer)
• Olli Pettay [:smaug] (Code Reviewer)

Testing Approach

Risk Profile

Describe the risks that exist in the project area and how those risks are mitigated.

1) Where is the spec?

The spec can be found here.

2) What are some of common errors and issues that manual testing should target?

Similar to what we do for XHR. It's an API for networking, so the testing should focus on server and client (browser) behaviors. Unfortunately it's not so easy to test, because having a running webSocket server requires nodeJS or other backend. Not a normal webserver.

3) What are some of common issues that automated testing is targeting and where can we find those tests?

We have a nice test suite here:

• this runs the same tests we have in dom/base/test
• this runs a basic test of the interface
• this tests loadGroup for webSocket
• [https://mxr.mozilla.org/mozilla-central/source/dom/workers/test/test_websocket_pref.html this tests enable/disable by pref
• this tests sharedWorker/serviceWorker/window-less workers

4) When filing bugs, how are they to be reported? What component(s) should they go under? What information makes a bug particularly actionable? What keywords, tags, flags, or other verbiage is expected when reporting bugs? What is the criteria for a bug to track a release? What is the criteria for a bug to block a release?

• Core :: DOM: Workers
• Core :: Networking

5) What is the acceptance criteria for Nightly? Aurora? Beta? Release?

The last time we tried to ship this it was turned off due to instability in Firefox 35. Crash stats should probably be an indicator for release-ready.

6) How easily can the code be backed out or disabled?

Very easily by setting dom.workers.webSocket.enabled.

7) What other code/features are directly or indirectly affected by the code? What about if the code has to be backed out or pref'd off?

Test Cases

Define the test cases required, including which tests can/should be automated, framework(s) used, and how often they should be executed.

• Provide link to repository(ies) for automated tests.
• Smoke
• Describe basic smoke tests required to prove minimum acceptance
• Functional
• List each major functional area to be tested and basic concepts for testing
• End-to-end User Stories
• Describe primary use cases
• Exploratory
• Describe some related areas and user stories that may be useful to explore

Bug Triage

Document any bug triage meetings and/or processes, including priorities:

• unconfirmed bugs
• development bugs
• fixed bugs
• regressions
• tracking bugs
• blocking bugs

Getting Involved

Provide instructions on the various ways to help with the project.

• Links to One and Done tasks
• Links to Moztrap tests
• Good First Verify in bugzilla
• Links to any tutorials and other QA introductory material
• Contact information and Meetings schedules and information on how to join
• Minimum requirements for becoming involved (Hardware, Software, Skills)
  • Describe the required test environment and provide instructions on how to create it.
  • If special skills are required, provide links to any tutorials that may be available on the subject.
  • If special hardware is required, provide steps on how to verify that the testers systems meet the minimum requirements.