Neste guia
Um beta test responde a uma pergunta: o que quebra em máquinas que não são suas? No Windows isso importa mais do que na maioria das plataformas, porque hardware, drivers, configurações de tela e programas de segurança variam muito.
1. Decida o que você quer descobrir
Escolha duas ou três perguntas antes de convidar alguém. Exemplos: o app instala e atualiza direito? O fluxo principal termina? Ele funciona em um notebook com um segundo monitor? Testadores que conhecem o objetivo dão feedback melhor.
2. Escolha os testadores
Busque variedade, não quantidade: versões diferentes do Windows que você suporta, notebook e desktop, um ou dois monitores de alta resolução, uma conta de usuário padrão, uma máquina com programas de segurança rigorosos. Comece pequeno, com um punhado de pessoas, e amplie depois da primeira rodada de correções. Para saber onde encontrá-los, veja como encontrar beta testers para apps desktop.
3. Envie a build
Dê aos testadores um único lugar para pegar as builds e um único jeito de saber a versão. Seja honesto sobre as opções: um download direto, um pacote assinado por você, ou um canal de distribuição de uma loja ou de terceiros. Cada uma troca esforço por conveniência. Qualquer que seja a escolha:
- Mostre o número da build de forma visível no app (tela Sobre).
- Assine suas builds se puder, e diga aos testadores qual aviso esperar se não assinar.
- Mantenha uma lista de mudanças por build: o que é novo, o que testar de novo.
4. Peça feedback específico
"Me diga o que você achou" rende pouco. Envie tarefas:
- Instale na sua máquina e anote qualquer coisa estranha.
- Faça o fluxo principal uma vez, do início ao fim.
- Feche o app, abra de novo e confira se seus dados continuam lá.
- Atualize para a próxima build e repita o passo 3.
Forneça um formulário com os mesmos campos sempre: versão do Windows, número da build, o que você fez, o que aconteceu, o que você esperava, uma captura de tela ou um log. O modelo de relatório de bug para apps desktop serve de base; como escrever feedback que o desenvolvedor consegue usar explica os hábitos por trás dele.
5. Defina o ritmo
| Quando | O quê |
|---|---|
| Dia 0 | Convide, envie a build 1 e a lista de tarefas |
| Dia 2-3 | Lembrete curto; responda a todos os relatórios |
| Dia 5-7 | Envie a build corrigida; peça que testem de novo só o que mudou |
| Fim da semana 2 | Agradeça a todos e compartilhe o que você corrigiu |
Este é um ritmo inicial, não uma regra. Encurte para uma correção pequena e estenda para uma mudança grande.
6. Mantenha os testadores reportando
- Responda a todo relatório, mesmo que seja com "não consegui reproduzir, pode me mandar o log?".
- Avise os testadores quando o relato deles levou a uma correção.
- Mantenha as tarefas curtas. Quinze minutos são feitos; duas horas não.
Avaliações nas lojas não fazem parte do acordo
Não peça avaliações nas lojas em troca e não ofereça nada por uma. Avaliações dadas em troca de algo não são honestas; veja por que comprar avaliações de apps dá errado. O feedback vai para você em privado; se alguém quiser avaliar o app depois, é escolha dessa pessoa, livre e não paga.
O que o AppReviewX cobre
O AppReviewX aceita apps por link da loja: Google Play, Apple App Store, Mac App Store e Microsoft Store. Apps para Windows e Mac precisam já estar publicados na loja, e o AppReviewX não distribui builds nem instaladores. O feedback é privado e estruturado, um feedback aceito = um crédito, e avaliações nas lojas são voluntárias, não pagas e nunca exigidas. Esta página traz orientação geral.
Comece grátis e receba feedback privado sobre o seu app.
Relacionados: guia de testes para apps Windows e Mac, como fazer um beta test de um app Mac, como encontrar beta testers para apps desktop.