Sauce Labs i BrowserStack: chmurowe platformy do testów cross-browser i cross-device

Sauce Labs i BrowserStack to dwie największe chmurowe platformy do testów na wielu przeglądarkach i urządzeniach. Zamiast kupować telefony i utrzymywać własny Selenium Grid, wynajmujecie sesje na maszynach i realnych urządzeniach dostawcy. Poniżej znajdziecie ceny sprawdzone u obu dostawców 11 października 2026 roku, obsługę Playwright i Cypress, działający przykład capabilities dla Selenium 4 oraz uczciwe porównanie z alternatywami.

Tekst jest dla testerów automatyzujących, liderów QA i osób, które mają podpisać fakturę. Jeśli dopiero wybieracie framework, zacznijcie od porównania Selenium, Cypress i Playwright, bo to od niego zależy, którą platformę w ogóle warto rozważać.

Czym są Sauce Labs i BrowserStack?

Obie usługi robią to samo: udostępniają zdalnie przeglądarki, systemy operacyjne, emulatory i realne telefony. Wasz test Selenium, Appium, Playwright albo Cypress łączy się z ich infrastrukturą zamiast z lokalną przeglądarką. Po teście dostajecie nagranie wideo, zrzuty ekranu, logi konsoli i sieci.

Z obu platform korzysta się na dwa sposoby. Pierwszy to sesje ręczne, czyli tester otwiera w przeglądarce konkretny model telefonu i odtwarza zgłoszony błąd. Drugi to testy automatyczne, uruchamiane równolegle z pipeline’u. Ten drugi sposób generuje większość kosztów i większość korzyści.

Ile kosztują Sauce Labs i BrowserStack w październiku 2026?

Ceny poniżej spisaliśmy ze stron dostawców 11 października 2026 roku. Podajemy plany samoobsługowe; plany dla dużych firm oba serwisy wyceniają indywidualnie. Kluczowy szczegół: każdy plan bazowy obejmuje tylko jeden test równoległy, a to właśnie liczba równoległych sesji decyduje o rachunku.

Dwie rzeczy z tej tabeli warto zapamiętać. Sauce Labs w planach samoobsługowych nie limituje liczby użytkowników ani minut, a strona cennika mówi o od 1 do 24 sesji równoległych zależnie od planu. BrowserStack rozlicza testy ręczne per użytkownik, a w planach automatyzacji pozwala wybrać 1, 2, 5 albo więcej testów równoległych. Według cennika BrowserStack najtańszy jest plan Freelancer: $12,50 miesięcznie przy płatności rocznej za 100 minut testów ręcznych.

Czy Sauce Labs i BrowserStack obsługują Playwright i Cypress?

Tak, i tego brakowało w poprzedniej wersji tego artykułu. Obie platformy zaczynały od Selenium i Appium, ale dziś uruchamiają także Playwright i Cypress. Różni się sposób podłączenia, a nie sam fakt obsługi.

Praktyczna uwaga do Playwright: Sauce Labs wspiera konkretne wersje frameworka, a najnowsza wersja Playwright z rejestru npm bywa o kilka wydań nowsza. Przed zakupem sprawdźcie, czy wersja z Waszego package.json jest na liście dostawcy. Według dokumentacji Sauce Labs najnowsza wspierana tam wersja 1.61.1 ma wsparcie do 9 lipca 2027 roku.

Jak podłączyć testy Selenium do chmury? Przykład w Javie

W Selenium 4 obie platformy działają jako zdalny WebDriver. Zmieniacie adres huba i dokładacie blok opcji dostawcy w standardzie W3C. Pokazujemy dwie części klasy testowej z polem WebDriver driver; cała klasa kompiluje się z Selenium 4.51.0, JUnit 6.1.3 i Javą 25. Dostawcę wybiera zmienna środowiskowa, więc ten sam kod uruchomicie na obu platformach i porównacie wyniki.

    static ChromeOptions opcje(String dostawca) {
        ChromeOptions o = new ChromeOptions();
        o.setBrowserVersion("latest");
        if (dostawca.equals("saucelabs")) {
            o.setPlatformName("Windows 11");
            o.setCapability("sauce:options", Map.of(
                    "username", System.getenv("SAUCE_USERNAME"),
                    "accessKey", System.getenv("SAUCE_ACCESS_KEY"),
                    "build", System.getenv().getOrDefault("BUILD_ID", "lokalnie"),
                    "name", "Logowanie, Chrome, Windows 11"));
        } else {
            o.setCapability("bstack:options", Map.of(
                    "os", "Windows",
                    "osVersion", "11",
                    "userName", System.getenv("BROWSERSTACK_USERNAME"),
                    "accessKey", System.getenv("BROWSERSTACK_ACCESS_KEY"),
                    "buildName", System.getenv().getOrDefault("BUILD_ID", "lokalnie"),
                    "sessionName", "Logowanie, Chrome, Windows 11"));
        }
        return o;
    }

Druga część klasy wybiera adres huba i uruchamia test. Importy pominęliśmy dla czytelności: to RemoteWebDriver, ChromeOptions, URI, Map i adnotacje JUnit.

    static String hub(String dostawca) {
        return dostawca.equals("saucelabs")
                ? "https://ondemand.eu-central-1.saucelabs.com/wd/hub"
                : "https://hub.browserstack.com/wd/hub";
    }

    @Test
    void stronaLogowaniaSieOtwiera() throws Exception {
        String dostawca = System.getenv().getOrDefault("CHMURA", "browserstack");
        driver = new RemoteWebDriver(URI.create(hub(dostawca)).toURL(), opcje(dostawca));
        driver.get("https://example.com/logowanie");
        assertTrue(driver.getTitle().length() > 0);
    }

    @AfterEach
    void zamknij() {
        if (driver != null) {
            driver.quit();
        }
    }

Klucze dostępu zawsze czytajcie ze zmiennych środowiskowych albo magazynu sekretów w CI. Zwróćcie też uwagę na adres Sauce Labs: dostawca ma osobne centra danych dla zachodu i wschodu USA oraz dla Europy, a my używamy europejskiego eu-central-1. BrowserStack dla Javy proponuje dziś także SDK, w którym platformy opisujecie w pliku browserstack.yml zamiast w kodzie. Selenium od podstaw, z lokatorami i oczekiwaniami, przerabiamy na szkoleniu Automatyzacja testów Selenium WebDriver.

Czym Sauce Labs różni się od BrowserStack w praktyce?

Na poziomie funkcji obie usługi są bardzo podobne. Różnice widać w modelu rozliczeń, w lokalizacji danych i w tym, które funkcje są w planie bazowym, a które w ofercie dla dużych firm.

Obie firmy w materiałach sprzedażowych mają „najwięcej urządzeń na rynku”, co przypomina dwóch wędkarzy porównujących, kto złowił większą rybę, której nikt inny nie widział. Dla Was liczy się nie suma urządzeń, tylko to, czy na liście są modele z Waszej matrycy. Jak taką matrycę zbudować na danych dla Polski, pokazujemy w tekście o błędach w testach aplikacji mobilnych.

Ile sesji równoległych naprawdę potrzebujecie?

Tu kryje się większość rachunku. Policzmy prosty przykład na liczbach z Waszego zestawu: 600 testów regresji po średnio 30 sekund daje 300 minut pracy przeglądarki. Przy jednym teście równoległym czekacie 5 godzin. Przy pięciu sesjach czas spada do około godziny, a przy dziesięciu do około 30 minut.

Rzeczywistość jest nieco gorsza od arytmetyki, bo każda sesja potrzebuje czasu na start, a testy rzadko dzielą się po równo. Z naszego doświadczenia drugim źródłem kosztów są testy niestabilne: każde ponowne uruchomienie zjada sesję, za którą płacicie. Zanim dokupicie równoległość, ustabilizujcie oczekiwania w testach. Pomaga w tym tekst o explicit wait i implicit wait w Selenium.

Kiedy lepsza będzie alternatywa: TestMu AI albo własny Grid?

Chmura nie zawsze wygrywa. W naszych projektach decyzję sprowadzamy do trzech pytań: czy potrzebujecie realnych telefonów, ile przeglądarek musicie pokryć i czy dane testowe mogą opuścić Waszą sieć.

Pełne porównanie własnej infrastruktury z chmurą, z działającym plikiem docker-compose dla Selenium Grid 4 i konfiguracją shardów w GitHub Actions, znajdziecie w artykule o testach automatycznych w środowisku chmurowym. Szerszy kontekst wyboru frameworka daje też tekst na Strefie QA Selenium, Cypress czy Playwright: które wybrać w 2026.

Jak wpiąć platformę chmurową w CI/CD?

Platforma uruchamiana ręcznie przed wydaniem traci większość wartości. Testy powinny ruszać same po każdej zmianie, a wynik wracać do zespołu w kilka minut. Minimalna konfiguracja GitHub Actions dla przykładu z Javą wygląda tak:

name: testy-w-chmurze
on: [push]
jobs:
  selenium:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: "25"
      - name: Testy na BrowserStack
        env:
          CHMURA: browserstack
          BUILD_ID: ${{ github.run_number }}
          BROWSERSTACK_USERNAME: ${{ secrets.BROWSERSTACK_USERNAME }}
          BROWSERSTACK_ACCESS_KEY: ${{ secrets.BROWSERSTACK_ACCESS_KEY }}
        run: mvn -B test

1. Sekrety. Login i klucz trzymajcie w sekretach repozytorium, nigdy w kodzie ani w pliku konfiguracyjnym.
2. Numer buildu. Przekazujcie identyfikator przebiegu, żeby w panelu dostawcy grupować sesje z jednego uruchomienia.
3. Matryca. Konfiguracje dobierajcie z analityki ruchu, a nie z listy wszystkich dostępnych przeglądarek.
4. Tunel. Środowiska testowe za firewallem wymagają tunelu dostawcy: Sauce Connect albo BrowserStack Local.

Jeśli chcecie, żeby ktoś zaprojektował cały przepływ, od matrycy po raportowanie, zobaczcie usługę budowy procesów CI/CD dla testów.

Jakie błędy najczęściej przepalają budżet na chmurę?

• Wszystkie konfiguracje po równo. Egzotyczne kombinacje zjadają sesje, a nie łapią błędów, które widzą Wasi użytkownicy.
• Niestabilne testy. Każde ponowne uruchomienie to płatna sesja. U naszych klientów porządek w oczekiwaniach często daje więcej niż dokupienie równoległości.
• Brak limitu czasu testu. Zawieszony test blokuje sesję do limitu dostawcy; ustawcie własne, krótsze limity.
• Tylko emulatory. Gesty, aparat, powiadomienia i zużycie baterii warto potwierdzić na realnym urządzeniu.
• Brak właściciela kosztów. Ktoś w zespole powinien raz w miesiącu sprawdzić wykorzystanie sesji w panelu dostawcy.

Fundament jest zawsze ten sam: stabilne lokatory, jawne oczekiwania i świadomy dobór scenariuszy. Te umiejętności rozwiniecie na szkoleniach Automatyzacja testów z narzędziem Playwright oraz Testowanie automatyczne aplikacji mobilnych w Appium (Java).

Powiązane na blogu Quality Island

• Testowanie automatyczne w środowisku chmurowym: Selenium Grid 4, Playwright i koszty równoległości
• Selenium, Cypress czy Playwright: porównanie narzędzi do automatyzacji testów
• Selenium: co to jest, jak działa i od czego zacząć automatyzację testów
• Błędy w aplikacji mobilnej: 7 luk w testach i jak je zamknąć
• Explicit Wait vs Implicit Wait: waity w Selenium WebDriver, które stabilizują testy

Pełna lista źródeł

• Sauce Labs, Pricing Plans, odczyt 11.10.2026. Stąd ceny Live Testing, Virtual Device Cloud i Real Device Cloud, limit 1 do 24 sesji oraz nielimitowani użytkownicy.
• BrowserStack, Pricing, odczyt 11.10.2026. Stąd ceny Live, Automate i App Automate oraz deklarowana liczba przeglądarek i urządzeń.
• Sauce Labs, Playwright on Sauce Labs, 2026. Stąd obsługa Playwright przez saucectl i lista wspieranych wersji.
• Sauce Labs, Cypress on Sauce Labs, 2026. Stąd obsługa Cypress, wersje i przeglądarki.
• Sauce Labs, Data Center Endpoints, 2026. Stąd adresy hubów dla centrów danych w USA i Europie.
• Sauce Labs, Test Configuration Options, 2026. Stąd klucze bloku sauce:options.
• BrowserStack, Run Playwright tests on BrowserStack Automate, 2026. Stąd obsługa Playwright przez SDK.
• BrowserStack, Run Cypress tests on BrowserStack, 2026. Stąd obsługa Cypress i konfiguracja browserstack.json.
• BrowserStack, Selenium with Java, 2026. Stąd podejście z SDK i plikiem browserstack.yml oraz wymóg Selenium 4.23+.
• TestMu AI, komunikat prasowy przez AAP, LambdaTest Rebrands to TestMu AI, 12 stycznia 2026. Stąd zmiana nazwy LambdaTest i deklarowana liczba użytkowników.
• Selenium, Selenium Grid, 2026. Stąd opis własnej infrastruktury Selenium Grid 4.