|Deletions are marked like this.||Additions are marked like this.|
|Line 45:||Line 45:|
|As a new way to test the builds, we host cadence testing weeks every two weeks, possibly in the middle of a milestone, for example in between Alpha 2 and Alpha 3. It is also tested using [http://iso.qa.ubuntu.com/|ISO QA Tracker]]. It is a good way to keep you busy with testing, but only for a certain time.||As a new way to test the builds, we host cadence testing weeks every two weeks, possibly in the middle of a milestone, for example in between Alpha 2 and Alpha 3. These run on the Daily Builds system as above.|
This section provides further information and useful links for testers. As with all alphas and betas they are not suitable for a production environment, please take the time to read Common Questions for Testing
At each milestone release, the notes at technical overview are updated.
It is especially important that Bugs found in the development release be upstreamed so that their upstream authors can see them. Often we are using the latest, unmodified alpha code for various projects during the development release, so the odds of it being fixed are much greater if they can be reported to the upstream developers making the changes.
Discussing a bug on IRC, email, forum or facebook areas etc. does not raise a bug. The devs do not monitor those areas. By all means use them to discuss a problem. Once your discussion about the bug is at a stage where you can report it, then for it to be actioned by the devs you must raise a bug.
My Bug went Private
The bot that goes looking for duplicated bugs is not aware if the bug it is using as master is private. If this happens please go to #ubuntu-bugs and raise it with them.
Dealing with Bug Reports
Triaging (dealing) with bug reports is a really important area. When new fixes come through it is important to let people know. please try a newer version is one such answer. There is also full list of responses. It is important that the person who raised the bug, no matter if it is incomplete, a duplicate or any other reason is made to feel that their bug is important. Simply put, to them, it is the most important bug in the world and should be treated as such.
The Bug Squad
If you'd like to know more about the treatment of bugs, please head over to The Bug Squad new comers are always welcome.
Testing is split into distinct, but joined areas. The Daily Builds, the Cadence Testing, the QA-testing of Milestone releases and the Milestone releases themselves.
To not get overly complicated, think of it as that we have a schedule to keep to. A few days before a Milestone is due, the daily is plucked and becomes the QA (Quality Assurance) test version for the Milestone release. Once it is confirmed that the QA version works, it then becomes the Milestone.
So, in order of how they happen.
These iso's are automatically generated every 24 hours using the latest updates on the system from the devs. They are available from ISO tracker. Using the zsync (or rsync) option allows you to update your iso to any of the various dailies you choose to follow without having to re-download the entire iso. They are there to check that bugs that are resolved between the Milestone releases do not break the install. They also are used to confirm that any fix for a bug that seriously affects an initial install which is released for testing now works.
As a new way to test the builds, we host cadence testing weeks every two weeks, possibly in the middle of a milestone, for example in between Alpha 2 and Alpha 3. These run on the Daily Builds system as above.
QA testing of Milestone releases
Alpha, Beta and Release Candidates (RC) are also tested using ISO tracker. If you want to help out in this important area of testing, please read through Procedures for further details. These appear a couple of days before the actual Milestone release so that we can check they are okay to become Milestone releases.
QA testing is to ensure the actual install iso works, if you can, please get involved in the qa testing
Once a Milestone release passes the QA testing, it becomes a Milestone Release and is listed on the Releases as such.
If you would to know more about how this all works, have a read of Stages of testing.
Calls for Testing
Occasionally, we will have unscheduled testing events to test a specific product or feature. Tests for these and instructions will vary, however the qatracker will be utilized if possible to help manage and record the testing.
During the release cycle, things will get broken. You can really reduce these occurrences by taking the time to read Partial Upgrades.
All the known issues for a particular release are mentioned in the Announcement email, and are available to see at ISO Tracker.
Manual test of ISO and CD
On the help-pages of Ubuntu there is an extensive guide on how to MD5SUM.
You can do more specific tests, like ones done for the Ubuntu ISO : http://iso.qa.ubuntu.com/qatracker/test/5090
Laptops never cease to have their little 'quirks'. You can help on this important area by heading over to Laptop Testing for full details.
You can test some aspects of Ubuntu performance with the following programs :
gtkperf : Test the performance of the gtk theme.
phoronix-test-suite: General benchmarks and test suite.
bootchart : Test boot process.
Some packages can be automatically installed, but are not wanted on a default installation. To find the package which automatically installed the package that you don't want :
- Install apt-rdepends
run "apt-rdepends -r --show=Depends the_unwanted_package" => It will show which packages depend on the_unwanted_package.
run "apt-rdepends -r --show=Recommends the_unwanted_package" => It will show which packages recommend the_package_unwanted (Recommended packages are installed by default).
- You may have to run the commands several times to see the complete chain of depends / recommends.