A página de resultados de testes para os testes QUnit se parece com isso (exemplo: Shopping Cart).

Quantos dos seus usuários finais / testadores podem afirmar que esses testes são válidos? Esses são testes feitos para o desenvolvedor, e, por isso, existe um certo risco de que esses testes não sejam totalmente confiáveis. Nos primeiros anos das apps Fiori, não era incomum encontrar apps que passavam pelo controle de qualidade dos testes unitários, incluindo testes que verificavam se 1 === 1.

Testar a interface do usuário (UI) torna mais fácil verificar o que o desenvolvedor está testando. Executar, por exemplo, OPA5 no navegador mostra visualmente o que o teste está fazendo.

Embora seja positivo ver o que está sendo feito, sendo capaz de acompanhar as ações e observar como o aplicativo muda, ainda é difícil descobrir o que realmente foi testado. O resultado do teste se assemelha ao dos testes unitários.

Levante a mão se você acha que seus usuários finais ou principais conseguem ler esse relatório e entender o que foi feito para passar no teste. Caso eles queiram descobrir o que foi testado, essa será a jornada:

As funções chamadas para executar o teste estão distribuídas em 3 arquivos:

welcome.js

Product.js

Category.js

Como já mencionado: OPA5 é voltado para o desenvolvedor. Se a interface do usuário (UI) mudar, você se sente confiante em afirmar que isso será detectado pelos testes OPA5? Ou que os testadores conseguirão identificar testes ausentes ou desatualizados?

Visão do usuário final

Mesmo que sua equipe e cultura de testes sejam de excelência, nem tudo que causa a falha de um aplicativo em produção é facilmente identificável com testes de unidade, integração ou sistema. Às vezes, os aplicativos falham em produção devido a erros que não são detectados pelos testes. Um ícone pode estar faltando, os dados na linha 5 podem estar deslocados, a página de detalhes pode parecer estranha, um botão pode estar oculto atrás de um ícone “mostrar mais”. Por quê? Um tema atualizado ou com erro pode fazer com que o navegador renderize um controle da UI de forma diferente. Dados de teste fictícios podem fazer com que os textos em produção não se ajustem. Elementos podem estar ocultos em smartphones, enquanto o teste OPA5 foi realizado apenas em resolução de desktop.

Resumindo: o aplicativo é testado. No entanto, o aplicativo não funciona para o usuário final. Um desenvolvedor não é o usuário final. E essa é uma das principais razões pelas quais os aplicativos falham em produção. Esse problema não pode ser totalmente resolvido. Mas o gap pode, pelo menos, ser parcialmente fechado.

Fechando a lacuna

O truque é incluir os usuários/testadores desde o início.

Spoiler

Você não vai escapar de escrever testes. Testes com QUnit e wdi5 são o que deve ser fornecido. Para controles de UI: eles são indispensáveis.

Como incluir o usuário logo nos testes? Primeiro, cedo não significa necessariamente no momento em que a primeira linha de código é escrita, ou antes disso. Significa: assim que testes para o usuário puderem ser criados. E como garantir que o usuário esteja disposto a se envolver ativamente?

Fornecendo informações que eles não apenas possam entender, mas que conheçam e possam influenciar.

Forneça dados simulados úteis 

Tente obter o mais cedo possível dados simulados do QA ou do sistema de testes. Dados simulados gerados automaticamente, como “Produto A, Produto B” ou “Lorem ipsum dolor sit amet” são interessantes. No entanto, se o usuário estiver acostumado a trabalhar com “SAX31P0” e “SAX31P03 Operating voltage AC 230 V, 3-position positioning signal” como descrição, é isso que o app deve exibir durante os testes. Usar textos fictícios facilita que os usuários/testadores se distanciem dos resultados dos testes. Isso causa uma sensação de “isso ainda não está pronto, ainda está em desenvolvimento intenso”, o que impede que os usuários se comprometam com os testes. Utilizar dados do QA desde o início traz um efeito colateral positivo: caso os textos de produção contenham caracteres como √, que possam parecer “estranhos” na apresentação, isso será detectado logo no início.

Deixe o usuário gravar 

Para envolver os usuários desde o início, forneça a eles a versão atual do app e permita que gravem as ações da jornada do usuário. Em vez de o desenvolvedor traduzir a jornada do usuário em código, deixe que o próprio usuário faça isso. É a jornada gravada por eles que será usada nos testes. Faça com que eles sejam os donos desse processo. Outro efeito colateral positivo: o usuário estará testando a interface (UI) enquanto ela é desenvolvida e poderá já fornecer feedback sobre a experiência do usuário (UX) ou outras expectativas.

Testes visuais

Valide com testes visuais se a interface (UI) está funcionando corretamente. Verifique se o texto está adequado, se os ícones estão visíveis e se o layout funciona em diferentes tipos de dispositivos. Em vez de testar se um ID específico existe no HTML e acionar ações sobre ele, grave a interface como um todo. Capturar o app em todos os dispositivos suportados permite identificar possíveis problemas de experiência do usuário (UX). Testes visuais são possíveis, por exemplo, com o uso de wdio (que também pode tirar screenshots). Os testes de UI devem ser feitos com uma ferramenta que permita criar capturas de tela facilmente e compará-las com uma linha de base. Executar testes visuais em produção ajuda a identificar problemas causados por atualizações. As linhas de base ajudam a identificar quando uma alteração na UI foi introduzida.

Utilize os testes   

Embora isso possa parecer óbvio, não se trata apenas de usar os testes nos estágios iniciais. À medida que outros testes são adicionados ao longo do tempo (por exemplo, wdi5), eles devem ser baseados no que já foi capturado. Quando o desenvolvedor começar a escrever todos os testes detalhados, certifique-se de que eles sejam baseados no que já foi registrado pelo usuário. Os testes QUnit, OPA ou wdi5 devem ser entendidos como um refinamento. O fato de o usuário fornecer a gravação de uma jornada implica que ele também é o proprietário dela. Essa propriedade é sagrada e deve ser cultivada. Os testes podem ser usados para limpar o código: o que não é testado é código morto. Remova-o. Se mais tarde perceber que esse código era necessário, significa que os cenários de teste não estão completos. E adivinhe quem é responsável por esses testes? Certo, não é o desenvolvedor.

Próximos passos

Para cada uma das três abordagens recomendadas, escreverei um post no blog e compartilharei os códigos. As ferramentas utilizadas são:

– SAP UX mock server e proxy

– Chrome recorder

– Puppeteer e BackstopJS

Deixe o mundo saber