Talk:Quality Assurance/Strategy/LQT Archive 1

Manual testing strategy
Draft aiming to take over the "Volunteer strategy" text of this page.

Goals

 * 1) Improve Wikimedia software products:
 * 2) * User perceived quality.
 * 3) * Areas difficult to cover with automated testing.
 * 4) Grow the Wikimedia technical community.
 * 5) * Accessible entry point for Wikimedia users and editors. No technical skills required.
 * 6) * Good motivation for experienced and professional testers.

Volunteer profiles

 * Wikipedia/Wikimedia editors and motivated users willing to try what's coming next.
 * Experienced / professional testers willing to contribute.
 * Companies developing products where Wikipedia/Wikimedia software needs to run well.
 * ... and of course other regular contributors at https://bugzilla.wikimedia.org/ willing to get involved in a more structured way.

Consolidating a testing team
We need to identify, empower and let lead to those experienced in testing and QA, and those experienced in Wikimedia software & community.

We must build a healthy meritocratic structure with a dose of fun and incentives to those doing great progress and helping out others progressing as well.

Based on this we have another view on profiles required:


 * Senior testers - can help and teach others.
 * Organizers - can increase the quantity and quality of QA activities.
 * Connectors - can bridge QA volunteers efforts with development teams.
 * Promoters - can help reaching out to new volunteers.

Activities
Almost all combinations apply:


 * Testing / bug triaging.
 * Online / on-site.
 * DIY / team sprint.
 * Synchronous / asynchronous.

We need good documentation to clone efficiently at least these cases:


 * Online testing sprint: how to organize, announce, perform, evaluate.
 * Individual testing: tasks that a person can perform and report about anytime / anywhere.
 * Individual bug triaging: reports to look at and instructions to improve their status.

Reaching out
We need to go beyond the sporadic isolated efforts and build a continuous, incremental flow of activites. The success of each activity must contribute to future successes.

We need to let people know about ongoing / DIY opportunities as well as events. We need to reach out to the current MediaWiki / Wikimedia communities as well as to external groups and potential new contributors.


 * Calendar: a central place where activities are announced. It should be possible to subscribe and receive notifications of new activities.
 * QA communities: reaching out and having processes in place to promote our activities.
 * Work with promoters to spread the news.
 * Contact companies testing Wikipedia in their products e.g. browser developers.
 * Organize on-site activities engaging local groups.

Measuring success
Team activities:
 * Number of events.
 * Diversity of events across development areas, promoters and locations.
 * Number of participants.
 * Effectiveness welcoming new contributors.
 * Effectiveness retaining and promoting current contributors.
 * Quantity and quality of reports created / triaged.
 * Impact in software releases and Bugzilla statistics.
 * Contributions to the goals of the Wikimedia Foundation.
 * Feedback from the related development team.

Individual activities:
 * How easy and how long before doing a first contribution.
 * Positive / negative feedback, complaints, bugs.
 * Individual contributors showing up in community channels and team activities.
 * Statistics on individual contributors (to be defined).
 * QA contributor retention.