Around the Verse: Spaccare il Gioco

I ragazzi del QA ci spiegano come spaccano Star Citizen in questo Around the Verse loro dedicato!

AGGIORNAMENTO DAGLI STUDI – FOUNDRY 42 DE

·        Dipartimento VFX

o   Lavorano fianco a fianco con gli ingegneri per definire la tecnologia/gli strumenti necessari per i pianeti procedurali.

o   Hanno effettuato dei progressi sulle configurazioni manuali richieste per generare gli effetti nel motore di gioco.

·        Dipartimento delle Cinematiche

o   Un nuovo designer si è unito al team.

o   Stanno riguardando le scene di performance capture relative ai vari capitoli di SQ42.

o   Stanno lavorando a tutte le scene della storia ambientate all’interno della struttura Shubin per finalizzarle.

o   Stanno editando le grandi sequenze relative all’inizio ed alla porzione centrale del gioco.

·        Dipartimento Artistico degli Ambienti

o   Stanno definendo vari elementi procedurali del terreno di Delamar e stanno risolvendo diverse sfide.

o   Hanno apportate alcune modifiche all’esterno di Levski: hanno integrato i garage per i veicoli di superficie.

o   Hanno aggiunto la struttura mineraria dentro ed attorno alla cava di trivellazione in maniera più efficiente, oltre ad effettuare un passaggio di rifinitura.

o   Hanno apportato alcuni tocchi finali alle lune per renderle più distintive le une dalle altre.

·        Dipartimento di Design dei Livelli

o   È stato terminato il passaggio di design degli avamposti di superficie, che sono stati inviati al team Artistico.

o   È iniziato il lavoro di integrazione di Levski nella versione procedurale di Delamar: lobby, airlock, garage, strade ed aree di parcheggio per mezzi terrestri.

o   È stata pianificata la rete degli ascensori, le aree di lavoro e sono stati aggiunti gli uffici amministrativi.

·        Dipartimento Artistico Tecnico

o   Sono stati effettuati dei lavori di R&D sul sistema di movimento a piedi per fornire ai personaggi una vera sensazione di peso a tutte le velocità ed a tutti gli angoli di spostamento.

o   Si sono occupati dei compiti di texturing per ampliare le possibilità di personalizzazione dei personaggi.

o   Hanno lavorato con il team delle Armi sugli strumenti necessari per individuare gli errori nello sviluppo, per l’aggiornamento e per la preparazione delle armi.

·        Dipartimento di Design di Sistema

o   Sono stati fatti progressi con il sistema di Stato Attore: hanno incorporato la respirazione, la stamina, le forze-G, le ferite, ecc.

o   Hanno aggiunto i sottosistemi per i danni e le riparazioni alle tute, nonché per la ricarica delle riserve di ossigeno.

o   Hanno iniziato la produzione in massa degli oggetti utilizzabili.

o   Questi andranno a collegarsi al Sistema Oggetti 2.0, che avrà un’enorme flessibilità e permetterà di replicare i comportamenti nel mondo reale, cose come sostituire gli oggetti rotti, aprire dei pannelli per accedere ai componenti delle navi, ecc.

o   Stanno finalizzando il design dell’integrazione Spectrum-Gioco per abilitare l’accesso in-game alle funzionalità dello Spectrum, cose come la creazione delle chat, la gestione delle liste amici, delle org e via dicendo.

·        Dipartimento di QA

o   Sono iniziati i test del livello del PU del nuovo sistema Stanton.

o   Stanno sistemando e testando internamente lo strumento “Catapult” per il lancio dei server.

o   Hanno effettuato un primo giro di test sul nuovo sistema di conversazione dell’Editor della Sussunzione.

o   Stanno collaborando con i designer di Sistema per creare il livello di test delle funzionalità base dell’IA ed aggiungere i comportamenti a tutti gli NPC.

o   Hanno aggiunto dei nuovi casi di test dei VFX ed una lista di controllo per l’Editor delle Particelle.

·        Dipartimento di Illuminazione

o   Sono concentrati sul supportare il rilascio della 3.0 con Cellin, Yela e Daymar.

o   Hanno definito il livello di qualità visiva richiesto per gli avamposti di superficie della 3.0.

o   Stanno implementando un nuovo sistema di Gruppi Luce: le luci degli avamposti terrestri reagiranno alle condizioni di alimentazione, alle situazioni di emergenza, pericolo, ecc.

·        Dipartimento dell’IA

o   Un nuovo sviluppatore si è unito al team.

o   Hanno rifattorizzato il sistema di movimento nelle navi per unificare la struttura di movimento tra NPC e navi.

o   Hanno apportato dei miglioramenti generali alla capacità di navigazione e di tracciamento del percorso dell’IA: hanno risolto i problemi riguardanti certe configurazioni degli angoli.

o   Si stanno concentrando su due capitoli di SQ42 per espandere le funzionalità esistenti ed aggiungerne di nuove.

o   Il Visualizzatore della Sussunzione adesso permetterà di sovrascrivere le missioni iniziali di un livello per le necessità di test.

o   Hanno aggiunto le “piattaforme” (uno schema dei Contenitori Oggetti con una lista di elementi) per il sistema delle Missioni.

o   Queste piattaforme potranno essere modificate e personalizzate in varie configurazioni, e costituiranno uno schema di supporto per realizzare varie possibilità e logiche di gioco.

o   Ad esempio, una di queste piattaforme potrebbe essere una Idris caduta in mano di pirati, mentre un’altra leggermente differente potrebbe essere una Idris regolarmente utilizzata dalla UEE.

·        Dipartimento delle Armi

o   Hanno abbozzato delle nuove armi: 2 Vanduul, 4 Kastak Arms, 3 Gemini ed 1 K-Hex.

o   Hanno completato il primo passaggio sul cannone balistico della Knightbidge Arms attraverso la nuova catena di sviluppo modulare.

o   Nel tempo libero, hanno assistito il team degli UK nella realizzazione di vari oggetti scenici.

·        Dipartimento del Motore

o   Hanno continuato a lavorare sullo streaming dei Contenitori Oggetti e su SolEd.

o   Hanno effettuato la manutenzione del codice esistente per ridurre di alcuni minuti i tempi di compilazione.

o   Hanno migliorato ulteriormente la tecnologia planetaria procedurale: il blending (terreno, oggetti dispersi) e il blending in dissolvenza.

CONTROLLO QUALITA’

TLDR

·        Il team di QA testa tutte le tecnologie che vengono implementate nelle build.

·        Il loro compito è di trovare i problemi e scrivere delle guide dettagliate su come riprodurli.

·        Il QA va a toccare praticamente ogni ambito del gioco e si deve occupare di un po’ tutto quello che lo riguarda, in quanto gli sviluppatori/i designer si occupano per la maggior parte delle basi.

·        Il Consiglio di Discussione è molto importante per il QA, dal momento che i giocatori spesso si imbattono in problemi semplicemente giocando e, solitamente, sono problemi che il QA o non ha riscontrato, o non ha pensato che potessero accadere.

·        Sia Chris che Erin Roberts hanno enfatizzato quanto sia importante il dipartimento di QA nella realizzazione e sviluppo del gioco.

Trascrizione Completa

Justin Binford (JB): Sono Justin Binford, Direttore del QA.

Chris Eckersley (CE): Sono il Tester Tecnico Senior di Foundry 42, UK.

Michael Dalston (MD): Sono il tester Capo QA Live qui a Wilmslow, Foundry 42.

Michael Blackard (MB): Sono tester Specialista del Controllo Qualità.

Don Allen (DA): Sono Specialista QA e la mia specialità è il Sistema Planetario.

Wayne Owen (WO): Sono Specialista QA dei Controlli a Foundry 42.

James Stevens (JS): Sono Tester Senior.

Andrew Hernando (AH): Sono Tester QA negli studi di LA.

Mici Oliver (MO): Sono Specialista QA Artistico dei Personaggi.

Glen Kneale (GK): Inizialmente ero Capo QA negli uffici UK, ora risiedo qui nella soleggiata Francoforte.

Colby Schneider (CS): Specialista QA.

Brandon Crocker (BC); Sono Specialista QA delle Navi.

Vincent Sinatra (VS): Sono Manager QA qui a Los Angeles.

Melissa Estrada (ME): Capo Tecnico del QA qui negli uffici di Francoforte.

Scott McCrea (SM): Specialista del QA per lo FPS Star Marine, distruttore di mondi.

MD: Spesso la gente dice: “Oh, QA consiste soltanto nello stare seduti a giocare ai videogame, giusto?”, e per certi versi è così, ma il nostro compito non consiste nel giocare. Il nostro compito consiste nel rompere il gioco.

SM: La mia giornata è fantastica, vengo al lavoro e gioco a Star Marine per tutto il tempo. Non posso lamentarmi. Sostanzialmente arrivo a lavoro, lancio Star Marine e cerco di spaccare roba per tutto il giorno. È divertente.

GK: Io testo la tecnologia che verrà implementate nelle nostre build per assicurarmi che non rompa nulla di quello che già c’è nel gioco.

AH: L’aspetto che preferisco del mio lavoro è, sostanzialmente, avere l’opportunità di rompere roba e far incavolare la gente per questo, ma è piuttosto divertente perché poi dicono: “Non avrei mai pensato di provare a romperlo in quel modo” e tu puoi rispondere: “Beh, io ci sono riuscito”.

JB: Nel QA sicuramente lavoriamo cercando di rompere tutte le funzionalità che abbiamo, così da poter dire poi agli sviluppatori cosa abbiamo esattamente rotto e come, nonché cosa potrebbe essere fatto per migliorare questo o quello.

GK: Il nostro obiettivo è di rompere tutto, già.

MK: Ok, questa è una nave nuova di zecca che ci è appena arrivata. Come la rompiamo? Cosa dobbiamo fare per non farla funzionare? Come mostriamo agli sviluppatori quali sono i punti in cui, forse, c’è bisogno di altro lavoro? Voglio dire, al momento stiamo lavorando su una nuova nave, non posso dire quale, ed è inutile ricordare che all’inizio era qualcosa di mediocre, è una parola che usiamo all’interno del dipartimento di QA, ma nell’arco di una settimana, da mediocre è diventa passabile, fino a diventare bellissima e lucente, pronta ad essere rilasciata. Andiamo ad ammazzare qualche idiota.

VS: Non è la stessa cosa che giocare tutto il giorno, no.

SM: Dopo aver rotto i giochi altrui, sostanzialmente scrivo una guida passo passo su come io abbia esattamente fatto e cosa sia successo. A volte conosco i meccanismi sottostanti, perché certe cosa succedano, ma la mia opinione sul perché certe cose stiano accadendo non è un elemento che vada necessariamente inserito nella descrizione del bug. Soltanto come accade.

JB: Il QA è un po’ il punto di unione tra lo sviluppo e la messa in pratica di quanto creato, per cui abbraccia un po’ tutte le discipline ed è compito del QA assicurarsi che tutto funzioni bene e che la magia avvenga, tanto per dire.

WO: Quando troviamo dei problemi, dobbiamo riprodurli per identificarne la causa.

VS: Dobbiamo toccare praticamente ogni disciplina, che si tratti di lavorare all’editor, su Squadron 42, Star Marine, l’Arena Commander o l’Universo Persistente. Dobbiamo essere capaci su praticamente tutto, perché i nostri sviluppatori e designer locali coprono principalmente le basi.

GK: Quello che facciamo è piuttosto importante, perché impedisce che accada qualcosa di catastrofico alle build, qualcosa che non solo potrebbe influenzare i test, ma anche gli sviluppatori al lavoro sullo stesso ambito.

MO: Il mio lavoro è davvero entusiasmante, perché ogni giorno ho modo di fare qualcosa di diverso. Ho l’opportunità di usare l’editor ed il mio photoshop, nonché di lavorare con gli elementi di gioco. Ho modo di occuparmi di cose riguardanti Squadron 42 e di imparare davvero tanti sui personaggi e sulla loro storia.

AH: Ci occupiamo delle richieste specifiche degli sviluppatori per testare le loro nuove modifiche o funzionalità man mano che arrivano, nonché le correzioni.

JS: Solitamente, quando arriviamo sul posto di lavoro troviamo sempre una nuova build che ci sta aspettando e di cui dobbiamo effettuare quello che chiamiamo il controllo dell’integrità. Si tratta di un test che ci permette di passare rapidamente in rassegna ciascuna delle sezioni dell’editor e vedere cosa funziona. Successivamente possiamo inviare una lista di ciò che è rotto e di quello che non lo è direttamente ai designer.

WO: Io mi occupo dei controlli, che costituiscono un’area di specializzazione piuttosto vasta, dal momento che lo schema di controllo è davvero, davvero grande. Probabilmente ci sono oltre 120 differenti mappature di tasti tra tutte le varie aree, è un compito abbastanza arduo, ma comunque divertente e molto interessante.

MD: Io mi occupo della telecamera spettatore, le note di aggiornamento, alcune scritte tecniche e la formazione.

VS: Io ho l’opportunità di far volare ed esplodere le astronavi. Ogniqualvolta qualcuno ha bisogno di far volare un’astronave, viene da me e questo mi fa sentire bene.

CE: Due strumenti in particolare che testiamo di continuo sono l’Editor degli Equipaggiamenti e l’Editor Planetario, che sono estremamente divertenti da usare e testare. È stato fantastico vedere tutto il lavoro svolto sui pianeti procedurali, ma lo è ancora di più essere in grado di andare nell’editor, lanciare lo strumento e creare dal nulla il nostro pianeta di QA, mettere le montagne, le valli, i deserti e via dicendo. Usarlo durante i test è molto divertente, perché chi non vorrebbe vedere Gary Oldman portare una mop ed un fucile allo stesso tempo.

JB: Quando ci avviciniamo ad una data di rilascio, iniziamo con una build piuttosto instabile e buggata. E partendo da qui, effettuiamo iterativamente una serie di test e riferiamo alla produzione ed ai responsabili i principali problemi che abbiamo riscontrato, così che possano iniziare a stabilizzare la build e renderla funzionale ad un livello base.

CS: Sostanzialmente, quando riceviamo una nuova build dobbiamo compilare una lista di controllo di flusso, chiunque sia disponibile, mentre nei casi in cui qualcuno sia impegnato su altri aspetti specifici, dobbiamo prenderci in carico anche la loro sezione.

VS: Metà delle volte applichiamo qualche fix e dobbiamo sviluppare il nostro stesso codice. Già, ci sono tanti aspetti che ricadono all’esterno dei normali compiti di QA. Per cui si prende la loro lista delle modifiche e si compila una nuova build contenente soltanto quel determinato pezzo di codice, così da poter verificare se ci sia qualche grosso problema prima di inviarla ad uno dei rami principali, cosa che potrebbe influenzare negativamente la capacità degli sviluppatori di fare il loro lavoro.

WO: Successivamente facciamo un test di gioco. Tutto questo coinvolge la maggior parte del team di QA negli UK, a volte dobbiamo collaborare con i nostri colleghi negli US e prendere parte ai grandi test multiplayer. Spesso dobbiamo controllare elementi specifici che, solitamente, vanno ben oltre le mansioni di un tester QA medio, me incluso. Credo che il test di oggi riguardi le variabili serializzate, per cui sarebbe magnifico se qualcuno lì fuori sapesse di cosa si tratta. Solitamente i test di gioco durano un’ora o due e verso la fine della giornata mi reco nella mia area di specializzazione e verifico nuovamente se ci siano dei nuovi problemi con i controlli. Di solito raccolgo dai test di gioco i feedback riguardanti i controlli per assicurarmi che non ce ne siano di nuovi, per poi vedere se c’è qualche nuovo designer o altra gente con cui devo andare a parlare. Ci sono letteralmente centinaia di bug che vengono prodotti ogni giorno e tra di essi ci sono alcune chicche, o roba da incubo. Per cui in generale è sempre tutto molto divertente.

AH: Il bug più divertente che io abbia mai trovato in Star Citizen è ancora quello delle navi che spawnavano con l’IA che cadeva fuori dalla nave. Sostanzialmente compariva la nave e, tutto d’un tratto, l’IA andava sotto… Attraversava la nave e cadeva giù, mentre l’astronave iniziava a volare senza l’IA e sembrava che si controllasse da sola, in autopilota.

SM: Il bug che ho riscontrato più di recente è probabilmente quello che riguardava Star Marine: se entravo in ADS, che vuol dire guardare attraverso il mirino dell’arma, e poi cercavo di prendere un’altra arma, la telecamera partiva in modalità quantistica e finiva ad anni luce dalla mia posizione; sostanzialmente era una sorta di esperienza extra corporale che si è rivelata essere davvero fantastica, con una percentuale di riproduzione del 100%. Tutti potevano riprodurla, ma nessuno l’aveva scoperta prima.

MB: Ce ne era uno che causava una rotazione incontrollata del personaggio dopo la sua morte, ma se lo facevi nella maniera giusta, la telecamera zoomava all’indietro e potevi vedere l’intero pianeta della mappa Luna Spezzata, potevi vedere la gente che combatteva come se fossero delle micromachine e tutta un’altra serie di piccole cose. E potevi capire che il pianeta in realtà c’era, ma non era visibili da quella visuale: è stato davvero strano, ma anche tanto figo. Mi è piaciuto da pazzi.

MD: Quando arrivano dei nuovi incarichi, solitamente questi vengono divisi tra i vari ambiti, per cui ci può arrivare roba riguardante Star Marine, il combattimento FPS. Oppure le navi, l’Universo Persistente, le armi, gli scudi, o le centinaia di migliaia di piccoli elementi differenti che sono ovviamente presenti in Star Citizen.

CE: Fortunatamente ad Austin, in Texas, abbiamo un ottimo dipartimento devops. Grazie alla differenza di fuso orario, loro solitamente sono in grado di coprire la maggior parte delle ore in cui noi non siamo al lavoro, mentre quando attacchiamo noi, loro solitamente stanno staccando e ci inviano dei messaggi stanchi o aggiornamenti riguardanti tutto quello che hanno fatto e tutto ciò che richiede di essere ricontrollato o su cui bisogna continuare a lavorare.

VS: Durante la mattina scambiamo informazioni con i team Inglesi e Tedeschi.

CE: Lavoriamo a stretto contatto con il dipartimento di QA di Francoforte. Loro sono quasi completamente specializzati nei test relativi al motore ed all’editor, ma tra di noi c’è un ottimo scambio di comunicazioni e conoscenze.

ME: La cosa interessante di questa collaborazione con il team del motore è che, quando troviamo dei problemi, solitamente possiamo notificarglieli al volo, chiamarli direttamente e dire: “Hey, ho trovato questo problema, penso che potrebbe riguardarvi. Volete dargli un’occhiata adesso?”. E se possono dargli un’occhiata, possono anche approntare una correzione. È tutto un enorme processo iterativo che continua fino a quando non riusciamo ad ottenere un set di build che funzioni abbastanza bene: niente crash e niente strani problemi che potrebbero essere legati alle modifiche che gli sviluppatori hanno apportato alle build.

CS: Qui in LA lavoriamo a stretto contatto con gli sviluppatori, per cui quando ci sono delle richieste di test specifiche, siamo qui per occuparci immediatamente di esse e loro possono realizzare le correzioni del caso, per cui il ritmo lavorativo può procedere ad alta velocità e con un ottimo livello qualitativo.

MD: 24 ore al giorno, sette giorni la settimana, lo sviluppo offre sempre nuove sfide al QA, questo perché ovviamente vengono sempre realizzate tante modifiche. Qualcosa potrebbe cambiare di qui ad un’ora, tra mezza giornata, una giornata o una settimana, e queste modifiche potrebbero provenire da LA, dagli UK o dalla Germania, semplicemente non lo possiamo sapere.

Ci sono un po’ ovunque sviluppatori che modificano tanti piccoli bit, ma tuttavia siamo supportati da tre altri meravigliosi team: quello di Francoforte, in Germania, quello di Austin, in Texas, ed uno in LA. Di giorno in giorno ci passiamo la roba l’un l’altro.

ME: E lo hanno fatto anche la scorsa notte, beh, per noi era la scorsa notte, per loro era pomeriggio.

JB: Per cui le cose non sono compartimentalizzate o limitate agli uffici locali e noi possiamo continuare ad effettuare i test grazie agli altri dipartimenti ed agli altri studi.

MD: La domanda che mi fanno spesso è quanto sia importante il Consiglio di Discussione, quanto siano importanti i forum, e credo che tutti qui nel QA sarebbero d’accordo con me nel dire: estremamente importanti. Quando testiamo il gioco, creiamo numerose situazioni di test, ma ci sono sempre uno o due scenari che passano inosservati, a cui nessuno pensa, ed è questo che fanno i backer per noi, perché solitamente possono giocare senza avere problemi, senza rompere il gioco, e divertirsi, ma a volte, inevitabilmente, qualcosa si spacca. Per cui avere la possibilità di ricevere dei report direttamente da questi ragazzi, nonché mostrarci passo passo come fare per riprodurre i bug utilizzando video, screenshot e così via, è estremamente importante. Ci indirizzano nella giusta direzione e spesso ci possono indicare dei problemi enormi, cose che potremmo aver trascurato, così che noi possiamo darci una seconda occhiata, sistemarli e quindi realizzare una versione del gioco migliore della precedente.

SM: C’è sempre qualcosa di nuovo. A volte sono elementi che vengono aggiunti all’ultimo momento e richiedono di essere testati. A volte aggiungono una funzionalità, o trenta nuove funzionalità, che sono state a malapena toccate, per cui richiedono dei test più approfonditi, ed è per questo che… Si può dire che i giocatori lavorino fianco a fianco con i tester per fare in modo che tutto venga sistemato.

MB: Nel mio ruolo io ho modo di occuparmi di tanti compiti perché, ovviamente, ci sono i test e poi ci sono i test distruttivi e quindi ancora test, ma ho anche l’opportunità di dare una mano con la stesura delle note di aggiornamento ed aiutare a formare le persone che non hanno familiarità con i nostri attuali protocolli. Per cui ho modo di educare tante persone che magari già lavorano nel campo dello sviluppo da un po’, ma non si occupano di QA da diverso tempo. Tuttavia, noi affrontiamo i problemi usando approcci sempre nuovi e differenti, per cui il mio compito è di aggiornare tutti su questo aspetto, in modo che siano tutti al corrente delle ultime novità. È un aspetto del QA che amo tanto, oltre a quello di potermi assicurare che: “Hey, siamo vicini al traguardo, lavoriamoci tutti insieme, ci siamo, realizziamo il miglior prodotto possibile”.

SM: È una specie di scalata verso la build live che affrontiamo trovando i problemi più importanti prima di arrivare alla data di rilascio. Voglio assicurarmi di rilasciare un gioco con cui le persone si possano divertire senza sperimentare crash o lag o grossi bug.

BC: Quando bisogna mettere le mani su qualcosa collegato all’ambiente live, cambia tutto. Ovviamente non c’è paragone tra il numero di persone che possono lavorare o concentrarsi su un certo aspetto prima del rilascio, e dopo.

MB: Penso che le cose inizieranno a farsi movimentate con l’arrivo della 3.0, dato che introduce tantissimi cambiamenti legati ai pianeti procedurali, le navi, le telecamere e l’assegnazione dei tasti, tutte cose che dovremo testare per assicurarci che funzionino alla perfezione per i nostri giocatori.

BC: Prevedo delle nottate incredibilmente, incredibilmente lunghe. Nottate che arriveranno al mattino e viceversa.

MD: Le cose erano semplici con il mio vecchio lavoro. Era a 10 minuti da dove vivevo. Potevo farmi una passeggiata per andare a lavoro, mentre qui devo viaggiare almeno per un’ora prima di arrivare in ufficio. Tuttavia, preferisco dover viaggiare un’ora ogni giorno piuttosto che farmi una passeggiata di 10 minuti fino al luogo in cui lavoravo prima. Quando iniziai qui, durante uno dei nostri incontri sociali, ebbi l’occasione di parlare con Erin Roberts e gli dissi che alla fine io ero un semplice addetto del QA, ma lui mi interruppe, rispondendomi:” Non voglio sentire una cosa del genere, non voglio mai sentire le parole ‘Solo QA’” e poi ha ribadito l’importanza del nostro lavoro. Vengo qui ogni giorno colmo di felicità, beh okay, magari non proprio ogni giorno, tutti noi abbiamo di tanto in tanto delle giornate difficili, ma so che quando tornerò a casa dopo una giornata di lavoro, avrò fatto qualcosa di significativo ed avrò aiutato… Beh, a realizzare il simulatore spaziale più cazzuto di sempre.

WO: Le relazioni che si formano qui sono molto diverse da quelle delle mie occupazioni precedenti nel ramo del QA. In passato, la maggior parte dei contatti che ho avuto con gli sviluppatori riguardavano soltanto i feedback sui bug.

JB: Chiunque entri nel gruppo di QA, se è bravo, può immergersi quanto vuole in un certo ambito e approfondendo le sue conoscenze di quella disciplina, può arrivare a diventare uno specialista e quindi un esperto in quella materia per il resto del QA, diventando così estremamente prezioso per tutto il team.

JS: Dunque, le abilità che probabilmente dovreste avere per entrare nel QA sono per iniziare la curiosità, perché nella maggior parte dei casi vi ritroverete a chiedervi cosa potrebbe accadere facendo questo o quello. Dovreste andare contro la logica legata a questo o quell’elemento.

ME: Anche se io o voi, oppure James non sarà la persona che sistemerà quel problema, vi sembrerà in un certo senso di essere parte della soluzione, perché sarete stati voi ad aver trovato quel bug, sarete stati voi ad averlo portato all’attenzione di qualcuno, che quindi lo avrà risolto ed adesso la prossima build non conterrà più quel problema.

AH: Sapete, ho sentito molte storie riguarda il QA, riguardo il fatto che è separato dal team di sviluppo, ma in realtà io non ho mai sperimentato nulla di tutto questo, per cui per me questa situazione è completamente normale, mentre altre persone mi dicono: “Oh, il QA qui è fantastico, sei così fortunato”, mentre io non sono d’accordo, perché ok, sono stato fortunato ed è… In ogni posto in cui sono stato è sempre stato tutto fantastico. Ho avuto modo di lavorare direttamente con gli sviluppatori e fornire loro direttamente degli input o dei feedback e, capite, ho avuto modo di vedere come quei feedback sono stati implementati, per cui qui è sicuramente fantastico. Capite, lavorare con un qualsiasi team di sviluppo è fantastico, specialmente quando sei un tester di QA.

JB: Semplicemente, lavoriamo per assicurarci che la build sia la migliore possibile prima che venga rilasciata e che tutto funzioni come dovrebbe.

Traduzione a cura di Darnos.
Trascrizione integrale disponibile presso Relay.
Articolo originale disponibile presso le Roberts Space Industries.