Estas são convenções, não regras: as equipes usam as palavras de formas diferentes. A tabela dá uma leitura comum. As trilhas da loja (interna, fechada, aberta) são um conceito separado; veja teste fechado vs rollout escalonado vs soft launch.
As etapas
| Alpha | Beta | Release candidate | |
|---|---|---|---|
| Objetivo | O núcleo funciona de jeito nenhum? | Funciona para pessoas além de você? | Este build está pronto para ir ao ar como está? |
| Completude | Funções podem faltar ou estar toscas | Completo em funções, ou quase | Completo em funções; só correções que bloqueiam |
| Quem testa | Você, sua equipe, algumas pessoas de confiança | Testadores externos parecidos com seus usuários | Os mesmos testadores, mais uma checagem final sua |
| Feedback que você quer | Crashes, fluxos quebrados | Usabilidade, problemas de aparelho, partes confusas | Só problemas que param tudo |
| Mudanças permitidas | Qualquer coisa | Correções e polimento; funções raramente | Apenas correções que bloqueiam |
| Condição de saída | Fluxos principais funcionam | Sem grandes problemas conhecidos | Sem problemas bloqueantes; você publicaria assim |
Uso prático
- Não pule o meio. Ir do seu próprio teste direto para o lançamento faz os usuários reais acharem os problemas.
- Congele o escopo no RC. Se você adicionar funções, volta a ser beta.
- Escreva as condições de saída antes de cada etapa. Sem elas, as etapas nunca terminam.
- Combine testadores com a etapa. Alpha: pessoas que toleram arestas. Beta: pessoas parecidas com seus usuários. RC: quem notar uma regressão.
Onde o AppReviewX se encaixa
Principalmente na etapa beta, para apps já publicados em uma loja: outros desenvolvedores dão feedback privado e estruturado (1 feedback aceito = 1 crédito; contas novas começam com 0). Builds e instaladores não são distribuídos.
Relacionados: todas as opções de teste, teste beta vs soft launch, teste fechado vs rollout escalonado vs soft launch.