Iteracyjny Q/A

Testowanie gry, oraz jej poszczególnych podsystemów jest bardzo ważnym etapem całej produkcji. Pozwala wychwycić błędy, które w przyszłości mogłyby negatywnie odbić się na odbiorze projektu przez społeczeństwo lub, w krytycznych sytuacjach, całkowicie przekreślić szansę na sprzedażowy i marketingowy sukces. Ponadto, warto dodać, że zaangażowanie zespołu w Q/A, ale i nie tylko jego, sprawi, że każdy będzie aktualny z tym co dzieje się w projekcie, szczególnie jeżeli w skład Twojego projektu wchodzi więcej niż 20 osób.

Kilka lat temu brałem udział w bardzo ciekawym projekcie, którego nazwa brzmiała Drakland: Tales. Był to projekt gry RTS tworzonej przez, w szczytowym momencie, 20 osób. Niestety, buildy gry (wersje, które można pobrać, uruchomić i w nie zagrać) powstawały raz na jakiś czas, w nieregularnych odstępach. Sprawiało to, że nie wszyscy mogli na bieżąco oglądać jak ich praca (np. Modele 3D) pojawia się w grach, przez co często tracili początkową motywację lub nie wiedzieli, że dany Feature w grze jest już od jakiegoś czasu.

Dążę do tego, że dobrze rozplanowany Q/A nie spełnia tylko i wyłącznie zapotrzebowania na dobry stan techniczny gry. Jeśli będziemy sprytni, możemy zyskać dodatkową porcję motywacji wśród współpracowników oraz, co ważniejsze, ustalić terminy. Tak, dobrze napisałem – w tym przypadku, terminy będą naszym sojusznikiem, szczególnie jeśli nad projektem pracujesz po godzinach.

Wypuszczanie builda iteracyjnie, czyli w równych odstępach czasu ma swoje następujące zalety:

a) Wszyscy są na bieżąco z tym, co powstaje i pojawia się w produkcji. Tworzenie tzw. Changelogów, czyli list zmian, sprawi, że programiści będą mieli bardziej ustystematyzowaną wiedzę na temat tego, co jeszcze należy zrobić i poprawić, a osoby testujące (lub/i współpracownicy) co zostało już naprawione a na co należy zwrócić szczególną uwagę.

b) Gra staje się sprawniejsza. Iteracyjny Q/A daje nam konkretny odcinek czasu na przetestowanie konkretnych pozycji, a następnie naprawienie uprzednio zgłoszonych błędów i następnie zweryfikowanie ich przez osoby w testach biorące udział. W związku z tym punktem, przygotowałem poniższą grafikę, aby zobrazować ten schemat:

QA

c) Terminy sprawiają, że otrzymujesz konkretne zadania do zrobienia i w łatwy sposób możesz zmierzyć własną wydajność. Dzięki temu, po kilku Buildach, będziesz dokładnie wiedział ile jesteś w stanie zrobić w danym odcinku czasu. Przykładowo: mówisz, że w Build’zie 0.5.8 musisz dodać system X oraz Y i Z. Okazuje się, dzień przed terminem, że nie dałeś rady zrobić Z. Wiesz już wtedy, że ten Features musisz przenieść na następny termin, do kolejnej iteracji.

Taki system zastosowaliśmy właśnie przy projekcie Phantaruk, gdzie co tydzień wypuszczamy Build oznaczony następnym numerkiem. Dziś chociażby, wrzucamy oznaczony numerkiem 0.0.2 zawierający poprawki z poprzedniego tygodnia. Ludzie, którzy mają dostęp do wczesnej wersji gry, będą mogli go pobrać oraz testować przez następny tydzień. Dzięki takiemu rozwiązaniu, możemy sprawdzać nawet najmniejsze mechaniki, jakie zawieramy w grze.

Czy Waszym zdaniem iteracyjne testy są dobrym pomysłem? A może macie jakieś inne rozwiązania?

Reklamy

Posted on 2014/01/25, in Inne and tagged , , , , , . Bookmark the permalink. Dodaj komentarz.

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj / Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj / Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj / Zmień )

Connecting to %s

%d blogerów lubi to: