Testowanie Progressive Web App (PWA)

Czym jest progresywna aplikacja webowa (Progressive Web App, PWA)?

PWA to aplikacja internetowa, która uruchamiana jest jak strona internetowa poprzez przeglądarkę, ale umożliwia stworzenie wrażenia działania jak natywna aplikacja mobilna (lub aplikacja desktopowa). Jednym z głównych założeń jest to, że aplikacja może działać offline. Uzyskuje się to poprzez cacheowanie wszystkich zapytań i odpowiedzi przy pomocy mechanizmu service worker.

Przykłady takich aplikacji: https://pwa.rocks/

Co jest niemożliwe?

Aplikacje webowe z zasady nie są rozwiązaniami w pełni stacjonarnymi czy też aplikacjami dedykowanymi. Wynika to między innymi z ograniczeń, jakie mają przeglądarki internetowe. Chociaż PWA jako koncept jest możliwe, to aplikacje progresywne są wciąż ograniczone względem rozwiązań instalowalnych.

To, co jest możliwe i niemożliwe dla aplikacji webowych w danej przeglądarce opisuje świetna strona https://whatwebcando.today/.

Status dla Firefox Quantum 58.0.2 na marzec 2018.

Uruchom tę stronę na dowolnej przeglądarce i zobacz, co aktualnie potrafi.

Konstrukcja oprogramowania

Z perspektywy programistycznej PWA musi mieć:

• manifest.json - plik, który zawiera zbiór metadata opisujący daną aplikację (od nazwy przez URL po możliwość wyświetlania na całym ekranie),
• service workers, który jest proxy obsługującym zapytania do serwera z rozbudowanym mechanizmem cache'owania oraz funkcją obsługi zdarzeń w trybie offline.

Znajomość działania mechanizmów i struktury plików json pomaga w ich weryfikacji i testowaniu. Są to rzeczy, które można jednak zautomatyzować, co opiszę za chwilę.

Kiedy aplikacja staje się PWA?

Istnieje kilka reguł, które aplikacja musi spełnić, by zostać uznaną za Progressive Web App. Musi być:

• progresywna - oprogramowanie powinno działać poprawnie dla każdego użytkownika, niezależnie od przeglądarki, jej rozwój oparty jest na ciągłym ulepszaniu (jako podstawowej zasadzie);
• responsywna - aplikacja powinna dopasowywać się do platformy: na komputer, komórkę, tablet lub przyszłe środowiska;
• niezależna od połączenia - service workers (pracownicy usług?) umożliwiają użytkownikowi pracę w trybie offline lub w sieciach z niską przepustowością;
• jak aplikacja - doświadczenie "jak w aplikacjach" osiągnane jest dzięki interakcjom i nawigacjom zgodnym w stylu z podobnymi aplikacjami;
• świeża - zawsze aktualna dzięki procesom aktualizacji w service workers;
• bezpieczna - obsługiwana przez HTTPS, aby zapobiec podsłuchiwaniu i zapewnić, że treści nie zostały zmodyfikowane;
• znajdywalna - identyfikowana jako "aplikacja" dzięki zgodności z manifestem W3C i dzięki zakresowi działania service workers, umożliwiającemu wyszukiwarkom ich znalezienie;
• angażująca - ułatwiająca ponowne zaangażowanie dzięki funkcjom takim jak powiadomienia push;
• instalowalna - pozwalająca użytkownikom na przechowywanie aplikacji, które uznają za najbardziej przydatne na ekranie głównym, bez konieczności korzystania ze sklepów z aplikacjami;
• linkowalna - łatwa w udostępnieniu poprzez przekazanie adresu URL.

Już sama powyższa lista może zostać użyta do tego, by zbadać jak bardzo PWA jest poprawne. Wiele z tych rzeczy można jednak zautomatyzować i sprawdzić dość prosto dzięki narzędziom.

Analiza statyczna strony przy pomocy Lighthouse

Powyższe elementy mogą zostać w łatwy sposób zweryfikowane w narzędzu, które dostarczane jest razem z DevTools w Chromie. Aplikacja nazywa się Lighthouse i wywołuje się ją z sekcji Audits.

Poniżej wyniki analizy dla wspomnianej wcześniej pwa.rocks.

Widać, że na 11-stu automatycznych sprawdzeniach dwa (o mniejszej wadze) zakończyły się niepowodzeniem. Reszta jest spełniona. 

Są jednak jeszcze trzy dodatkowe testy, które trzeba wykonać ręcznie, ponieważ maszyna nie jest w stanie tego samodzielnie ocenić.

1. Czy aplikacja rzeczywiście wygląda tak samo na najważniejszych przeglądarkach?

   • Spełnione dla pwa.rocks.

2. Aplikacja powinna ciągle działać pomimo słabego połączenia sieciowego.

   • Spełnione dla pwa.rocks.

3. Każda podstrona ma swój adres URL.

   • Spełnione dla pwa.rocks.

Dowiedz się więcej o Lighthousie.

Krytyczna rzecz, która nie została jeszcze opisana (a jest ważna) zarówno dla PWA, jak i dla każdej innej aplikacji webowej i desktopowej to użyteczność. Musimy upewnić się, że użytkownik nie jest zaskakiwany przez aplikację i że użycie PWA nie zakłóca jego normalnej interakcji z aplikacją.

Co jeszcze testować?

Jest jeszcze jeden aspekt, który należy zweryfikować przy badaniu PWA. Jest to przełożenie stosowania tej technologii na wartość biznesową dla twórców rozwiązania.

Google, które cały koncept promuje, pokazuje na przykładach, jak stworzenie aplikacji przekłada się na komercyjny sukces aplikacji >>

Kilka wybranych cytatów o tym, co serwisy zyskały dzięki PWA:

• Alibaba
  • 76% większa konwersja na cel

  • 14% więcej użytkowników na iOS i 30% na Androida

• The Weather Channel – 80% szybszy czas ładowania

• George.com
  • 3.8 x szybszy średni czas ładowania strony
  • 31% większa konwersja na cel
  • 20%  więcej odwiedzonych stron na wizytę

  • 28%  większy czas na stronie.

Źródłem danych jest firma, w której murach powstał koncept PWA, nie można więc bezkrytycznie wierzyć powyższym informacjom. Jeśli jednak przynajmniej część z tego jest prawdziwa to te liczby robią wrażenie.

Podsumowanie

W artykule nie opisałem aspektu testowania funkcjonalnego, bezpieczeństwa i wydajności, które w testowaniu PWA będą nieznacznie różnić się od testowania aplikacji webowych i aplikacji natywnych. Nowością jest audyt statyczny, wykonywany na aplikacjach PWA wraz z dodatkowymi sprawdzeniami reguł manualnie. Widać wyraźnie, że coraz więcej twórców stron sięga po tę technologię, a co za tym idzie coraz więcej testerów będzie musiało ją weryfikować.

Autor: Radek Smilgin

Źródła

• https://developers.google.com/web/showcase/
• https://developers.google.com/web/tools/lighthouse/#devtools
• https://developers.google.com/web/fundamentals/codelabs/your-first-pwapp/
• https://en.wikipedia.org/wiki/Progressive_web_app
• https://programistamag.pl/programista-12-2017-67/