Usando RPA para teste de software:um “tech hack”?

A automação ineficaz de testes de software é notória por atrasar lançamentos enquanto consome quantidades incríveis de recursos.
De vez em quando, meu feed de notícias apresenta um artigo que oferece “Os 10 principais hacks da vida”. Estas são dicas e truques sobre como usar produtos domésticos comuns de maneiras inesperadas de melhorar sua vida – “… e a dica número 7 vai explodir sua mente!!!”

É certo que fui enganado para abrir esta isca de cliques. Para ser honesto, há momentos em que sou agradavelmente surpreendido. Por exemplo, quem diria que você poderia cortar embalagens plásticas irritantes com um abridor de latas ou usar um rolo de papel higiênico para impedir que o papel de embrulho se desenrolasse?



Eu tentei os dois “hacks” acima e adivinhem? Eles “meio” funcionaram… por um tempo. O abridor de latas cortou a costura onde o plástico foi fundido, mas não conseguiu cortar o comprimento da embalagem. O rolo de papel higiênico segurou o papel de embrulho por um tempo, mas finalmente o papelão enfraqueceu e o papel de embrulho se desfez. Não surpreendentemente, o uso de tesoura para as embalagens de plástico e pequenos pedaços de fita adesiva para o papel de embrulho funcionou muito, muito melhor.

Em uma linha muito semelhante, muitas organizações estão considerando usar RPA para automatizar testes de software:um “hack técnico” para testes de software, das sortes. No entanto, assim como o rolo de papel higiênico não apresentou uma solução sustentável para evitar que meu papel de embrulho se desenrolasse, o RPA não é uma solução sustentável para automação de teste de software… e as modificações necessárias para tornar a ferramenta RPA sustentável para a tarefa de teste de software automação seria, bem, um hack.

Se você já possui uma ferramenta de RPA em sua organização e deseja começar com a automação de testes, sua ferramenta de RPA pode parecer uma escolha lógica. Geralmente, é relativamente fácil automatizar alguns cenários de teste fundamentais (por exemplo, criar um novo usuário e concluir uma transação), adicionar validação e acreditar que você está no caminho da automação de testes.

No entanto, é importante reconhecer que a automação de teste bem-sucedida e sustentável requer muito mais do que a capacidade de clicar nos caminhos do aplicativo. Para superar a desanimadora taxa média de automação de teste da indústria de <20%, as equipes também devem ser capazes de construir e estabilizar um conjunto de testes automatizados eficaz. As ferramentas de RPA geralmente não são projetadas para permitir isso. Como resultado, você encontrará obstáculos de automação de teste, como atrasos na espera pelos dados de teste e ambientes de teste necessários, resultados inconsistentes que corroem a confiança na iniciativa de automação e suítes de teste "inchadas" que consomem recursos consideráveis, mas não fornecem resultados claros, feedback acionável.

Para uma rápida visão geral da diferença de escopo entre ferramentas de RPA e ferramentas de automação de teste, compare as seguintes definições do Gartner:

As ferramentas de RPA “realizam instruções ‘if, then, else’ em dados estruturados, normalmente usando uma combinação de interações de interface do usuário (UI) ou conectando-se a APIs para direcionar servidores cliente, mainframes ou código HTML. Uma ferramenta RPA opera mapeando um processo na linguagem da ferramenta RPA para o “robô” do software seguir, com tempo de execução alocado para executar o script por um painel de controle.”

As ferramentas de automação de teste “permitem que uma organização projete, desenvolva, mantenha, gerencie, execute e analise testes funcionais automatizados… Eles fornecem amplitude e profundidade de produtos e recursos em todo o ciclo de vida de desenvolvimento de software (SDLC). Isso inclui projeto e desenvolvimento de teste; manutenção e reutilização de casos de teste; e gerenciamento de testes, gerenciamento de dados de teste, testes automatizados e integração, com forte foco no suporte para testes contínuos.”

A necessidade desses recursos de teste adicionais fica clara quando você considera algumas das principais diferenças entre:

• Automatizar sequências de tarefas em ambientes de produção para executar com êxito um caminho claramente definido por meio de um processo para que você possa concluir o trabalho mais rapidamente e
• Automatizar processos de negócios realistas em ambientes de teste para ver onde um aplicativo falha para que você possa tomar decisões informadas sobre se um aplicativo é muito arriscado para liberar

O que essas diferenças significam para o teste de software?

• A automação deve ser executada em um ambiente de teste que normalmente é incompleto, em evolução e restrito
• Gerenciar dados de teste com estado, seguros e compatíveis torna-se um grande desafio
• O design eficaz do caso de teste é essencial para o sucesso
• As falhas precisam fornecer informações sobre o risco do negócio

Para colocar em termos mais concretos, vamos considerar o exemplo de testar um serviço de viagens online. Suponha que você queira verificar a funcionalidade que permite a um usuário estender sua reserva de hotel pré-pago. Primeiro, você precisa decidir quantos testes são necessários para exercitar completamente a lógica do aplicativo e quais combinações de dados cada um precisaria usar.

Em seguida, você precisaria adquirir e provisionar todos os dados necessários para definir o aplicativo para o estado em que o cenário de teste pode ser executado. Nesse caso, você precisa (pelo menos) de uma conta de usuário existente com uma reserva pré-paga existente para alguma data no futuro - e não pode usar dados de produção reais devido a regulamentos de privacidade como o GDPR.

Em seguida, você precisa de uma maneira de invocar o intervalo necessário de respostas do sistema de reservas do hotel conectado (um quarto está disponível/não disponível), o cartão de crédito (transação aprovada/negada) etc., mas sem realmente reservar um quarto ou cobrar um Cartão de crédito.

Você precisaria automatizar o processo, é claro. Isso envolve fazer login, recuperar a reserva existente, indicar que você deseja modificá-la e especificar o comprimento da extensão.

Depois de automatizar todo o processo, você precisará configurar várias validações em diferentes pontos de verificação. Os detalhes apropriados foram enviados ao hotel no formato de mensagem apropriado? A reserva foi atualizada em seu banco de dados de usuários? Os dados de pagamento foram enviados corretamente ao provedor do cartão de crédito? Algum crédito de conta foi aplicado? O usuário recebeu uma mensagem apropriada se a reserva não pudesse ser estendida? E se o cartão de crédito foi negado? E se o cartão de crédito foi negado, seu sistema reverteu para a duração original da reserva em vez de adicionar noites adicionais que não foram realmente pagas?

Agora imagine que sua empresa decidiu adicionar uma taxa de alteração de US$ 10 para todas as reservas pré-pagas. Você poderia inserir facilmente esse novo requisito em seus testes automatizados existentes ou teria que retrabalhar substancialmente cada teste para acomodar essa pequena alteração?

Mesmo este exemplo simples expõe algumas das muitas complexidades de teste de software que as ferramentas de RPA simplesmente não foram projetadas para resolver. As ferramentas de RPA são criadas para automatizar tarefas específicas em uma sequência. As ferramentas de automação de teste de software são projetadas para medir a resiliência de uma sequência mais ampla de tarefas. Para ser franco:as ferramentas de RPA são arquitetadas para fazer um processo funcionar. Mas para teste de software, você precisa de ferramentas que o ajudem a determinar como um processo pode quebrar.

A automação ineficaz de testes de software é notória por atrasar lançamentos enquanto consome quantidades incríveis de recursos. À medida que os CIOs investem cada vez mais em iniciativas de transformação digital que melhoram a experiência do cliente por meio de entrega de software mais rápida, economizar nos testes de software é contraproducente. Escolher a ferramenta certa para o trabalho vai compensar significativamente em termos de entrega acelerada, risco de negócios reduzido e mais recursos para dedicar à inovação.

Wayne Ariola, é o autor de Testes Contínuos para líderes de TI e um palestrante bem conhecido no espaço DevOps e App Dev.