Hello people

I am thinking about starting the development of a (very small) project that might lead to a (very small) new software in the KDE community
Before I start I want to collect as much informations as possible in order that I avoid losses of times and more generally to do things wrong.

So my question today is about how to organize the beta testing phase:
I mean, if everything goes well the project will pass through following processes:
Omega: Theoritical description with express of the needs and functional description
Pre-alpha: First Mockup of the UI, without core functionalities
Alpha: Core functionalities implemented but lacking some non core functionalities
Beta: All functionalities implemented. Buggy
Release All functionalities Zero Bug

As long as it does not reach the Beta phase, I would make it public.
What I am wondering is how should the Beta phase be organized:
To design the programm I will define some functions and use cases
The validation from Beta to Release mean that none of them suffer from bug anymore. But how to be sure of this: If I let the sources on sourceforge or anything and I get bug reports for functionality X, it does not mean that functionality Y does not suffer from bug
Furthermore I can't have any idea about the number of people that test it. Hence it is quite hazardous to say that the programm is ready or not if I don't even know how extensively it has tested
Plus the problem that ideally, the beta user has to be guided. Indeed if i attached a paper with all possible uses cases, no one is likely to follow it. At the end, only the most common will have been extensively tested while other one might not have been even once.
But how to guide him? Should the beta be a sort of variant of the programm were extra windows guide the user (for example with a checklist of uses cases that shoul be tested).

Lots of questions...


How do people usually handle this process?

In most cases, people start development in a source code repository (either git or svn) which is publicly accessible then once the software has reached an adequate maturity - they make an Alpha release. This is usually done using a blog post.

They will then continue developing the software, fixing issues and getting feedback from people (usually other developers - as they have the right environment for compiling software) and making further Alpha releases.

Eventually, it will have enough features and be stable enough for Beta releases to be made. (it might get packaged for distributions at this point). More of the same testing, bug fixing, etc now takes place - then the final release is made. The cycle then repeats at some point.

Features are usually "frozen" (ie. no further new features) at some point - usually just before the first Beta - with just bugfixes and feature completion happening from then on.

Excellent, thanks a lot for your reply.
For the beginning, since it would be very small i think I would do alone by my self on my own computer. (i have never use a git or svn on a server)

The great things that i am wondering now, is how to judge the programm is mature enough and stable enough to pass from nothing to alpha ( and then from alpha to beta), I mean there is not any way to be sure that all the part of your programm have been deeply thorougfully tested is there? That is really the point that I feel concern with and that I have no idea about how to handle it

In general, Alpha programs should perform some of the tasks which they are designed to do (ie. may not be feature complete) and shouldn't crash under a basic usage scenario.

Beta programs should be mostly feature complete (as far as the initial feature set is concerned anyway, it need not be fully featured) and shouldn't crash under most usage scenarios.

If you want to use Git, then you can use that just locally, with no server being required as it is decentralised.

One way to ensure your app functions (other than using it yourself) is by writing unit tests which check to see if the application behaves in the expected manner.

You should start with git directly, so you have a local versioning history already which will make a transition to a git server much easier. Alternatively you can get yourself a git hosting on Gitorious or Github where you can already get familiar with Git quite easily, that doesn't publish anything to the public, unless you share your git location.