Testy przy każdym wdrożeniu i błędy, które zgłaszają się same
QA Spider testuje Twoją aplikację w prawdziwej przeglądarce i przez jej API, uruchamia zestaw przy każdym wdrożeniu i zgłasza każdą potwierdzoną regresję w trackerze, z którego już korzysta Twój zespół. Plan Enterprise: skontaktuj się z nami.
Co dostajesz
- Testy UI w prawdziwej przeglądarce
- Kontrole kontraktów REST i GraphQL
- Zgłoszenia błędów napisane na podstawie nieudanego uruchomienia: kroki, zrzut ekranu, waga. Sprawdzone pod kątem duplikatów, zgłaszane dopiero po Twojej akceptacji.
- Błędy zgłaszane do: Jira, ClickUp, GitHub Issues, Linear, Azure DevOps
- Alerty w: Slack, Discord, Telegram
- Triaż AI: niestabilny test czy prawdziwy błąd
- Przyczyna źródłowa z Twojego repozytorium, tylko do odczytu
- Waga
- P1
- Kroki
- Dodaj produkt, otwórz /checkout, użyj wygasłego kodu, zapłać kartą testową.
- Oczekiwano
- Kod zostaje odrzucony z komunikatem.
- Faktycznie
- Wyświetla się „Kod zastosowany” i pobierana jest pełna kwota.
- Zgłoszono do
- Jira, po akceptacji. Wysłano alert na Slack.
Droga błędu
Wdrożenie uruchamia zestaw testów. Nieudany test staje się zgłoszeniem błędu; po Twojej akceptacji trafia do trackera, a czat zespołu dostaje powiadomienie.
Po wdrożeniu uruchamiają się testy, jeden zawodzi, a jego zgłoszenie błędu trafia do trackera zespołu, podczas gdy wiadomość na Slacku ogłasza to zespołowi.
Uruchomienie się nie udaje
Przy każdym wdrożeniu, w prawdziwej przeglądarce i na Twoim API.
Triaż rozstrzyga
Niestabilny test, chwilowa awaria infrastruktury albo prawdziwy błąd produktu.
Zgłoszenie pisze się samo
Kroki z tego, co faktycznie się wykonało, zrzut ekranu, waga.
Akceptujesz
Trafia do trackera i na czat, nie wcześniej.
Bezpiecznie domyślnie
Kontrole tylko do odczytu działają na produkcji. Wszystko, co tworzy lub zmienia dane, działa wyłącznie na środowiskach dev lub staging. Zgłoszenie błędu i wpis na czacie czekają na Twoją akceptację. Nigdy nie ukrywamy prawdziwego błędu, by uruchomienie wyszło na zielono.
Także w planie Pro
Pro ($29/mo) zawiera 1000 kredytów testowych miesięcznie: uruchamianie wygenerowanych testów na żądanie, wybór testów, zapisywanie zestawów, generowanie testu z opisu i jego edycję wizualną. Harmonogramy, zgłaszanie do trackerów, alerty na czatach i triaż AI są w planie Enterprise.
Także Web3. Aplikacje dApp dostają takie samo traktowanie: pająk obsługuje przepływy z portfelami za pomocą emulowanych portfeli (połączenie, zmiana sieci, podpis, odrzucenie), wywołuje kontrakty w sieciach testowych i sprawdza, czy to, co pokazuje Twój interfejs, zgadza się z łańcuchem.
Pytania od zespołów
Czym to się różni od pisania testów samodzielnie?
Nic nie stoi na przeszkodzie. QA Spider pisze standardowy kod testów, który mógłby napisać Wasz zespół. Różnica polega na tym, kto wykonuje pracę: on przygotowuje testy, uruchamia je przy każdym wdrożeniu, naprawia lokatory, gdy zmienia się UI, i zgłasza błędy. Wasi inżynierowie przeglądają wyniki.
Czy zasypie nam tracker?
Nie. Każda awaria przechodzi najpierw triaż: niestabilne testy są naprawiane, chwilowe problemy infrastruktury ponawiane, a zadaniami stają się tylko potwierdzone błędy produktu. Zgłoszenie wymaga Waszej zgody, a każde zadanie jest sprawdzane pod kątem duplikatów.
Co się dzieje, gdy zmienia się nasz UI?
Jeśli lokator przestał działać po zmianie wyglądu, pająk naprawia test i odnotowuje to. Jeśli zachowanie uległo regresji, zgłasza błąd zamiast po cichu poprawiać test, żeby był zielony.
Jak radzicie sobie z logowaniem, płatnościami i danymi testowymi?
Dajecie pająkowi konta testowe na staging. Loguje się, płaci kartami testowymi i wysyła formularze na stagingu. Ścieżki modyfikujące dane działają tylko na dev i staging; produkcja dostaje kontrole tylko do odczytu.
Czy potrzebujecie naszego kodu źródłowego?
Nie do testów: pająk testuje aplikację tak, jak spotyka ją użytkownik. Opcjonalnie można podłączyć repozytorium tylko do odczytu, dzięki czemu awaria wskazuje plik i commit, który za nią stoi.
Czy bezpiecznie uruchamiać to na produkcji?
Przebiegi na produkcji ograniczają się do kontroli smoke tylko do odczytu. Wszystko, co tworzy, edytuje lub usuwa dane, jest oznaczone jako modyfikujące i działa wyłącznie na dev lub staging.