{"id":746,"date":"2024-10-02T15:40:47","date_gmt":"2024-10-02T18:40:47","guid":{"rendered":"https:\/\/tachyonix.io\/br\/?p=746"},"modified":"2024-10-02T15:52:31","modified_gmt":"2024-10-02T18:52:31","slug":"o-aplicativo-passou-no-teste-ainda-nao-esta-funcionando-para-o-usuario-final-2","status":"publish","type":"post","link":"https:\/\/www.tachyonix.io\/br\/o-aplicativo-passou-no-teste-ainda-nao-esta-funcionando-para-o-usuario-final-2\/","title":{"rendered":"O aplicativo passou no teste. Ainda n\u00e3o est\u00e1 funcionando para o usu\u00e1rio final."},"content":{"rendered":"\n

A p\u00e1gina de resultados de testes para os testes QUnit se parece com isso (exemplo: Shopping Cart).<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

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

Testar a interface do usu\u00e1rio (UI) torna mais f\u00e1cil verificar o que o desenvolvedor est\u00e1 testando. Executar, por exemplo, OPA5 no navegador mostra visualmente o que o teste est\u00e1 fazendo.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Embora seja positivo ver o que est\u00e1 sendo feito, sendo capaz de acompanhar as a\u00e7\u00f5es e observar como o aplicativo muda, ainda \u00e9 dif\u00edcil descobrir o que realmente foi testado. O resultado do teste se assemelha ao dos testes unit\u00e1rios.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Levante a m\u00e3o se voc\u00ea acha que seus usu\u00e1rios finais ou principais conseguem ler esse relat\u00f3rio e entender o que foi feito para passar no teste. Caso eles queiram descobrir o que foi testado, essa ser\u00e1 a jornada:<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n

As fun\u00e7\u00f5es chamadas para executar o teste est\u00e3o distribu\u00eddas em 3 arquivos:<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

welcome.js<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Product.js<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Category.js<\/p>\n\n\n\n

Como j\u00e1 mencionado: OPA5 \u00e9 voltado para o desenvolvedor. Se a interface do usu\u00e1rio (UI) mudar, voc\u00ea se sente confiante em afirmar que isso ser\u00e1 detectado pelos testes OPA5? Ou que os testadores conseguir\u00e3o identificar testes ausentes ou desatualizados?<\/p>\n\n\n\n

Vis\u00e3o do usu\u00e1rio final<\/strong><\/p>\n\n\n\n

Mesmo que sua equipe e cultura de testes sejam de excel\u00eancia, nem tudo que causa a falha de um aplicativo em produ\u00e7\u00e3o \u00e9 facilmente identific\u00e1vel com testes de unidade, integra\u00e7\u00e3o ou sistema. \u00c0s vezes, os aplicativos falham em produ\u00e7\u00e3o devido a erros que n\u00e3o s\u00e3o detectados pelos testes. Um \u00edcone pode estar faltando, os dados na linha 5 podem estar deslocados, a p\u00e1gina de detalhes pode parecer estranha, um bot\u00e3o pode estar oculto atr\u00e1s de um \u00edcone “mostrar mais”. Por qu\u00ea? Um tema atualizado ou com erro pode fazer com que o navegador renderize um controle da UI de forma diferente. Dados de teste fict\u00edcios podem fazer com que os textos em produ\u00e7\u00e3o n\u00e3o se ajustem. Elementos podem estar ocultos em smartphones, enquanto o teste OPA5 foi realizado apenas em resolu\u00e7\u00e3o de desktop.<\/p>\n\n\n\n

Resumindo: o aplicativo \u00e9 testado. No entanto, o aplicativo n\u00e3o funciona para o usu\u00e1rio final. Um desenvolvedor n\u00e3o \u00e9 o usu\u00e1rio final. E essa \u00e9 uma das principais raz\u00f5es pelas quais os aplicativos falham em produ\u00e7\u00e3o. Esse problema n\u00e3o pode ser totalmente resolvido. Mas o gap pode, pelo menos, ser parcialmente fechado.<\/p>\n\n\n\n

Fechando a lacuna<\/p>\n\n\n\n

O truque \u00e9 incluir os usu\u00e1rios\/testadores desde o in\u00edcio.<\/p>\n\n\n\n

Spoiler<\/em><\/strong><\/em><\/p>\n\n\n\n

Voc\u00ea n\u00e3o vai escapar de escrever testes. Testes com QUnit e wdi5 s\u00e3o o que deve ser fornecido. Para controles de UI: eles s\u00e3o indispens\u00e1veis.<\/em><\/p>\n\n\n\n

Como incluir o usu\u00e1rio logo nos testes? Primeiro, cedo n\u00e3o significa necessariamente no momento em que a primeira linha de c\u00f3digo \u00e9 escrita, ou antes disso. Significa: assim que testes para o usu\u00e1rio puderem ser criados. E como garantir que o usu\u00e1rio esteja disposto a se envolver ativamente?<\/p>\n\n\n\n

Fornecendo informa\u00e7\u00f5es que eles n\u00e3o apenas possam entender, mas que conhe\u00e7am e possam influenciar.<\/p>\n\n\n\n

Forne\u00e7a dados simulados \u00fateis <\/strong><\/p>\n\n\n\n

Tente obter o mais cedo poss\u00edvel dados simulados do QA ou do sistema de testes. Dados simulados gerados automaticamente, como \u201cProduto A, Produto B\u201d ou \u201cLorem ipsum dolor sit amet\u201d s\u00e3o interessantes. No entanto, se o usu\u00e1rio estiver acostumado a trabalhar com \u201cSAX31P0\u201d e \u201cSAX31P03 Operating voltage AC 230 V, 3-position positioning signal\u201d como descri\u00e7\u00e3o, \u00e9 isso que o app deve exibir durante os testes. Usar textos fict\u00edcios facilita que os usu\u00e1rios\/testadores se distanciem dos resultados dos testes. Isso causa uma sensa\u00e7\u00e3o de \u201cisso ainda n\u00e3o est\u00e1 pronto, ainda est\u00e1 em desenvolvimento intenso\u201d, o que impede que os usu\u00e1rios se comprometam com os testes. Utilizar dados do QA desde o in\u00edcio traz um efeito colateral positivo: caso os textos de produ\u00e7\u00e3o contenham caracteres como \u221a, que possam parecer \u201cestranhos\u201d na apresenta\u00e7\u00e3o, isso ser\u00e1 detectado logo no in\u00edcio.<\/p>\n\n\n\n

Deixe o usu\u00e1rio gravar <\/strong><\/p>\n\n\n\n

Para envolver os usu\u00e1rios desde o in\u00edcio, forne\u00e7a a eles a vers\u00e3o atual do app e permita que gravem as a\u00e7\u00f5es da jornada do usu\u00e1rio. Em vez de o desenvolvedor traduzir a jornada do usu\u00e1rio em c\u00f3digo, deixe que o pr\u00f3prio usu\u00e1rio fa\u00e7a isso. \u00c9 a jornada gravada por eles que ser\u00e1 usada nos testes. Fa\u00e7a com que eles sejam os donos desse processo. Outro efeito colateral positivo: o usu\u00e1rio estar\u00e1 testando a interface (UI) enquanto ela \u00e9 desenvolvida e poder\u00e1 j\u00e1 fornecer feedback sobre a experi\u00eancia do usu\u00e1rio (UX) ou outras expectativas.<\/p>\n\n\n\n

Testes visuais<\/strong><\/p>\n\n\n\n

Valide com testes visuais se a interface (UI) est\u00e1 funcionando corretamente. Verifique se o texto est\u00e1 adequado, se os \u00edcones est\u00e3o vis\u00edveis e se o layout funciona em diferentes tipos de dispositivos. Em vez de testar se um ID espec\u00edfico existe no HTML e acionar a\u00e7\u00f5es sobre ele, grave a interface como um todo. Capturar o app em todos os dispositivos suportados permite identificar poss\u00edveis problemas de experi\u00eancia do usu\u00e1rio (UX). Testes visuais s\u00e3o poss\u00edveis, por exemplo, com o uso de wdio (que tamb\u00e9m pode tirar screenshots). Os testes de UI devem ser feitos com uma ferramenta que permita criar capturas de tela facilmente e compar\u00e1-las com uma linha de base. Executar testes visuais em produ\u00e7\u00e3o ajuda a identificar problemas causados por atualiza\u00e7\u00f5es. As linhas de base ajudam a identificar quando uma altera\u00e7\u00e3o na UI foi introduzida.<\/p>\n\n\n\n

Utilize os testes <\/strong>  <\/p>\n\n\n\n

Embora isso possa parecer \u00f3bvio, n\u00e3o se trata apenas de usar os testes nos est\u00e1gios iniciais. \u00c0 medida que outros testes s\u00e3o adicionados ao longo do tempo (por exemplo, wdi5), eles devem ser baseados no que j\u00e1 foi capturado. Quando o desenvolvedor come\u00e7ar a escrever todos os testes detalhados, certifique-se de que eles sejam baseados no que j\u00e1 foi registrado pelo usu\u00e1rio. Os testes QUnit, OPA ou wdi5 devem ser entendidos como um refinamento. O fato de o usu\u00e1rio fornecer a grava\u00e7\u00e3o de uma jornada implica que ele tamb\u00e9m \u00e9 o propriet\u00e1rio dela. Essa propriedade \u00e9 sagrada e deve ser cultivada. Os testes podem ser usados para limpar o c\u00f3digo: o que n\u00e3o \u00e9 testado \u00e9 c\u00f3digo morto. Remova-o. Se mais tarde perceber que esse c\u00f3digo era necess\u00e1rio, significa que os cen\u00e1rios de teste n\u00e3o est\u00e3o completos. E adivinhe quem \u00e9 respons\u00e1vel por esses testes? Certo, n\u00e3o \u00e9 o desenvolvedor.<\/p>\n\n\n\n

Pr\u00f3ximos passos<\/p>\n\n\n\n

Para cada uma das tr\u00eas abordagens recomendadas, escreverei um post no blog e compartilharei os c\u00f3digos. As ferramentas utilizadas s\u00e3o:<\/p>\n\n\n\n

– SAP UX mock server e proxy<\/p>\n\n\n\n

– Chrome recorder<\/p>\n\n\n\n

– Puppeteer e BackstopJS<\/p>\n\n\n\n

Deixe o mundo saber<\/p>\n","protected":false},"excerpt":{"rendered":"

A p\u00e1gina de resultados de testes para os testes QUnit se parece com isso (exemplo: Shopping Cart). Quantos dos seus usu\u00e1rios finais \/ testadores podem afirmar que esses testes s\u00e3o v\u00e1lidos? Esses s\u00e3o testes feitos para o desenvolvedor, e, por isso, existe um certo risco de que esses testes n\u00e3o sejam totalmente confi\u00e1veis. Nos primeiros […]<\/p>\n","protected":false},"author":1,"featured_media":757,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-746","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sem-categoria"],"_links":{"self":[{"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/posts\/746","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/comments?post=746"}],"version-history":[{"count":4,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/posts\/746\/revisions"}],"predecessor-version":[{"id":759,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/posts\/746\/revisions\/759"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/media\/757"}],"wp:attachment":[{"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/media?parent=746"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/categories?post=746"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tachyonix.io\/br\/wp-json\/wp\/v2\/tags?post=746"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}