Ubuntu Testing Team

If you think that testing software is an unskilled activity that “even a two-year-old can perform”, keep reading, I’ll try to change your mind. If you do not agree with that sentence, keep reading, you may be interested in joining us.

Software testing is generally seen as the poor cousin of programming. While the bad reputation of testers happens in all software environments, this is more common in free software communities, probably because the “show me the code” motto is too deeply attached to the open source communities. This, unfortunately, is too often translated in unreliable software released with a lot of bugs (some of them critical).

Testing software, as any human activity, is a task that almost everybody can perform to some sort of proficiency. However, that does not mean that it is an unskilled activity. You have to know what to do. You need to have (or to develop), among others, excellent communication skills, technical writing skills, software architecture knowledge, technical research expertise, a critical mindset, etc.

We cannot leave quality to good luck. We cannot rely in having millions of users who will find bugs as they use the applications. Our users want to use the software, not to find bugs and report them. FOSS projects in general and Ubuntu in particular need a new way of rethinking testing as a skilled activity and an opportunity to contribute to the project.

We want to build a Testing Team in Ubuntu to try to minimize the impact of bugs in the released versions. This team would have a mailing list and regular meetings on IRC. Activities will be diverse and will include things like: formal manual testing, exploratory testing, writing new test cases, organize and conduct community testing days, automated testing and developing new tools (yes, if you like to code, there’s also a place for you).

We would love you to join us and make it happen.

We are having a session at UDS Lucid to discuss this topic (scheduled for Wednesday). You can subscribe to the blueprint as well.

9 comments

  1. Hi there,

    I think you make some really great points about the negative comments directed towards QA in general.

    I would be very much interested in joining a the Testing Team in Ubuntu. I do have a launchpad account. I was curious though about any prerequisites to joining this team? I’ve been looking into ways of contributing to Ubuntu and think that this could be a great way to start. Please let me know if there is any sort of prerequisites, etc.

    Thanks alot!

    • Hello Daniel, thanks for stepping forward.

      Requirements to join is one of the things we are going to discuss during UDS, but I think it will only imply signing the code of conduct.

      Anyway, after UDS, we will announce it here (and in various mailing list) the process to join, meetings, etc.

  2. I like your lead-in to this article. I feel the same way about documentation sometimes, and I find that I’m able to replace the words “testing” or “testing team” with “documentation” and “documentation team” in your post.

    Best of luck in building out the testing team. :)

  3. Also, a skill which really is far from the “trivial” and “2 years old” category is being able to create good and useful bug reports (http://www.chiark.greenend.org.uk/~sgtatham/bugs.html).

    I would love to see such a team come to existence. We already have lots of well-known community members who do a lot of testing and write great bug reports, but it’d be great to formalize this in a way to get a measurable coverage of different hardware (the field where by far the most regressions happen).

    As part of that, testers/developers/the community at large should build a growing set of test cases in an easily accessible format. We have put “Test plan”s into our blueprints for quite a while now, but never really made good use of them. Also, we completely lack formal test plans for most of the upstream software that we package, such as “create an audio CD”, “import your music player’s collection into Rhythmbox”, “connect to an ethernet without DHCP”, and so on.

    • Indeed. Even more, when a non-technical user encounters a new bug, the user is frustrated. But if he or she decides to report a bug and just reports “I was using Firefox and something broke”, then developers are also frustrated, because they can’t do much about it.

  4. Pingback: Peng’s links for Saturday, 14 November « I’m Just an Avatar

  5. Pingback: Why do software test teams get a bad name? | Stuart Taylor

Leave a Reply

Required fields are marked *.