Quality Assurance
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. See Wikimedia Release Engineering Team instead for the Wikimedia Foundation team. See Continuous integration for our automated testing infrastructure. See Selenium for automated browser testing. |
|
Quality Assurance
Software testing and quality assurance for Wikimedia engineering activities
|
Mission
The Quality Assurance (QA) efforts at WMF are a part of the Wikimedia Release Engineering Team.
The job of Release Engineering is to get software from the developer's head to production as quickly, easily, efficiently and safely as possible. QA is where we drive forward the safety part of that list.
Getting Started
Getting started with Quality Assurance? See Quality Assurance/Getting Started.
Projects
Software testing
WMF practices two main approaches to software testing: exploratory testing and automated browser testing.
Exploratory testing is "simultaneous learning, test design and test execution" or "test design and test execution at the same time". Exploratory testing is a powerful approach that everyone should know.
Our automated browser tests use Cucumber to define test scenarios and implement the Page Object design pattern. Browser test code resides with the code repositories that they test. You can find browser test code in the /tests/browser directory of the repositories.
We have pages devoted to exploratory testing and automated browser testing.
Testing environment
The test environment is known as the Beta Cluster. This cluster mimics, as closely as possible, the production setup but in a smaller (virtualized) footprint.
It duplicates a few Wikimedia projects, for example http://en.wikipedia.beta.wmflabs.org and http://wikidata.beta.wmflabs.org. It runs the latest version of the master branch of the wiki software and all extensions. The code on the beta cluster is updated automatically every 10 minutes, and the databases about every hour.
On the Beta cluster we test the most recent software features that are assumed to be viable. It does not host wild experiments or unsupported features, but only the latest version of the master branch of features to be deployed to production.
Contact
Mailing list: The QA mail list is a great resource not only for testing Wikipedia software but also for general discussion of QA and testing practice
IRC: We are on IRC in #wikimedia-releng connect.
More information
Because our QA effort is spread across Wikimedia Engineering we are not always 100% engaged with every project. We have a guide on when to use QA services.
We also collaborate with Bug management, Continuous integration, Wikimedia Labs and the testing plans of other Wikimedia Engineering teams.
See also
- The first week of training QA staff get
- Bug management & How to report a bug
- Continuous integration
- Wikimedia Labs
- Manual:Unit testing
Subpages
- Article Feedback Test Plan
- Examples
- Exploratory testing
- First week
- Getting Started
- Guide to getting started
- How we prioritize
- Levels
- Meetings
- Meetings/2013-07-18
- Meetings/2015-06-02
- Meetings/2015-06-09
- Meetings/2015-06-16
- Meetings/2015-06-23
- Meetings/2015-07-07
- Meetings/2015-08-25
- Meetings/2015-09-15
- Meetings/2015-09-22
- Meetings/2015-09-29
- Meetings/2015-10-06
- Meetings/2015-10-13
- Meetings/2015-10-20
- Meetings/2015-11-03
- Meetings/2015-11-10
- Meetings/2015-11-17
- Meetings/2015-11-24
- Meetings/2015-12-01
- Monitoring results
- Refactoring 2014
- Review February 2013
- Roadmap
- Status 2012-2014
- Status 2012-2015
- Strategy
- User priorities
- VisualEditor regression test backlog
- Weekly goals
- When to use QA services
- Writing feature descriptions