QA/Testdays/Strategy: Difference between revisions

Jump to navigation Jump to search

QA/Testdays/Strategy (view source)

Revision as of 22:54, 31 March 2015

6,738 bytes removed ,  31 March 2015
Replaced content with "; Page Removed"
(Replaced content with "; Page Removed")
Line 1: Line 1:
 
; Page Removed
 
The following ideas have been vetted as ideas we think are good to pursue but are yet to be prioritized within the roadmap.
* Consider using uservoice to collect ideas/feedback/topics for testdays ([https://ffdevtools.uservoice.com/ example])
* Contribute to http://fedoraproject.org/wiki/QA/Test_Days and see what can be learned
* Define a long-term vision of what we want of testdays
* Define a set of curricula to enable other community leaders to contribute to the vision
* Develop a roadmap based on the long-term vision
* Define a quarterly goal based on pre-determined milestones from the roadmap
* Learn from what the [https://etherpad.mozilla.org/marketplace-day Marketplace team] has been doing
* Learn from what the Automation Development team has been doing
* Set up a periodic check-in to evaluate progress on the roadmap and pros/cons of testdays run since the last check-in
* Push testdays more in a direction of mentorship and establishing relationships, less about testing a certain product
* Create a tool that allows people to contribute their own ideas
* Figure out a way to map skills/value to specific events so volunteers can better select events based on interest
* Explore using a tool like the "questions voting" system we use for townhalls so people can contribute ideas and ask questions
* Have a canonical document on "how to run an event"
* Have testdays which are focused on teaching skills
* Have more mentors from QA and Dev, less moderators
* Have testdays from a wider range of projects
* Develop better tools for outreach, metrics, rewards, and engagement
* Research the pain points that exist with testdays (from organizers to devs to volunteers)
* Find community members with the technical skills to assist in building/improving our tools
* Look into using [https://github.com/ppapadeas/mozmoderator Mozilla Moderator] to collect feedback
* Hold a weekend testing event
* Replace the idea of "moderators" with "mentors"
* Mentors should be easily identifiable during the event
* Mentors should focus on 1:1 or few:1 interactions
* Mentors should mentor on their area of expertise in addition to general, common-place methodologies
* Being a mentor should not be limited to employees
* Leverage existing mentorship programs
* Hold "training days" once in a while
* Design testdays to create long-term contribution outside of testdays (feature ownership, automation development, crashkill, good-first-bugs, feature development, etc)
* We should have dedicated, knowledgeable people in channel to engage with people participating in the testday
* Set up untimeboxed tasks in one-and-done [see Automation Training Days as an example]
* Have a flexible schedule to allow for broader participation
* Have a presence on Vidyo or some other "live" technology to provide guidance
* Broaden our communication channels to more social networks
* Encourage testers to provide general feedback about what they're testing, not just focus on finding bugs
* Encourage testers to come up with new ideas for features, design, and testing methods
* Try to tie testday topic to something new and exciting but with a learning aspect (ie. need variety)
* Figure out the most effective channels for reaching our target audience and use those channels effectively
* Consider holding locale specific testdays organized by those communities
* Move #testday to #qa to get more eyes on the chatter
* Follow up each testday with a feedback survey to participants
* Encourage repeat participants to take on more supportive roles (assisting with events, mentoring, event promotion, etc)
* Need to clearly define the mutual value of participation (how it benefits the participant, how it benefits Mozilla)
* Understand our stakeholders and define what we expect from them, what they expect from us
* Time-bound activities should be included in the About:Mozilla newsletter (see [mailto:jhalperin@mozilla.com Jennie Halperin])
* Learn from what other teams are doing (Marketplace, Mozillians.org, Grow Mozilla, Reps, etc)
* Learn from what other communities are doing (Fedora, Ubuntu, Weekendtesters, etc)
* Incorporate components of a mixer (ie. meet and greet Mozilla employees, volunteers, and mentors)
* Reach out to different audiences based on the topic (ex. Flash developers if testing Shumway)
* Emphasize the value/benefit and reason why a task is done
* Emphasize the opportunity outside QA that participating in a testday creates
* Create a testday Vidyo room (or some other AV tech)
* Make IRC easier to use, more accessible, and consider using alternate technologies for people who don't want to engage on IRC
* Conduct an audit of each of our tools for intent and value, whether to invest or devest
* Ask Marcia Knous and Michelle Marovich about community programs we could be utilizing
* Try running a testday in collaboration with an external community (Redhat, Canonical, etc)
* Have discussions with the Community Champions and the Grow Mozilla group
* Revisit the idea of having a QA community manager
* Develop better tools for outreach, metrics, rewards, and engagement
* "Thank You" posts across our channels
* Badges
* Gear
* Statistics in Mozillians.org, along with earned skills and next steps
* Invitation to physical events
* Invitation to take on a greater role
* Need an easy mechanism to track results (per event, per contributor, per time period, etc)
* Define clear pathways to rewards
* Define the Contribution Ladder for testdays
** how to convert a "trained volunteer" into a "trainer"
** how to open up events to a broader set of contribution
** what makes it difficult for contributors to engage long-term
** define a tool that makes it easier to engage with volunteers
** why do people come to testdays
** what do people want to learn
** what draws them to a particular project
** how can a testday act as a first step toward long-term contribution in another project
** what are the various activities/levels for testdays?
* Stop using etherpad for testday documentation [needs further discussion]
* Instructions which are common-place should be documented and recorded for easier consumption
* Provide tutorials on the most basic tasks/processes [see bugdays as an example]
* Documentation should be translated whenever possible
* Create some flow-chart tutorials like [http://www.tizianasellitto.it/trainingmontage/bugzilla-triage-tutorial.html this one]
* Improve feature documentation so it's easier for contributors to contribute [QA Owners?]
* Create a mechanism to more easily track changes to a feature/component over time ([http://timeline.knightlab.com/ example])
* Create better documentation around feature ownership so contributors know who to ask if they have questions or want to get involved
Ashughes
Confirmed users
14,525

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/1065687"

Navigation menu