User:Mchua/Braindumps/learning testing: Difference between revisions

From OLPC
Jump to navigation Jump to search
mNo edit summary
Line 39: Line 39:
* '''Testing volunteers:''' SugarLabs.
* '''Testing volunteers:''' SugarLabs.
* '''Testing tools:''' This space intentionally left blank. Ideas?
* '''Testing tools:''' This space intentionally left blank. Ideas?

== Groups to learn from ==

* Fedora (coordinating volunteer efforts with commercial releases)
* Ubuntu (dealing with upstream)
* GNOME (bug triage days, getting newbies started)
* TOPP (session-based exploratory testing)
* Mozilla (automated testing)

Revision as of 15:41, 10 October 2008

Ongoing

  • Testing volunteers: learning how other large open-source projects get their testing to happen. I'm going to volunteer for a different open source project's test squad every month, and then find ways to bring best-practices back to OLPC. The goal is to have volunteers do as much solid testing as possible with as little intervention from 1cc as possible; I forsee much toolmaking in this.
  • Testing Tools: tools that seem to be used a lot in testing, that we already use in testing, etc. and how to use, configure/modify, and (most importantly) get others to consistently adopt them. I'll pick a tool or type of tool each month and tweak/document it for devels and broader community use.
  • New words and concepts: Keep a log of terms I haven't heard before (hey, "waterfall" used to only refer to actual bodies of falling H2O for me). This will be useful to new testers in our community who may come from nontech backgrounds and are unfamiliar with the terms.
  • Feedback loops: Everything I'm doing should get a quick sanity check on who it's benefiting - the test team? the devels? our product manager? our volunteer dev and/or test community? And then actually make sure those people benefit; ask them what they want and how the current fix is doing.
  • Testing books: One book per month.

October

  • Testing volunteers: Fedora. Gregdek is organizing Fedora-on-XO testing, I'm watching how he gets people excited and keeps them motivated about this.
  • Testing tools: Trac (more generally, ticket systems). This will be heavy on the taking-tweak-requests side; I've made a Trac plugin before and it's a fun architecture to roam in.
  • Testing book: Testing Computer Software, 2nd Edition

November

  • Testing volunteers: Ubuntu. This is immediately after the release of Intrepid and the beginning of their 6-month release cycle; I'm going to watch how they kick off.
  • Testing tools: Tinderbox (more generally, automated build tools... I could stand to learn more about make). Goal is to write Light the Tinderbox with Chris and Michael. (I didn't know we used tinderbox until 2 weeks ago!)
  • Testing book: Lessons Learned in Software Testing

December

  • Testing volunteers: GNOME. This is in the middle of their release cycle when there's nothing scheduled and the testers will have more time - I've admired their getting-newbies-started approach with bug triage days for a while, and want to learn how they manage to keep things friendly while turning nontechnical people into great testers.
  • Testing tools: GUI testing tools. Things like X Window System event scripting, etc... what do the GNOME folks use?
  • Testing book: From here on out it's blank - I'd love to get some hardware/RF testing stuff in here, but will play it by ear.

January

  • Testing volunteers: Ubuntu. This is immediately after the release of Intrepid and the beginning of their 6-month release cycle; I'm going to watch how they begin each round.
  • Testing tools: Volunteer management frameworks. For Ubuntu, Launchpad. For us, perhaps the wiki? Semantic Mediawiki is one possible thing to focus on this month. Wiki/IRC bots to translate info between various frameworks may also be helpful here; automated scripts for testing volunteer web frameworks (twill, ClientCookie, etc.) can also be used for bots.

March

  • Testing volunteers: OpenPlans. I need to talk with Tim to see if he wants to experiment with remote exploratory testing.
  • Testing tools: Memory leak / performance testing. (This will fit in towards the end of OLPC's release cycle when we'll need to test many such bugs.) We do these manually right now, I want to automate them.

April

  • Testing volunteers: SugarLabs.
  • Testing tools: This space intentionally left blank. Ideas?

Groups to learn from

  • Fedora (coordinating volunteer efforts with commercial releases)
  • Ubuntu (dealing with upstream)
  • GNOME (bug triage days, getting newbies started)
  • TOPP (session-based exploratory testing)
  • Mozilla (automated testing)