ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 147
Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 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 30
Abonament PDF

Testarea de performanță de la Waterfall la Agile

Claudiu Gorgan
Senior Delivery Service Engineer
@Betfair



PROGRAMARE


Ca orice altă poveste de succes, atunci când vine vorba de testele de performanță povestea noastră îmbină armonios oameni și procese. Companii diferite au la baza culturi diferite, astfel încât acestea jonglează cu un amalgam diferit de oameni și procese . Echipele versate, care au persoane dedicate testelor de performanță ar putea folosi doar ghidări generale ca un proces, în timp ce echipele mai agile în care se rotește rolul responsabilului în testarea de performanță, între membrii echipei, probabil că ar avea nevoie de procese mai detaliate, liste de verificare etc. astfel încât întregul flux de testare de performanță să fie consecvent de la un sprint la altul, iar rezultatele să ofere același nivel de încredere.

Paragrafele următoare se vor concentra mai mult pe modul de lucru de tip Agile, dar va sublinia și importanța bazei solide a întregului proces în sine, care a fost construit de-a lungul anilor și a implicat mulți experți în domeniu.

Waterfall

În multe cazuri, procesul de testare de performanță ar fi arătat ca și cel de mai jos: o echipă de testare de performanță (echipa perfqa), care are ultimul cuvânt, înainte ca un produs să ajungă în producție:

Chiar dacă echipa perfqa ar fi fost implicată în stadiile incipiente ale unui produs, prin intermediul ședinței de începere a proiectului (Kick-off meeting), aceasta nu făceam parte din sprint-uri, nu era lângă programatori și nici nu aveau același manager ca și echipa de dezvoltare. Toate cele de mai sus au generat câteva neconcordanțe cu modul de lucru Agile, după care s-au ghidat echipele de dezvoltare:

”Minunea” Agile

În timp, procesul de perfqa a început să se schimbe și a încercat să rezolve problemele de mai sus. Drept urmare, a luat naștere conceptul de „performance champions”. Chiar dacă conceptul a fost nou, nu aducea nimic inovator sau extraordinar. Era vorba mai mult de o comunitate ai cărei membri au fost programatori sau _tester-_i din diferite echipe de dezvoltare. Acești „performance champions” au început să fie direct implicați în procesul de perfqa aducând astfel testarea de performanță și responsabilitatea testelor de performanță mai aproape de echipele de dezvoltare în timp ce echipa de perfqa le-a oferit coaching, mentorat și îndrumare.

Ca un susținător și într-un fel îndrumător a conceptului de „performance champions”, voi prezenta câteva dintre gândurile mele precum le-ar fi prezentat Clint Eastwood:

Binele

Până acuma aveam programarea, testarea funcțională, managementul de proiect, analiza de business, devops cu rol de componente ale unei echipe, dacă la toate acestea adăugăm și testarea de performanță, echipa devine completă și pe deplin responsabilă de produsele livrate. Testarea de performanță poate face parte acuma din planificarea sprint și poate fi adaptată în funcție de nevoile fiecărei echipe.

Însă odată cu aceasta apar și noi provocări și oamenii vor fi nevoiți să își extindă domeniul de expertiză cu: strategii de testare de performanță, instrumente, reglare și monitorizare.

Răul

Trebuie ținut cont de diferența dintre un expert pe un anumit domeniu (ex.: expert pe testarea de performanță) și o persoană mai versatilă care este specializată pe diferite tehnologii (ex.: dezvoltare și testare de performanță sau testare funcțională și testare de performanță).

Urâtul

Având în vedere ca testele de performanță intră acum în responsabilitatea fiecărei echipe, ei le vor adapta nevoilor pe care le au. Acesta ar putea să nu fie neapărat un lucru urât, având în vedere că până la sfârșitul zilei toții ar trebui să aibă o înțelegere coerentă despre performanța unei componente (ex. :100 de tranzacții pe secundă TPS ar însemna același lucru pentru toți) și toți ar dori să aibă un produs integrat și nu o grămadă de componente mari și performante. Mediile de testare de performanță vor trebui menținute de diferite părți ale organizației.

Suporterii pentru conceptul ”performance champions” (comunitatea de experți) ar trebui să încerce cel puțin schimbarea de mai sus – însă desigur nu trebuie schimbate lucrurile care deja merg bine (”Binele”). Expertiza poate consta din următoarele:

Mediu pentru testarea de performanță: pregătirea mediului ar trebui abordată cât mai curând posibil, mai ales în cazul în care nu există nici un responsabil pentru asta. Folosind mediul, echipa ar trebui să aloce timp pentru reîmprospătarea (refreshing) componentei de testat și a dependințelor sale. Mediul de performanță ar putea fi o replică la scală a mediului de producție sau un mediu pentru disaster recovery.

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects