Recursos de teste de hipótese para aplicativos móveis

Quanto tempo leva um teste de hipótese para um aplicativo móvel? Vamos contar:

1. Desenvolvimento de um aplicativo que funciona em diferentes modos para diferentes grupos de usuários.
2. Testando o resultado.
3. Colocando o aplicativo nas lojas de aplicativos e aguardando aprovação.
4. Aguardando que os usuários atualizem o aplicativo. Em 2019, a maioria tem a atualização automática ativada, mas nem todo mundo a possui.
5. Coleta e análise de estatísticas.
6. Trazendo a aplicação ao estado da hipótese vencedora, em paralelo com o desenvolvimento das seguintes ...

Se seus desenvolvedores trabalham no Scrum com iterações de duas semanas, isso geralmente significa que testar uma hipótese leva um mês inteiro. Com outras metodologias, esse período pode ser reduzido, mas não significativamente.

Esse estado de coisas torna impossível atingir o ritmo de “5 hipóteses por semana”, pelas quais muitas equipes de produtos buscam.

Abaixo, mostrarei como você pode acelerar e melhorar esse processo e indicar várias soluções prontas que você pode usar.

Vamos lá

Ligar e desligar

Antes de mergulhar nos detalhes, é necessário inserir um termo adicional - o padrão de sinalizador de recurso (alternância de recurso) .

Para leitores sem formação técnica, podem ser necessários esclarecimentos:

Ao desenvolver um novo recurso, o programador introduz uma "opção" no código do aplicativo que ativa esse recurso. Normalmente, essa solução é usada para manter os recursos inacabados desativados no código geral do programa, mas, é claro, também pode ser usada para testar hipóteses.

Para usar o padrão de sinalizador de recurso ao testar o experimento, será necessário:

1. Funcionalidade totalmente desenvolvida para experimentar.
2. O interruptor para ele está no estado padrão de "Desligado".
3. Controle de switch remoto do servidor.

A questão é: qual é o tempo economizado se a funcionalidade ainda precisar ser desenvolvida antes da realização de testes A / B? Vamos tentar analisar as etapas do experimento:

O que vemos aqui?

Em primeiro lugar, usando o sinalizador de recursos, podemos carregar o aplicativo nos armazenamentos de aplicativos antes de testar completamente os erros. Só precisamos garantir que, quando a nova funcionalidade for desativada, o aplicativo se comporte como antes - e isso possa ser feito com autotestes escritos anteriormente. O restante pode ser testado enquanto o aplicativo é distribuído entre os usuários.

Em segundo lugar, após a conclusão da experiência, você pode usar o sinalizador de Recurso para ativar / desativar a funcionalidade de todos os usuários até a próxima versão estar pronta, onde o sinalizador não será mais usado.

É por esse princípio que o serviço Apptimize funciona , fornecendo um sistema pronto para testes A / B.

Analisar

Para realizar um experimento, você precisa fazer várias coisas:

1. Selecione um segmento de usuário se a experiência não for para todos.
2. Escolha o tamanho da audiência.
3. Colete dados, e não apenas aqueles que são verificados por experiência. O restante das métricas de negócios será necessário para garantir que o experimento não interrompa nada em outras métricas.
4. Colete e analise o resultado.

Se você não usar a solução pronta da Apptimize, a abordagem mais simples seria uma combinação do Google Analytics for Firebase para análise e Firebase Remote Config para definir configurações individuais (segmentos e testes). Essas ferramentas foram projetadas para trabalharem juntas.

Assim, você precisa:

1. Use o Google Analytics para Firebase para rastrear métricas de negócios.
2. Use o Firebase Remote Config para gerenciar os sinalizadores de recursos.
3. Use o Firebase Remote Config para especificar segmentos e parâmetros de experiência.
4. Analise os dados do Google Analytics usando as chaves do Firebase Remote Config na análise. Esse recurso é fornecido por essas ferramentas "prontas para uso".

Vamos otimizar ainda mais

Analisamos como reduzir o ciclo de testes de hipóteses para aplicativos móveis, reduzindo o tempo gasto em testes e disseminando os resultados do experimento. Mas essa abordagem não permite se livrar do tempo para aprovação e distribuição do aplicativo. O objetivo de “5 hipóteses por semana” com essa abordagem ainda não é muito realista.

Para acelerar as experiências, você precisa desenvolver e enviar novas funcionalidades sem precisar atualizar o aplicativo. Isso pode ser alcançado, você deve usar uma interface de usuário dinâmica. No entanto, essa abordagem tem problemas:

Por um lado, existem limitações técnicas na construção da interface de acordo com as configurações recebidas do exterior. A maioria das estruturas de desenvolvimento móvel usa uma abordagem declarativa onde é impossível ou muito difícil.

Por outro lado, a política de armazenamento de aplicativos proíbe o download e a execução de código arbitrário, pois pode ser usado para funcionalidades que violam as regras dos armazenamentos de aplicativos.

Outra limitação é a quantidade de dados transferidos do Firebase Remote Config. Não pode ser usado para transferir toda a interface. É ideal armazenar nele apenas a “chave” de uma versão específica da interface e, ao alterar esse código, carregue a interface em um serviço de terceiros. Por si só, não limita a escolha da estrutura de desenvolvimento móvel, mas requer esforços adicionais de implementação.

A solução ideal é uma abordagem na qual apenas a interface do usuário é construída dinamicamente e a lógica de negócios permanece fixa. Como a grande maioria das experiências com produtos se refere especificamente à interface, você pode manter um ritmo alto de trabalho. Ao mesmo tempo, experimentos que exigem refinamento da lógica de negócios podem ser realizados em paralelo, de acordo com o processo descrito acima com sinalizadores.

Tecnicamente, essa abordagem é mais facilmente implementada em uma estrutura que possui as seguintes características:

1. Uma interface do usuário reativa e de alto desempenho que não usa uma abordagem declarativa por padrão.
2. Suporte para o Google Analytics para Firebase e Firebase Remote Config.
3. Uma solução de plataforma cruzada é desejável para acelerar o desenvolvimento em geral.

Idealmente, a estrutura Flutter atende a esses critérios. Como prova de conceito dessa abordagem, para ele existe uma biblioteca que permite criar uma interface dinâmica .

Usando a interface dinâmica criada no Flutter, no Google Analytics para Firebase e no Firebase Remote Config, você pode desenvolver aplicativos que possam ser comparados a sites com facilidade de teste de hipóteses.