ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 140
Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 48
Abonament PDF

The Testing Map – Procese și standarde

Claudiu Draghia
Quality Manager @Capgemini



PROGRAMARE

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.

Nu ai dreptul la o părere.

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)

Standarde.

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.

NUMĂRUL 138 - Maps & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO