Hei Habr!
Avem un nou subiect important - dezvoltarea de înaltă calitate a produselor IT. La HighLoad++ vorbim adesea despre cum să facem rapid serviciile ocupate, iar la Frontend Conf vorbim despre o interfață de utilizator cool care nu încetinește. Avem în mod regulat subiecte despre testare și DevOpsConf despre combinarea diferitelor procese, inclusiv testare. Dar despre ceea ce se poate numi calitate în general și cum să lucrezi cuprinzător la ea - nu.
Să reparăm asta până — vom dezvolta o cultură a gândirii la calitatea produsului final pentru utilizator în fiecare etapă de dezvoltare. Obiceiul de a nu te concentra pe zona ta de responsabilitate și de a asocia calitatea nu numai cu testeri.
Mai jos de tăiere vom discuta cu șeful comitetului de program, șeful de testare la Tinkoff.Business, creator al comunității QA vorbitoare de limbă rusă Anastasia Aseeva-Nguyen despre starea industriei QA și misiunea noii conferințe.
- Bună Nastia. Vă rugăm să ne spuneți despre dvs.
Anastasia: Conduc testarea la o bancă și sunt responsabil pentru o echipă foarte mare – suntem peste 90 de oameni. Avem o linie de afaceri importantă; suntem responsabili pentru ecosistemul persoanelor juridice.
Am studiat mecanica și matematica și mi-am dorit inițial să devin programator. Dar când am primit o ofertă interesantă, am decis să mă încerc ca tester. Destul de ciudat, aceasta s-a dovedit a fi chemarea mea. Acum văd toată munca mea în această industrie.
Sunt un adept înflăcărat al disciplinei Asigurarea Calității. Îmi pasă ce produse sunt create, cum este tratată calitatea în companie, în echipă și, în principiu, în procesul de dezvoltare.
Pentru mine este evident că comunitatea în această direcţie nu este suficient de matură, cel putin in Rusia. Nu înțelegem întotdeauna că asigurarea calității nu este doar faptul de a testa o aplicație pentru conformitatea cu cerințele. Aș dori să schimb această situație.
— Folosiți cuvintele asigurare a calității și testare. În ochii omului obișnuit, acești doi termeni se suprapun foarte des. Cum diferă ele dacă sapi adânc?
Anastasia: Mai degrabă, nu sunt diferiți. Testarea face parte din disciplina Asigurarea Calității, este o activitate directă - chiar faptul că testez ceva. De fapt, există o mulțime de tipuri de testare și o varietate de oameni sunt responsabili pentru diferite tipuri de testare. Dar aici, în Rusia, când a apărut un val de externalizatori care furnizează testere companiilor, testarea a fost redusă la un singur tip.
În cele mai multe cazuri, acestea se limitează doar la testarea funcțională: verifică dacă ceea ce dezvoltatorii au codificat respectă specificația și atât.
— Vă rugăm să ne spuneți ce alte discipline de asigurare a calității există? Ce altceva, în afară de testare, este inclus aici?
Anastasia: Asigurarea Calității este, în primul rând, despre crearea unui produs de calitate. Adică ne întrebăm ce atribute de calitate ar trebui să aibă produsul nostru. În consecință, dacă înțelegem acest lucru, atunci putem compara cine influențează aceste atribute de calitate. Nu contează, dezvoltator, manager de proiect sau specialist de produs este o persoană care influențează dezvoltarea unui produs, stocul acestuia și strategia acestuia.
Testerul devine mai conștient de rolul său. El înțelege că sarcina lui nu este doar să testeze conformitatea cu cerințele, ci și să testeze cerințele, să pună în discuție formulările care vin de la specialistul de produs și să dezvăluie toate cerințele și așteptările implicite ale clientului. Când oferim noi funcționalități clienților noștri, trebuie să le îndeplinim cu adevărat așteptările și să le rezolvăm durerea. Dacă ne gândim la toate atributele calității, clientul va fi mulțumit și va înțelege că companiei al cărei produs îl folosește îi pasă cu adevărat de interesele sale și nu lucrează pe principiul „doar lansarea unei caracteristici”.
— Se pare că ceea ce tocmai ați descris este sarcina unui specialist în produse. Acest lucru, în principiu, nu este despre testare și nu despre calitate - este în general despre managementul produsului, nu?
Anastasia: Inclusiv. Asigurarea calității nu este o disciplină pentru care o anumită persoană este responsabilă. Acum există o direcție populară în testare, o abordare numită Testare Agile. Definiția sa afirmă clar că este o abordare de echipă a testării, care include un anumit set de practici. Întreaga echipă este responsabilă de implementarea acestei abordări; nici măcar nu este necesar să existe un tester în echipă. Întreaga echipă se concentrează pe furnizarea de valoare clientului și pe asigurarea că valoarea corespunde așteptărilor clienților.
— Se dovedește că calitatea se intersectează cu aproape toate disciplinele din jur, impunând un cadru pentru tot ce este în jur?
Anastasia: Dreapta. Când ne gândim la faptul că vrem să creăm un produs de calitate, începem să ne gândim la diferitele atribute ale calității. De exemplu, cum să verificăm dacă am creat cu adevărat funcția de care are nevoie clientul nostru.
Aici intervine acest tip de testare: UAT (testarea de acceptare a utilizatorului). Din păcate, în Rusia se practică rar, dar uneori este prezent în echipele SCRUM ca demo pentru clientul final. Acesta este un tip de testare destul de comun în companiile străine. Înainte de a deschide funcționalitatea tuturor clienților, mai întâi facem UAT, adică invităm utilizatorul final să testeze și să furnizeze imediat feedback cu privire la dacă produsul într-adevăr întrunește așteptările și rezolvă durerea. Numai după aceasta are loc scalarea la toți ceilalți clienți.
Adică ne concentrăm pe business, pe clientul final, dar în același timp nu uita de tehnologie. De asemenea, calitatea produsului depinde în mare măsură de tehnologie. Dacă avem o arhitectură proastă, nu vom putea lansa rapid funcții și nu vom putea îndeplini așteptările clienților. S-ar putea să apară o mulțime de erori atunci când încercăm să mărim sau când încercăm să refactorăm, s-ar putea să spargem ceva. Toate acestea vor influența satisfacția clienților.
Din acest punct de vedere, arhitectura ar trebui să fie astfel încât să putem scrie cod curat care să ne permită să facem rapid modificări și să nu ne fie teamă că vom sparge totul. Pentru a ne asigura că iterațiile de revizuire nu se întind pe câteva luni, pur și simplu pentru că avem atât de multă moștenire, trebuie să facem etape lungi de testare.
— În total, dezvoltatorii, arhitecții, oamenii de știință de produs, managerii de produs și testerii înșiși sunt deja implicați. Cine altcineva este implicat în procesul de asigurare a calității?
Anastasia: Acum să ne imaginăm că am livrat deja caracteristica clientului. Evident, calitatea produsului trebuie monitorizată chiar și atunci când este deja în producție. În această etapă, pot apărea situații cu scenarii neevidente, așa-numitele bug-uri.
Prima întrebare este cum facem față acestor erori după ce am lansat deja produsul? Cum reacționăm noi, de exemplu, la stres? Clientul nu va fi foarte mulțumit dacă pagina durează mai mult de 30 de secunde pentru a se încărca.
Aici intervine exploatarea, sau cum o numesc ei acum. DevOps. De fapt, aceștia sunt oamenii care sunt responsabili pentru operarea produsului atunci când acesta este deja în producție. Aceasta include diferite tipuri de monitorizare. Există chiar și un subtip de testare - testarea în producție, când ne permitem să nu testăm ceva înainte de lansare și să-l testăm imediat în producție. Aceasta este o serie de activități din punct de vedere al organizării infrastructurii care vă permit să răspundeți rapid la un incident, să îl influențați și să îl corectați.
Infrastructura este, de asemenea, importantă. Sunt adesea situații în care, în timpul unui test, este imposibil să ne asigurăm că avem cu adevărat tot ceea ce am dori să dăm clientului. Îl lansăm în producție și începem să surprindem situații care nu sunt evidente. Și totul pentru că infrastructura din test nu corespunde infrastructurii din producție. Acest lucru duce la un nou tip de testare - testarea infrastructurii. Acestea includ diverse configurații, setări, migrări de baze de date etc.
Acest lucru ridică întrebarea - poate că echipa trebuie să folosească infrastructura ca cod.
Consider că infrastructura afectează direct calitatea produsului.
Sper să existe un raport cu un caz real la conferință. Scrieți-ne dacă sunteți gata să ne spuneți din propria experiență modul în care infrastructura ca cod afectează calitatea. Infrastructura ca cod facilitează verificarea tuturor setărilor și testarea lucrurilor care altfel nu sunt posibile. Prin urmare, operarea este implicată și în procesul de dezvoltare a unui produs de calitate.
— Dar analize și documentare?
Anastasia: Acest lucru se aplică mai mult sistemelor de întreprindere. Când vorbim despre întreprindere, ne vin imediat în minte oameni precum analiștii și analiștii de sisteme. Aceștia sunt uneori numiți scriitori tehnici. Ei primesc o sarcină pentru a scrie o specificație și a o completa, de exemplu, timp de o lună.
S-a dovedit în mod repetat că scrierea unei astfel de documentații duce la iterații de dezvoltare foarte lungi și iterații lungi de îmbunătățire, deoarece în timpul procesului de testare sunt identificate erori și încep returnările. Ca urmare, există o mulțime de bucle care cresc costul de dezvoltare. În plus, acest lucru poate introduce vulnerabilități. Se pare că avem cod de referință scris, dar apoi am făcut modificări care sparg arhitectura perfect gândită.
Ca urmare, rezultatul nu este un produs de foarte înaltă calitate, deoarece patch-urile au apărut deja în arhitectură, codul în unele locuri nu este suficient acoperit cu teste, deoarece termenele limită se termină, toate erorile trebuie închise mai repede. Și totul pentru că specificația originală nu a ținut cont de toate punctele care trebuie implementate.
Dezvoltatorii nu sunt dăunători și nu scriu cod cu erori intenționat.
Dacă inițial ne-am fi gândit la o specificație care să acopere toate punctele necesare, atunci totul ar fi fost implementat exact așa cum era necesar. Dar aceasta este o utopie.
Probabil că este imposibil să scrii o specificație perfectă de 100 de pagini. De aceea trebuie să se gândească la modalități alternative de scriere a documentației, specificații, declarații de sarcini care ne-ar aduce mai aproape de a ne asigura că dezvoltatorul face exact ceea ce este necesar.
Aici îmi vin în minte abordările Agile – povești de utilizatori cu criterii de acceptare. Acest lucru este mai aplicabil pentru echipele care se dezvoltă în iterații mici.
— Cum rămâne cu testarea de utilizare, uzabilitate a produsului, design?
Anastasia: Acesta este un punct foarte important, pentru că sunt designeri în echipă. Cel mai adesea, designerii sunt folosiți ca serviciu - fie de un departament de design, fie de un designer externalizat. Sunt adesea situații în care se pare că designerul l-a ascultat pe omul de știință al produsului și a făcut ceea ce a înțeles. Dar când începem iterația, se dovedește că ceea ce s-a făcut de fapt nu a fost ceea ce se aștepta: designerul a uitat ceva, nu s-a gândit pe deplin la comportament, pentru că nu a fost în echipă și nici în context, sau în față. -Dezvoltatorul final nu a înțeles pe deplin aspectul. Poate fi nevoie de mai multe iterații doar pentru că există o problemă cu înțelegerea de către dezvoltatorul front-end a designului.
Plus ca mai este o problema. Sistemele de proiectare câștigă acum popularitate. Sunt în hype, dar beneficiile lor nu sunt în totalitate evidente.
Mă confrunt cu opinia că sistemele de proiectare, pe de o parte, simplifică dezvoltarea, dar, pe de altă parte, impun o mulțime de restricții asupra interfeței.
Ca urmare, nu facem caracteristica pe care o doreste clientul, ci cea care ne este convenabila, pentru ca avem deja anumite cuburi din care putem sa o facem.
Cred că merită să acordăm atenție acestui subiect și să ne întrebăm dacă încercând să simplificăm munca de proiectare rezolvăm de fapt durerea clientului.
— Există un număr surprinzător de subiecte legate de asigurarea calității. Există o conferință în Rusia unde toate acestea să poată fi discutate?
Anastasia: Există cea mai veche conferință despre testare, care va avea loc pentru a 25-a oară în acest an și se numește Conferința de asigurare a calității SQA Days. Se discută în principal instrumente și abordări specifice de testare pentru testerii funcționali. De regulă, rapoartele de la SQA Days examinează în profunzime domenii specifice din zona de responsabilitate a testatorilor înșiși, dar nu activități complexe.
Acest lucru ajută foarte mult la înțelegerea diferitelor instrumente și abordări, cum să testați bazele de date, API-urile etc. Dar, în același timp, pe de o parte, nu motivează să implice mai mult decât doar testarea în crearea unui produs mai bun. Pe de altă parte, testerii nu se implică mai mult în proces pentru a se gândi la obiectivul global al produsului și la componenta sa de afaceri.
Conduc un departament mare și conduc o mulțime de interviuri, care oferă cu adevărat o perspectivă asupra stării industriei în ansamblu. De regulă, băieții noștri lucrează în întreprinderi și au o zonă clară de responsabilitate. Colegii care lucrează în proiecte străine folosesc diferite tipuri de testare: ei înșiși pot face teste de încărcare, testare de performanță și chiar uneori teste de securitate, pentru că ajută cu adevărat echipa să asigure calitatea produsului.
Mi-ar plăcea ca băieții din Rusia să înceapă să se gândească și la faptul că industria nu se termină cu testarea funcțională.
— În acest scop, organizăm o nouă conferință, QualityConf, care este dedicată calității ca disciplină integrală. Spune-ne mai multe despre idee, care este scopul principal al conferinței?
Anastasia: Vrem să creăm o comunitate de oameni interesați să facă produse de calitate. Oferiți o platformă unde să vină, să asculte rapoarte și să părăsească conferința cu o înțelegere specifică a ceea ce trebuie să schimbe pentru a îmbunătăți calitatea.
În zilele noastre aud adesea o solicitare de la consultanță despre ce să fac atunci când există probleme cu testarea și calitatea. Când începi să comunici cu echipele, vezi că problema nu este cu testerii înșiși, ci cu modul în care este structurat procesul. De exemplu, atunci când dezvoltatorii cred că sunt responsabili doar pentru scrierea codului, responsabilitatea lor se termină exact în momentul în care transferă sarcina la testare.
Nu toată lumea se gândește la faptul că codul scris prost, de calitate scăzută cu arhitectură proastă amenință cu mari probleme pentru proiect. Ei nu se gândesc la costul erorilor, că erorile care ajung în producție pot duce la costuri mari pentru companie și echipă. Nu există cultură care să se gândească la asta. Vreau să începem să-l distribuim la conferință.
Înțeleg că aceasta nu este inovație. Edward Deming, autorul celor 14 principii ale calității, a scris despre costul unei erori în secolul trecut. Asigurarea calității ca disciplină se bazează pe această carte, dar, din păcate, dezvoltarea modernă uită de ea.
— Aveți de gând să abordați direct subiecte despre testare și instrumente?
Anastasia: Recunosc că vor exista rapoarte despre instrumente. Există instrumente destul de universale cu care companiile și echipele pot influența produsul.
Toate rapoartele vor fi unite la nivel global printr-o misiune comună: de a transmite publicului că, cu ajutorul acestei abordări, instrument, metodă, proces, tip de testare, am influențat calitatea produsului și am îmbunătățit viața clientului.
Cu siguranță nu vom avea rapoarte despre un instrument de dragul unui instrument. Toate rapoartele incluse în program vor fi unite printr-un obiectiv comun.
— Pe cine va interesa ceea ce vorbiți, pe cine vedeți ca invitați ai conferinței?
Anastasia: Vom avea rapoarte pentru dezvoltatorii cărora le pasă de soarta proiectului, produsului, sistemului lor. La fel, va fi de interes pentru testeri și, mi se pare, mai ales pentru manageri. Prin manageri mă refer la oameni care iau decizii și pot influența soarta și dezvoltarea unui produs, sistem, echipă, printre altele.
Aceștia sunt oameni care se întreabă cum să îmbunătățească calitatea unui produs sau a unui sistem. La conferința noastră, ei vor afla despre diverse seturi de măsuri și vor putea înțelege ce este în neregulă cu ei acum și ce trebuie schimbat.
Cred că principalul criteriu este să înțelegi că ceva nu este în regulă cu calitatea și să vrei să o influențezi. Probabil că nu vom putea ajunge la oameni care cred că acest lucru se va întâmpla prima dată.
— Crezi că industria în ansamblu este pregătită să vorbească nu doar despre testare, ci și despre o cultură a calității?
Anastasia: Cred că m-am maturizat. Acum multe companii se îndepărtează de abordarea tradițională Waterfall către Agile. Se pune accent pe client, oamenii din echipe chiar încep să se gândească la cum să creeze un produs de calitate. Chiar și companiile comerciale se reorientează pe îmbunătățirea calității.
Judecând după numărul de solicitări care apar în comunitate, cred că este timpul. Desigur, nu sunt sigur că aceasta va fi o revoluție la scară largă, dar mi-aș dori să se întâmple această revoluție a conștiinței.
- De acord! Vom insufla cultura și vom schimba conștiința.
Conferință despre dezvoltarea de înaltă calitate a produselor IT va avea loc la Moscova pe 7 iunie. Știți ce etape alcătuiesc un produs de înaltă calitate, avem cazuri de combatere cu succes a erorilor în producție, am testat metode populare în propria noastră practică - avem nevoie de experiența dumneavoastră. lor aplicații până la 1 mai, iar Comitetul de program va ajuta la concentrarea temei pentru integritatea generală a conferinței.
Conectează la , în care discutăm probleme de calitate și conferința, abonați-vă pentru a fi la curent cu noutățile programului.
Sursa: www.habr.com