Am avut plăcerea de a lua un interviu lui Rene Tuinhout, chairman al ediției 2015 a Romanian Testing Conference. Cu o experiență de peste șaptesprezece ani în testarea software, acesta oferă consultanță companiilor pentru Lean Testing, test management, test change management structuring testing și managementul proiectelor de testare.
[Ovidiu Mățan] Într-un interviu pentru revista Professional Tester ați făcut o afirmație interesantă cu privire la modul de a vedea testarea ca o diminuare a riscului mai degrabă decât prevenirea unui eșec. Ați putea să dezvoltați această idee pentru cititorii revistei noastre?
[Rene Tuinhout] Ideea din spatele afirmației pe care ai citat-o de la Richard și din articolul meu este destul de simplă: noi am ajuns la concluzia că discuția despre beneficiile testării este destul de complicată și că în cele mai multe cazuri se sfârșește printr-o situație în care convenim "să fim de acord să nu cădem de acord", atunci când discuția este despre defecte găsite și remediate. Noi în calitate de testeri, considerăm că un anume defect găsit este similar cu unul nedescoperit într-un alt proiect, care a cauzat o pierdere de X euro atunci când a fost descoperit în utilizare în viața reală. Deci, am spune că noi am economisit X euro pentru companie. Totuși, compania ar susține că defectul descoperit (și remediat) era destul de diferit de cel nedetectat anterior, și de aceea, comparația nu poate fi făcută. Ceea ce ne lasă fără temei pentru a demonstra beneficiile testării într-un limbaj pe care afacerile îl înțeleg: banii.
Totuși, asta s-a schimbat când am trecut de la discutarea beneficiilor testării bazate pe prevenirea eșecurilor la discutarea beneficiilor testării bazate pe diminuarea riscurilor. În articolul pe care l-ai menționat, Richard și cu mine am prezentat o metodă simplă care le permite managerilor afacerilor (cu ajutorul testerilor) să întocmească o hartă a tipurilor de riscuri pentru afacerea lor specifică. Apoi, riscurile concrete prevăzute în schimbarea/ produsul nou pe care compania o/îl dorește sunt colectate de la personalul companiei (utilizatori, operatori, dba, etc.). Combinând aportul personalului companiei cu cel al managementului companiei, toate riscurile concrete identificate de către personal pot fi trecute pe o hartă - termometru al riscului, utilizând riscurile afacerii furnizate de către managerii companiei.
Aceasta va duce la un model reprezentat de un termometru care indică riscurile concrete, pe categorii, după cum este de acord managementul companiei.
Există trei avantaje:
Acest punct final merită puțină analiză:
Atunci când se discută tipurile de risc cu managementul companiei, de obicei managementul dorește să exprime riscurile în valori monetare: "Cât ar costa dacă se întâmplă să se concretizeze acest risc?" Dacă această întrebare nu este ridicată în timpul ședinței cu managementul companiei, atunci li se poate sugera că exprimarea tipurilor de risc în valori monetare ar putea fi o idee bună.
Drept consecință, toate riscurile poartă acum o valoare monetară (de obicei exprimată așa: "va costa cel puțin Y și cel mult Z"). Mai târziu, după ce riscurile au fost clasificate în categoriile indicate de către conducere, vor fi concepute teste pentru a acoperi riscurile cele mai importante. Acest lucru înseamnă automat că o defecțiune detectată atunci când se testează pentru a acoperi un risc ar fi costat compania "cel puțin Y și cel mult Z", permițând tester-ilor și conducerii companiei să discute beneficiile testării pe baza unui temei comun: banii.
Decizia cu privire la ceea ce ar trebui testat și ce nu pe baza abordării metodei termometru pare a fi un instrument simplu și puternic pentru a face oamenii să înțeleagă mai bine importanța testării. Cum funcționează acest lucru în practică pentru proiectele reale?
[Rene Tuinhout] Într-un cuvânt: Grozav! Articolul pe care l-ai menționat a fost publicat în 2011. Chiar și mai înainte de acest moment, termometrul era utilizat în unele proiecte, iar după publicarea articolului a fost utilizat în mult mai multe. S-a dovedit a fi un instrument puternic care:
Modelul este cel mai mult utilizat drept modelul termometru. Totuși, în unele cazuri a evoluat într-o matrice bidimensională, care pune la dispoziția managementului companiei puțin mai multe detalii. Practic, riscul este prezentat pe termometru drept o valoare, în timp ce pe matricea bidimensională riscul este divizat în impact și probabilitate.
Există proiecte care deleagă sarcinile de testare inginerilor software prin faptul că fac testarea unităților și testarea integrării. De asemenea, am văzut și proiecte în care testarea este practic făcută de către proprietarul de produs (product owner). Cum vedeți această abordare?
[Rene Tuinhout] Deși apreciez aceste abordări, eu cred că implicarea tester-ilor profesioniști în eforturile de testare are importanța ei. Inginerii de software și proprietarii de produs ar trebui în mod cert să fie implicați în testare. Anumite abordări, precum Agile, pavează în prezent calea pentru ca inginerii de software și product owner-ii să fie implicați în testare. Asta este ceva ce mulți testeri profesioniști au cerut de ani de zile, pentru că are drept rezultat un software de o calitate mai bună și o implicare mai mare a proprietarilor de produs în dezvoltarea și testarea produsului. Cu toate acestea, excluderea tester-ilor din dezvoltarea produsului ar însemna ignorarea unui aspect foarte important din meșteșugul tester-ului: distrugerea constructivă.
Inginerii de sistem la fel ca și product owner-ii, se concentrează pe a face lucruri. Ei tind să își concentreze eforturile de dezvoltare și testare asupra acelor aspecte ale produsului testat pe care acel produs ar trebui să le facă.
Tester-ii au capacitatea, priceperea și setul de instrumente pentru a descoperi și a se concentra pe acele aspecte ale produsului testat pe care acel produs nu ar trebui să le facă sau ar trebui să le facă foarte rar, cât și pe aspecte non-funcționale care nu sunt ușor de testat (de exemplu, securitatea, performanța, ușurința de a fi utilizat sau întreținut), descoperind astfel potențiale defecte pe care inginerii de sistem și product owner-ii au mai puține șanse de a le descoperi.
De aceea, eu consider că eforturile de testare ale inginerilor de sistem, proprietarilor de produs și ale tester-ilor se completează unele pe altele.
Eu consider că un mare beneficiu al faptului că toate aceste ramuri sunt implicate în testare este posibilitatea de a învăța unele de la altele: dezvoltatorii de sistem învață un pic mai multă distrugere constructivă, proprietarii de produs câștigă o mai bună înțelegere a dificultăților tehnice ale realizării unui produs și a riscurilor sale asociate, iar tester-ii învață câte ceva despre programare și despre riscurile pe care trebuie să le prevină proprietarul de produs.
Dacă mâine v-ar cere cineva să înființați o universitate de testare, cum ar arăta materialele de studiu?
[Rene Tuinhout] A fost depus mult efort de către echipa de lucru Dutch TestNet (Asociația tester-ilor Olandezi) pentru a realiza un curriculum academic/ politehnic. Ar fi mult prea elaborat să discutăm în acest articol curriculumul care a fost creat în detaliu, dar acesta se centrează pe învățarea studenților despre interacțiunea utilizatorului, procesele de business, software, infrastructură, interfața hardware și abilitățile de analiză, consiliere, proiectare, dezvoltare și mentenanță. Toate materialele sunt în olandeză, dar dacă sunteți interesați, trimiteți-mi un e-mail și putem discuta despre asta.
Felicitări pentru obținerea premiului "People′s Choice Award" la RTC în 2014. În acest an veți fi președintele RTC. Ce subiecte interesante sunt pregătite pentru acest an?
Mulțumesc! Am fost foarte onorat să câștig acest premiu și să fiu rugat să fiu președinte în acest an. Sunt multe subiecte interesante și vorbitori atât experimentați cât și novici în ediția RTC de anul acesta.
Pentru o privire de ansamblu asupra întregului program, vă rog vizitați www.romaniatesting.ro. Personal, consider că Romanian Testing Conference 2015 are mulți oratori interesanți (ex. Peter Varhol, Markus Gärtner, Echipa Army Ants (Software Testing World Cup)) de la multe companii interesante (ex. Adobe, Cisco, Facebook) și se concentrează pe subiecte interesante care sunt de actualitate precum cloud, legile de confidențialitate, automatizarea testării, calitatea datelor testelor, IoT.
de Ovidiu Mățan
de Vlad Ciurca
de Ștefan Bălan
de Ioana Varga , Ioana Costea
