devthomas.pl Tomasz Stanisz
  • ls blog/Czytaj blogStrona
  • cat blog/en/building-mobile-and-web-clients-around-one-appwrite-backend.mdxBuilding mobile and web clients around one Appwrite backend (EN)Strona
  • cat blog/pl/building-mobile-and-web-clients-around-one-appwrite-backend.mdxAplikacja mobilna i webowa ze wspólnym backendem Appwrite (PL)Strona
  • whoamiPrzejdź na góręSekcja
  • cd workPrzejdź: Sprawdzone na produkcjiSekcja
  • cd nowPrzejdź: W budowie i wdrożoneSekcja
  • cd approachPrzejdź: Jak pracuję — i gdzie to widaćSekcja
  • cd backgroundPrzejdź: DoświadczenieSekcja
  • cd contactPrzejdź: KontaktSekcja
  • cat work/orange-cms.mdStudium przypadku: CMS, który backend rozszerza bez zmian frontenduStrona
  • cat work/orange-e2e-testing.mdStudium przypadku: Od dni ręcznej regresji do mniej niż godzinyStrona
  • cat work/theeventa-mvp.mdStudium przypadku: Jeden Tech Lead, agenci AI i MVP zbudowane niemal od zeraStrona
  • cat README.mdJak powstała ta stronaStrona
  • cat cvOtwórz CV (EN)Link
  • open linkedinOtwórz LinkedInLink
  • open githubOtwórz GitHubLink
  • git remote -vZobacz kod tej stronyLink
  • copy emailKopiuj adres e-mailAkcja
  • shareKopiuj link z tym wyglądemAkcja
  • theme darkWłącz ciemny motywUstawienie
  • skin terminalWłącz styl TerminalUstawienie

Studium przypadku · Orange Polska

Od dni ręcznej regresji do mniej niż godziny

Jak wprowadziłem automatyczne testy end-to-end w Orange Polska, przeszkoliłem dwie osoby i skróciłem regresję z dni do mniej niż godziny.

Rezultat

~1 h

regresja Orange TV GO, wcześniej 1–3 dni

Moja rola
Wprowadziłem automatyzację E2E, zbudowałem architekturę testów i przeszkoliłem dwie osoby
Kiedy
Od 2022
Zespół
Ja, nowo zatrudniony tester automatyzujący i tester manualny przechodzący do automatyzacji
Stack
Cypress, TypeScript, Page Object Model

Sytuacja

Dołączyłem do Orange Polska, by pracować nad platformą streamingową Orange TV GO. Wtedy testerzy manualni sprawdzali ręcznie każdy scenariusz end-to-end. Pełna regresja obejmowała ponad 100 scenariuszy i zajmowała od jednego do trzech dni.

Początki

Uczyłem się wtedy Cypressa i chciałem wykorzystać go w praktyce. Podczas obiadu opowiedziałem przełożonemu o automatyzacji E2E i swoim pomyśle. Zamiast pisać propozycję, zbudowałem osobne repozytorium z pełną konfiguracją, TypeScriptem, lintowaniem i pierwszymi działającymi testami. Gdy przełożony zobaczył je w akcji, zaczął szukać testera automatyzującego.

Rozważane opcje

  • OdrzuconoSelenium:

    zbyt skomplikowane i wymagające zbyt dużo konfiguracji dla naszego zespołu.

  • OdrzuconoPlaywright:

    obiecujący, ale moim zdaniem jeszcze wtedy niedostatecznie dojrzały.

  • WybranoCypress:

    nowoczesny, popularny i dobrze dopasowany do testowania aplikacji webowej. Wybrałem go.

  • WybranoOsobne repozytorium.

    Testy pisali i utrzymywali testerzy, a nie programiści aplikacji, dlatego miały własny projekt.

Budowanie praktyki testowania

  • Szkolenie: każdy zaczynał od samodzielnych podstaw Cypressa. Następnie wspólnie pisaliśmy prawdziwe testy na mojej konfiguracji, a przez pierwszy rok przeglądałem każdą zmianę. Zespół tworzył nowo zatrudniony tester oraz tester manualny przechodzący do automatyzacji.
  • Page Object Model: interakcje z poszczególnymi częściami aplikacji są zamknięte w obiektach wielokrotnego użytku. Zmianę interfejsu poprawiamy w jednym miejscu.
  • Wspólne funkcje pomocnicze: powtarzalne kroki zapisujemy raz i wykorzystujemy ponownie (DRY).
  • Uruchomienia równoległe: testy działają obok siebie. Wymaga to ich niezależności, dlatego każdy test po zakończeniu usuwa własne dane przez API.
  1. Scenariusz testowyOpisuje jedną ścieżkę użytkownika, niezależną od pozostałych testów
  2. Page ObjectsInterakcje wielokrotnego użytku z poszczególnymi częściami aplikacji
  3. Funkcje pomocniczeWspólne kroki zapisane raz i wykorzystywane ponownie
  4. Równoległe uruchomienieScenariusze działają obok siebie; każdy usuwa własne dane przez API
Przebieg testu: niezależne scenariusze ze wspólnych elementów, uruchamiane równolegle.

Uruchamianie testów

  • Orange TV GO: zestaw działa w CI/CD przy każdym merge requeście funkcji.
  • Wewnętrzny CMS: przed upływem roku przeszedłem do projektu CMS, który otrzymał tę samą konfigurację wewnątrz repozytorium frontendu, z równoległym uruchamianiem testów.
  • Środowiska: w obu projektach testy działają również na środowiskach deweloperskim, testowym i przedprodukcyjnym.

Rezultat

Wcześniej (ręcznie)Teraz (automatycznie)
Orange TV GO, ponad 100 scenariuszy1–3 dniokoło 1 godziny
Wewnętrzny CMS, około 80 scenariuszy1–3 dniokoło 30 minut

Dane testowe nie sprawiają problemów: testy są odizolowane na potrzeby równoległych uruchomień i każdy sprząta po sobie.

Co zrobiłbym inaczej

Dziś wybrałbym Playwright z TypeScriptem. Dostęp do narzędzi deweloperskich przeglądarki i zakres możliwości ułatwiają obsługę nietypowych scenariuszy w porównaniu z Cypressem. Miejsce testów powinno wynikać z tego, kto je pisze. Zostawiłbym je w repozytorium aplikacji tylko wtedy, gdy jej programiści sami tworzą testy E2E.