Selenium/Ruby/Browser testing

Rationale
Why automate tests at the browser level? They find bugs!

Browser tests are most useful for:
 * Beta features: checking that they work in all browsers.
 * JavaScript: different browsers interpret JS in different ways.
 * Features requiring navigation: unit tests don't navigate.
 * Fragile: if something breaks often, we want to test it regularly.
 * Critical: features that must work all the time.

It's tedious to test manually Wikimedia sites within the multiple browser/operating system combinations that are out there, so we do automated testing to find errors and assure quality.

We use Cucumber because it lets you write tests in plain English; you don't need to know Ruby. Cucumber implements an idea called Acceptance Test Driven Development. The plain English test specifications open a communication channel with non-technical people who wish to contribute to browser test automation.

Check some real examples.

Timeline
See QA/Roadmap.

How to contribute
Contributing to Browser testing may take several forms


 * Write feature descriptions in plain English. Technical experience is NOT required. Currently this is our foremost need.
 * Run automated browser tests locally.
 * Write browser test code
 * Analyzing test results and reporting failures discovered by way of Jenkins
 * Contribute to the backlog of tests to be automated.
 * Check the list of EASY tasks - especially good for new contributors.

If you are interested in automated browser tests, join the proposed MediaWiki Group Browser testing.

Resources

 * Current test results.
 * Browser test source code in Gerrit, mirrored at GitHub.
 * Test plan: see the backlog of tests to be automated.
 * We use given-when-then testing format.