The Testing Map încearcă să evidenţieze, într-o formă vizuala, cele mai importante informaţii pe care un tester ar trebui să le ştie. Printre aceste zone se află şi o parte dedicată proceselor. Despre ea, voi vorbi mai departe.
Nimănui nu îi plac procesele. Sunt plictisitoare, este foarte dificil să vezi valoarea pe care o dau urmându-le. Au un miros de chestii pe care trebuie să le facem doar pentru că cineva vrea. Cumva procesele nu se potrivesc cu dezvoltarea software. Programatorii şi testerii sunt meşteşugari. Cum poţi pune un proces într-un meşteşug? Deşi răspunsul ar părea dificil, este în realitate foarte simplu: nimeni nu vrea o aplicaţie fără bug-uri (poate doar cu excepţia programatorilor şi testărilor), dar toată lumea vrea un produs care să meargă. Că să faci un produs care să meargă e nevoie să ai o serie de reguli. Sunt şi alte discipline, pe lângă programare şi testare, care influenţează un produs. Poţi lucra într-o echipă doar dacă ştii ce se aşteaptă din partea ta, ce trebuie să livrezi. Este adevărat că în dezvoltarea software sunt o grămadă de reguli nefolositoare, izvorâte dintr-o mentalitate post industrială care nu poate percepe programarea şi testarea ca un meşteşug.
De cele mai multe ori, noi suntem de vină pentru că acceptăm această situaţie. Dacă vrem să schimbăm situaţia, atunci nu trebuie să ne resemnăm. "Nu ai dreptul la o părere. Ai dreptul la o părere informată. Nimeni nu are dreptul să fie ignorant" (Harlan Ellison). Dacă v-aş spune despre modelul waterfall că este "risky and invites failure", cred că cei mai mulţi dintre voi aţi fi de acord cu mine. Dar dacă v-aş spune că această afirmaţie vine din articolul "Managing the development of large software system" de Winston Royce, baza modelului waterfall. Este pe pagină 2 a articolului. Prima afirmaţie după reprezentarea clasică a modelului:
Dacă v-aş spune că Jeff Sutherland, unul din părinţii SCRUM ului, în cartea lui "Scrum: The Art of Doing Twice the Work in Half the Time" spune că nu şi-a dorit ca "SCRUM-ul să devină încă un proces". Când Agile Manifesto a fost scris (2001) "…Scrum was pretty much unknown at the time. it was only with the advent of Ken Schwaber's 2-day Certified Scrummaster Certificate several years later that Scrum rose în ascendancy…" (Alistar Cockburn)
Procesele devin enervante şi nefolositoare când scopul lor nu este clar. Când oamenii nu înţeleg motivul, nu caută motivul şi nu vor să lupte cu "status quo"-ul. S-a ajuns la punctul în care standardele vin pentru a da o siguranţă că facem o treaba bună ca programator, tester, analist… Un standard care dictează ce trebuie să faci este un afront pentru oricine ţine la individualitatea sa.. Sunt standard bune şi rele, în funcţie de contextul tău. Dar de ce avem nevoie de standarde? În "History of software engineering", Wikipedia menţionează perioada dintre 1965 şi 1985 drept "Criză Software". Multe proiecte depăşeau bugetul şi durata. Unele proiecte produceau pagube. Câteva chiar pierderi de vieţi. Pierderea de vieţi nu este o exagerare: Therac-25 a fost o maşină pentru radiaţii terapeutice. A cauzat cel putin șase accidente în care pacienților li s-au administrat supradoze masive de radiații din cauza unei erori de programare.
Aşa că în 1980 am primit ITIL (IT Infrastructure Library) şi în 1989 CMM (Capability Maturity Model). Standardele acoperă cele două mari modalităţi de a vinde software: ca un serviciu (ITIL), sau cod sursă (CMM). Poate pare ciudat dar ambele standarde au fost cerute şi finanţate de către guverne: ITIL în Marea Britanie (prin Central Computing and Telecommunications Agency) şi CMM în SUA ( principalii sponsori au fost Office of the Secretary of Defense şi Naţional Defense Industrial Association). Ele au apărut ca o nevoie a cumpărătorilor de software de a avea o şansă mai mare să primească softul pentru care l-au plătit. Standardele nu sunt rele, ci modul în care sunt înţelese şi aplicate are consecințe negative. Poţi vedea un standard ca o colecţie de "cele mai bune practici" (ceea ce cineva a considerat mai bun). Dar nu există "cele mai bune practici": există doar practici bune în contextul tău. Înainte a a implementa un standard ai nevoie de o abordare contextuală a companiei și a proiectului), precum și de o înţelegere solidă a standardului pentru a fi sigur că implementezi o practică în mod corect. Poate într-un alt articol, vom clarifica şi diferenţa dintre "a şti" şi "a înţelege". Pentru a înţelege un standard este nevoie să îl explorezi, să găseşti oameni competenți care să îți dea informaţii valoroase, să te documentezi, nu să fii un culegător de folclor. Un lucru important de ştiut despre standarde este că ele au fost concepute pentru a fi aplicate indiferent de context. "Limba" lor nu este uşor de înţeles şi interpretat. Să luăm un exemplu din ISO 9001:2008. În capitolul Controlul monitorizării şi echipamentului pentru măsurători există o practică: "… pentru a avea rezultate valide echipamentul de măsurare… trebuie calibrat şi/sau verificat, la intervale specifice sau înainte de folosire, cu standardele de măsurare…". Primul meu gând este: dar noi nu avem aşa echipamente în dezvoltarea software. Aceasta este ceva pentru fabrici. Dar greşesc. Gândiţi-va numai cum monitorizăm disponibilitatea aplicaţiilor (SLA). Există o calibrare şi o verificare pe care le facem. Gândiţi-va la testele de peformanță: evaluezi performanţă în functie de un standard pe care ţi l-ai stabilit (benchmark). Sunt o grămadă de locuri în care această practică poate fi folosită în dezvoltarea software, dar cuvintele prin care practică este descrisă nu ajută. Este nevoie să înţelegi contextul în care aplici practica şi standardul pentru a putea avea o implementare de succes. Dacă tot vorbim despre ISO, ai auzit cumva de ISO 29119? Aş cam paria că nu. Este un standard ISO pentru testare. Costă în jur de 160 de euro doar să îl vezi. Feedbackul comunitatiilor de testare din întreagă lume a fost unul negativ. Există chiar şi o petiţie "Stop 29119" semnată de "oameni mari" din testare. În final, vreau să subliniez că îmi plac standardele. Cred în unele dintre ele. Cred că te pot ajută dacă le înţelegi. Cele mai multe probleme pe care standardele le fac sunt cauze ale neînţelegerii, interpretării diferite sau greşite. Cred cu tărie că atunci când discutăm despre standarde şi procese "Nu ai dreptul la o părere. Ai dreptul la părere informată (Harlan Ellison). Nici un standard nu specifică că trebuie să respecţi toate practicile. Pot există derogări dacă motivele sunt întemeiate.
de Bogdan Bucur
de Emilia Toma
