I was recently asked whether I wanted to be part of the Quick Test Pro 8.0 Beta Program. Unfortunately I had to decline, but it got me thinking about beta testing in general.
As a Test Consultant, it is rare to be involved in testing of software that is going to be shrink-wrapped and sold. Most engagements seem to involve the testing of an application that is to be used “in-house”, whether that is a custom implementation of an existing application (as is seen with ERP/CRM apps), or an application that has been written from scratch. It’s probably possible to be involved in QA for an entire career and never be on the vendor side of a beta test.
In-house applications are not generally beta tested as they have clearly defined functionality (and therefore clearly testable functionality, not open-ended like a computer game) and they usually run on a standardised platform, so testing a million different permutations of end-user hardware and software is not an issue. Usability issues are covered by Usability Testing and User Acceptance Testing, and defects that are missed by the test team are hopefully picked up early by real users if the software can be rolled out in staged releases. Besides, managers seem to get a little agitated when their staff time is wasted, especially when there is a dedicated (and budgeted for) test team.
But, after saying all of that, if I was going to be managing a beta test, I would probably pay attention to Joel Spolsky‘s article, Top Twelve Tips for Running a Beta Test.
