Language Selection

English French German Italian Portuguese Spanish

Beta Testing 101

Filed under
Howtos

Ever have one of those days when you can't stand end users? I know I have.

There are several expectations end users have for people creating software, or even Linux distros. They want it to work on their hardware, they want it to be stable, and they want it right now. But, at the same time, new releases shouldn't come too often, or it messes up the feng shui of their systems.

But you can't get them to beta test. I say this from experience in multiple projects, both those I lead and those I've observed. Oh, you can get them to agree to beta test, but I'm not sure that they understand how. So, here's a few tips from someone who's been on all sides of the equation.

1. Get a jumpdrive and backup all your logs. They've come way down in price over the past few years, and it's not prohibitively expensive to buy. And buy you should... get a separate drive just for backing up logs while beta testing. The least experience Linux user in the world can be the best beta tester a project has just by making copies of their logfiles available.

2. In that vein, back up system information as well. Hardware-specific bugs are much easier to track down and kill when the bug-hunter can look for patterns. Make it a habit to save the output from lspci and lsusb into their own log files on that jumpdrive. Set up a folder for each session, cd to that folder, and simply lspci > lspci.log and lsusb > lsusb.log.

3. Further in the logging journey, learn to use dmesg and grep. To find out information in the system log about your agp setup, dmesg | grep agp. This will prove invaluable, and keep you from having to manually parse potentially hundreds of lines of text to find two lines of interest. Once again, you can concatenate the output to a logfile: dmesg | grep agp > agpinfo.log.

4. Finally, learn to use stdout and stderr. These are the output and errors that come from running a program. To help diagnose dependency errors and the like, the output from a malfunctioning program can be redirected to a log file like so: make > makelog 2>&1. This can turn a single run into a goldmine of information for the harried developer with people breathing down his neck about the next release.

5. Try things you normally wouldn't. Play the games. Write a letter to your Great Aunt Ruth. Listen to that Hanson cd you won't admit you still own. Burn copies of it and leave it unmarked in your friends' cars so they get curious and pop it in. Cross-compile the kernel for a 386. Test your dial-up modem. Scan for wireless networks. Any number of these things will be attempted by the end users of this project, and your input may keep a bad situation from ruining a release.

6. Go to Wal-Mart and buy one of those cheap marble composition books. Take notes in it while you use the computer. Having a hard copy in case of major system meltdown can be worth more than gold, and it will give you something to look back on later. Notes files get deleted, but you can keep notebooks for 20 years if you take care of them.

Well, that's it for this lesson. I hope that it's useful for potential beta testers, software developers, and even the end users (maybe now you can understand why some things aren't being released yet.)

And that's life when you're in spinlock.

More in Tux Machines

CORD becomes a Linux Foundation project

Central Office Re-architected as a Data Center (CORD), an open source integrated solutions platform for service providers leveraging merchant silicon, white boxes, and open source platforms such as Open Network Operating System (ONOS), OpenStack, Docker, and the cloud operating system XOS, is now part of the Linux Foundation as a new independent project. The Linux foundation is already home to many open source networking projects, including OpenDaylight and ONOS, so CORD is a natural fit for the non-profit foundation. Read more

Google beefs Linux up kernel defenses in Android

Future versions of Android will be more resilient to exploits thanks to developers' efforts to integrate the latest Linux kernel defenses into the operating system. Android's security model relies heavily on the Linux kernel that sits at its core. As such, Android developers have always been interested in adding new security features that are intended to prevent potentially malicious code from reaching the kernel, which is the most privileged area of the operating system. Read more

Fork YOU! Sure, take the code. Then what?

There's an old adage in the open source world – if you don't like it, fork it. This advice, often given in a flippant manner, makes it seem like forking a piece of software is not a big deal. Indeed, forking a small project you find on GitHub is not a big deal. There's even a handy button to make it easy to fork it. Unlike many things in programming though, that interaction model, that simplicity of forking, does not scale. There is no button next to Debian that says Fork it! Thinking that all you need to do to make a project yours is to fork it is a fundamental misunderstanding of what large free/open source projects are – at their hearts, they are communities. One does not simply walk into Debian and fork it. One can, on the other hand, walk out of a project, bring all the other core developers along, and essentially leave the original an empty husk. This is what happened when LibreOffice forked away from the once-mighty OpenOffice; it's what happened when MariaDB split from MySQL; and it's what happened more recently when the core developers behind ownCloud left the company and forked the code to start their own project, Nextcloud. They also, thankfully, dropped the silly lowercase first letter thing. Nextcloud consists of the core developers who built ownCloud, but who were not, and, judging by the very public way this happened, had not been, in control of the direction of the product for some time. Read more

Proprietary and Microsoft Software