Ubuntu Unleashed 2017 Edition (2017)

---

There are many ways to help the Ubuntu community create, refine, and promote the operating system. Some are highly technical, like writing code or packaging programs to be included in the software repositories. Some are less technical, such as helping promote Ubuntu locally or through blogging interesting news items from the community. Somewhere in the middle, leaning toward the technical side, is a task that is wide open for greater community involvement.

This is a rather brief and intentionally vague chapter. Testing by volunteers is something that requires more than a casual interest if it is going to be helpful to the developers and not an annoyance. For that reason, this chapter covers the basics of how to get involved and some of the opportunities, but not the precise details. If you are interested, and after reading this chapter we hope you are, the next step is to visit the websites listed at the end of the chapter.

Community Teams

Two community teams would love to see volunteers who can follow directions, be careful and methodical, and who notice details. Both teams work to refine the distribution during the development cycle to help make Ubuntu the best it can be.

The Ubuntu QA Team looks directly at the overall quality of the distribution, trying out default programs and configurations and trying to break things. The goal is to find bugs during the development cycle and make clear reports about them, trying to get them fixed before end users ever know of their existence. The goal here is product improvement and quality control or assurance.

These are big tasks. Even with several Canonical employees working on these full time, it is nearly impossible to test every hardware configuration or use case. It is also impossible to guess what creative ways users will attempt to perform tasks that developers have designed to perform differently. Testing as many of these options as possible is key when the goal is to create a positive experience for as many people as possible. This is why volunteers are both welcome and actively recruited.

These are also exacting tasks. Testing and bug reporting (or fixing) requires careful attention so that problems are reported clearly with steps that can be repeated by developers. This enables them to find where problems lie and more easily fix them. Not everyone is well suited for this sort of thing, but those who are able to be clear and precise and who can follow the directions given in testing plans and procedures are worth their weight in gold. You might not receive public glory for testing, but you will receive honor from those working with you in testing if you can do the job well.

You will notice some crossover in the team descriptions that follow. That is because the teams work together closely. Although each has a main focus, each may perform similar tasks from time to time. Even the individual team’s web pages link to the others and offer similar information to help coordinate and direct any interested volunteers to the tasks they feel most equipped to help with.

Ubuntu Testing Team

Members of the Ubuntu Testing Team are probably best known for their work during a release week, when they help validate all of the CD and DVD images. They also operate during the release cycle testing beta releases and release candidates. In addition, they test update packages for stable releases before the packages are pushed out to users. They do this by enabling a new software repository called -proposed and trying out the software there before it ends up in the -updates repository. In addition, they help developers by coordinating communications and actively seeking and connecting additional volunteers when specific testing needs are encountered.

To get started, you need a Launchpad account. Then join the Ubuntu Testing Team via the team’s page in Launchpad at https://launchpad.net/~ubuntu-testing. It is also a good idea to subscribe to the team’s email list at https://lists.ubuntu.com/mailman/listinfo/ubuntu-qa. When testers are needed, the Launchpad team list and the mailing list are the initial points of contact for those that are asked to help.

There are many ways to get involved in testing; each has varying requirements on time and technical skill. Some tasks are quick and easy, and others might be more involved. Some of the tests are general in nature, and others involve specific features, applications, and hardware. Some tests are automated and require specific test software to be downloaded and installed. Others are given as a list of instructions. Opportunities exist for many skill levels and most time schedules.

QA Team

The QA Team has a stronger focus on developing and using tools to automate the process. This enables people using the tools to run a large battery of tests against a code base very quickly while ensuring they are probing precisely what is needed. Much of their work is useful for hardware certification, logic testing, and bug discovery. They have developed an Ubuntu developer-focused suite of tools called ubuntu-qa-tools, a library called Mago for the Linux Desktop Testing Project (LDTP) to simplify testing of Ubuntu within the wider realm of Linux desktops, a framework called Checkbox that tests and sends test data directly to Launchpad, and more.

Bug Squad

One of the first places people become involved in Ubuntu testing is with Bug Squad. These volunteers are the initial point of contact for most bugs filed with Ubuntu. They read bug reports to see whether the bug seems legitimate (for example, that it isn’t something like “Ubuntu doesn’t work,” but is rather specific and measurable), that it is filed against the appropriate software package, and that adequate information is included with each report for the developers to be able to figure out the problem. If the bug report meets the criteria, the Bug Squad determines which developer or team should be notified. Sometimes during the triage process they might ask reporters for more information. They attempt to determine the severity of the bug and might assign a priority setting to the report.

Test Drive

One specific tool used by both volunteers and developers that deserves a mention is Test Drive. When he wrote Test Drive, Dustin Kirkland was an Ubuntu developer on Canonical’s Ubuntu Server team (he still develops for Ubuntu as a community member, but has moved on to another job). He was looking for an easy way to download and run the latest daily development snapshot of Ubuntu using a virtual machine such as KVM or VirtualBox. Like any good developer who doesn’t want to repeat tasks unnecessarily, he wrote a tool to automate the process. While creating Test Drive, he made it configurable to use different virtual machines with different settings according to the user’s taste. It can even download and run any ISO that may be accessed via a URL, which means it could be used to download and run images from other distributions during their development cycles.

Test Drive is written in a way that enables even a nontechnical Ubuntu user to consistently test Ubuntu development releases. Test Drive is available in the Ubuntu repositories as testdrive. It runs from the command line.

When you run the program, you are offered a menu:

Click here to view code image

matthew@seymour:~$ testdrive

Welcome to Testdrive!

1. Ubuntu Desktop (saucy-amd64)
2. Ubuntu Desktop (saucy-i386)
3. Ubuntu Alternate (saucy-amd64)
4. Ubuntu Alternate (saucy-i386)
5. Ubuntu DVD (saucy-amd64)
6. Ubuntu DVD (saucy-i386)
7. Ubuntu Server (saucy-amd64)
8. Ubuntu Server (saucy-i386)
9. Other (prompt for ISO URL)

Select an image to testdrive [1]:

Type a number to download and run a specific ISO. As you can see, the preceding example is from the development cycle for Saucy Salamander, which eventually became Ubuntu 13.10.

The Test Drive configuration is stored in a simple text file and is easy to understand and edit (although many using Test Drive will never need to edit it). Test Drive looks several places for the testdriverc file, including the default location /etc/testdriverc and in the user’s /home directory at /home/matthew/.testdriverc and /home/matthew/.config/testdrive/testdriverc

Here is an example:

Click here to view code image

# This is the global configuration file for the testdrive(1) utility.
[testdrive-common]

# CACHE is the directory to cache the ISOs and disk images
# Default: $HOME/.cache/testdrive
#CACHE = /path/to/your/cache

# CACHE_IMG and CACHE_ISO will default to $CACHE/img and $CACHE/iso, respectively.
# You can set them explicitly if you want (especially interesting if you are
# trying to run the image off /dev/shm. Make sure you have enough space there!!!
#CACHE_IMG = /dev/shm

# CLEAN_IMG will remove the just-generated image at the end of run. By default the
image
# is kept, unless nothing was changed (i.e., the disk image was created, but no
installation
# was actually tried).
# If running the image off /dev/shm, then *by default* the image will be removed
(memory is a
# restricted resource, and we should not over-allocate it)
#CLEAN_IMG = False

# VIRT is the type of hypervisor to use
# VIRT can be either 'kvm', 'virtualbox', or 'parallels'
VIRT = kvm
#VIRT = virtualbox
#VIRT = parallels

# MEM is the amount of memory in MB to give to the VM guest
# Default: 384
MEM = 384
#MEM = 512
#MEM = 1024

# SMP is the number of processors to give to the VM guest if
# running in KVM.
# Default is the number of CPUs in the host
#SMP = 1

# DISK_SIZE is the size of the disk image
# Note that this will be a sparse, qcow2 file, so it should not actually
# take that much space on the filesystem.
# Default: 6G
DISK_SIZE = 6G
#DISK_SIZE = 10G

# KVM_ARGS is a string of arbitrary KVM_ARGS to use when launching the VM
# See kvm(1) for a comprehensive list of arguments
KVM_ARGS = -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370 -
vga cirrus

# Uncomment the following line if you want to hardcode the Ubuntu release
# and arch; otherwise, TestDrive will try to determine it dynamically.
#r = maverick
#m = i386
u = rsync://cdimage.ubuntu.com/cdimage

# Section for TestDrive (Command-line) specific variables.
[testdrive]

# DISK_FILE is the full path to the disk image
# Default: $CACHE/$ISO.img
#DISK_FILE = /path/to/foo.img

# The following line determines the default Ubuntu Flavor used by TestDrive.
# Possible flavors are:
#
ubuntu/kubuntu/xubuntu/edubuntu/mythbuntu/ubuntustudio/lubuntu/cloud-server/cloud-desktop
f = ubuntu

# Section for TestDrive GTK specific variables.
[testdrive-gtk]

# The following line determines the default Ubuntu Flavors used by
TestDrive GTK.
# Possible flavors are:
# ubuntu/kubuntu/xubuntu/edubuntu/mythbuntu/ubuntustudio/lubuntu
f = ubuntu, kubuntu, xubuntu

A GUI version of Test Drive is available in the Ubuntu repositories. It is called testdrive-gtk. The back-end software is the same, but the GUI version eliminates the need for new users to interact using the command line.

References

http://www.ubuntu.com/info/testing—An invitation from the Ubuntu website to get involved in testing.

http://community.ubuntu.com/contribute/quality/—The starting point for understanding and volunteering for QA Testing.

https://wiki.ubuntu.com/BugSquad—The Ubuntu Bug Squad.

https://launchpad.net/testdrive—The official location for downloading TestDrive and assisting with its development.