Testing ideas

From OLPC
Revision as of 09:34, 23 January 2013 by Walter (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
542-stopicon.png This page has a more up-to-date location: Friends in testing


Who Should Read This?

This page is for those people who want to volunteer their time to the OLPC project in a software testing capacity. While there are many ways to install a test instance of the Sugar desktop environment on your own computer, this page tries to simplify the task by offering only one. The objective here is to welcome as many potential software testers as possible into the process.

Preparing a Test Environment

Emblem-warning.png The currency of this article or section may be limited by out-of-date information.
There may be relevant discussion on its talk page

Note: QEMU support is no longer maintained. Sugar on a Stick and sugar-build are the currently maintained development environments.

  • Install qemu
    • On Ubuntu: aptitude install qemu
    • On Fedora: yum install qemu
  • Select a development branch to focus your testing on (to be referenced when submitting your bug report)
  • Download the img file from http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/
  • Decompress the img with bunzip2 xo-1-olpc-stream-joyride-devel_ext3.img.bz2
  • Increase the size of /dev/shm. As root...
    • kill the process listed in lsof -n | grep shm
    • umount /dev/shm
    • mount -t tmpfs -o size=272m none /dev/shm
  • Launch the image with qemu -m 256 -soundhw es1370 -net user -net nic -hda xo-1-olpc-stream-joyride-devel_ext3.img.bz2

Please read the wiki on Qemu for more detailed instructions on how to get up and running with it.

Question: where do we get the .bz images that can be bzcat'd into 1gb files for? Ask CScott

Submitting a Bug Report

Bug reports are submitted on dev.laptop.org. Please consult http://dev.laptop.org/wiki/NewTickets for information pertaining to how to submit a bug report.

Volunteer Team Structure

Once there are a bunch of people helping in the testing effort, how will that volunteer team be organised? For instance, when should the volunteer team's effort be focussed on Joyride, and when should it be focussed on a release candidate? Will there be times when the whole volnteer team should focus on particlar activities? Will the volunteer team be divided into groups specialising in activities.

It would also be good for the volunteer team to get some idea of which areas have been changed. A way for the development team to indicate where bugs might have been introduced. If an area hasn't changed for six months and was thoroughly tested volunteers should concentrate on other areas.

Stuff like that.

Development Branches

There are four current branches of the software for the XO.

Update.1 (current) Stable build that are eligible for signing and distribution
Joyride Testing build where new features are implemented first
Faster
OLPC -3 A rebase of Joyride from Fedora 7 to Fedora 9

Signed Builds

A signed build is a build that can be run on any XO-1. Or put another way, an unsigned build may not be run on an XO-1 unless you accompany it with an developer key.

Deadend Instructions

Emulating the XO and Developers/Setup are obvious starting places for anybody wanting to get their hands dirty.. The problem is that where a volunteer may be serious about contributing their time, the options presented on those pages are overwhelming.

When the question of volunteer team organisation is answered, perhaps the best approach is to drop a banner in some of those pages. The banner would suggest to readers that if they are looking to get involved in the testing effort that this page is the place to start (or to read on if their install needs to be more exotic).

Old Instructions

  • See Test issues for QA test cases.
  • add a functional test for your activity.
  • add a description of who is editing your activity and where its source is to its info-box.