The OutRider Computing Journal A free monthly column for users, administrators, programmers and hobbyists who use UNIXlike Operating Systems. Home | Search | Site Map | Feedback | Subscriptions

The Value of Friendly BETA Testers

The first time I ever received feedback from a user I was pretty upset. Not that I had made a mistake, heck, that is more often the case, rather the tone of the message was not shall we say, nice. While this was discouraging, it was not long afterwards that I received a nicer one that plainly stated what the problem was and not something to the effect of "This fscking thing does not work."

The Back Story: You Just Never Know

Ever hear of a saying that goes something like this:

"The Road to heck is paved with good intentions?"

well, that is not it exactly, but in my case it could be reworded to the effect of:

"the road to occidental segfaults are paved with Jays good intentions."

Okay so they were not actually segfaulting, but the problem was critical. A system file handle, surprise surprise, was different on a certain release on a certain platform with a certain . . . I think you get the idea.

So I quickly patched up the source (now with a file hunter code snippet) and sent up the revised version of the program. The same person who informed me of the problem volunteered to test it out and the problem was resolved.

Not exactly an exciting story, but here is where it gets better. I ended up becoming good friends with the person. Now they volunteer all the time to test out stuff I am working on.

Running My First Rapid Fire Release Program

With most utilities I write, they are so small and so focused I can usually get the entire design, both internal and external, finished with one release. After that it is patchwork and upgrades. Recently I took on a larger project. This time I decided to use a different approach. Instead of completely building the program then uploading it and sort of waiting, I decided to build a portion of it that worked and upload that with the internal design "still in the air" as it were.

My motivation was simple, the programs eventual scope will be quite large. If I complete the immense task of adding all functionality now, fixing critical errors later would be somewhat of a daunting task.

I also realized I would need a small group of folks to help out with both guts and the front end, so I hit up a couple of different people I knew. Some are good programmers, some systems people, some both.

It was definitely the right thing to do. Already our tiny team has uncovered small, but critical, fundamental problems that I can correct well before the program's first version is out.

One final important note, enter names in the credits as people volunteer. This is a time saver and they appreciate knowing during the process that you will be crediting them.

All You Have To Do is Ask

It doesn't get any harder than that, again, realize the scope of what it is you are doing. If it is technically small in size, you may not need anyone else during the building process, if it is a large program that may have a large number of external dependencies - recruit. The worst anyone will say is sorry, I don't have the time.

I also believe it is worth mentioning that this "volunteer testing" does not exclusively exist in software. While at OutRider, I have had hundreds of readers volunteer to proof read. Many times they did so because some of my initial cuts on articles were grammatically horrendous (as one astute reader rather humorously put it: "You have taken Thesaurus Abuse to a New Level").

Unfortunately I do not have the time to coordinate such efforts at all, but it is nice to know that people would be willing to just read stuff for you.