← todos os posts
Tutorial 6 min de leitura

"Testou o botão e publicou: os 4 testes que ninguém faz e que derrubam o app na primeira semana"

"Conta nova, celular no 4G, dois usuários ao mesmo tempo, 45,90 com vírgula: as quatro condições em que o cliente chega e o seu teste nunca passa."

"Simplesmente existem tantos por menores que ninguém conta."

Escreveu um brasileiro que não é programador, num fórum, depois de duas semanas tentando montar um sistema com IA. Relato de uma pessoa, não estatística. E os "por menores" de teste têm um detalhe cruel: nenhum aparece quando quem testa é você.

Você testa com a sua conta, cheia de dado, no Wi-Fi de casa, sozinho, digitando do jeito que o computador gosta. O cliente chega sem dado nenhum, no 4G, junto com outro cliente, e digita "45,90". São quatro condições, e o seu teste não passa por nenhuma delas. Não é descuido: elas não existem na mesa onde você constrói.

As seis entradas maldosas cobrem o que a pessoa digita. Este checklist cobre em que condição ela chega.

1. Conta nova, do zero

Como: crie uma conta com um e-mail que nunca entrou no app e passe por todas as telas antes de cadastrar qualquer coisa.

Deveria: cada tela vazia dizer o próximo passo. "Você ainda não tem pedidos. Crie o primeiro."

Costuma: tela branca, erro, ou um "NaN" no painel (sigla em inglês pra "não é um número", o que aparece quando o app tenta tirar a média de zero pedidos). A sua conta nunca mostra isso, porque tem dado desde o primeiro dia.

Pedido: "Para cada tela, mostre o que aparece quando o usuário não tem nenhum registro. Nenhum número pode aparecer como NaN ou vazio; troque por uma mensagem com o próximo passo."

O e-mail de confirmação que não chega pra quem não é do projeto é outro defeito da conta nova, e está aqui.

2. Celular no 4G

A TIC Domicílios 2025, pesquisa do Cetic.br (o centro de estudos do comitê que cuida da internet no Brasil), mediu que 65% dos usuários de internet no país acessam só pelo celular, sem computador. Na classe C são 67%; nas classes D e E, 87%. Cuidado com o que o número não diz: ele mede o aparelho, não a rede, e muita gente está no Wi-Fi de casa. Mas diz o principal: o seu cliente não está no seu notebook.

Como: no Chrome do computador, aperte F12 (abre as ferramentas de desenvolvedor), vá na aba Network (rede) e, no menu de velocidade, escolha Slow 4G (4G lento). Faça o fluxo principal do app. Melhor ainda: celular de verdade, sem Wi-Fi.

Deveria: todo botão que espera resposta ficar travado e dizer "enviando…".

Costuma: a tela fica parada uns segundos sem sinal nenhum, o cliente aperta de novo, e o pedido sai duplo.

Pedido: "Todo botão que envia dado deve ficar desabilitado e mostrar 'enviando…' até a resposta chegar. Se falhar ou passar de 15 segundos, diga que não foi salvo e deixe tentar de novo sem perder o que foi digitado."

3. Dois usuários ao mesmo tempo

Não é o teste das duas contas, que confere quem vê o quê. Aqui as duas pessoas disputam a mesma coisa.

Como: uma janela normal e uma anônima (ou dois celulares), duas contas. Os dois abrem a mesma coisa escassa: o último horário, a última unidade do estoque. Conte "três, dois, um" e confirmem juntos.

Deveria: um consegue; o outro recebe "esse horário acabou de ser ocupado".

Costuma: os dois conseguem. O app perguntou "está livre?" pros dois antes de qualquer um gravar, e você descobre quando as duas clientes chegam no mesmo horário.

A tela não resolve isso; quem resolve é o banco de dados. O PostgreSQL, o banco por trás do Supabase, tem a restrição de unicidade, que segundo a documentação "garante que o dado de uma coluna, ou de um grupo de colunas, é único entre todas as linhas da tabela". Com ela, o segundo agendamento no mesmo horário é recusado, não importa quantas telas tentem juntas.

Pedido: "Garanta no banco de dados, com uma restrição de unicidade, que não existam dois agendamentos do mesmo profissional no mesmo horário. Quando o banco recusar, mostre 'esse horário acabou de ser ocupado' em vez de erro. Depois me diga como confiro com duas contas."

4. Dado com acento e vírgula

Como: no campo de valor, digite 45,90. Depois 1.234,56. Abra o registro de novo e leia o que ficou. Na busca, procure joao por um cliente cadastrado como "João".

Deveria: gravar 45,90 e 1.234,56 exatos, e a busca achar o João.

Costuma: gravar 45. Não é azar. A função que muito código JavaScript usa pra transformar texto em número, a parseFloat, segundo a referência oficial da Mozilla, ao achar um caractere inválido "devolve o número representado até ali, ignorando esse caractere e todos os seguintes". Pra ela, a vírgula é inválida. 45,90 vira 45, e 1.234,56 vira 1,23. Nenhum erro aparece: o app salva um número, só que outro.

Pedido: "Todo campo de valor deve aceitar o padrão brasileiro, vírgula nos centavos e ponto no milhar, e gravar o valor exato. A busca por nome deve ignorar acento e maiúscula. Me mostre o registro salvo de 45,90 e de 1.234,56."

Se o acento sai torto no próprio banco, é outra história, e ela está aqui.

A folha

OS 4 TESTES DA PRIMEIRA SEMANA
[ ] Conta nova: toda tela vazia diz o próximo passo
[ ] 4G lento: o botão trava e diz "enviando…"
[ ] Duas contas, mesmo horário, "3, 2, 1": só uma consegue
[ ] 45,90 e 1.234,56 gravam exatos; "joao" acha o João

Rode as quatro hoje, com o app como está, e de novo sempre que a IA mexer na tela daquele teste.

Era uma parede de várias

Essas quatro dizem em que condição o cliente chega. Não dizem quem pode ver o quê, nem o que conferir depois de cada mudança, nem qual conferência merece virar automática. São listas diferentes, cada uma com a sua hora, e o mapa de qual entra quando é o começo. Fechar as quatro hoje derruba uma parede. Saber a ordem das outras é o que impede a próxima.

Fontes