Um teste em dispositivo móvel só é útil se o ambiente em que ele é aplicado for adequado. 

Sua equipe criou um teste para dispositivos móveis de um fluxo de finalização de compra. O teste é aprovado no celular usado para criá-lo. Antes do próximo lançamento, alguém pergunta se o mesmo fluxo funciona nos dispositivos e sistemas operacionais que seus clientes usam. É nesse momento que a conversa muda do teste em si para o ambiente ao seu redor. 

O oposto também pode acontecer. Uma equipe pode ter muitos dispositivos, mas nenhuma maneira repetível de transformar suas jornadas de usuário mais importantes em testes. Nenhuma das situações exige uma resposta universal. Isso exige que a criação de testes e o acesso a dispositivos sejam tratados como decisões interligadas no planejamento de testes em dispositivos móveis. 

Sua equipe consegue criar testes que ela mesma queira manter? 

Um teste em dispositivos móveis deve capturar uma jornada do usuário que valha a pena verificar novamente: fazer login, realizar um pedido, pagar uma conta ou recuperar-se de uma sessão interrompida. Criar a primeira versão é útil. Mantê-la útil à medida que as telas, os rótulos e o comportamento do aplicativo mudam é o trabalho mais demorado. 

Considere quem será o autor dos testes. As pessoas que entendem a jornada do usuário poderão contribuir? Outro membro da equipe consegue ler o fluxo de trabalho e ver o que ele verifica? Quando um teste falha após uma atualização do aplicativo, a equipe consegue determinar se o aplicativo foi alterado ou se o teste precisa de atenção? Essas questões definem o valor de uma abordagem de autoria mais do que a velocidade de uma primeira demonstração. 

Uma organização pode já possuir uma plataforma de automação utilizada em outras áreas da empresa. Estender essa abordagem familiar para dispositivos móveis pode fazer sentido, desde que ela seja compatível com os aplicativos e dispositivos que a equipe precisa validar. Outra organização pode estar definindo sua abordagem de desenvolvimento para dispositivos móveis do zero. Ambas devem avaliar como os testes serão mantidos após a conclusão do projeto inicial. 

Esses testes podem ser executados onde precisam? 

A próxima decisão é o ambiente. Quais modelos de dispositivos e versões de sistemas operacionais são importantes para seus usuários? Quais fluxos precisam de hardware físico em vez de um dispositivo virtual? Quem precisa de acesso e quando os dispositivos estarão disponíveis para uma execução de lançamento? 

A solução pode ser um laboratório interno existente, dispositivos hospedados por um provedor ou uma combinação de ambos. Cada um desses métodos envolve trabalho operacional. Os dispositivos precisam ser provisionados, atualizados, configurados para a aplicação e disponibilizados para as equipes responsáveis. Um conjunto de dispositivos pode atender a essa necessidade, mas seu valor depende de sua compatibilidade com a cobertura de testes e o cronograma de lançamentos da organização. 

Não há motivo para presumir que uma equipe precise substituir um laboratório que funciona bem. A questão relevante é se o ambiente atual suporta a abrangência, o acesso e o controle esperados à medida que os testes em dispositivos móveis crescem. Em particular, um teste que aguarda um dispositivo ou é executado em uma configuração diferente da pretendida reduz a confiança da equipe nos resultados. 

A conexão importa tanto quanto qualquer uma das opções. 

Uma ferramenta de autoria e um ambiente de dispositivo só se tornam um fluxo de trabalho de teste quando podem trabalhar juntos. Um teste deve ser capaz de alcançar o dispositivo pretendido, ser executado na versão correta do aplicativo e fornecer à equipe informações suficientes para entender o que aconteceu. Essa conexão merece atenção desde o início, antes que um conjunto crescente de ferramentas torne as alterações dispendiosas. 

Por isso, a escolha não deve ser formulada apenas como "Qual ferramenta escreverá nossos testes?". Pergunte-se como é o caminho do autor do teste até o dispositivo para a equipe que o operará. Descubra o que precisa ser configurado, quem é o responsável e como a equipe investigará uma falha. 

Planeje todo o percurso, do teste ao resultado. 

Comece com um pequeno conjunto de jornadas móveis importantes. Decida como a equipe criará e manterá esses testes e, em seguida, mapeie cada um para os dispositivos e condições que ele deve abranger. Verifique se a abordagem de criação de testes é compatível com o ambiente escolhido e se a equipe consegue repetir a execução quando uma versão do produto depender dela. 

Esse é o teste prático de uma estratégia de testes em dispositivos móveis: Sua equipe consegue criar os testes necessários, executá-los nos dispositivos necessários e compreender os resultados suficientemente bem para agir?  

Parte 2 da nossa série de posts sobre UiPath. analisa uma maneira de conectar essas peças com o UiPath e Digital.ai Testing.