Śmierć Selenium ogłoszono zbyt wcześnie. Co pokazują liczby z 2025 roku?

Jeszcze kilka lat temu wydawało się, że los Selenium jest przesądzony. Na konferencjach QA coraz częściej mówiło się o nim w czasie przeszłym, a w branżowych dyskusjach padały określenia, których trudno nazwać subtelnymi: przestarzałe, zbyt ciężkie, nieprzystające do świata CI/CD. Wraz ze wzrostem Playwrighta i ekspansją Cypressa narracja o końcu Selenium zaczęła funkcjonować niemal jak fakt, powtarzany tak często, aż przestał być kwestionowany.

Problem w tym, że rzeczywistość, jak to zwykle bywa w IT, nie zamierzała potwierdzić tej opowieści. Selenium nie wygrywa dziś nowych projektów. Nadal jednak trzyma krytyczne ścieżki w organizacjach, w których stawką są pieniądze, stabilność i reputacja. Ten tekst wyjaśnia, dlaczego tak jest, co realnie zmieniło się w architekturze narzędzia i kiedy pozostanie przy nim jest dobrą decyzją, a kiedy tylko odkładaniem rachunku.

Rynek, który nie nagradza sentymentu

Automatyzacja testów funkcjonuje dziś w innym kontekście niż dekadę temu. Testowanie przestało być technicznym dodatkiem do developmentu, a stało się jednym z obszarów inwestycyjnych, które zarząd widzi w budżecie. W takim środowisku decyzje technologiczne przestają być kwestią preferencji zespołu. Stają się decyzjami o ryzyku operacyjnym i przewidywalności. I właśnie dlatego Selenium wciąż ma silną pozycję w dużych organizacjach.

W największych firmach Selenium jest narzędziem spłaconym. Istnieją tysiące, a czasem dziesiątki tysięcy testów, które przez lata były stabilizowane, refaktoryzowane i dopasowywane do procesów wydawniczych. Migracja takiej bazy to nie projekt technologiczny, tylko wielomiesięczna inicjatywa obarczona realnym ryzykiem biznesowym. Selenium jest przewidywalne, a przewidywalność bywa w tym świecie ważniejsza niż nowoczesność.

WebDriver BiDi, czyli co realnie się zmieniło

Przez lata największym zarzutem wobec Selenium była architektura oparta na jednokierunkowej komunikacji HTTP. W porównaniu z narzędziami, które od początku korzystały z dwukierunkowych połączeń, Selenium wydawało się spóźnione o epokę. Test musiał odpytywać przeglądarkę zamiast słuchać, co się w niej dzieje.

WebDriver BiDi zmienił ten obraz. To standard W3C, tworzony przez projekt Selenium wspólnie z producentami przeglądarek, który dokłada do WebDrivera połączenie WebSocket. Dzięki temu skrypty mogą odbierać i reagować na zdarzenia z przeglądarki w czasie rzeczywistym: żądania sieciowe, komunikaty konsoli, błędy JavaScriptu. Dokumentacja Selenium opisuje BiDi wprost jako międzyprzeglądarkowy zamiennik protokołu DevTools, który do tej pory działał głównie w rodzinie Chrome. Dla zespołów oznacza to jedno: część rzeczy, które wcześniej wymagały obejść albo osobnych narzędzi, staje się dostępna w standardzie.

Hybryda jako nowa normalność

Najczęstszy model, który spotykamy w projektach, nie jest wyborem jednego narzędzia. Selenium obsługuje starszy kod i krytyczne ścieżki, które od lat działają i nikt nie ma powodu ich ruszać. Playwright wchodzi do nowych obszarów i do szybkiej regresji w pipeline. Cypress zostaje przy zespołach frontendowych, blisko komponentów. To nie jest niezdecydowanie. To racjonalny podział ryzyka: nie migrujecie tego, co działa, a nowe rzeczy budujecie na tańszym w utrzymaniu fundamencie.

Warunek jest jeden i bywa pomijany: każde narzędzie musi mieć właściciela i jasną granicę. Bez tego hybryda zamienia się w trzy zestawy testów, których nikt nie utrzymuje w całości, trzy różne raporty i trzy różne odpowiedzi na pytanie, czy można wydawać. Jak porównać te trzy narzędzia pod kątem własnego kontekstu, rozkładamy w tekście Selenium kontra Cypress kontra Playwright.

Kiedy zostać przy Selenium, a kiedy nie

Zostańcie, jeśli macie duży ekosystem w Javie albo .NET, działające testy, kompetencje w zespole i procesy zbudowane wokół tego narzędzia. Zostańcie też wtedy, gdy koszt zmiany byłby wyższy niż zysk, a obecny zestaw daje wiarygodny sygnał. To jest uczciwa decyzja biznesowa, nie zaniedbanie.

Odpuśćcie, jeśli startujecie nowy produkt i chcecie szybkiego, stabilnego sygnału w CI bez inwestowania w ciężką infrastrukturę. Odpuśćcie też wtedy, gdy zespół nie ma doświadczenia w budowaniu stabilnych testów przez interfejs i nie będzie miał czasu, żeby się tego nauczyć. W takim układzie testy zamieniają się w generator fałszywych alarmów, a nie w system jakości. Migracja, jeśli już, powinna być selektywna: bierzecie najbardziej bolesne scenariusze, te które padają najczęściej i najczęściej blokują wydanie, i przenosicie je pierwsze. Reszta może dożyć swoje, dopóki biznes akceptuje koszt utrzymania.

Co naprawdę decyduje o koszcie

Najczęstszy błąd w tej dyskusji to przypisywanie frameworkowi rzeczy, za które odpowiada projekt testów. Niestabilność bierze się zwykle z kruchych lokatorów, danych testowych i środowiska, nie z nazwy biblioteki. Google w tekście o testach niestabilnych pokazało, że przy dużej skali około 1,5 procent uruchomień daje wynik niestabilny, a 84 procent przejść z zielonego na czerwone ma udział takiego testu. To zjawisko nie zna marek. Zmiana narzędzia bez zmiany podejścia przenosi problem, a nie rozwiązuje go.

Zespół Quality Island napisał dotąd ponad 450 000 testów automatycznych, w różnych frameworkach i w bardzo różnych organizacjach. Wniosek z tej pracy jest jeden: o koszcie decyduje utrzymanie, a o utrzymaniu decyduje architektura testów, nie logo na stronie startowej. Ten sam projekt można prowadzić drogo w nowoczesnym narzędziu i tanio w klasycznym, jeśli ktoś zadbał o lokatory, dane i podział warstw. Jak uniknąć testowego spaghetti przy dużej skali, opisujemy w tekście o testach end to end na dużą skalę.

Co zrobić z istniejącym zestawem testów, zanim zdecydujecie o migracji

Zanim ktokolwiek policzy koszt przepisania testów, warto zrobić trzy rzeczy, które są tańsze i często wystarczają. Pierwsza: przegląd wartości. Bierzecie listę testów i przy każdym zapisujecie, kiedy ostatnio wykrył realny defekt. Nie kiedy padł, tylko kiedy złapał coś, co inaczej poszłoby na produkcję. W większości zestawów, które audytujemy, jedna trzecia testów nie złapała niczego przez rok, a mimo to codziennie zjada czas w pipeline i uwagę przy każdej awarii. To nie jest materiał do migracji. To materiał do usunięcia.

Druga: przegląd lokatorów. Jeśli testy wyszukują elementy po klasach stylu, pozycji w strukturze dokumentu albo identyfikatorach generowanych automatycznie, będą padać przy każdym refaktorze niezależnie od frameworka. Zamiana ich na lokatory oparte na roli, etykiecie i widocznym tekście jest pracą na kilka dni dla krytycznych ścieżek, a znosi znaczną część fałszywych awarii. To jest ta sama zmiana, którą i tak trzeba wykonać po migracji, więc równie dobrze można ją zrobić najpierw i zobaczyć, ile problemu zostanie.

Trzecia: przegląd oczekiwania na elementy. Sztywne pauzy czasowe rozsiane po kodzie to najczęstsza przyczyna testów, które raz przechodzą, a raz nie. Każda taka pauza jest jednocześnie stratą czasu w każdym przebiegu i źródłem niestabilności, gdy środowisko zwolni. Zastąpienie ich warunkami oczekiwania na konkretny stan aplikacji zwykle skraca przebieg i podnosi stabilność w tym samym ruchu. Dopiero po tych trzech krokach macie uczciwą odpowiedź na pytanie, czy problemem jest narzędzie, czy sposób, w jaki go używacie. Jak dobrać metryki, żeby to zmierzyć, a nie oceniać na wyczucie, opisujemy w tekście o tym, jak mierzyć produktywność zespołu QA.

Podsumowanie

Czy Selenium jeszcze żyje? Tak, choć już nie jako jedyny król automatyzacji. Jest dziś dojrzałym filarem strategii testowej: narzędziem, które rzadko wygrywa nowe projekty, ale wciąż trzyma to, czego nikt nie chce ruszać. WebDriver BiDi zamknął najpoważniejszy zarzut architektoniczny, a wbudowany menedżer sterowników usunął jeden z najbardziej uciążliwych elementów codziennej pracy. Jeśli ktoś ogłasza koniec Selenium, warto zapytać, czy patrzy na nowe projekty, czy na całość rynku, bo to dwie różne odpowiedzi.

W Quality Island pomagamy zespołom podjąć tę decyzję na danych, a nie na modzie: przegląd obecnego zestawu testów, ocena kosztu utrzymania, krótki test porównawczy na jednym krytycznym scenariuszu i rekomendacja, co zostaje, co migruje i w jakiej kolejności. Jeśli nie wiecie, czy Wasze testy są problemem, czy tylko wyglądają staro, zacznijcie od pierwszego pytania z tego tekstu: ile z nich cokolwiek złapało w ostatnim półroczu.

Powiązane na Strefie QA

• Selenium vs Cypress vs Playwright: które wybrać w 2026?
• Automatyzacja testów: co się naprawdę opłaca automatyzować, a co nie
• Testy end to end: jak unikać testowego spaghetti

Źródła:

• Selenium, dokumentacja: WebDriver BiDi
• W3C, specyfikacja WebDriver BiDi
• Google Testing Blog, Flaky Tests at Google and How We Mitigate Them, 2016
• Automatyzacja testów, Quality Island
• Praktyka własna Quality Island z projektów automatyzacji, ponad 450 000 napisanych testów automatycznych