TesterArmy: czym jest agent QA od ekipy z YC i jak wpiąć go w workflow vibecodingu

TL;DR

TesterArmy to chmurowy agent QA z portfela Y Combinator (Spring 2026, P26), który steruje prawdziwą przeglądarką oraz prawdziwymi buildami iOS i Androida na podstawie opisów testów napisanych zwykłym językiem. Asercje są wizyjne, a obsługa loginu (OAuth, OTP, captcha) jest wbudowana. Produkt budują trzej polscy ex-inżynierowie Callstack operujący z San Francisco: Szymon Rybczak (CEO), Oskar Kwaśniewski (CTO), Piotr Matyjasik (CPO). Dla vibecoderów, czyli devów, którzy oddają większość kodu Claude Code, Cursorowi albo Codeksowi, TesterArmy dostarcza oficjalny agent skill (npx skills add tester-army/cli) oraz CLI w trybie JSON, które domyka pętlę zmiana → test → fix bez utrzymywania własnego pakietu Playwright. Produkt jest też uczciwie krytyczny wobec własnych braków, co waży więcej niż lakier marketingowy.

Poniżej: co TesterArmy robi mechanicznie, jak wygląda jego powierzchnia integracyjna pod koniec kwietnia 2026, pięć konkretnych wzorców wpięcia w workflow z agentem kodującym oraz jeden strukturalny blocker, który decyduje, czy warto wchodzić w to dzisiaj.

1. Co to właściwie robi

Slogan na stronie głównej brzmi: „Test your app with AI, catch bugs before users do.” Pod spodem siedzi hostowany runner przeglądarkowy w stylu Playwrighta z agentem LLM na wierzchu. Piszesz testy naturalnym językiem („Zaloguj się, przejdź onboarding, załóż nowy projekt, zaproś osobę z zespołu”), agent rozbija prompt na plan kroków, który możesz edytować, a potem odpala plan w zdalnej sesji przeglądarki. Każda asercja jest wizyjna: agent patrzy na wyrenderowaną stronę, zamiast zaglądać w selektory CSS. To jawna deklaracja przeciwko kruchym pakietom Playwrighta utrzymywanym ręcznie.

Trzy rzeczy, które nie wynikają wprost z marketingu:

Auth to realna powierzchnia inżynierska, a nie checkbox. TesterArmy trzyma poświadczenia w AES-256-GCM, każdemu uruchomieniu agenta przypisuje dedykowany inbox e-mailowy na kody OTP i obsługuje OAuth, HTTP Basic, upload plików oraz rozwiązywanie captcha. To najbardziej upierdliwa część utrzymywania jakiegokolwiek pakietu E2E ręcznie i jednocześnie najbardziej obronny element produktu.

Mobile jest pierwszoklasowym targetem, a nie odgrzewanym dodatkiem. Wrzucasz binarkę .app (iOS) albo .apk (Android) i ten sam agent steruje aplikacją w ten sam sposób. Do CI dochodzi osobny tester-army/mobile-github-action@v1. Większość bezpośredniej konkurencji (Octomind, Reflect, QA.tech, Meticulous) jest tylko web albo dolicza za mobile osobno. To najwyraźniejszy moat TesterArmy w tej kategorii.

Nazwa „army” to marketing. Każde uruchomienie testu to jeden agent w jednej chmurowej przeglądarce. Nie ma semantyki roju: testy lecą równolegle przez --parallel N, ale to są po prostu współbieżne uruchomienia, a nie skoordynowani agenci.

Tryby uruchomienia, które działają dziś: ręczny run z dashboardu, cykliczny „Production Monitoring” w cronie, GitHub App podpinający się do każdego PR-a (deploy z Vercela i Coolify obsługiwany pierwszoklasowo) oraz generyczny webhook trigger, który strzeli z dowolnego CI.

Czego strona nie mówi nawet po uważnym czytaniu: na jakim LLM-ie siedzi agent, gdzie naprawdę chodzą chmurowe przeglądarki (Browserbase? Steel? własna infra?), jaki jest backend egzekucji mobilnej i jakakolwiek konkretna liczba w cenniku. Pricing brzmi dosłownie: „Start with your free test runs. Paid plans are handled by call when your team is ready.” Jednostka rozliczeniowa to jeden run testu, workspaces to osobna oś. Etykiety planów (trial, plans, teams) są trzy, opublikowanych cen zero. Postura SOC2/ISO niesprecyzowana. Self-hosting wzmiankowany wyłącznie jako rozmowa enterprise, czyli płatne plany przez rozmowę handlową.

2. Kto to zbudował

Założycielska trójka to ex-inżynierowie Callstack od React Native z głębokim rodowodem w open source i to jest najmocniejszy nie-marketingowy sygnał w całym tym raporcie. Szymon Rybczak to dziewiętnastoletni CEO, który wrócił do Polski dokończyć liceum, prowadząc równocześnie firmę. Oskar Kwaśniewski jest CTO, wcześniej senior RN engineer w Callstack pracujący nad LLM-ami on-device. Piotr Matyjasik jest CPO. Zespół to łącznie cztery osoby, baza w San Francisco na czas YC Spring 2026, partnerem YC jest Pete Koomen.

Rodowód z Callstack tłumaczy kształt produktu: testowanie React Native jest naprawdę trudne, ekipa siedziała blisko tego bólu latami, a decyzja o traktowaniu binarki mobilnej jako pierwszoklasowego targetu jest w tej kategorii nietypowa, ale oczywista, jeśli całe zawodowe życie wysyłałeś apki w RN. To też powód, dla którego brand „TesterArmy” da się wymówić bez ironii: to nie są założyciele od żartobliwych pet-projectów, tylko ludzie z infrastruktury.

Jeden wypadek wart oznaczenia, jeśli operujesz na polskim rynku: TestArmy Group S.A. to ugruntowana, dwustuosobowa polska firma QA i cyber, działająca z Wrocławia od 2014 roku. Nazwy będą się zderzać w Google przy każdym polskim kupującym z QA. Z czasem to się rozjedzie wraz z trakcją TesterArmy, ale dziś SEO jest mętne.

Sygnał community jest uczciwy wobec etapu. Oficjalny GitHub org ma cztery publiczne repo, tester-army/cli ma 29 gwiazdek, brak Product Hunta, brak Show HN, brak dyskusji na oczywistych subredditach. Założyciele postują na X i LinkedInie, najtwardszym dowodem trakcji jest notka Szymona z LinkedIna o wirusowym demie aplikacji Bluesky, które wygenerowało „500+ rejestracji z firm Fortune 500 i 40+ rozmów handlowych w kilka dni”. Bierz to dosłownie: jest realny ruch, jest realny pipeline, ale publicznych logo klientów jeszcze nie ma.

3. Powierzchnia integracji w szczegółach

CLI

npm install -g testerarmy   # or: npx testerarmy ...
ta auth --api-key <KEY>     # one-time
ta tests run <testId> --url http://localhost:3000 --json --parallel 3
ta status --json
ta list

Binarki: testerarmy i krótki alias ta. Zmienne środowiskowe: TESTERARMY_API_KEY, TESTERARMY_TARGET_URL, TESTERARMY_PROJECT_ID, TESTERARMY_WEBHOOK_URL. Źródło: tester-army/cli, licencja MIT, zbudowane na commander plus Playwright 1.59-alpha i @playwright/mcp. Exit code 1 przy nieudanym teście, artefakty lądują w .testerarmy/<timestamp>/.

REST API

Spec OpenAPI 3.1 pod /api/v1/openapi.json, 19 endpointów, pełny reference na docs.tester.army/api-reference. Auth przez Authorization: Bearer <API_KEY>. Endpointy warte zapamiętania:

• Odpalenie runu: POST /v1/runs (przyjmuje pole prompt, ale CLI go jeszcze nie wystawia)
• Trigger przez webhook: POST /v1/webhook/{id}/{secret} oraz POST /v1/groups/webhook/{id}/{secret}
• Polling runu: GET /v1/runs/{id}
• Cancel: POST /v1/runs/{id}/cancel
• List/create testów: GET/POST /v1/tests
• Upload binarki mobilnej: POST /v1/projects/{projectId}/mobile/upload oraz /upload/confirm (multipart)

Limity rate limitów nie są udokumentowane w nagłówkach, ale każdy endpoint definiuje odpowiedź 429. Cap storage'u to 2 GB na projekt, jeden webhook na grupę. GraphQL nie ma, SDK w żadnym języku też nie ma.

GitHub App

Instalujesz raz. Auto-komentarz na każdym PR ze zrzutami ekranu, nagraniami wideo i linkiem do pełnego raportu. Zawiera „exploration agent”, który czyta tytuł i diff PR-a, a potem generuje celowany plan testów. Ciekawe, bo zamyka lukę, w której nikt nie zdążył napisać suite'a pod nową funkcję. Zdarzenia deploya z Vercela i Coolify odpalają go automatycznie.

GitHub Action (mobile)

- uses: tester-army/mobile-github-action@v1
  with:
    app_path: .build/MyApp.app
    api_key: ${{ secrets.TESTERARMY_API_KEY }}
    project_id: ${{ secrets.TESTERARMY_PROJECT_ID }}
    webhook_url: ${{ secrets.TESTERARMY_WEBHOOK_URL }}
    timeout_seconds: "1800"

Outputy: app_id, run_ids (tablica JSON), overall_status (passed | failed | timed_out).

Agent skill

npx skills add tester-army/cli instaluje opiniodawczy agent skill w formacie Skills, który czytają Claude Code, Codex i OpenCode. Uczy agenta kodującego wołać CLI, parsować JSON-owy output, czytać artefakty i ponawiać przy failu. Najmniej oporu na drodze.

MCP server

Oficjalnego ani społecznościowego MCP servera dziś nie ma. CLI ciągnie @playwright/mcp jako dependencję, ale to MCP Playwrighta, a nie własny TesterArmy.

Self-hosting

Tylko SaaS. Brak runnera offline. Chmurowy agent musi dotrzeć do Twojego URL-a: dla localhost:3000 potrzebujesz tunelu (ngrok, cloudflared), chyba że strzelasz w deployowany preview.

4. Pięć konkretnych wzorców wpięcia w vibecoding

Wzorzec 1, slash command /test-this

Trigger: developer wpisuje /test-this, kiedy agent skończy fichę. Mechanika: project-scoped slash command w .claude/commands/test-this.md, który odpala ta tests run --group $TA_SMOKE_GROUP --url http://localhost:3000 --json, parsuje exit code, czyta .testerarmy/<timestamp>/result.json i wpycha failure'y w kontekst kolejnej tury. Wartość ponad npm test: realna przeglądarka, realne logowanie, asercje wizyjne. Pętla agenta domyka się: zmiana, run, czytanie zrzutu i loga, patch, kolejny run, bez człowieka pomiędzy.

Wzorzec 2, Stop hook: smoke run po każdej fiszce

{
  "hooks": {
    "Stop": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "if curl -sf http://localhost:3000 >/dev/null && git diff --cached --name-only HEAD~1 | grep -q '^apps/web/'; then TESTERARMY_TARGET_URL=http://localhost:3000 ta tests run --group $TA_SMOKE_GROUP --json --parallel 3 || echo 'TESTERARMY_FAIL: see .testerarmy/'; fi"
      }]
    }]
  }
}

Wartość: zero ceremonii. Nigdy nie wpisujesz „odpal testy”, agent dostaje tekst z failem w kontekście następnej tury i sam się poprawia.

Wzorzec 3, pre-commit gate przez Husky

Hook pre-commit w Husky woła ta tests run --group $TA_CRITICAL_GROUP --json. Trzymaj „critical” mały (login, checkout). Łapie regresje wizyjne, których Vitest nie zobaczy. Tradeoff: 30-90 sekund latencji na commit.

Wzorzec 4, bot na PR przez GitHub App (zero-config)

Push na PR → preview na Vercelu → zdarzenie deploya odpala Appkę automatycznie. Bez YAML-a, bez minut CI. Exploration agent wyciąga bugi z flowów, dla których nikt nie napisał testu.

Jeśli nie jesteś na Vercelu ani Coolify, sześć linijek GitHub Action załatwia sprawę:

- name: Smoke against preview
  run: npx testerarmy tests run --group ${{ vars.TA_GROUP }} --project ${{ vars.TA_PROJECT }} --parallel 3 --json
  env:
    TESTERARMY_API_KEY: ${{ secrets.TESTERARMY_API_KEY }}
    TESTERARMY_TARGET_URL: ${{ steps.deploy.outputs.url }}

Wzorzec 5, subagent qa-runner w Claude Code

Subagent w .claude/agents/qa-runner.md z uprawnieniami Bash(ta:*) i Read(.testerarmy/**). Wybiera odpowiednią grupę po ścieżkach zmienionych plików, odpala ta tests run --group … --json --debug, parsuje result.json i zwraca głównemu agentowi tylko failure'y plus URL-e do zrzutów. Trzyma długie transkrypty QA poza głównym oknem kontekstu.

5. Gdzie TesterArmy stoi wobec alternatyw

Najbliższe porównywalne:

• Momentic: niemal identyczny pitch, web-only, większe finansowanie.
• QA.tech: cennik publiczny, brak jasnego wsparcia iOS/Android.
• Octomind: generuje kod Playwrighta (testy zostają u Ciebie), ma MCP.
• QA Wolf: ciężki produkt, AI plus wbudowany human QA.
• Reflect.run: record-and-play z AI, klasyczny kupujący QA.
• Meticulous.ai: nagrywa interakcje realnych użytkowników, bez promptów, web-only.
• Checkly: code-first synthetic monitoring, realny free tier, MCP do Claude'a i Cursora.

Część obronna: iOS, Android i web w jednym projekcie, AES-256-GCM dla credsów z per-agent inboxami OTP, „setki ewaluacji” tuningujących false positive'y.

Część cienka: prompt-to-browser-agent jest dziś standardem w branży, brak publicznego cennika, brak otwartego MCP servera, brak portable eksportu testów.

6. Werdykt i jeden blocker, który o wszystkim decyduje

Jeśli wysyłasz web plus natywne mobile, chcesz zespołu mówiącego po polsku i tolerujesz rozmowę handlową, TesterArmy jest realnie konkurencyjny. Jeśli jesteś solo indie devem od side-projektu SaaS, brak publicznego cennika i ograniczony free tier to twardy stop: weź Checkly albo Octomind.

Strukturalny blocker, który decyduje, czy TesterArmy pasuje do pętli vibecodingu:

Testy są definiowane w dashboardzie i identyfikowane przez ID. Nie istnieje ta run "verify checkout still works after my last change" na ad-hoc test napisany przez agenta. Agent może odpalać grupy, których ID zna, ale nie potrafi stworzyć i odpalić jednorazowego testu z naturalnego prompta scope'owanego do swojego diffu. POST /v1/runs przyjmuje prompt, ale CLI go nie wystawia.

Każdy z powyższych wzorców nadal wymaga człowieka, który najpierw napisał testy w dashboardzie. To rozbija najczystszą wersję obietnicy vibecodingu: agent pisze kod, agent pisze test, agent odpala test, agent naprawia, co się zepsuło. Dzień, w którym TesterArmy wyśle ta run --prompt "test the new flow at /checkout", równanie się odwraca.

Na teraz: zainstaluj GitHub Appkę dla pokrycia PR-ów bez konfiguracji, zainstaluj agent skill dla QA odpalanego slash commandem i traktuj testy z dashboardu jako tę część projektu, którą człowiek nadal musi rozpocząć.

Źródła: tester.army, docs.tester.army, npm: testerarmy, github.com/tester-army, YC: TesterArmy.