Vi intervjuet spilltester Robert Zalot om hans tid hos Epyx og i EAs QA-gruppe «GOD Squad».
Sommeren 1989 var Robert Zalot arbeidsledig og på jakt etter en jobb med noe som hadde med teknologi å gjøre. Da han gjennom en venn fikk tilbud om å «teste joysticker» for et hemmelig prosjekt i Redwood City, grep han sjansen. Da han ankom jobbintervjuet kjente han straks igjen stedet der den tidligere storutgiveren Epyx sine kontorer i Redwood Shores. Det han trodde ville bli monotont joystick-arbeid, viste seg å være testing av en gigantisk prototypeversjon av Atari Lynx.
Han ble ansatt dagen etter, og jobbet nattskift med å teste spill til Atari Lynx, der han hver morgen rapporterte nye bugs til programmererne. Senere sluttet han seg til EAs elite-QA-gruppe «GOD Squad», hvor han jobbet på tvers av konsoller med intern debugmaskinvare, regneark og penn og papir-logging, lenge før det fantes moderne feilrapporteringsverktøy.
Hvordan endte du opp med å teste videospill?
Det var sommeren 1989, og jeg og kameraten min hadde fri fra skolen. Begge var arbeidsledige og blakke. Han søkte jobber via byråer over hele Silicon Valley, fordi han hadde lært seg å programmere. Jeg hadde også søkt hos noen vikarbyråer, men uten hell. Jeg var interessert i datamaskiner, men så meg ikke som programmerer, så det var langt færre stillinger jeg kunne søke på. Men jeg ville gjøre noe innen teknologi. Til slutt fikk kameraten min en jobb som programmerer, men ett vikarbyrå fortsatte å ringe ham. De var desperate etter folk til å «teste joysticker». Han avslo fordi han allerede hadde jobb. Etter hvert ringte og spurte om han kjente noen andre som kunne være interessert. Han ga dem navnet mitt, og jeg ble ringt opp.
Rekruttereren sa at de prøvde å fylle stillinger for å teste joysticker i et topphemmelig prosjekt hos et hemmelig selskap i Redwood City. Han spurte også om jeg kunne jobbe nattskift… Det hørtes ut som det kom til å bli en kjedelig og monoton stilling der jeg brukte hele natten ved et samlebånd og trykket opp, ned, venstre, høyre, A, B og start. Men den var okay betalt (til å være på den tiden, om jeg husker riktig var det rundt $12,50 i timen!), så jeg sa meg interessert og ble invitert til intervju.
Merkverdig nok kjørte han meg dit. Det fikk det til å virke enda mer hemmelig. Jeg fikk ikke bare et tidspunkt og en adresse hvor jeg skulle møte opp, han fulgte meg fysisk dit. Jeg var litt nervøs, men hemmeligholdet gjorde det bare mer spennende. Vi kjørte til Epyx sine kontorer i Redwood Shores [tilfeldigvis de samme lokalene som senere ble til 3DO], og jeg kjente både firmanavn og logo igjen etter å ha kjent spillene deres. Ikke bare det, men som ung hadde jeg gravd gjennom søppelcontainerne deres for å få gratis spill! («dumpster diving»). Husk at dette var tiden rundt filmen Wargames, så dette var en greie da. Spesielt for de av oss som vokste opp midt i det hele.
Det var uansett en lettelse da vi kom til et kontorbygg, og ikke en fabrikk for joysticker, men jeg hadde fortsatt ingen anelse om hva jeg faktisk skulle gjøre der. Jeg ble intervjuet av testleder og en av programmererne. Enten var de virkelig desperate, eller så overbeviste jeg dem om at jeg forsto hva bugs var, for neste dag ringte rekruttereren og sa at jeg hadde fått jobben. Da jeg først møtte opp til jobb, var det bedre enn jeg kunne forestille meg: Jeg testet topphemmelige spillkonsoller, ikke joysticker!
De «topphemmelige joystickene» viste seg nemlig å være store prototypekort for Lynx håndholdt spillkonsoll (kodenavn «Handy») som Epyx utviklet, og som senere ble gitt ut av Atari. Disse tingene dekket hele skrivebordet! Det var eksponerte brikker og ledninger alle steder, et gigantisk kretskort med en liten skjerm og en NES-kontroller hengende foran som vi brukte. Alt var koblet til en Amiga (500 tror jeg?) og det hele virket veldig komplisert i starten.
Hvordan fungerte prosjektene og testingen den gangen?
Hos Epyx var teamene veldig små, men vi (testerne) hadde heller ikke mye kontakt med folk. Bare testlederen og et par programmerere om morgenen. Utviklingssystemene sto i et område med spesialtilgang i bygget, og du trengte riktig adgangskort for å komme inn. I tillegg jobbet vi midt på natta, så vi så nesten ingen andre folk. Jeg vet derfor egentlig ikke hvor store teamene var. Vi satt stort sett alene, som spøkelser i mørket.
Natteskiftet startet rundt midnatt. Da møtte vi testere opp og spilte hele natta. På den måten lå det ferske bugrapporter klare når programmererne kom inn rundt klokka 9–10 om morgenen. Det var voldsomt tidspress på alle prosjektene, så jeg fikk beskjed om at det var mer effektivt om vi forskjøv arbeidstidene våre. Dessuten fantes det bare et fåtall utviklingssystemer i hele verden på den tiden, så vi kunne ikke teste hvis en programmerer brukte maskinen. Alt handlet i bunn og grunn om logistikk.
Arbeidstidene var rare, men vi var bare en gjeng unger, så vi tok det med et skuldertrekk. Det ble mer utfordrende da skolen startet igjen på høsten. I et par måneder så dagsplanen min slik ut: teste spill hele natta, dra rett på skolen for å ha timer, så hjem for å gjøre lekser, ta en lur, og så starte alt på nytt! Gode tider.
Det fungerte likevel bra. Om morgenen møtte vi vanligvis programmereren på det aktuelle spillet, det var gjerne én utvikler per spill, og gikk gjennom bugs. Noen ganger måtte vi gjenskape dem på et utviklingssystem med all debugfunksjonalitet aktivert, og det kunne være stressende. Andre ganger var det bare å levere fra seg en liste med nye feil og hvilke som var bekreftet fikset kvelden før.
Et par år senere, hos EA, fikk jeg en mer «normal» arbeidstid. Der testet jeg på Genesis, SNES, PC, til og med 3DO da den kom. QA-teamet hos EA ble kalt GOD Squad, «Gold or Die», der «Gold» refererte til når et spill gikk «gold master», altså til endelig versjon. Vår jobb var å sørge for at spillene var fri for feil og kom seg gjennom konsollprodusentenes godkjenning uten problemer. Det var viktig. Når man ville gi ut et spill, måtte det sendes til Nintendo, Sega eller en annen konsollprodusent for testing. Hvis de fant feil og avviste spillet, var det i praksis vår feil, fordi vi ikke hadde funnet buggen først. Da ble lanseringen forsinket, fordi vi måtte rette feilen og sende inn på nytt.
Det var mye press, men vi følte også stort eierskap og jobbet tett med produsenter og ledere for å sikre høy standard. Målet for GOD Squad var at første versjon som ble sendt inn til godkjenning, skulle være den som ble godkjent. Og vi hadde en veldig god statistikk. Faktisk ble mange fra GOD Squad (meg selv inkludert) forfremmet videre til produksjonsroller.
Hos EA hadde vi også spennende maskinvare. Det finnes mange historier på nettet om hvordan EA dekonstruerte Sega Genesis, så jeg trenger ikke gå i detaljer her. Men resultatet var at vi fikk spesielle maskiner kalt SPROBES. Det var i praksis konsoller som ble bygget internt og gjorde at vi kunne spille spillene mens de var i utvikling. Genesis SPROBE er nok den mest kjente, men det fantes også SNES versjoner. De så ut som store aluminiumsbokser, Sega-versjonene var blå og SNES-versjonene røde, om jeg husker rett. Vi brukte også høye aluminiumskassetter drevet av batterier, som lot oss laste opp ROM-avbildninger direkte. Dermed slapp vi å brenne nye EPROM-brikker hver gang vi skulle teste en feilretting eller nye versjoner. Husk: dette var kassettdrevne konsoller!
Prosjektene ble ellers drevet ganske likt som i dag, bortsett fra at vi skrev ned feil på papir i stedet for å bruke Jira. Excel ble flittig brukt, for det fantes egentlig ikke andre alternativer. Vanligvis ble det utpekt en hovedtester fra GOD Squad for hvert spill, og denne personen samarbeidet med produsenten for å definere oppgavene. Hovedtesteren ledet de andre testerene, samlet og leverte bugrapporter, koordinerte nye versjoner tilbake til testteamet og fordelte regresjonstesting. Han eller hun var i praksis limet mellom produksjon og test.
Ble all testing gjort manuelt, eller brukte dere noe automatisering?
Den eneste automatiseringen var turboknappen på kontrolleren! Alt annet ble gjort for hånd, folk og «brute force». Det fantes noen videospillere hos EA, men ikke mange. Hvis du var heldig, hadde du en på pulten og kunne ta opp når du fant en bug. Som regel måtte du bare skrive ned det du så (med penn og papir) og gjøre ditt beste for å gjenskape feilen. Klarte du bare å fremprovosere den en gang, ble den nesten ugyldig, så man jobbet hardt for å finne en sikker måte å reprodusere den på. Det var nesten som å være detektiv: du måtte finne årsaken, og så bekrefte den ved å gjenskape feilen.
Hvis det var sent i testfasen og spillet snart skulle sendes til produksjon, ble det ofte veldig hektisk å lukke alle feil. Fikk du en alvorlig bug på det tidspunktet, kunne du bli satt i et programmererkontor med et debug-system og spille i timevis, til og med i flere dager, bare for å reprodusere feilen med dem som tilskuere. Ja, jobben var «å spille spill», men det kunne bety at du satt med samme parti av samme nivå i samme spill en hel uke, under press!
Men okay, det var fortsatt gøy.
Måtte dere følge en testplan/strategi, eller spilte dere bare?
Noen ganger fantes det fullstendig spilldesign som testplanen ble laget ut fra. Hvis ikke, gjorde vi vårt beste for å forstå hvordan spillet skulle fungere, slik at vi kunne oppdage når noe ikke fungerte. Spillene var enkle, men det kunne likevel bli diskusjoner, som regel om brukergrensesnitt og knappemapping. Testernes hemmelige våpen var å rapportere ting vi ikke likte som bugs. Ville du ha «hopp» på (A) i stedet for (X), kunne du sørge for at produsenten så det ved å skrive det opp som en feil. Heldigvis var de fleste produsentene og designerne åpne for å diskutere endringer.
Hva vi testet var avhengig av fasen spillet var i. Under utviklingen testet vi de nye funnksjonene, nivåene eller lignende i hver nye versjon vi fikk tilgang på. Da var alt fokuset på å sjekke at det som var nytt fungerte, og ikke ødela noe annet. I denne fasen brukte vi gjerne debugkommandoer som ga oss uendelig liv, ammunisjon eller nivåvalg, slik at vi kunne hoppe raskt mellom områder.
Senere, når spillet nærmet seg Gold Master, testet vi «release candidate»-versjoner. Det betydde at hvis vi ikke fant noen feil, ble den versjonen utgitt. Da var debugfunksjonene stort sett fjernet. Da var det bare oss mot spillet, og testingen ble langt vanskeligere. Planen var å teste alt som var rapportert som fikset siden sist versjon, samt sjekke viktige eller problematiske feil fra tidligere versjoner. Det kunne være ting som var vanskelige å fikse, eller situasjoner der programmererne ikke hadde full tillit til at de hadde klart det. Eller bare ting produsentene engstet seg over.
Vi kjørte også «massetesting», der vi fikk så mange folk som mulig til å spille samme versjon samtidig. Dette for å teste spillet så bredt som mulig, og i tillegg få «nye øyne» til å se over det. I tillegg brukte vi noe vi kalte «soak testing», der vi lot en ekstra konsoll stå og kjøre spillet i flere dager og så tittet innom av og til for å se om alt fungerte som det skulle. Noe så enkelt som å kjøre tittelsekvensen eller oppstartssekvensen, eller pause spillet spesifikke steder. Det hørtes kanskje meningsløst ut, men vi fant faktisk mange feil på den måten!
Hvis dere laget manuelle testcaser, hvordan fulgte dere opp fremdriften?
Fremdrift ble fulgt opp av produsenter og hovedtestere, for å sikre at hele spillet fikk riktig testdekning. I tillegg hadde vi regresjonstesting. Spillene var enkle nok til at man sjelden trengte detaljerte planer eller forberedelser. Men i tilfeller som med mye tall og statistikk, eller sportsspill som prøvde å «gjenskape» virkelige atleter, fikk vi ofte lister av verdier som måtte kontrolleres for å sikre at spillene fungerte slik de skulle.
Hvilke verktøy ble brukt til feilrapportering?
Bortsett fra den spesielle maskinvaren skrev vi bare ting ned på papir. Videospillere var nyttige, men sjeldne. Med tanke på programvare fantes det ikke noe spesifikt for testing, slik som i dag. Som hovedtester samlet jeg rapportene og førte dem inn i et regneark. Senere, som produsent, brukte vi hjemmelagde databaser, Filemaker eller interne systemer. Noen selskaper jeg jobbet for brukte faktisk Excel helt opp til 2005!
Den største utfordringen var å oppdage duplikatfeil. Det er fremdeles et problem i dag, men mye verre den gangen da alt ble gjort for hånd.
Har du noen spennende anektdoter helt på slutten?
Siden du har lagt inn et skjermbilde fra NHLPA Hockey, kom jeg på en liten historie. Det var en bug i det spillet hvor hvis du kom alene med keeper kunne du alltid score. Hvis jeg husker rett, trykket du venstre, høyre og venstre veldig kjapt før du skjøt ballen. Dette forvirret keeperen av en eller annen grunn, så skuddet gikk alltid inn.
Vi kalte denne manøveren «the Matulac», etter Steve Matulac som var GOD Squad-medlemmet som fant bugen. Han holdt den faktisk hemmelig i noen dager, fordi han brukte den til å slå alle på kontoret! Etter hvert ble den jo rapportert, og jeg er nokså sikker på at den ble fikset. Men jeg må kanskje starte opp en emulator for å dobbeltsjekke…
Vi takker Robert Zalot for at han tok seg tid til å svarte på alle spørsmålene våre!
Spillbildene er hentet fra Mobygames.