Redakcja
Gracze kontra scenariusze testowe
InZOI, nowy symulator życia od Krafton, miał być godnym rywalem dla The Sims. Sprzedał milion kopii w tydzień od premiery wczesnego dostępu, co już samo w sobie jest imponującym osiągnięciem. Ale wraz z sukcesem przyszły problemy, których nikt się nie spodziewał.
Najpierw Internet obiegła informacja, że w grze można potrącać dzieci. Zanim zdążono załatać ten bug, gracze odkryli kolejną możliwość: "kradzież" niemowląt z domów innych postaci oraz "porywanie" dzieci wracających ze szkoły. Z technicznego punktu widzenia to klasyczny przypadek nieprzewidzianej interakcji między systemami. Z punktu widzenia PR-u to czysty koszmar. A dla testerów, to kolejna ciekawa lekcja.
Dlaczego pewnych scenariuszy nie ma w testach
Problem z testowaniem symulatorów polega na tym, że liczba możliwych kombinacji rośnie wykładniczo. Jeśli postać może wykonać 10 akcji na 10 obiektach, to mamy już 100 kombinacji do przetestowania. A co, jeśli tych akcji jest 100, obiektów 1000? Albo jeśli dodamy do tego zmienne środowiskowe?
InZOI pokazuje nam, że w testowaniu współczesnych gier klasyczne przypadki testowe nie wystarczają. Żaden rozsądny tester nie napisałby scenariusza "Sprawdź, czy można porwać dziecko wracające ze szkoły". A jednak to właśnie takie scenariusze realizują gracze.
Gracze jako nieformalny dział testerski
Wczesny dostęp do gier stał się formą masowego testowania, rozszerzając je o kreatywność tysięcy graczy. To oni, kierowani ciekawością i chęcią eksploracji, znajdują rzeczy, których nie przewidział żaden projektant. Taki model ma jednak swoje zagrożenia. Negatywne informacje płynące od graczy z wstępnym dostępem mogą zniechęcić do innych do zakupu. Z naszej, testerskiej perspektywy wydaje się też nieetyczne, że za pracę testerską ci gracze-testerzy muszą jeszcze płacić.
Krafton zapewne nie planował, by ich gra pozwalała na porywanie dzieci, podobnie jak wcześniej nie zamierzali umożliwiać ich potrącania. Szybka reakcja developerów (łatanie defektów i wydawanie stosownych oświadczeń) pokazuje, że firma traktuje te problemy poważnie.
Ale pytanie brzmi: czy mogli przewidzieć te problemy wcześniej? I co to mówi o naszej pracy?
Testowanie poza schematem
Historia InZOI przypomina nam o kilku rzeczach, które testerzy powinni mieć w głowie.
Po pierwsze: najbardziej problematyczne bugi często znajdują się na styku różnych systemów. Mechanika jazdy + mechanika interakcji społecznych = możliwość potrącenia/porwania dziecka.
Po drugie: kontekst kulturowy ma znaczenie. Ten sam bug w jednej grze może być zabawną ciekawostką, a w innej może stać się katastrofą wizerunkową.
Po trzecie: potrzebujemy w zespołach ludzi, którzy myślą nietypowo. Ktoś, kto zada pytanie „A co jeśli spróbuję ukraść dziecko innemu Zoi?”, zanim zrobi to tysiąc graczy, jest na wagę złota.
Czego nauczył nas przypadek InZOI?
Przypadek InZOI to ostrzeżenie dla branży testerskiej. Przypomina nam, że testowanie to nie tylko wykonywanie zaplanowanych scenariuszy, ale również twórcze myślenie o tym, co może pójść nie tak.
Warto przy planowaniu testów zadać sobie pytanie: „Jaki najbardziej szalony, nieprawdopodobny i potencjalnie problematyczny scenariusz może wymyślić użytkownik?”. A potem… przetestować go. Bo jeśli historia gier nas czegoś nauczyła, to tego, że jeśli coś da się nadużyć, to gracze z pewnością to znajdą. Nawet jeśli tym czymś jest możliwość porwania wirtualnego dziecka.
Tymczasem, InZOI będzie dalej łatać swoje defekty, a my będziemy obserwować z zawodową ciekawością. Bo czy jest lepszy sposób nauki niż ta dziejąca się na cudzych błędach?
Zwłaszcza gdy te błędy pozwalają graczom porywać wirtualne dzieci.
