Testing ideas: Difference between revisions
(Included a note from the Qemu page advising against jffs2 images for Qemu) |
(Added notes on dead end pages) |
||
| Line 22: | Line 22: | ||
''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.'' |
''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.'' |
''Stuff like that.'' |
||
| Line 43: | Line 45: | ||
|} |
|} |
||
=== Signed |
=== Signed Builds === |
||
A Signed build is a build that can be run on any |
|||
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 [[Activation and developer keys|developer key]]. |
|||
| ⚫ | |||
<br/><br/><br/><br/><br/><br/> |
|||
| ⚫ | |||
[[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 Structure|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 == |
== Old Instructions == |
||
Revision as of 12:05, 1 July 2008
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
- 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/
- eg. build2092/devel_ext3/xo-1-olpc-stream-joyride-devel_ext3.img.bz2
- Note. Do not download the jffs2 image for Qemu emulation. Download the ext3 images instead.
- Launch the image with qemu -m 256 -soundhw es1370 -net user -net nic,model=rt8130 -hda en708-1.img
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.