Misja
Dostarczać małym zespołom materiał QA, który można od razu zamienić w decyzję produkcyjną: poprawić, odłożyć, zaakceptować albo zbadać głębiej.
Zewnętrzne QA / Warszawa
Błąd jest użyteczny, gdy ktoś potrafi go powtórzyć.
Stan Powtórzony prowadzi niezależne testy funkcjonalne i moderowane playtesty dla producentów gier bez własnego działu QA albo potrzebujących dodatkowego pokrycia przed ważnym wydaniem.
Nie przekazujemy surowej listy uwag. Każde zgłoszenie opisuje warunki, kroki reprodukcji, rzeczywisty i oczekiwany wynik, częstotliwość oraz materiał potrzebny zespołowi do decyzji.
Dlaczego działamy
Oddzielamy problem produktu od pojedynczej opinii.
Wizja
Testy traktowane jako część projektowania, a nie kontrola uruchamiana dopiero przed premierą. Ryzyko powinno być widoczne wtedy, gdy zmiana jest jeszcze możliwa.
Zgłoszenie prowadzi od stanu do skutku.
Pracujemy na uzgodnionej wersji i środowisku. Numer buildu, platforma, konto, konfiguracja oraz plik zapisu pozostają przy zgłoszeniu, dzięki czemu poprawkę można później sprawdzić w tych samych warunkach.
Warunek
Build, platforma, urządzenia, konto i stan zapisu.
Kroki
Najkrótsza potwierdzona droga bez interpretowania intencji.
Wynik
Różnica między zachowaniem obserwowanym i oczekiwanym.
Dowód
Wideo, log, zrzut, plik zapisu albo dane wydajności.
Reprodukcja
Zmniejszamy problem, zanim zwiększymy priorytet.
Zmieniamy jeden warunek naraz, skracamy sekwencję i sprawdzamy częstotliwość. Jeżeli błąd znika, zapisujemy również nieudane próby — informacja o tym, kiedy problem nie występuje, często prowadzi szybciej do przyczyny.
Priorytet ustalamy według wpływu na gracza, możliwości obejścia, ryzyka utraty danych i zakresu dotkniętej funkcji. Nie podnosimy go wyłącznie dlatego, że problem wygląda źle na nagraniu.
Testy funkcjonalne
Postęp, zapisy, ekonomia, ekwipunek, zadania i stany po ponownym uruchomieniu. Zakres budujemy z aktualnego ryzyka produktu.
Kompatybilność i regresja
Urządzenia wejścia, proporcje ekranu, konfiguracje sprzętowe oraz ponowne sprawdzenie obszarów zmienionych przez poprawkę.
Sieć i sesje
Dołączanie, utrata połączenia, migracja hosta, role graczy i zachowanie po powrocie. Zapisujemy perspektywę każdego uczestnika.
Moderowane playtesty
Obserwujemy zachowanie, zanim poprosimy o ocenę.
Scenariusz opisuje zadanie, ale nie podpowiada rozwiązania. Moderator notuje moment zawahania, błędny model działania, przeoczoną informację i sposób odzyskania kontroli.
Po sesji oddzielamy obserwacje powtarzalne od preferencji pojedynczych osób. Raport nie udaje badań reprezentatywnych, jeżeli próba była mała.
Jak wygląda tydzień współpracy
- Poniedziałek: przyjęcie buildu, smoke test i potwierdzenie zakresu.
- Wtorek–czwartek: testy, triage oraz krótkie pytania do właścicieli funkcji.
- Piątek: regresja uzgodnionych poprawek, raport pokrycia i ryzyka na następną wersję.
Zespół klienta zachowuje własny tracker. Możemy pracować w Jira, Linear, YouTrack, GitHub Issues albo przygotować eksport zgodny z ustalonym schematem.
Pakiet po rundzie
- lista zweryfikowanych problemów z priorytetem i właścicielem decyzji;
- materiał potrzebny do reprodukcji oraz środowisko testowe;
- osobny zapis obserwacji użyteczności i pytań projektowych;
- obszary bez wystarczającego pokrycia oraz powód ograniczenia;
- krótkie podsumowanie ryzyk dla następnego buildu.
Przyjęcie buildu
Powiedz, jaką decyzję ma wesprzeć runda testów.
Podaj platformę, dostępny termin, sposób dystrybucji buildu i obszary o najwyższym ryzyku. Przed startem potwierdzimy zakres, środowisko, częstotliwość raportów i zasady dostępu do materiałów.
Warszawa, Polskaqa@sozoxukoxxy.com
+48 22 307 24 19