Um candidato a lançamento aprovado no emulador ainda pode falhar no aparelho que o cliente carrega no bolso. A diferença aparece em condições que a simulação não reproduz por completo, como memória disputada, permissões antigas, sensores, rede instável e o estado acumulado de uma instalação real.
Às 18h12 de uma sexta-feira, Marina segurava um Android com a tela congelada no fluxo de cadastro. Fundadora de um aplicativo de organização financeira e personagem composta para esta história, ela estava no escritório quase vazio, com uma mochila aberta sobre a cadeira e o jantar esfriando ao lado do notebook. No emulador, a mesma versão tinha concluído todos os testes.
O lançamento estava marcado para a manhã seguinte. Se aquela falha chegasse à loja, os primeiros clientes poderiam baixar o aplicativo e ficar presos antes de criar a conta. Adiar significava perder a janela combinada com parceiros e explicar por que uma versão considerada pronta nunca tinha passado pelo aparelho de uso diário de ninguém.
O emulador confirmou uma condição controlada
A equipe de Marina tinha feito o que parecia razoável. Instalou a versão candidata em dois emuladores, repetiu o cadastro, alternou entre telas e simulou diferentes tamanhos de exibição. Tudo ficou verde.
O problema estava no significado dado ao verde. Aqueles testes confirmavam que o aplicativo funcionava nas configurações escolhidas, com instalação limpa, armazenamento disponível e um ambiente previsível. Eles não provavam que a versão sobreviveria ao histórico bagunçado de um telefone real.
O aparelho de Marina já tinha recebido versões anteriores do aplicativo. Guardava dados locais antigos, permissões concedidas em outro momento e dezenas de processos disputando memória. Uma atualização do sistema também havia mudado o comportamento de uma permissão usada durante o cadastro.
No emulador recém-criado, nada disso existia. O teste começava em uma mesa vazia. O cliente começaria em uma mesa coberta de papéis.
Essa distinção precisa aparecer no relatório de qualidade. “Passou no emulador” é um fato. “Está pronto para lançamento” é uma conclusão mais ampla, que exige evidência em hardware físico e em estados próximos dos encontrados fora da equipe.
O telefone revelou o caminho que ninguém havia testado
Marina tentou repetir a falha. Na primeira vez, o aplicativo travou depois que ela negou uma permissão e voltou à tela anterior. Na segunda, concluiu o cadastro. Na terceira, travou ao alternar para o aplicativo de mensagens e retornar pelo seletor de tarefas.
Faltava pouco para a equipe encerrar o expediente, e ainda não havia uma sequência confiável. Sem reprodução, qualquer correção seria um palpite. A decisão real daquela noite era desconfortável: adiar o lançamento ou publicar sabendo que o primeiro passo do produto podia quebrar.
A virada veio quando Marina parou de tratar o telefone como uma versão menor do emulador. Ela registrou o estado inicial do aparelho, repetiu as ações em ordem e observou o que acontecia quando o sistema removia o aplicativo da memória durante a troca de telas.
O fluxo tentava recuperar uma informação que só existia enquanto o processo permanecia ativo. Em uma instalação limpa e sem pressão de memória, a condição quase nunca aparecia. No telefone, com outros aplicativos abertos, ela surgiu diante da equipe.
O reparo foi pequeno. A evidência necessária para confiar nele não era. A equipe precisou testar atualização sobre uma versão anterior, instalação limpa, permissão aceita, permissão recusada, interrupção por outro aplicativo e retorno ao cadastro.
Testar em hardware físico é uma etapa de decisão
Um aparelho na gaveta, usado no fim da sexta-feira, continua sendo uma cobertura frágil. O teste físico precisa entrar antes do congelamento da versão, com responsáveis, cenários definidos e critérios claros para bloquear a publicação.
Comece pelos riscos do produto. Um aplicativo que depende da câmera precisa enfrentar iluminação ruim, rotação da tela, interrupções e permissões revogadas. Um produto que usa localização precisa lidar com sinal indisponível e retorno depois de ficar em segundo plano. Um fluxo de pagamento precisa sobreviver a troca de aplicativo, rede oscilante e retomada da sessão.
Depois, escolha aparelhos que representem diferenças relevantes, como versão do sistema, faixa de memória, tamanho de tela e fabricante. A meta não é montar uma coleção infinita. É cobrir os pontos em que o comportamento pode mudar.
O acesso a hardware também deixou de depender apenas de um armário cheio de telefones. O Google Cloud lançou uma prévia pública de uma plataforma gerenciada com dispositivos físicos e emuladores sob demanda, acessíveis por streaming e APIs de testes paralelos. A novidade pode ampliar a cobertura, mas não substitui a escolha criteriosa dos cenários. Cem execuções do mesmo caminho limpo continuam deixando o caminho quebrado sem teste.
O lançamento começa antes da sexta-feira
Naquela noite, Marina retirou a versão da fila de publicação. A equipe corrigiu a recuperação de estado e refez os cenários no emulador e no aparelho físico. O lançamento perdeu a janela prevista, mas evitou transformar os primeiros clientes em equipe involuntária de testes.
Na semana seguinte, havia uma mudança concreta no processo: nenhuma versão candidata poderia ser marcada como pronta sem evidência de instalação limpa, atualização, interrupção, retomada e permissões em pelo menos um aparelho físico representativo. O telefone de Marina deixou de ser o último recurso sobre a mesa. Passou a aparecer enquanto ainda havia tempo para encontrar o problema sem apostar o lançamento.
Comentários
Ainda não há comentários.