Despre testare și responsabilitate

Dorin
Tehnic

A început de ieri să umble informația legată de faptul că eșecul Cyberpunk 2077 s-ar fi datorat, printre altele, unei firme românești de testare de software, Quantic Lab. Pe scurt, articolul din Forbes zice că oamenii de la Quantic ar fi mințit în legătură cu stadiul testării, dar și cu profesionalismul angajaților. Oricât de mult ne place să fim depreciativi la adresa românilor, României, și orice e produs/atins de români, aș vrea să abordăm informația asta cu un pic de circumspecție.

„Capetele de acuzare” sunt destul de grave. Avertisment: textul de mai jos conține englezisme.

  1. Quantic Lab a exagerat în legătură cu mărimea echipei care lucra pe CP77 ca să mențină contractul
  2. Quantic Lab a mințit în legătură cu senioritatea membrilor echipei care lucra pe CP77
  3. Quantic Lab a avut o cotă de buguri zilnice de raportat, ceea ce a făcut ca CDPR să primească mii de bug-reports relativ neînsemnate, și bugurile serioase nu au fost prioritizate.

Informațiile din 1) și 2) sunt destul de grave și dacă situația e adevărată, probabil există deja un proces pornit de CDPR contra Quantic Lab. Contractele de genul ăsta sunt de obicei super-solide, făcute și revizuite de armate de avocați, nu cred că Quantic ar putea să scape foarte ușor dacă ar fi mințit pe bune. Dar, cine știe, poate acum află și CDPR lucrul ăsta, și vom vedea un proces. Avocățeala scoasă din peisaj, să vorbim despre lucrurile pe care le mai cunosc, și anume partea de la numărul 3.

Cota de buguri

Prima idee care mă deranjează acolo e cota de buguri. Nu e un fenomen nemaiîntâlnit, dar oricine a impus sau a sugerat o cotă de buguri nu cunoaște nici software development, nici proceduri de testare de software/hardware. Personal nu am lucrat cu astfel de echipe de testare - am avut mai tot timpul parte de parteneri inteligenți la testare - oameni care înțelegeau priorități, înțelegeau scopul comun pentru care se lucrează, și înțelegeau că sunt parte dintr-o echipă care trebuie să livreze produse de calitate înaltă, iar ei erau garanții acelei calități.

În primul rând, e cam greu să impui unui om să găsească probleme acolo unde nu sunt. Pot să-ți dau la testare o bucată de soft suficient de solidă încât să nu poți să-i găsești niciun fel de probleme, și chiar și cu o cotă de un bug pe zi nu o să te poți descurca. Rolul testării nu e doar să găsească probleme, e să și valideze și să genereze o listă de scenarii importante care trebuiesc validate/testate.

Și da, poți impune unui om să valideze X testcases. Dar nu îi poți impune unui om să găsească X buguri într-o săptămână. Poți să-i impui să încerce să reproducă pe baza unor informații niște probleme găsite de alții. Poți să-i ceri să valideze/invalideze rezolvarea unei probleme pe care a detectat-o anterior. Dar nu poți să îi impui să găsească un număr fix de buguri.

Așa că cine le-a impus o cotă de buguri (dacă informația e adevărată) nu e software developer și nici nu are experiență reală în câmpul ăsta (nu zic că nu activează, doar nu își dă seama de ce consecințe distructive are). Care sunt posibilele consecințe?

Buguri repetate sub alt enunț. Buguri neînsemnate, superficiale. Săritul peste probleme complicate doar pentru că nu pot fi reproduse ușor (bugurile trebuie să fie reproductibile/reproduse). Ceea ce într-adevăr ar explica și un număr mare de bug reports, și lipsa lor de însemnătate (deși ele sunt acolo, și probabil că deranjează). Un alt side-effect e că bugurile ar fi putut să fie etichetate prost, cu însemnătate mai mare decât e cazul, iar când ai mii de buguri înregistrate cu severitate High, începi să te desensibilizezi de la ideea de bug cu severitate înaltă, și să pui în același coș și o problemă de aliniere de text, și un bug care îți oprește quest-ul principal și practic te împiedică să termini jocul.

Prioritizările

Asta cu „bugurile serioase nu au fost prioritizate” mă amuză tare. Da, când testerul vine la tine să-ți pună pe același nivel o aliniere de text și un bug care afectează experiența de joc complet, și tu le accepți verdictul că sunt la același nivel, ai o problemă. Trierea bugurilor e o treabă pe care ar fi trebuit s-o facă cineva de la CDPR, nu poți să-l faci responsabil pentru evaluarea ca valoare de business a unui bug pe cel care îți zice că e o problemă acolo. Pentru unii o aliniere de text e super-importantă. De exemplu mi-a fost imposibil să joc Per Aspera din cauza faptului că textele de pe diversele clădiri și resurse erau blurate într-un mod neplăcut. A trebuit să mă plâng dezvoltatorului ca să pot să dau drumul la joc, pur și simplu mă dureau ochii de la textul respectiv. Dar probabil nu era pentru marea majoritate o problemă - un indiciu vizual pe care probabil începuseră să-l ignore; dar pentru mine făcea jocul de nejucat. Era o problemă dificil de rezolvat? Nu, pentru că au putut să bage modificarea în cam 10 zile de când le-am raportat problema. În fine, ce vreau să zic e că ce e game breaking pentru unii nu e game-breaking pentru toată lumea.

Cine hotărășțe prioritățile? Oricine ar fi, trebuie să fie cineva din echipa de bază a jocului. Cineva de la CDPR, nu firma de testare, că firma de testare are alte priorități decât firma care construiește jocul. Și de-asta vreau să închei un pic cu o discuție despre

Responsabilitate și profesionalism

Există anumite exigențe pe care mi le-am impus întotdeauna în legătură cu produsele software la care am lucrat. Eu, ca dezvoltator, eu ca conducător de echipă de dezvoltare, port prima responsabilitate în legătură cu ce producem. Ce iese de pe mâna noastră ar trebui să nu aibă probleme - sau dacă le are, să le declarăm din start ca probleme cunoscute. Dezvoltatorul e primul tester, și cel mai important.

De exemplu, e inadmisibil să iasă spre testare o bucată de software care să crape pe „happy flow” - care e logica cea mai importantă a oricărui produs: în situația în care ai un utilizator neostil, în care toate precondițiile sunt corect satisfăcute, softul trebuie să funcționeze corect. În al doilea rând, e foarte important să recunoști ca dezvoltator unde ar putea să fie punctele slabe, și eventual să sprijini testarea în a investiga zona de nesiguranță. Dacă există probleme cunoscute nu mai e nevoie să le dau eu la testare ca să mi le zică ei. O bază de date comună de buguri e 100% necesară.

Dezvoltatorul are responsabilitate ca atunci când vine testerul la el cu raport de zero buguri să facă challenge - să sugereze noi scenarii de testat, să sugereze testcase-uri care poate testerului i-au scăpat. Dezvoltatorul e responsabil și pentru testarea în izolare (unit testing) și pentru testarea integrată. Dezvoltatorul e primul și cel mai important tester.

Asta nu înseamnă că echipa de testare e inutilă. Echipa de testare vine cu un punct de vedere mai business oriented (de obicei testarea înțelege un pic mai bine partea de business decât dezvoltatorul). Din cauza asta nu prea cred în externalizarea testării fără un training foarte serios, chiar mult mai serios decât al dezvoltatorilor, în care testerii să înțeleagă necesitățile de business pentru care testează. Trebuie să testeze și produse similare dacă există pe piață, trebuie să înțeleagă mai bine cerințele utilizatorilor, și să înțeleagă mai bine și punctul de vedere al utilizatorilor.

Și mai vrei ca echipa de testare să fie în contact direct cu echipa de dezvoltare - să facă parte din echipa mare de dezvoltare a softului respectiv, pentru că pe lângă necesitățile de business, echipa de testare trebuie să înțeleagă și modul de lucru al echipei, și felul în care pot să conlucreze eficient pentru a identifica cele mai importante probleme. Poate ce e un simplu text prost aliniat este o problemă de securitate majoră pentru un dezvoltator - vrei să ai comunicare, vrei ca testerii să îi întrebe pe dezvoltatori „de ce”, și să înțeleagă mai bine ce e prioritate și ce nu.

Dar genul ăsta de colaborare și integrare ține de profesionalism. Când încerci să rezolvi problemele cu neosclavagism aruncând mai mulți oameni la o problemă pe care nu o înțelegi, ajungi să ai lansări eșuate precum CP77.

Concluzii

Sincer, articolul respectiv mi se pare un rant al unui (fost) angajat care spune și el „din auzite” chestii. Că e de la CDPR sau de la Quantic, nu contează. E foarte probabil ca informațiile să fie reale, dar în același timp puternic exagerate. Mai mult ca sigur cel care a leak-uit informațiile să nu fie de mare încredere, sau să fi avut o viziune foarte îngustă asupra problemei. În orice caz, problema e mai complexă decât un simplu „românii au făcut treabă proastă și de-asta a fost jocul prost”. Munca de dezvoltare au făcut-o tot CDPR, ei au prima responsabilitate de testare, inclusiv responsabilitatea de a coordona procesul de testare.

Din păcate, am văzut că articolul ăla doar a alimentat sentimentul anti-român al românilor. Sincer, sunt sătul de el. M-am săturat să se accepte instantaneu orice „vai, dar românii nu-s capabili”, „vai, sigur românii au făcut prost ce au făcut”. M-am săturat de aplicarea unui filtru gri peste absolut orice fac românii. Chiar dacă Quantic Lab ar fi fost un scam care i-a țepuit pe polonezi, nu înseamnă că „românii fac numai de-astea”. Uneori e posibil ca niște oameni să fie slabi profesioniști nu pentru că sunt români, ci pentru că ei, individual, sunt slabi profesional.

Dar a fost o ocazie bună să discutăm un pic despre testare, și sper că am clarificat niște răspunsuri la niște întrebări pe care poate că nici nu vi le puneați.

Confirmare

Situația e confirmată de LegacyKilla, un streamer youtube cu surse în interiorul CDPR:

Spoke to a few different CD Projekt Red sources that worked on #Cyberpunk2077, they all refuted this claim. As one developer told me: “…we knew about the bugs that people were complaining about. This was not something that was “unknown” to us. But we did not have time to focus on it, we were crunching like crazy so we were paper thin at the end.”. Same dev also said that more important or tech aspects of the game was tested internally.

Especially later in development, complex bugs required in-depth involvement with the dev team. Quantic’s QA role was minimal with much of the issues being on CDPR’s own mismanagement. “Anything that flows in is screened by internal QA, production & devs. It’s not like we’re morons & spend hours on obviously bad bugs.”

“Management not knowing [about the bugs/issues] is laughable… They knew, everyone knew. They would play the game all day, every day.”