Compartilhar via

Parte 6 – Teste e aprovações da app store

  • Artigo

Teste

Muitos aplicativos (até mesmo aplicativos Android, em algumas lojas) terão que passar por um processo de aprovação antes de serem publicados; portanto, o teste é essencial para garantir que seu aplicativo chegue ao mercado (muito menos seja bem-sucedido com seus clientes). Os testes podem ter várias formas, desde testes de unidade no nível do desenvolvedor até o gerenciamento de testes beta em uma ampla variedade de hardware.

Testar em todas as plataformas

Há pequenas diferenças entre o que o .NET dá suporte em dispositivos windows phone, tablet e desktop, bem como limitações no iOS que impedem que o código dinâmico seja gerado em tempo real. Planeje testar o código em várias plataformas ao desenvolvê-lo ou agende tempo para refatorar e atualizar a parte do modelo do aplicativo no final do projeto.

É sempre uma boa prática usar o simulador/emulador para testar várias versões do sistema operacional e também diferentes funcionalidades/configurações do dispositivo.

Você também deve testar o máximo de dispositivos de hardware físico diferentes possível.

Dispositivos na nuvem

O ecossistema de telefones celulares e tablets está crescendo o tempo todo, tornando impossível testar o número cada vez maior de dispositivos disponíveis. Para resolver esse problema, vários serviços oferecem a capacidade de controlar remotamente muitos dispositivos diferentes para que os aplicativos possam ser instalados e testados sem a necessidade de investir diretamente em muitos hardwares.

O Teste do App Center oferece uma maneira fácil de testar aplicativos iOS e Android em centenas de dispositivos diferentes. Para obter mais informações, consulte Preparando aplicativos Xamarin.Android e Preparando aplicativos Xamarin.iOS.

Gerenciamento de testes

Ao testar aplicativos em sua organização ou gerenciar um programa beta com usuários externos, há dois desafios:

  • Distribuição – gerenciando o processo de provisionamento (especialmente para dispositivos iOS) e obtendo versões atualizadas do software para os testadores.
  • Comentários – coletando informações sobre o uso do aplicativo e informações detalhadas sobre quaisquer erros que possam ocorrer.

Há uma série de serviços que ajudam a resolver esses problemas, fornecendo infraestrutura integrada ao seu aplicativo para coletar e relatar sobre uso e erros, além de simplificar o processo de provisionamento para ajudar a inscrever e gerenciar testadores e seus dispositivos.

O Visual Studio App Center oferece uma solução para esses problemas, fornecendo distribuição de versão de teste, relatórios de falhas e informações sofisticadas de uso do aplicativo.

Automação de teste

O Xamarin UITest pode ser usado para criar scripts de teste de interface do usuário automatizados que podem ser executados localmente ou carregados no Teste do App Center.

Teste de Unidade

Touch.Unit

O Xamarin.iOS inclui uma estrutura de teste de unidade chamada Touch.Unit que segue os testes de escrita de estilo JUnit/NUnit.

Consulte nossa documentação do Teste de Unidade com o Xamarin.iOS para obter detalhes sobre como escrever testes e executar o Touch.Unit.

Andr.Unit

Há um equivalente de software livre de Touch.Unit para Android chamado Andr.Unit. Você pode baixá-lo do github e ler sobre a ferramenta no blog do @spouliot.

Aprovações de App Store

A Apple e a Microsoft operam a única loja em suas plataformas: o App Store e o Marketplace, respectivamente. Ambos bloqueiam seus dispositivos e implementam um rigoroso processo de revisão de aplicativo para controlar a qualidade dos aplicativos disponíveis para download. A natureza aberta do Android significa que há várias opções de loja que vão desde o Google's Play, que está amplamente disponível e não tem nenhum processo de revisão, até a Appstore da Amazon para Android e esforços específicos de hardware, como o Samsung Apps, que têm distribuição mais limitada e implementam um processo de aprovação.

Esperar que um aplicativo seja revisado pode ser muito estressante - pressões de negócios geralmente significam que os aplicativos são enviados para aprovação com muito pouca margem de erro antes de uma data de lançamento "direcionada". O processo em si pode levar até duas semanas e não é necessariamente transparente: há comentários limitados sobre o progresso do seu aplicativo até que ele seja finalmente rejeitado ou aprovado. A rejeição pode significar a falta de uma janela de oportunidade de marketing, especialmente se ela acontecer mais de uma vez, e as semanas passarem entre a data de lançamento original e quando o aplicativo for finalmente aprovado.

Esteja preparado

O primeiro conselho: planeje o lançamento do seu aplicativo com bastante antecedência e faça concessões para uma possível rejeição e reenviamento. Cada repositório exige que você crie uma conta antes de enviar seu aplicativo . Faça isso o mais cedo possível. Embora a inscrição do Google Play leve apenas alguns minutos se seus aplicativos forem gratuitos, o processo ficará muito mais envolvido se você estiver vendendo-os e precisar fornecer informações bancárias e fiscais. Os processos da Apple e da Microsoft estão muito mais envolvidos do que os do Google, pode levar uma semana ou mais para que sua conta seja aprovada, portanto, considere desta vez seus planos de lançamento.

Depois que sua conta for aprovada, você estará pronto para enviar um aplicativo. O processo real para enviar aplicativos é abordado na seguinte documentação:

O restante desta seção discute as coisas que você deve levar em consideração para garantir que seu aplicativo seja aprovado sem nenhum soluço.

Qualidade

Parece óbvio, mas os aplicativos geralmente serão rejeitados porque não atendem a um certo nível de qualidade: afinal, essa é a razão pela qual as lojas coletadas têm um processo de aprovação em primeiro lugar!

Falhas são um motivo comum para rejeição. Se for muito fácil fazer seu aplicativo falhar, é garantido que ele seja rejeitado. A maioria dos desenvolvedores não envia seus aplicativos com a expectativa de que eles falharão, mas geralmente o fazem. Teste seu aplicativo completamente antes de enviá-lo, concentrando-se não apenas em garantir que tudo funcione, mas também que você lide com cenários comuns de erro móvel, como problemas de rede e restrições de recursos, como memória ou espaço de armazenamento. Use o simulador e os dispositivos físicos para testar , independentemente de quão bem o código é executado em um simulador, apenas um dispositivo pode demonstrar o desempenho real de um aplicativo. Use o máximo de dispositivos diferentes que puder encontrar e insira uma equipe de testadores beta se puder – serviços de terceiros podem ajudar a gerenciar a distribuição beta e os comentários.

Todos os sistemas operacionais móveis eliminarão um aplicativo que não é iniciado rapidamente o suficiente. O período de tempo permitido varia, mas, em geral, os aplicativos devem ter como objetivo ser responsivos em alguns segundos e usar tarefas em segundo plano para fazer qualquer trabalho que levaria mais tempo. Os aplicativos que levam muito tempo para serem carregados ou que não são responsivos o suficiente no uso regular serão rejeitados. Sempre forneça comentários do usuário quando algo estiver acontecendo em segundo plano, ou o aplicativo parecerá ter falhado e, mais uma vez, ser rejeitado.

Verificar seus casos de borda

Uma armadilha comum para os desenvolvedores é não resolver casos de borda, especialmente aqueles que exigem a reconfiguração do simulador ou do dispositivo para testar corretamente. Pode ser fácil esquecer que nem todos os clientes vão "permitir" que seu aplicativo acesse sua localização porque depois que o desenvolvedor aceitar a solicitação uma vez, ele nunca mais será solicitado. As permissões e o uso da rede são especificamente focados durante o processo de aprovação, o que significa que uma pequena supervisão nessas áreas pode resultar em rejeição.

A lista a seguir é um bom ponto de partida para verificar casos de borda que podem ter sido perdidos:

  • Os clientes podem 'negar' o acesso aos serviços – especialmente no iOS, o acesso a dados como informações de localização geográfica só será fornecido se o usuário conceder permissão ao seu aplicativo. Os testadores de aplicativo devem frequentemente reinstalar o aplicativo em seu estado inicial e não permitir quaisquer solicitações de permissão para garantir que o aplicativo se comporte adequadamente. Ative e desative a permissão para verificar o comportamento correto à medida que os clientes mudam de ideia.
  • Os clientes estão em todos os lugares – não suponha que um aplicativo só será usado na cidade ou no país onde ele foi desenvolvido! O código que funciona com coordenadas GPS, valores de data e hora e moedas pode ser afetado pelas configurações de local e localidade do cliente. Todas as plataformas oferecem um simulador que permite especificar locais e localidades diferentes – use-o para testar locais em outros hemisférios e com culturas que formatam datas e moedas de forma diferente. Os valores de latitude e longitude podem ser positivos ou negativos, o separador decimal pode ser um ponto ou uma vírgula, e as datas podem ser formatadas de várias maneiras – lidar com isso!
  • Conexões de rede lentas – os desenvolvedores de aplicativos geralmente trabalham em um "mundo ideal" de conectividade de rede rápida e sempre funcional, o que obviamente não é o caso no mundo real. Testar com conectividade de rede lenta (como uma conexão 3G ruim), bem como sem acesso à rede, é essencial para garantir que você não envie um aplicativo de bugs. O processo de aprovação sempre incluirá um teste com o dispositivo no modo avião, portanto, verifique se você testou isso para si mesmo.
  • O hardware varia – lembre-se de testar o hardware mais antigo e lento que você planeja dar suporte. Há dois aspectos que podem afetar seu aplicativo: desempenho, que pode ser inutilizável em um dispositivo mais antigo e suporte para recursos de hardware, como câmera, microfone, GPS, giroscópio ou outro componente opcional. Os aplicativos devem degradar normalmente (e não falhar) quando um componente não estiver disponível.

As diretrizes são mais do que apenas um "guia"

A Apple é famosa por ser rigorosa quanto à adesão às suas Diretrizes de Interface Humana, pois um dos principais pontos fortes de sua plataforma é a consistência (e o aumento percebido da usabilidade). A Microsoft adotou uma abordagem semelhante com os aplicativos do Windows que implementam o Sistema Fluent Design. O processo de aprovação para ambas as plataformas envolverá seu aplicativo sendo avaliado por sua adesão à filosofia de design relevante.

Isso não quer dizer que a inovação da interface do usuário não seja compatível ou incentivada, mas há certas coisas que você "simplesmente não deve fazer" ou seu aplicativo será rejeitado.

No iOS, isso inclui o uso incorreto de ícones internos ou o uso de outras metáforas bem estabelecidas de maneira não consistente; por exemplo, usando o ícone 'compor' para qualquer outra coisa que não seja a criação de novo conteúdo.

Os desenvolvedores do Windows devem ter cuidado semelhante; um erro comum é não dar suporte adequado ao botão Voltar de hardware de acordo com as diretrizes da Microsoft.

Incentive seus designers a ler e seguir as diretrizes de design para cada plataforma.

Implementando recursos de Platform-Specific

As coisas são um pouco mais rigorosas quando se trata de implementar serviços específicos da plataforma, especialmente no iOS. Para evitar a rejeição automática pela Apple, há algumas regras a seguir com os seguintes recursos do iOS:

  • Compras no aplicativo – os aplicativos NÃO devem implementar mecanismos de pagamento externos para produtos digitais, incluindo moeda no jogo, recursos de aplicativo, assinaturas de revistas e muito mais. Os aplicativos iOS devem usar o serviço baseado no iTunes da Apple para esse tipo de funcionalidade. Há uma brecha - aplicativos como o Kindle Reader e alguns aplicativos baseados em assinatura permitem que você compre conteúdo em outro lugar que seja anexado a uma "conta" que você pode acessar por meio do aplicativo, no entanto, neste caso, o aplicativo não deve conter links ou referências ao processo de compra fora do aplicativo (ou, mais uma vez, ele será rejeitado).
  • Backup do iCloud – com o advento do iCloud, os revisores da Apple são muito mais rigorosos em relação a como os aplicativos usam o armazenamento (para garantir que a experiência de backup remoto do cliente seja agradável). Os aplicativos que desperdiçam espaço de armazenamento capaz de backup podem ser rejeitados, portanto, use a pasta Cache adequadamente e siga outras diretrizes relacionadas ao armazenamento da Apple.
  • Newsstand – Os aplicativos de jornais e revistas são uma ótima opção para o Newsstand da Apple, no entanto, os aplicativos devem implementar pelo menos uma assinatura de renovação automática e dar suporte ao download em segundo plano para serem aprovados.
  • Mapas – é cada vez mais comum adicionar sobreposições e outros recursos a mapas móveis, no entanto, tenha cuidado para não obscurecer as informações de "créditos" do mapa (como o logotipo do Google no iOS5), pois isso resultará em rejeição.

Gerenciar seus metadados

Além dos problemas técnicos óbvios que podem resultar na rejeição de um aplicativo, há alguns aspectos mais sutis do seu envio que podem resultar em rejeição, especialmente em torno dos metadados (descrição, palavras-chave e imagens de marketing) que você envia com seu aplicativo para exibição no App Store ou marketplace.

  • Imagens – siga as diretrizes da plataforma para ícones de aplicativo e armazene imagens. Não use imagens registradas, vimos aplicativos serem rejeitados porque seus ícones apresentavam um desenho de um iPhone!
  • Marcas comerciais – evite usar marcas comerciais diferentes das suas. Os aplicativos foram negados por mencionar marcas comerciais na descrição do aplicativo ou até mesmo nas palavras-chave no App Store da Apple.
  • Descrição – não use a palavra 'beta' ou de forma alguma indique que o aplicativo não está pronto para o horário nobre. Não menção outras plataformas móveis (mesmo que seu aplicativo seja multiplataforma). O mais importante é garantir que o aplicativo faça exatamente o que você diz que faz. Se você listar vários recursos em sua descrição, é melhor que seja óbvio como usar cada um desses recursos ou obterá uma rejeição "o recurso mencionado na descrição do aplicativo não foi implementado".

Coloque tanto esforço nos metadados do aplicativo quanto no desenvolvimento e teste. Os aplicativos são rejeitados por violações secundárias nos metadados, portanto, vale a pena ter tempo para acertar.

Lojas de aplicativos: não para todos

O foco principal das lojas em cada plataforma é a distribuição do consumidor - a capacidade de alcançar o maior número possível de clientes. No entanto, nem todos os aplicativos são direcionados aos consumidores, há uma base em rápido crescimento de aplicativos internos e semelhantes à extranet que exigem distribuição limitada a funcionários, fornecedores ou clientes. Esses aplicativos não estão "à venda" e não precisam de aprovação, pois o desenvolvedor controla a distribuição para um grupo fechado de usuários. O suporte para esse tipo de implantação varia de acordo com a plataforma.

O Android oferece a maior flexibilidade nesse sentido: os aplicativos podem ser instalados diretamente de uma URL ou anexo de email (desde que a configuração do dispositivo permita isso). Isso significa que é trivial criar e distribuir aplicativos corporativos internos ou publicar aplicativos para clientes ou fornecedores específicos.

A Apple fornece uma opção de implantação interna para desenvolvedores registrados no Programa Empresarial para Desenvolvedores do iOS, que ignora o processo de aprovação de App Store e permite que as empresas distribuam aplicativos internos para seus funcionários. Infelizmente, essa licença não atende à necessidade de distribuição de aplicativos semelhantes à extranet para outros grupos fechados de clientes ou fornecedores. Implantação enterprise (e Ad-Hoc)

Resumo do App Store

O processo de revisão pode ser assustador, mas como o resto do ciclo de vida de desenvolvimento, você pode ajudar a garantir o sucesso com algum planejamento e atenção aos detalhes. Tudo se resume a algumas etapas simples: leia e entenda as diretrizes de interface do usuário que você deve seguir, siga as regras se estiver implementando recursos específicos da plataforma, teste minuciosamente (depois teste um pouco mais) e, por fim, verifique se os metadados do aplicativo estão corretos antes de enviar.

Uma última palavra de conselho para os desenvolvedores que publicam no Google Play: a falta de processo de aprovação pode parecer que facilita seu trabalho - mas seus clientes serão ainda mais exigentes do que uma equipe de revisão. Siga estas diretrizes como se seu aplicativo pudesse ser rejeitado, caso contrário, seus clientes farão a rejeição.