Start · Rozwiązania · IT i usługi
Rozwiązanie · IT i usługiPortal i aplikacja testowane przy każdym buildzie, nie w ostatnie popołudnie
Regresja portalu i aplikacji mobilnej przy każdym wydaniu
Każdy build portalu i aplikacji mobilnej uruchamia pakiet regresji bez udziału ludzi; błędy trafiają na Teams do dewelopera wraz z dowodami, a gotowość wydania widać przed decyzją.
Streszczenie dla zarządu
Regresja to lista kontrolna, którą dwie osoby przeklikują w ostatnie popołudnie przed wydaniem.
Pakiet regresji budujemy jako zasób produktu, a nie jako czynność tygodnia wydania.
Regresja przestaje być slotem w kalendarzu.
portal klienta oraz buildy iOS i Android; usługi polisowe, szkodowe i płatnicze; backlog w Azure DevOps
Problem biznesowy
Jakość wydań
Portal klienta i aplikacja mobilna to miejsca, w których ubezpieczyciel spotyka większość swoich klientów pomiędzy wznowieniami. Ubezpieczeni logują się, aby pobrać dokument polisy, zgłosić szkodę ze zdjęciami, zapłacić ratę składki, zmienić numer rachunku, kupić lub wznowić ochronę. Każda z tych ścieżek przechodzi przez kilka systemów zaplecza, a każde wydanie co dwa tygodnie może zepsuć dowolną z nich.
Testy regresyjne to obietnica, że nadal działa to, co działało w poprzednim wydaniu. Obietnicy dotrzymują dwie osoby i lista kontrolna, w jedynym oknie, jakie zostawia kalendarz. Pod presją czasu listy nie skraca się według ryzyka, tylko według kolejności: najpierw odpadają kroki z dołu, a na dole są ścieżki przechodzone najrzadziej, układ na tablet, poprzednia wersja systemu operacyjnego, klient z trzema polisami.
Z aplikacją mobilną jest trudniej niż z portalem. Błąd w portalu poprawia się i wdraża tego samego dnia; błąd w wydanej wersji aplikacji zostaje w telefonie klienta do czasu aktualizacji, a ci, którzy aktualizują najrzadziej, mają zwykle urządzenia testowane najsłabiej.
Odczuwa to nie tylko IT. Infolinia przyjmuje telefony, likwidacja szkód dostaje niedokończone zgłoszenia, a właściciel produktu odpowiada na pytanie o bezpieczeństwo wydania przeczuciem, a nie liczbą.
Jak to wygląda dzisiaj
Niezależnie od metodyki opisanej na ścianie sama regresja wygląda zwykle tak.
- SystemBuild ze sprintu trafia na środowisko testowe w środę wieczorem
- CzłowiekDwie osoby z zespołu testów otwierają listę kontrolną na SharePoint i dzielą między siebie 180 kroków
- OczekiwanieDane testowe trzeba najpierw przygotować ręcznie: polisa z otwartą szkodą, nieopłacona rata, klient z trzema pojazdami
- CzłowiekŚcieżki webowe są przeklikiwane w jednej przeglądarce, a aplikacja sprawdzana na telefonie, który akurat ma tester
- Ryzyko błęduGdy popołudnie się kończy, pozostałe kroki odpadają, a nigdzie nie zostaje ślad, które to były
- CzłowiekBłędy są opisywane na kanale wydania w Teams i, jeśli da się je odtworzyć, zakładane w Azure DevOps
- Ryzyko błęduWydanie rusza na podstawie ustnego podsumowania, a pierwsza informacja o awarii przychodzi z infolinii albo z recenzji w sklepie
Dlaczego obecny proces kosztuje więcej, niż widać
Rachunek, którego nie widać w budżecie.
- Ręczne testowanie tych samych ścieżek co dwa tygodnie nie zostawia niczego trwałego. Dwadzieścia sześć popołudni w roku daje dwadzieścia sześć ustnych zapewnień i żadnego zasobu, który dałoby się uruchomić ponownie jutro.
- Pokrycie spada dokładnie wtedy, gdy powinno rosnąć. Wydanie z wieloma zmianami zostawia mniej czasu na testy, więc największe zmiany dostają najcieńszą kontrolę, a zespół, który nie umie testować tanio, odpowiada łączeniem zmian w jeszcze większe wydania.
- Błąd znaleziony przez klienta kosztuje kilkakrotnie więcej niż błąd znaleziony na buildzie. Poprawka w portalu to hotfix i przeprosiny; poprawka w aplikacji to dodatkowo publikacja w sklepie i klienci, którzy nigdy nie aktualizują.
- Dostępności i wydajności nie ma na liście w ogóle, bo żadnej z nich nie da się przeklikać w jedno popołudnie, więc obie trafiają do audytu zewnętrznego raz w roku, o ile w ogóle.
Koszt zaniechania
Nic w kalendarzu wydań nie wymusza zmiany i dlatego zmiany nie ma. Popołudnie wraca co dwa tygodnie, lista kontrolna jest przycinana od dołu, a przycięcie pozostaje niewidoczne, dopóki klient nie znajdzie tego, co przycięto. Kwota 8 000 € na jeden błąd, który wyszedł do klientów, to nasza własna mieszanka hotfiksa, kontaktów na infolinii, transakcji wprowadzanych ręcznie od nowa i publikacji w sklepie, której wymaga poprawka mobilna; dziewięć takich błędów na dwadzieścia sześć wydań nie jest założeniem pesymistycznym.
To, co narasta, jest wolniejsze i mniej widoczne. Zespół, który nie umie testować tanio, wydaje rzadziej, przez co każde wydanie jest większe i trudniejsze do przetestowania. Przegląd dostępności wciąż się nie odbywa, a dwie osoby, które nadal potrafią powiedzieć, co naprawdę pokrywa lista kontrolna, stają się dwiema, których produkt nie może stracić.
Przykładowa organizacja o realnych proporcjach — liczby służą do policzenia sprawy na Waszych danych, nie są wynikiem klienta.
Europejski ubezpieczyciel, około 1 400 pracowników, około 600 000 klientów detalicznych na trzech rynkach; portal klienta oraz natywne aplikacje iOS i Android, dwa zespoły produktowe, wspólny dwuosobowy zespół jakości, Azure DevOps, Microsoft 365 E3.
26 wydań rocznie dla portalu i obu buildów aplikacji; lista kontrolna licząca około 180 kroków ręcznych, obejmująca dwanaście ścieżek klienta; około trzech osobodni regresji na wydanie.
Dwie osoby przechodzą listę kontrolną w popołudnie przed wdrożeniem, w jednej przeglądarce i na jednym telefonie, z danymi testowymi przygotowanymi ręcznie. Ustalenia trafiają na kanał wydania w Teams; te odtwarzalne stają się zadaniami w Azure DevOps.
Popołudnie to budżet stały, lista kontrolna nie. Kroki odpadają w kolejności z listy, a nie według ryzyka, pokrycie mobilne to jedno urządzenie, a dostępność i obciążenie leżą poza tym ćwiczeniem.
Przypadki testowe w UiPath Test Manager pokrywają dwanaście ścieżek na poziomie web, mobile i API, tworzone i utrzymywane przez Autopilot for Testers na podstawie wymagań, które już są w Azure DevOps. Każdy build uruchamia pakiet przez API trigger w Orchestrator, błędy trafiają do odpowiedzialnego dewelopera na Microsoft Teams wraz z dowodami, a wyniki wracają do Azure DevOps.
W modelowanym przypadku regresja, która zabierała popołudnie, wykonuje się bez udziału ludzi przy każdym buildzie, dwanaście ścieżek jest pokrytych na kilku kombinacjach urządzeń i przeglądarek zamiast jednej, a gotowość wydania staje się liczbą. Ilustracja, nie wynik klienta.
Proponowane rozwiązanie
Pakiet regresji budujemy jako zasób produktu, a nie jako czynność tygodnia wydania. Każda z dwunastu ścieżek staje się wymaganiem i zestawem przypadków testowych w UiPath Test Manager, tej części UiPath Test Cloud, która przechowuje przypadki i dowody wykonania. Autopilot for Testers tworzy je na podstawie historyjek użytkownika, które już są w Azure DevOps, generuje stojącą za nimi automatyzację i przygotowuje syntetyczne dane testowe dla każdego przypadku.
Wykonanie obejmuje oba kanały i warstwę pod nimi: ścieżki webowe na przeglądarkach i rozmiarach ekranu, z których korzystają klienci, ścieżki mobilne na buildach aplikacji z Państwa pipeline'u, na kombinacjach urządzeń i systemów, które wskazuje analityka. Test Cloud obsługuje testy web, mobile i API w jednym miejscu, więc jeden zestaw testowy prowadzi ekran, woła usługę pod nim i sprawdza obie strony. Nic nie czeka na człowieka: po każdym udanym buildzie pipeline wywołuje API trigger w Orchestrator, a pakiet wykonuje się bez nadzoru. Błąd staje się zadaniem powiązanym z przypadkiem testowym, ze zrzutem ekranu, nagraniem i asercją, która nie przeszła, i trafia do dewelopera odpowiedzialnego za ten obszar jako actionable notification na Microsoft Teams. Klienci pracujący na Jira mają synchronizację tam.
Nad tym stoi widok gotowości wydania: pokrycie na ścieżkę, liczba przejść i niepowodzeń oraz trend między buildami, zestawione z otwartymi błędami według wagi w Power BI. Tam, gdzie klient tego potrzebuje, ten sam pakiet niesie kontrole dostępności wobec kryteriów WCAG oraz testy wydajnościowe obciążeniowe, szczytowe, stresowe i długotrwałe. To inne zadanie niż nocna regresja SAP, która chroni jeden system zaplecza przed wdrażanymi do niego transportami, i jeszcze inne niż zapewnienie jakości migracji, gdzie jednorazowe przeniesienie danych jest dowodzone rekord po rekordzie przed przełączeniem.
UiPath Test Cloud z Test Manager (przypadki testowe, dowody, synchronizacja z Azure DevOps i Jira, testy WCAG i wydajnościowe); Autopilot for Testers (generowanie testów, syntetyczne dane testowe, samonaprawa); UiPath Orchestrator API triggers i ślad audytowy; UiPath Action Center actionable notifications na Microsoft Teams
Mapę ścieżek na przypadki testowe wraz z rankingiem ryzyka, biblioteki obiektów, zestawy danych testowych i ich sprzątanie, integrację z pipeline'em, reguły kierowania błędów, raport gotowości i runbook
Krok pipeline'u, który uruchamia pakiet i czeka na werdykt; połączenie z Państwa parkiem urządzeń, chmurą urządzeń albo własnym laboratorium; wywołania usług polisowych, szkodowych i płatniczych, które przygotowują i sprzątają dane testowe
Jak działa proces po automatyzacji
- AutomatyzacjaUdany build w Azure DevOps wywołuje API trigger w Orchestrator i uruchamia zestaw testowy dla obszarów objętych zmianą
- AutomatyzacjaDane testowe są przygotowywane: polisy, otwarte szkody, nieopłacone raty i zgody powstają przez usługi, a potem są usuwane
- SystemRoboty wykonują ścieżki webowe na przeglądarkach i rozmiarach ekranu w zakresie oraz ścieżki mobilne na nowych buildach aplikacji w parku urządzeń
- AutomatyzacjaKontrole API idą równolegle wobec usług polisowych, szkodowych i płatniczych; pakiety dostępności i wydajności wykonują się w uzgodnionym harmonogramie
- SystemKażdy wynik ląduje w Test Manager wraz z dowodami, a niepowodzenia zakładają lub aktualizują zadania w Azure DevOps powiązane z przypadkiem testowym i buildem
- CzłowiekDeweloper odpowiedzialny za obszar dostaje błąd na Microsoft Teams i kwalifikuje go jako defekt, poprawkę testu albo zamierzoną zmianę
- AutomatyzacjaWidok gotowości aktualizuje się: pokrycie na ścieżkę, wskaźnik przejść, otwarte błędy według wagi, trend na ostatnich buildach
Model współpracy człowieka z automatyzacją
Automatyzacja obsługuje
- Uruchamianie pakietu ścieżek na poziomie web, mobile i API po każdym buildzie, bez polecenia
- Przygotowanie i usuwanie danych testowych potrzebnych każdemu przypadkowi
- Zbieranie dowodów dla każdego wyniku i zakładanie powiązanego zadania w Azure DevOps
- Utrzymanie deskryptorów elementów przy zmianach interfejsu i raportowanie naprawionych testów
Ludzie decydują
- Które ścieżki należą do pakietu i jakie ryzyko niesie każda z nich
- Czy niepowodzenie to defekt, zamierzona zmiana czy test do aktualizacji
- Bramka wydania: co może pozostać otwarte, gdy build idzie na produkcję
- Progi dostępności i wydajności, które musi spełnić portal
Przed i po
Systemy i integracje
Nie dokładamy technologii, żeby architektura wyglądała poważniej. Każdy element poniżej ma w tym procesie konkretne zadanie.
Wejścia
- wymagania i historyjki użytkownika w Azure DevOps
- artefakty buildów z pipeline'u
- dwanaście ścieżek klienta i ich ranking ryzyka
- statystyki urządzeń i przeglądarek z Państwa analityki
Warstwa automatyzacji
- UiPath Test Cloud z Test Manager
- Autopilot for Testers
- UiPath Orchestrator
- UiPath Robots
- UiPath Action Center
Systemy docelowe
- portal klienta oraz buildy iOS i Android
- usługi polisowe, szkodowe i płatnicze
- backlog w Azure DevOps
- raport gotowości w Power BI
Punkty styku z człowiekiem: kwalifikacja błędów na Microsoft Teams; raport gotowości; przegląd przypadków testowych w Test Manager
Wykorzystane technologie
wymagania, przypadki testowe, dowody, synchronizacja z Azure DevOps lub Jira
Atworzy testy z wymagań, generuje automatyzację i syntetyczne dane testowe, samonaprawia testy
Auruchamiają pakiet bez nadzoru na API triggers z pipeline'u, z ponowieniami i śladem audytowym
Akieruje każde niepowodzenie do dewelopera odpowiedzialnego za obszar, z dowodami
Apipeline'y budujące, które uruchamiają pakiet; backlog, w którym żyją defekty
Apoświadczenia techniczne; utrzymuje środowiska testowe i maszyny robotów
Araport gotowości wydania czytany przed decyzją o publikacji
Akombinacje urządzeń i systemów, na których wykonują się ścieżki mobilne
CIlustracyjny model ekonomiczny
Ile to jest warte, policzone krok po kroku.
Osobodzień to tutaj 480 minut, a 6,5 osobodnia miesięcznie to kalendarz 26 wydań rozłożony równo na rok; obie wartości są założeniami, a nie pomiarem u klienta. 42 € to pełny koszt godzinowy specjalisty jakości w Europie Środkowej. Model wycenia wyłącznie regresję ręczną, a nie defekty docierające do klientów, które opisuje kolejna sekcja. Pokazuje uwolnioną zdolność; sposób jej wykorzystania jest decyzją Państwa.
Policz to na swoich danych
Szacunek ilustracyjny na podstawie Twoich danych. To model uwolnionej przepustowości, nie obietnica oszczędności.
Korzyści biznesowe
- Regresja przestaje być slotem w kalendarzu. Każdy build jest testowany, data wydania nie decyduje już o tym, ile testów się odbędzie, a wydania mogą być mniejsze i częstsze.
- Pokrycie staje się faktem, a nie zamiarem: dwanaście ścieżek, na przeglądarkach i urządzeniach używanych przez klientów, przy każdym buildzie, zapisane dla każdego przebiegu.
- Defekty docierają do dewelopera w ciągu minut od buildu, który je wywołał, kiedy poprawka jest jeszcze tania.
- Aplikacja mobilna przestaje być kanałem, na który nigdy nie było czasu, a dostępność i obciążenie stają się kontrolą ciągłą zamiast audytu raz do roku.
Perspektywa zarządu
- Gotowość wydania staje się liczbą, którą właściciel produktu może pokazać: pokrycie na ścieżkę, wskaźnik przejść i otwarte błędy według wagi, dla każdego buildu.
- Decyzja o publikacji opuszcza sferę przekonań. Co zostało przetestowane, co nie przeszło i co zostało zaakceptowane, jest zapisane przy każdym wydaniu.
- Zdolność dostarczania rośnie bez zatrudniania, a wiedza zespołu o jakości przestaje być przekazem ustnym i staje się przypadkami testowymi, które przeczyta każdy.
Wpływ na KPI zarządu
Bezpieczeństwo i nadzór
Zaufanie do automatyzacji buduje się na śladzie, nie na deklaracji.
- Testy działają na środowiskach z klientami syntetycznymi, a pakiet maskuje każde pole na zrzucie ekranu i w nagraniu, które mogłoby nieść dane osobowe. Danych produkcyjnych ubezpieczonych nie kopiuje się do przebiegu testowego i tylko taka wersja przechodzi przegląd ochrony danych.
- Każdy robot loguje się własnym kontem technicznym. Sekrety nie opuszczają Azure Key Vault, Orchestrator jedynie się do nich odwołuje, a konta mają uprawnienia w dzierżawach testowych i nigdzie indziej.
- Wymagania, wyniki i dowody pozostają w Państwa projekcie Azure DevOps oraz w regionie EU UiPath Automation Cloud, gdzie historia wykonań po miesiącach nadal odpowiada, kto zmienił przypadek testowy i kto zaakceptował niepowodzenie.
Dlaczego teraz
Dostępność przestała być opcjonalna dla usług sprzedawanych online. European Accessibility Act, dyrektywa (UE) 2019/882, obowiązuje od 28 czerwca 2025 r. i obejmuje usługi handlu elektronicznego, czyli usługi świadczone na odległość drogą elektroniczną w celu zawarcia umowy konsumenckiej, a tym właśnie jest portal sprzedający i wznawiający polisy. To, czy konkretna ścieżka mieści się w zakresie, jest pytaniem do Państwa działu prawnego; tak czy inaczej audyt raz w roku nie zastępuje kontroli przy każdym buildzie.
Modelowane 26 208 € rocznego nakładu na regresję to mniejsza połowa rachunku. Defekty, których jedno popołudnie nie wyłapie, są większą połową, a obie pozycje płaci się co roku, dopóki lista kontrolna trwa.
Pisanie testów nigdy nie było powodem, dla którego pakiety automatyczne obumierały; było nim utrzymanie. Autopilot for Testers tworzy przypadki z wymagań, generuje stojącą za nimi automatyzację i dane syntetyczne oraz naprawia testy przy zmianie interfejsu, przenosząc wysiłek na decyzję, co testować.
Role zarządcze, których to dotyczy
Jakość wydania staje się mierzalną cechą pipeline'u zamiast sporu w popołudnie przed wdrożeniem
Kanały, z których korzystają klienci, są testowane, zanim klienci ich użyją, więc infolinia przestaje odkrywać wydania
Produkt wydaje częściej, bo dowiedzenie bezpieczeństwa wydania nie rośnie już wraz z liczbą ścieżek
Uwolniona zdolność jest mała i policzalna; koszt defektów docierających do klientów jest większy i ląduje w wolumenach obsługi, a nie w budżecie IT
Częste pytania i zastrzeżenia
Wspólna jest platforma i prawie nic poza tym. Nocna regresja SAP chroni jeden system zaplecza przed transportami, które są do niego wdrażane; ten pakiet chroni dwa kanały, których dotykają klienci, przed przeglądarkami i telefonami zmieniającymi się we własnym rytmie. Większość firm prowadzi ostatecznie oba, często tym samym zespołem.
Właśnie dlatego pakiety umierają na utrzymaniu, a nie na pisaniu. Automatyzacja opiera się na wspólnych bibliotekach elementów, a nie na współrzędnych, Autopilot for Testers naprawia, co może, i raportuje, co naprawił, a UiPath Healing Agent obejmuje testy automatyczne tak samo jak przebiegi produkcyjne.
Szybka zmiana jest argumentem za. Ścieżki najważniejsze, logowanie, zgłoszenie szkody, opłacenie raty, zmieniają się najrzadziej i najbardziej bolą, gdy się zepsują. Zaczynamy od nich na dwóch lub trzech kombinacjach urządzeń i poszerzamy zakres, gdy pakiet zdobędzie zaufanie.
Kiedy to nie jest właściwe rozwiązanie
- Produkt wydawany dwa razy w roku i mało zmieniany pomiędzy wydaniami, gdzie lista kontrolna naprawdę kosztuje mniej niż pakiet, który ktoś musi utrzymywać
- Aplikacja wciąż przebudowywana, w której ekrany i identyfikatory zmieniają się co sprint z powodów niebędących defektami
- Brak środowiska testowego i możliwości tworzenia danych testowych, przez co każdy przebieg zależałby od rekordów produkcyjnych
Pytanie na najbliższe posiedzenie
Zanim kolejne wydanie trafi na produkcję, jakim dowodem będzie dysponowała ta firma na to, że portal i aplikacja mobilna nadal działają, i kto ten dowód wytworzy?
Podejście wdrożeniowe
Co dokładnie dostarczamy i czego potrzebujemy na start.
Dostarczamy
- Warsztat ścieżek i ryzyka: które ścieżki musi pokryć pakiet, ile warta jest każda z nich, co znaczy zepsute
- Wymagania i przypadki testowe w Test Manager, tworzone przez Autopilot for Testers z historyjek, które i tak Państwo piszą, wraz z automatyzacją webową i mobilną oraz bibliotekami obiektów, które utrzymują ją w ryzach
- Zestawy danych testowych, które same zakładają i sprzątają polisy, szkody i płatności, żeby żaden przebieg nie zależał od ręcznie zbudowanego rekordu
- Integrację z pipeline'em w Azure DevOps, kierowanie błędów na Microsoft Teams i stojące za tym reguły odpowiedzialności
- Raport gotowości w Power BI, pakiety dostępności i wydajności tam, gdzie są w zakresie, oraz runbook utrzymaniowy
Potrzebujemy od Państwa
- Środowiska testowego zbliżonego do produkcji, buildów aplikacji, które pipeline może przekazać, oraz analityki urządzeń i przeglądarek
- Dostępu do usług używanych do przygotowania danych testowych, ograniczonego wyłącznie do danych testowych
- Wskazanego właściciela produktu, który zdecyduje, czego wymaga bramka wydania
Etapy
Rozpoznanie
Ścieżki, ranking ryzyka, obecna lista kontrolna, środowiska, miks urządzeń i przeglądarek
Projekt
Macierz pokrycia, strategia danych testowych, kryteria bramki, odpowiedzialność i kierowanie błędów
Budowa
Przypadki testowe i automatyzacja web, mobile i API, integracja z pipeline'em, kierowanie na Teams
Stabilizacja
Pakiet działa obok listy kontrolnej, aż oba dają zgodny wynik, potem lista odchodzi
Utrzymanie
Rytm utrzymania, praca z niestabilnymi testami, pakiety dostępności i wydajności, kwartalny przegląd pokrycia
Działowe. O nakładzie decyduje liczba ścieżek, testowalność aplikacji (stabilne identyfikatory elementów, usługa pod każdym ekranem) oraz liczba kombinacji urządzeń i przeglądarek w macierzy.
Regresja skrócona w czwartkowe popołudnie to dokładnie to, co klienci znajdą w piątek.
Prosimy o obecną listę kontrolną regresji i historię wydań z ostatniego kwartału. Odsyłamy mapę ścieżek i ryzyka, propozycję macierzy pokrycia oraz pisemną ocenę, co zautomatyzować najpierw.
Zautomatyzujmy dwie najryzykowniejsze ścieżkiTen sam problem ma zwykle sąsiedni proces
Próbka kilkuset rekordów w arkuszu to dziś wszystko, co dzieli migrację od startu produkcyjnego.
Zobacz rozwiązanie IT i usługiWnioski o dostęp i kwartalne przeglądy uprawnieńMenedżerowie zatwierdzają uprawnienia, których nie rozumieją, a nikt nie odbiera tych nieużywanych.
Zobacz rozwiązanie Obsługa klientaPoziomy usług raportowane, zanim klient je zakwestionujeMiesięczne raporty SLA powstają w Excelu z eksportów zgłoszeń, a kary umowne pierwszy wylicza klient.
Zobacz rozwiązanie IT i usługiKażdy laptop rozliczony: od zamówienia do utylizacjiSprzęt zamawiany mailem, wydawany bez rekordu i spisywany na straty, gdy pyta audytor.
Zobacz rozwiązanie Case studyRegresja SAP co nocZamiast trzech osób klikających przez dwa dni — agenci testowi UiPath przechodzą krytyczne ścieżki SAP każdej nocy.
Zobacz case study Case studyRoboty, które naprawiają się sameZmienił się ekran w SAP i pół portfela robotów staje? Healing Agent wykrywa zmianę interfejsu i naprawia selektory w locie, a nasz zespół AMS pilnuje całości — zanim biznes zauważy problem.
Zobacz case studyBranże, w których wdrażamy to najczęściejHandel i e‑commerceUsługi i ITFinanse i ubezpieczenia