How to bring in a web app

Question

I run a game and the running is done by hand, I have a few scripts that help me but essentially it's me doing the work. I am at the moment working on web app that will allow the users to input directly some of their game actions and thus save me a lot of work.

The problem is that I'm one man working on a moderately sized (upwards of 20 tables) project, the workload isn't the issue, it's that bugs will have slipped in even though I test as I write. So my question is thus two-fold.

1. Beta testing, I love open beta's but would a closed beta be somehow more effective and give better results?
2. How should I bring in the app? Should I one turn drop it in and declare it's being used or should I use it alongside the normal construct of the game?

Thanks for your time and help.

Answer 1

I don't understand what you mean by "bring in the app" and "one turn drop it". By "bring in the app" do you mean deploy? As for "One turn drop", I totally don't understand it.

As for open betas, that depends on your audience, really. Counterstrike, for example, apparently run a few closed betas before doing open betas, so here's my suggestion:

1. Set up a forum in some free forumboard, or set up a topic in a popular gaming forum.
2. Look for people (whether or not they are in those forums) that you trust, and let them in in a closed beta. This will allow you to iron out serious kinks at first.
3. If your closed group isn't reporting as much bugs any more, release it to open beta, pointing out ways on how they could give feedback to you.

This is similar to the approach StackOverflow took, but this being a game setting it up on a gaming forum will give the dual benefit of advertising your game and getting some interested beta testers.

Answer 2

I'll try to answer with the limited amount of details you've given.

1: Wether it's open or closed is really only an issue if you have great buzz, and a large group of users hammering down your door, trying toget in on the action. If this is the case, I think you might get more loyalty and commitment from users in a closed beta.

2: You haven't given many (any) details as to what kind of game you are talking about, so it's pretty hard to answer this one.

/Jonas

Answer 3

This is my general approach to testing/launching. How you test/launch depends mostly on:

1. What your application is.
2. Who your users are.

If you application is a technical application and is geared to the technically-minded, the word "beta" won't really scare them - but provide an opportunity to test the product before it goes 'live', and help to improve the system. This is the ideal circumstance in which to use either an open or closed beta. It's usually beneficial to start off 'closed' with a group of people you select and trust to bug-find quickly and reliably - after you're more confident that all the critical bugs are gone, open it up with an invite system (for example).

If, however, your application is 'trivial' from a technical standpoint (i.e. it's something like Twitter, or Facebook, or Flickr - nothing that is inherently geared towards technical usage), then you're going to have to be more careful in how you plan your testing. Closed testing is most definitely your first port of call, and this should last for longer than a closed beta on a more 'technical' product. The reason? Your 'average Joe' doesn't necessarily know what the word "beta" means, and others may well be scared by it, or judge your service prematurely (not understanding the concept of this 'public testing' phase). Many won't want to be used as guinea pigs.