Por que você precisa mudar para a esquerda com testes móveis

Sinto que sempre houve uma relação de amor e ódio com o conceito de teste. Sem dúvida, os benefícios de testar tudo o que você está construindo ajudam a evitar que os clientes relatem essas mesmas descobertas. Essa é a parte amorosa do relacionamento.

A parte desagradável é quando os cronogramas do projeto fazem com que os testes se tornem uma prioridade mais baixa... muitas vezes a ponto de se tornarem um item da lista de desejos do backlog que raramente aparece em um sprint atual. Isso quase garante que os clientes entrarão em contato com você com resultados inesperados.

À medida que os ciclos de vida de desenvolvimento de software (SDLCs) amadureceram, os testes tornaram-se mais fáceis, permitindo aos desenvolvedores criar testes unitários que cobrem totalmente o aspecto que está sendo validado. O uso do ChatGPT ou GitHub Co-Pilot amadureceu a ponto de tais testes unitários poderem ser gerados automaticamente. As soluções de ferramentas de integração contínua (CI) foram aprimoradas para impor altos níveis de cobertura de código antes que qualquer solicitação pull (PR) possa ser mesclada. Isso permite que as equipes mudem para a esquerda em seu desenvolvimento – forçando a resolução dos problemas durante a fase de desenvolvimento e reduzindo o custo dos recursos ao longo do caminho.

Essa abordagem funcionou muito bem para APIs e estruturas web tradicionais, mas testar aplicativos móveis geralmente exige que as equipes realizem testes manuais, executando a partir de uma lista publicada de etapas em tantos tipos de dispositivos diferentes quanto possível.

Eu queria ver se conseguia identificar uma maneira pela qual o desenvolvimento e os testes móveis poderiam empregar o conceito de mudança para a esquerda.

O que está faltando nos testes móveis

Em alto nível, o espaço de aplicativos móveis deve ter a capacidade de testar recursos e funcionalidades da mesma forma que APIs e estruturas web estão testando hoje. Isso significa sair da tarefa de realizar testes manualmente usando um inventário de dispositivos físicos ou emuladores.

Este estado ideal de testes móveis seria orientado pela UI para evitar a escrita de testes enigmáticos focados na atividade do usuário. Esta abordagem poderia expandir as ferramentas para consumidores internos ou proprietários de produtos que desejam validar sua visão como realidade.

Assim como os testes unitários ou de integração tradicionais, a capacidade de introduzir módulos pode validar pequenos aspectos da aplicação móvel e ser usada como blocos de construção para fluxos maiores. Ao fazer isso, as equipes conseguirão permanecer “secas” (não se repita) e evitar trabalho duplicado.

Por fim, esses testes precisarão ser capazes de se tornar parte do pipeline de CI/CD, apesar de serem conduzidos por uma UI gráfica.

Nesse estado ideal, os engenheiros de software móvel podem efetivamente mudar para a esquerda no desenvolvimento e teste de dispositivos móveis.

Afinal, o que é “Shift Left”?

É uma boa ideia esclarecer o que quero dizer quando digo “deslocar para a esquerda” para testes móveis.

A Wikipedia define deslocamento para a esquerda para teste conforme observado abaixo:

“O teste shift-left é uma abordagem para testes de software e testes de sistema em que os testes são realizados no início do ciclo de vida (ou seja, movidos para a esquerda no cronograma do projeto). É a primeira metade da máxima “teste cedo e frequentemente”. Foi cunhado por Larry Smith em 2001. ”

Simplesmente abraçar o deslocamento para a esquerda permite que defeitos sejam identificados durante a fase de desenvolvimento. Isso é importante porque o problema pode ser resolvido enquanto o recurso está fresco na mente do(s) engenheiro(s) focado(s) na fonte.

Aqui estão alguns dos benefícios de adotar o deslocamento para a esquerda:

• Redução de custos para entregar recursos, encontrando e corrigindo problemas no momento do desenvolvimento.
• Maior eficiência devido à redução do tempo necessário para revisitar as soluções muito depois da entrega.
• Maior qualidade por ser forçado a cobrir e validar totalmente durante a fase de desenvolvimento.

Em última análise, o conceito de mudança para a esquerda conduzirá a uma vantagem competitiva quando as soluções chegarem aos consumidores que sejam validadas e funcionem conforme o esperado.

Sobre Tosca

No ano passado, explorei o uso do Tricentis Testim em meu artigo “ Melhorando a qualidade do aplicativo voltado para o cliente usando o Tricentis Testim ”. Fiquei impressionado com a facilidade de validar minha solução Magic 8 Ball usando uma API RESTful baseada em GO e um cliente baseado na web Vue.js. Eu queria ver se a Tricentis tinha uma solução que permitisse que as equipes mudassem para a esquerda para testes móveis.

Acontece que eles têm um produto chamado Tosca .

O produto Tosca proporciona geração de testes sem código, permitindo a criação de pequenos módulos que podem ser reaproveitados e automatizados. Esses módulos podem ser considerados blocos de Lego que podem ser conectados quando necessário devido ao emprego de um contrato padronizado entre eles. A Tosca dá um passo mais perto dos ciclos de vida de desenvolvimento mais tradicionais, fornecendo a capacidade de aproveitar a IA para ajudar a gerar testes móveis para seus recursos.

A Tosca também aproveita o poder do projeto Appium de código aberto sem uma curva de aprendizado pesada por meio do Tricentis Mobile Agent. Isso permite que todo o poder fornecido em meu artigo anterior seja incluído na jornada de mudança para a esquerda com o desenvolvimento móvel.

Como resultado, a Tosca permite testar aplicativos móveis nativos, híbridos e da web em dispositivos iPhone, Android, celulares e tablets reais, sem manter e possuir esses dispositivos.

Assim como o produto Testim, a solução Tosca oferece a capacidade de executar testes como parte de pipelines de CI/CD, permitindo a aplicação da adoção do deslocamento à esquerda.

Você pode usar o Tosca para testar diretamente em um telefone iOS ou Android, bem como por meio de emuladores ou simuladores disponíveis em um IDE como o Android Studio. Usando o Tosca, você pode digitalizar seu aplicativo e criar casos de teste:

Depois que Tosca tiver criado os casos de teste, você também poderá criar seus próprios casos de teste.

Uma das vantagens do Tosca é que ele permite escrever testes sem precisar escrever código. Isso é possível através de sua biblioteca de módulos que podem simular quase todas as ações, incluindo abrir um navegador ou preencher um formulário.

Neste exemplo, usamos três módulos para nosso caso de teste móvel Tosca. Nós testamos:

1. Abrindo um navegador e acessando o endpoint do nosso aplicativo
2. Selecionando um tipo específico de veículo
3. Preenchendo um formulário sobre aquele veículo específico

Observe que tudo o que precisamos fazer é fornecer entradas de amostra (na captura de tela, estamos fazendo isso para a etapa 3 destacada acima). Assim que o teste for concluído, você receberá um relatório de diagnóstico do Tosca.

Desloque para a esquerda para testes móveis

Ao aproveitar um produto como o Tosca, os engenheiros de software focados no desenvolvimento móvel podem colocar suas equipes em uma vantagem competitiva, empregando o que sobrou para testes móveis:

• Os recursos móveis são validados durante a fase de desenvolvimento, semelhante a serviços e estruturas web.
• Os testes são conduzidos por uma UI que pode ser expandida para consumidores internos e proprietários de produtos para ajudar a solidificar sua visão.
• O conjunto de testes pode ser construído a partir de uma coleção de módulos “secos” estruturados para cobrir totalmente novos recursos e funcionalidades.
• Os testes podem ser executados em um inventário exaustivo de dispositivos móveis sem possuir e manter tais dispositivos.
• Antes de introduzir novos recursos na ramificação de código primária, o PR associado teria chamado os testes gerados pela UI da mesma forma que os testes de unidade ou integração são executados em API ou pipelines de CI/CD de estrutura da web.

Conclusão

Meus leitores devem se lembrar que me concentrei na seguinte declaração de missão, que acredito poder ser aplicada a qualquer profissional de TI:

“Concentre seu tempo em fornecer recursos/funcionalidades que ampliem o valor de sua propriedade intelectual. Aproveite estruturas, produtos e serviços para todo o resto.” - J. Vester

Para atingir o pico de produtividade, os engenheiros de software focados no desenvolvimento móvel precisam adotar a mudança para a esquerda nos testes móveis . No entanto, a escolha ideal deve considerar qualquer curva de aprendizagem associada e capacidade de suporte na busca de soluções.

O produto Tosca segue minha declaração de missão pessoal, permitindo que as equipes alcancem o estado de mudança para a esquerda sem código-fonte adicional para suporte e manutenção. O produto também permite que não-engenheiros participem do desenvolvimento dos testes, dando às equipes uma vantagem para garantir que os projetos correspondam às expectativas.

Eu pessoalmente empreguei a abordagem de mudança para a esquerda por vários anos e aprecio a experiência sempre que um defeito é evitado simplesmente seguindo o processo. É hora de o desenvolvimento móvel empregar o conceito de mudança para a esquerda.

Tenha um ótimo dia!