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

Releases: Linux From Scratch 8.0, LEDE 17.01, 4MRescueKit 21.0

  • Linux From Scratch 8.0 and Beyond LFS 8.0 Land with GCC 6.2, GNU Binutils 2.27
    Bruce Dubbs from the LFS (Linux From Scratch) and BLFS (Beyond Linux From Scratch) projects that allow experienced users to build their own Linux-based operating systems from scratch announced the release of Linux From Scratch 8.0 and Beyond LFS 8.0. Both Linux From Scratch 8.0 and Beyond Linux From Scratch 8.0 major versions are available with and without the systemd init system, and they offer support for some of the latest GNU/Linux and Open Source components, including GCC (GNU Compiler Collection) 6.2.0, GNU Binutils 2.27, and Glibc (GNU C Library) 2.24.
  • OpenWRT-Forked LEDE Releases 17.01, Presents At The Embedded Linux Conf
    This week marks the 17.01.0 final release of the Linux Embedded Development Environment (LEDE). They also presented at this week's Linux Foundation Embedded Linux Conference about their project that's a fork of OpenWRT and aims for router/embedded use-cases. LEDE 17.01.0 final was released on Wednesday and modernizes many parts of its OpenWRT stack, switches to the Linux 4.4 kernel (from Linux 3.18), updates many pieces of key software, adds additional security features, improves networking support, and has a wide variety of other improvements.
  • 4MRescueKit 21.0 Has Antivirus Live CD 21.0-0.99.2, 4MRecover and 4MParted 21.0

Linux Kernel News

  • Linux Kernels 4.9.13 and 4.4.52 LTS Bring Updated USB Drivers, Networking Fixes
  • Linux Kernel 4.10 Gets Its First Point Release, It's Now Ready for Deployment
    Well, that didn't take long, and it looks like the recently released Linux 4.10 kernel series just got its first point release today, Linux kernel 4.10.1, marking the branch as stable and ready for deployment in stable OSes. Linux kernel 4.10.1 comes only one week after the release of Linux 4.10, which is now considered the most stable and advanced kernel available for any GNU/Linux distribution that wants to adopt it for their users, so you can imagine that the changes are quite small in number. According to the appended shortlog, a total of 21 files were changed in this first point release, with 259 insertions and 52 deletions.
  • GNU Linux-libre 4.10-gnu is now available
  • GNU Linux-Libre 4.10: GPU Drivers Remain The Most Frequent Offenders
    The GNU Linux-libre 4.10 kernel was released last weekend just after the official Linux 4.10 kernel release while I hadn't noticed the de-blobbed kernel release until today. The Linux-libre folks continue to criticize the open-source GPU DRM drivers as being offenders for using binary blob firmware/microcode. GNU Linux-libre for those that don't know is the FSFLA effort to de-blob the mainline Linux kernel by removing support for loading binary-only modules as well as stripping out drivers or portions of driver code that rely upon closed-source/binary-only firmware/microcode images, which is quite common among newer hardware.
  • AMD's Ryzen Will Really Like A Newer Linux Kernel

Today in Techrights

FreeBSD-Based TrueOS Operating System Gets New Jail Tools, Automounting Feature

The developers of the FreeBSD-based TrueOS operating system (formerly PC-BSD) announced the release and general availability of a new stable build versioned 2017-02-22. Read more