Automatização de Testes Funcionais em POS de Fast-Food

Objetivo

Construção de Robôs de Teste Automatizado, para:

Reduzir os ciclos de entrega e aumentar a Qualidade e Confiabilidade;
Aumentar a Cobertura de Testes, sem o crescimento proporcional nos custos operacionais;

Para uma rede de restaurantes Fast-food, que precisava diminuir o numero de chamados e incidentes de Software relacionados ao POS nas mais de 1.000 lojas espelhadas pelo Brasil, entendeu-se que o aumento da qualidade e confiabilidade, envolvia o aumento da cobertura de testes (atuais 3.000 condições para mais de 8.000) sem o respectivo aumento de prazo ou pessoas para testes e homologação.

POS ou PoS é um ponto de venda ou ponto de serviço (do inglês: Point of Sale ou Point of Service).

abordagem

Obter alta confiabilidade por meio de testes na camada de apresentação do usuário final (GUI) tornou-se essencial, uma vez que o software do POS trata-se de um sistema desktop, com a base de dados estruturada em um conjunto de arquivos XML sem estruturas de Serviço e Banco de Dados. Porém, é sabido que quanto mais se concentra o esforço de testes na interface de usuário, mais demorado e caro é o processo de testes e automação, o que nos leva a uma abordagem de testes anterior a GUI, validando os arquivos XML.

Isto posto, nossa abordagem teve foco em abordar os seguintes aspectos:

Funcionalidades e Mecânicas de Venda;
Seleção de Produtos (Imagens, Nomes, Preços);
Conformidade de Códigos de Produtos, Composição de Promoções e Preços na base da dados (XML) e nas telas (GUI);
Validação das informações enviadas aos periféricos, como impressoras de Cupom Fiscal e Monitores de Pedido na Cozinha (KVS);

CRONOGRAMA

Nossos métodos ágEis

Nosso framework de trabalho foi baseado no Scrum, por ser uma estrutura de processo leve, baseado em equipe e que promove o avanço rápido e iterativo da solução. Nossas Sprints tiveram um intervalo de tempo de duas semanas, durante as quais a equipe definiu, construiu, testou e analisou os resultados de cada incremento do Robô. Durante a fase de Planejamento e Aprendizado, realizamos visitas e trabalhos presenciais nos escritórios de nosso cliente, enquanto o restante do projeto foi realizado por meio de trabalho remoto e reuniões virtuais.

Sprints de duas semanas sempre entregando valor;
Coordenar por meio de eventos diários de stand-up;
Trabalho de pares e de propriedade coletiva;
Reuniões remotas via Zoom;
Canais no Slack fechados e organizados de acordo com tarefas ou assuntos específicos, possibilitando trocar arquivos, coletar feedback e colaborar em tempo real;
Hospedagem segura de código-fonte e arquivos com controle de versão;
Planejamento e visualização do trabalho usando o Trello no modo hard;

DESAFIOS

A automação de testes baseada na construção de scripts e definição manual dos milhares de canários possíveis, por si só era um grande obstáculo, porém, no caso do Software do POS desta cadeia de Fast-Food, era ainda mais grave. Percebemos caso seguíssemos o caminho tradicional, que os robôs de teste exigiriam intensa manutenção e intervenção humana a cada alteração do cardápio ou campanha de promoções, que mudam com alta frequência.

Como gerar as mais de 8.000 combinações de teste dinamicamente?
Como garantir a integridade da massa de Testes a Cada mudança de Cardápio?
Como manter a integridade da Automação (Ids, Locators, Imagens, Coordenadas e etc.) se a cada campanha semanal, os botões, produtos e telas em geral, sofrem grandes mudanças?

Soluções

Propomos utilizar uma arquitetura de AUTOMAÇÃO de Testes baseado em Modelos (model-based testing) onde os cenários de teste, a massa de testes e os resultados esperados são gerados automaticamente a partir dos arquivos XML de configuração do Software do POS, lendo Tabelas de Preços, Produtos e Disposição de Telas que alimentam o próprio software sob teste. Com isso, os Robôs de Testes do POS, tornaram-se capazes de se adaptar às frequentes mudanças, com mínima intervenção humana (apenas nos modelos).

Cobertura do Robô

Apesar da continua evolução do Software do POS, restringimos nosso escopo a 169 diferentes mecânicas de venda, que por sua vez resultam em 8.150 diferentes combinações de produtos em cada venda (GC) e cada um destes 8.150 GCs testa 7 aspectos 57.050 vezes.

Exemplo de mecânicas de venda:

Conquistas e Lições aprendidas:

Conseguimos superar a dificuldade técnica de implementação da Automação de Testes em Sistema Desktop.
Reduzimos o período de Testes Regressivos de 66,6 horas (04 minutos/teste), para 23,6 horas (32 segundos/Teste).
Aumentamos a Cobertura de Testes Regressivos em 63%, de 3 mil para 8 mil testes.
Possibilitamos, identificar rapidamente oportunidades de melhoria, inclusive disponibilizando novos testes assim que disponibilizado novos cardápios.
Alta disponibilidade do robô para execuções em múltiplos ambientes.

Equipe

Daniel Machado|Manager - linkedin.com/in/danielmachado1

Erik Amaral|DEV - linkedin.com/in/erik-amaral-francisco

Bruce Macedo|Automation Robotic Tester Architect - linkedin.com/in/brucemacedo/

Laryssa Mariana|Automation Robotic Tester Architect - linkedin.com/in/laryssa-mariana

Erickson Braz |Automation Robotic Tester Architect - linkedin.com/in/erickson-caprioli-dias-braz

Rogerio Pereira |Automation Robotic Tester Architect - linkedin.com/in/rogerio-pereira

Martin Tornquist |Mentor - https://www.linkedin.com/in/martin-tornquist-61b412183/

Google Sites

Report abuse