The Wikimedia Foundation currently has two open positions for QA staff. One is for a QA Engineer and the other for a Volunteer QA Coordinator.
I want to point out what a unique opportunity this is.
Before I was hired at WMF four months ago as "QA Lead", there had never been anyone working on the Wikipedias and related projects whose only focus was testing and quality. There was no UI test automation, there was no program of community testing. Actually, there still isn't. That's where these new staff come in. No exaggeration: this is an opportunity to create from scratch the quality and testing practices for one of the great achievements in human history. But WMF only has about 100 staff, and only about half of those are technical. At the moment, there are about 50 regular contributors to WMF software (and millions and millions of users!), so this QA staff will be outnumbered and outgunned. So we need help, both from automation and from a community of people interested in testing.
WMF has two priorities this year for QA and testing: one is to implement some browser-level test automation. The other is to involve both the testing community and the Wikipedia community in more testing activities.
As QA Lead, I figured it was my job to lay some groundwork for these activities. So I did a lot of research on the current state of browser automation (I'd not been following recent developments there for some time) and built a demonstration and example of what I think the best available browser test "stack" should be. (Note: there is some bad code in there right now, for a purpose) I think Ruby is the way to go for this, and this is my justification for that. I am really looking forward to working with our new QA Engineer to expand these tests, bring in community contributions, hook it up to Jenkins, run it against our brand new test environment, etc. etc. My little spike is only an example, and I look forward to having my mind changed about how it will ultimately be of use.
The other thing I've done is to begin having "test events" where WMF invites outside groups to help test some aspect of the Wikipedia software. On May 5 2012 we teamed up with Weekend Testing to validate the new frequent deployment scheme when we began updating all the Wikipedia software every two weeks. On June 9 we'll be teaming up with Openhatch.org for a "shakedown cruise" of the new Wikipedia Article Feedback system that will be rolled out to all of Wikipedia in just a few weeks. I'm looking forward to working with the new Volunteer QA Coordinator to expand community testing both in partnership with other organizations and within the Wikipedia community itself.
As for me, to the extent that I am a "Lead", I tend to lead from behind. I'll be working with new and evolving WMF projects to bring testing and quality work where it can be the most valuable. I'll be working with the test automation communities to improve development practices through testing. I'll be looking for cool stuff out in the world for Wikipedia to make use of. It's a brilliant future.
I want to point out what a unique opportunity this is.
Before I was hired at WMF four months ago as "QA Lead", there had never been anyone working on the Wikipedias and related projects whose only focus was testing and quality. There was no UI test automation, there was no program of community testing. Actually, there still isn't. That's where these new staff come in. No exaggeration: this is an opportunity to create from scratch the quality and testing practices for one of the great achievements in human history. But WMF only has about 100 staff, and only about half of those are technical. At the moment, there are about 50 regular contributors to WMF software (and millions and millions of users!), so this QA staff will be outnumbered and outgunned. So we need help, both from automation and from a community of people interested in testing.
WMF has two priorities this year for QA and testing: one is to implement some browser-level test automation. The other is to involve both the testing community and the Wikipedia community in more testing activities.
As QA Lead, I figured it was my job to lay some groundwork for these activities. So I did a lot of research on the current state of browser automation (I'd not been following recent developments there for some time) and built a demonstration and example of what I think the best available browser test "stack" should be. (Note: there is some bad code in there right now, for a purpose) I think Ruby is the way to go for this, and this is my justification for that. I am really looking forward to working with our new QA Engineer to expand these tests, bring in community contributions, hook it up to Jenkins, run it against our brand new test environment, etc. etc. My little spike is only an example, and I look forward to having my mind changed about how it will ultimately be of use.
The other thing I've done is to begin having "test events" where WMF invites outside groups to help test some aspect of the Wikipedia software. On May 5 2012 we teamed up with Weekend Testing to validate the new frequent deployment scheme when we began updating all the Wikipedia software every two weeks. On June 9 we'll be teaming up with Openhatch.org for a "shakedown cruise" of the new Wikipedia Article Feedback system that will be rolled out to all of Wikipedia in just a few weeks. I'm looking forward to working with the new Volunteer QA Coordinator to expand community testing both in partnership with other organizations and within the Wikipedia community itself.
As for me, to the extent that I am a "Lead", I tend to lead from behind. I'll be working with new and evolving WMF projects to bring testing and quality work where it can be the most valuable. I'll be working with the test automation communities to improve development practices through testing. I'll be looking for cool stuff out in the world for Wikipedia to make use of. It's a brilliant future.