Note that there are some explanatory texts on larger screens.

plurals
  1. POPrivate beta test communication and infrastructure
    text
    copied!<p>So your commercial app is in the middle stages of development.. enough that it's usable but still needs refinement, extension, bugfixing. It's far from shippable, but it's stable and complete enough that your developers and in-house testers/users feel it's time for more feedback from real users.</p> <p>So you go to a wider but still closed beta-test, likely selected from existing users/customers who want to contribute and give feedback.</p> <p>A <a href="https://stackoverflow.com/questions/358291/whats-the-best-way-to-aid-your-tester">previous SO question</a> showed that the best way to use beta testers is to make sure there's good two-way communication. We want to enable that communication!</p> <p><a href="http://fts.ifac.cnr.it/albums/album21/Last_Balloon_Launch_of_RHUBC_II_Beta_Test_001.sized.jpg" rel="nofollow noreferrer">Beta testers usually aren&#39;t this eager.. http://fts.ifac.cnr.it/albums/album21/Last_Balloon_Launch_of_RHUBC_II_Beta_Test_001.sized.jpg</a></p> <p>So the problem is to find the best ways to organize and allow communication between the developers and the beta-testers-at-large, and between the beta testers themselves?</p> <p>In the past, here we've always just set up a simple email mailing list, adding the secret testers to the list and letting them all post by emailing a centralized address, which is shared among everyone on the list. It's crude and old-school, but we've done it this way for fifteen years and it works all right, especially for our external group of about 10 testers.</p> <p>But there must be other methods, and perhaps it's best to explore them. What beta-test infrastructure have you set up for your own projects? The goals and requirements are vague, but some points which might be useful to consider</p> <ul> <li>Secrecy, you don't want non-invited users to find or eavesdrop</li> <li>Communication, let users talk about questions, documentation, share projects, help each other</li> <li>File sharing, how to distribute the beta software, as well as let users upload their own examples/problem/demo examples</li> <li>Bug reporting, should the communication system be tied to your bug tracker?</li> <li>Scaling, can it handle 5 testers, 20 testers, etc</li> <li>Privacy levels, can it handle a super-hardcore level of maybe only inhouse users who get a new build a day, a private beta of invited outside users, a public beta of anyone who wants to join..</li> <li>Noise filtration, if discussion gets too offtopic or chatty it may diffuse the focus of the beta</li> </ul> <p>There are some obvious options for designing this kind of beta support infrastructure that could even be combined.</p> <ul> <li>A (private) mailing list</li> <li>A <a href="http://www.vbulletin.com/" rel="nofollow noreferrer">vBulletin</a> like forum with private sections</li> <li>A bugtracker like <a href="http://www.fogcreek.com/FogBUGZ/" rel="nofollow noreferrer">FogBugz</a> (giving testers licenses so they can explore and annotate)</li> <li>A wiki for collaborative documentation/discussion</li> </ul> <p>It's also useful to look at SourceForge, which is for Open Source apps where there is no need for secrecy, invitations, or classes, but there is a forum and bugtracker associated with each project. It may also be interesting to even consider upcoming platforms/paradigms like <a href="http://wave.google.com/" rel="nofollow noreferrer">Google Wave.</a></p> <p>My question: what system have you used to organize your beta testers inhouse/external, and which one gives the best payoff in terms of enhancing the development process without being to hard or annoying to manage some overly complex system?</p> <p>I'm posting this as a community wiki because it's clear there will be no one single best answer.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload