Como testar sistemas de POS sem hardware real

O que se pode ensaiar sem hardware

Muito mais do que se costuma pensar. Dá para validar a pesquisa de produto, o comportamento de acrescentar ao cesto, alterações de quantidade, regras de desconto, atribuição de cliente, recuperação do foco, tratamento de erros e muitos casos-limite com que o operador de caixa se depara, sem tocar no leitor real.

A chave está em separar a lógica do fluxo da validação de hardware. Se o problema for a reacção do POS à entrada, às mudanças de estado ou aos resultados da pesquisa, o ensaio em software chega, regra geral, para o encontrar. Se o problema for o leitor, a impressora, o terminal ou uma restrição de USB, aí a passagem por hardware torna-se necessária.

Começar pelo fluxo do leitor

Na maior parte dos sistemas de POS, o leitor é a primeira dependência que preocupa as pessoas. Felizmente, é também uma das mais fáceis de simular bem, porque muitos leitores se comportam como teclados.

Por isso, uma ferramenta de emulação de leitor de códigos de barras é um ponto de partida sólido para testes de POS. Permite conduzir o mesmo campo de pesquisa ou a mesma entrada de artigo usados na caixa e verificar como o ecrã reage quando os valores chegam depressa, com ou sem um Enter no fim.

Construir uma matriz de ensaio pequena, mas realista

O caminho mais fácil para uma cobertura superficial é ensaiar um único produto do caminho feliz. É melhor criar uma matriz pequena de tipos de artigo que reflicta o comportamento do POS nos fluxos reais de retalho.

Convém ter, no mínimo:

• um produto normal em stock
• um código de barras desconhecido
• um artigo com zeros à esquerda
• um artigo restrito ou sujeito a verificação de idade
• um produto com promoção ou regra de preço

Isto importa porque as falhas de POS se escondem muitas vezes nas regras de negócio, não na própria leitura. Se o conjunto de ensaio for demasiado simples, o ecrã pode parecer estável enquanto o fluxo real não o é.

Simular o comportamento do operador, não apenas o do sistema

Uma sessão de POS não é um teste unitário arrumado. Os operadores movem-se depressa, clicam no campo errado, voltam a ler artigos, fecham avisos cedo de mais e trabalham sob pressão de tempo. Se os casos sem hardware não modelarem essa realidade, a cobertura vai parecer melhor do que é.

Experimente cenários como estes:

1. ler o mesmo artigo duas vezes, em sequência rápida
2. ler enquanto uma janela modal está aberta
3. retirar um artigo e lê-lo de novo
4. accionar uma autorização de responsável e ler outra vez
5. perder o foco de propósito e confirmar que a interface recupera

São falhas realistas, e precisamente o tipo de caso que um emulador permite repetir sem cansaço.

Usar ambientes em camadas de forma deliberada

Nos testes de POS, três camadas funcionam bem:

• desenvolvimento local com dados semeados e um emulador de código de barras
• pré-produção com lógica real de preços, impostos e stock
• validação de hardware num terminal real antes do lançamento

Assim, o tempo caro de hardware fica reservado ao conjunto pequeno de falhas que exigem mesmo aparelhos. Os programadores limpam a maior parte dos defeitos de fluxo localmente, a QA verifica cenários mais largos em pré-produção e quem trata do hardware concentra-se nos problemas ao nível do dispositivo.

Saber o que continua a exigir hardware real

O ensaio sem hardware é poderoso, mas tem limites. Os aparelhos reais continuam a ser necessários para:

• emparelhamento do leitor e comportamento dos controladores
• saída da impressora de talão e manuseamento do papel
• comunicação com o terminal de pagamento
• restrições de concentrador USB e de quiosque
• restrições de rede e de terminal próprias da loja

Ser honesto quanto a estes limites fortalece o resto do processo. O objectivo não é fingir que o hardware não conta. O objectivo é deixar de gastar tempo de hardware em problemas que podiam ter sido apanhados mais cedo.

Onde as equipas costumam falhar

O erro mais frequente é esperar por uma linha completa de hardware antes de ensaiar seja o que for de relevante. Parece prudência, mas normalmente adia as falhas em vez de as evitar. Se a pesquisa de um produto falhar porque o campo perde o foco depois de um aviso de desconto, o hardware não torna essa falha magicamente mais fácil de perceber.

Outro problema habitual é ensaiar apenas um caminho feliz calmo. As sessões reais de caixa são ruidosas. Os operadores leem depressa, repetem artigos, saem dos avisos e mudam de fluxo. O teste de POS sem hardware tem de reflectir essa realidade, caso contrário perde exactamente os problemas que o pessoal da loja nota primeiro.

Um exemplo prático

Imagine um ecrã de caixa em que ler um produto deve acrescentar o artigo, actualizar o cesto e devolver de imediato o foco ao campo de pesquisa. A maior parte disto valida-se sem hardware:

• simule a entrada do leitor no campo de pesquisa
• confirme que o artigo foi acrescentado correctamente
• confirme que as promoções e as regras de preço se aplicam
• verifique que a leitura seguinte cai no mesmo campo

Só depois de isto passar é que o leitor físico entra para a confiança final. Esta ordem poupa tempo e, regra geral, torna a sessão de hardware mais útil.

Uma verificação rápida da realidade

É possível testar sistemas de POS sem hardware real com muito mais eficácia do que muitas equipas supõem. Comece por uma simulação realista do leitor, junte dados de ensaio estáveis e concentre-se primeiro no comportamento do fluxo. Depois, use o hardware real para o conjunto mais estreito de problemas que só os aparelhos revelam. Esta abordagem é mais rápida, mais barata e, em geral, mais disciplinada do que depender do hardware desde o início.