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.
Î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:
Noi (echipa perfqa) urmăm propriul program, construit pe baza cerințelor pe care le au echipele de dezvoltare.
Nu simțeam ritmul și dificultățile echipei de dezvoltare - pentru care rulăm testele de performanță
Î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:
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.
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ță).
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.