Salut, Habr!
Avem o nouă temă importantă – dezvoltarea de calitate a produselor IT. Vorbim adesea la HighLoad++ despre cum să facem serviciile suprasolicitate rapide, iar la Frontend Conf – despre interfețe utilizator prietenoase care nu încetinesc. Avem regulat teme despre testare și DevOpsConf despre integrarea diferitelor procese, inclusiv testarea. Însă despre ceea ce putem numi calitate în general și cum să lucrăm complex asupra acestuia – încă nu avem.
Să corectăm asta la – vom promova cultura gândirii asupra calității produsului final pentru utilizator în fiecare etapă a dezvoltării. Obiceiul de a nu ne limita la zona noastră de responsabilitate și a asocia calitatea nu doar cu testătorii.
În continuare, vom discuta cu președintele comitetului de program, liderul testării la Tinkoff.Business, creatorul comunității QA vorbitoare de limbă rusă Anastasia Aseeva-Nguyen despre starea industriei QA și misiunea noii conferințe.
– Nastya, salut. Te rog, povestește-ne despre tine.
Anastasia: Eu coordonez testarea la bancă, răspund pentru o echipă foarte mare – suntem mai mult de 90 de persoane. Avem o linie de afaceri importantă, ne ocupăm de ecosistemul pentru persoanele juridice.
Am studiat la mecanică și matematică și inițial am vrut să devin programator. Dar când mi-a apărut o ofertă interesantă, am decis să încerc rolul de testător. Ciudat cum a fost, aceasta s-a dovedit a fi vocația mea. Acum, toată munca mea o văd exact în această industrie.
Sunt un adept pasionat al disciplinei Quality Assurance. Îmi pasă care produse sunt create, cum se abordează calitatea în companie, în echipă și, în general, în procesul de dezvoltare.
Pentru mine este evident că comunitatea în acest sens este insuficient de matură, cel puțin în Rusia. Nu întotdeauna înțelegem că asigurarea calității nu este doar faptul de a testa aplicația pentru a se conforma cerințelor. Mi-ar plăcea să schimb această situație.
– Folosești termenii Quality Assurance și testare. În ochii publicului, aceste două termeni se suprapun adesea. Care este diferența, dacă analizăm mai profund?
Anastasia: Probabil că nu se deosebesc. Testarea este o parte a disciplinei de Asigurare a Calității, este o activitate directă – faptul că testez ceva. De fapt, există foarte multe tipuri de testare, iar pentru diferitele tipuri de testare răspund diferite persoane. Dar în Rusia, când a apărut valul de outsourcing care furniza testeri în companii, testarea s-a restrâns la un singur tip.
În majoritatea cazurilor se limitează doar la testarea funcțională: verifică dacă ceea ce au codificat dezvoltatorii corespunde specificației și atât.
– Spune-mi, te rog, ce alte discipline de asigurare a calității există? Ce altceva, în afară de testare, este inclus aici?
Anastasia: Asigurarea Calității înseamnă, în primul rând, crearea unui produs de calitate. Asta înseamnă că ne punem întrebarea ce atribute de calitate ar trebui să aibă produsul nostru. Prin urmare, dacă înțelegem asta, putem corela cine influențează aceste atribute de calitate. Nu contează, dezvoltator, manager de proiect sau produsolog – este persoana care influențează dezvoltarea produsului, backlog-ul său, strategia sa.
Testerul începe să-și conștientizeze mai bine rolul. Înțelege că sarcina sa nu este doar să testeze conform cerințelor, ci și să testeze cerințele, să pună la îndoială formulările care vin de la produsolog, să descopere toate cerințele implicite și așteptările clientului. Atunci când furnizăm o nouă funcționalitate clientului nostru, trebuie să-i satisfacem cu adevărat așteptările și să-i rezolvăm durerea. Dacă ne gândim la toate atributele de calitate, clientul va fi mulțumit și va înțelege că compania al cărei produs îl folosește, se preocupă cu adevărat de interesele sale, și nu lucrează pe principiul „doar să lansăm o caracteristică”.
– Pare că ceea ce ai descris tu acum este sarcina produsologului. Asta, în principiu, nu are de-a face cu testarea și nici cu calitatea – este cu adevărat despre managementul produsului, nu?
Anastasia: Într-o măsură. Asigurarea Calității nu este o disciplină pentru care răspunde o singură persoană. Acum există o direcție populară în testare, o abordare care se numește Agile TestingÎn definiția sa se afirmă că este o abordare de echipă pentru testare, care include un set specific de practici. Implementarea acestei abordări este responsabilitatea întregii echipe, fără a fi necesar ca în echipă să existe un tester. Întreaga echipă este orientată spre livrarea valorii către client și pentru ca această valoare să corespundă așteptărilor lui.
— Așadar, calitatea se intersectează aproape cu toate disciplinele înconjurătoare, impunând limite asupra tuturor?
Anastasia: Corect. Când ne gândim la ceea ce vrem să creăm un produs de calitate, începem să ne gândim la diferite atribute de calitate. De exemplu, cum putem verifica că am realizat într-adevăr o caracteristică de care are nevoie clientul nostru.
Aici intervine un tip de testare, cum ar fi UAT (testarea acceptării utilizatorilor). Din păcate, în Rusia este rar practicat, dar uneori este prezent în echipele SCRUM, ca demo pentru clientul final. În companiile din străinătate este un tip de testare destul de comun. Înainte de a deschide funcționalitatea pentru toți clienții, mai întâi facem UAT, adică invităm consumatorul final, care efectuează testarea și oferă imediat feedback – dacă produsul corespunde așteptărilor și rezolvă o problemă. Numai după aceasta se face scalarea pentru toți ceilalți clienți.
Deci ne orientăm pe business, pe clientul final, dar în același timp nu uităm de tehnologie. De tehnologie depinde foarte mult calitatea produsului. Dacă avem o arhitectură slabă, nu putem lansa rapid funcționalități și nu vom respecta așteptările clientului. Pot exista multe buguri în încercarea de a scala, sau în încercarea de a face refactoring, am putea strica ceva. Toate acestea vor afecta satisfacția clientului.
Din acest punct de vedere, arhitectura trebuie să fie astfel încât să putem scrie cod curat, care să permită modificări rapide și să nu ne temem că vom distruge totul. Ca iterațiile de îmbunătățire să nu se întindă pe câteva luni doar pentru că avem atât de mult legacy, și trebuie să facem etape lungi de testare.
— În total, deja sunt implicați dezvoltatori, arhitecți, product owneri, product manageri, și testerii înșiși. Cine mai este implicat în procesul de asigurare a calității?
Anastasia: Acum să presupunem că am livrat deja funcționalitatea clientului. Este evident că trebuie să monitorizăm calitatea produsului, chiar și după ce acesta este în producție. În această etapă pot aparea situații cu scenarii neașteptate, numite bug-uri.
Prima întrebare este - cum lucrăm cu aceste bug-uri după ce am lansat deja produsul? Cum reacționăm, de exemplu, la încărcare? Clientul nu va fi foarte mulțumit dacă pagina se încarcă mai mult de 30 de secunde.
Aici intervine exploatarea sau, cum o numesc acum, DevOps. De fapt, aceștia sunt oamenii care se ocupă cu exploatarea produsului, atunci când acesta este deja în producție. Aceștia sunt implicați în diferite tipuri de monitorizare. Există chiar un subtip de testare - testarea în producție, când ne permitem să nu testăm ceva înainte de lansare și testăm direct în producție. Acestea sunt o serie de activități din perspectiva organizării infrastructurii, care permit o reacție rapidă la un incident, influențarea acestuia și corectarea lui.
Infrastructura este de asemenea importantă. Adesea, există situații când, în timpul testării, nu putem fi siguri că avem cu adevărat tot ceea ce ne-am dori să oferim clientului. Lansăm în producție - și începem să întâmpinăm situații neașteptate. Și totul se datorează faptului că infrastructura din test nu corespunde infrastructurii din producție. De aici apare un nou tip de testare - testarea infrastructurii. Acestea sunt diferite configurații, setări, migrarea bazelor de date etc.
De aici se ridică întrebarea - poate echipa trebuie să utilizeze infrastructura ca și cod.
Cred că infrastructura influențează direct calitatea produsului.
Sper că la conferință va fi o prezentare cu un caz real. Scrieți-ne dacă sunteți gata să vorbiți din experiența dvs. despre cum infrastructura ca și cod influențează calitatea. Infrastructura ca și cod permite verificarea mai ușoară a tuturor setărilor și testarea a ceea ce altfel ar fi imposibil. De aceea, în procesul de dezvoltare a unui produs de calitate este implicată și exploatarea.
— Și ce ne spuneti despre analitică și documentație?
Anastasia: Aceasta se referă mai mult la sistemele enterprise. Când vorbim despre enterprise, imediat ne vin în minte oameni precum analiștii și analiștii de sistem. Uneori, sunt numiți scriitori tehnici. Ei primesc o sarcină pentru a redacta o specificație și o finalizează, de exemplu, în termen de o lună.
S-a demonstrat de mai multe ori că redactarea unei astfel de documentații conduce la iterații de dezvoltare foarte lungi și întârzieri în finalizarea lucrărilor, deoarece în procesul de testare apar bug-uri, iar retururile încep. Ca urmare, se formează foarte multe bucle care cresc costul dezvoltării. În plus, acest lucru poate introduce vulnerabilități. Se pare că am scris cod de referință, dar apoi am făcut modificări care distrug arhitectura bine gândită.
Prin urmare, se obține un produs de calitate nu foarte bună, deoarece în arhitectură au apărut deja patch-uri, iar codul în anumite locuri nu este suficient acoperit de teste, deoarece termenele de livrare sunt presante și trebuie să închidem rapid toate bug-urile. Și toate acestea pentru că în specificația inițială nu au fost luate în considerare toate aspectele necesare implementării.
Dezvoltatorii nu sunt răufăcători și nu scriu intenționat cod cu erori.
Dacă am fi gândit inițial specificația care ar fi acoperit toate aspectele necesare, totul ar fi fost realizat exact așa cum trebuie. Dar aceasta este o utopie.
Probabil că nu este posibil să redactezi o specificație ideală de 100 de pagini. Așadar, trebuie să ne gândim la modalități alternative de redactare a documentației,specificării, formulării sarcinilor, care să ne apropie de situația în care dezvoltatorul face exact ceea ce trebuie.
Aici îmi vin în minte abordările din Agile – povestirile utilizatorului cu criterii de acceptare. Acest lucru este mai aplicabil echipelor care evoluează prin iterații mici.
– Ce părere ai despre testarea utilizabilității, despre confortul utilizării produsului, despre design?
Anastasia: Este un aspect foarte important, deoarece în echipă sunt designeri. Cel mai adesea, designerii sunt folosiți ca serviciu – fie un departament de designeri, fie un designer extern. Se întâlnesc des situații în care designerul a ascultat productologul și a realizat ceea ce a înțeles. Dar când ajungem la iterație, se dovedește că de fapt nu s-a realizat ceea ce ne așteptam: designerul a uitat ceva, nu a gândit până la capăt comportamentul, pentru că el nu este în echipă și nu este în context, sau dezvoltatorul front-end nu a înțeles pe deplin modelul său. Pot fi necesare câteva iterații doar din cauza că există o problemă de înțelegere a designului de către dezvoltatorul front-end.
Există însă o altă problemă. În prezent, sistemele de design câștigă popularitate. Sunt la modă, dar beneficiile lor nu sunt complet evidente.
Mă confrunt cu părerea că sistemele de design, pe de-o parte, simplifică dezvoltarea, pe de altă parte, impun foarte multe restricții asupra interfeței.
În cele din urmă, creăm nu caracteristica pe care clientul o dorește, ci pe cea care ne este convenabilă, pentru că deja avem anumite module din care putem să o facem.
Mi se pare că ar trebui să acordăm atenție acestui subiect și să ne gândim dacă, în încercarea de a simplifica munca asupra designului, rezolvăm, de fapt, problemele clientului.
— Așadar, apar surprinzător de multe subiecte legate de asigurarea calității. Există în Rusia o conferință în care să le putem discuta pe toate?
Anastasia: Există cea mai veche conferință de testare, care în acest an va avea loc pentru a 25-a oară și se numește Conferința de Asigurare a Calității SQA Days. În principal, aici se discută despre instrumente și abordări specifice de testare pentru testările funcționale. De regulă, în prezentările de la SQA Days se examinează profund anumite domenii din zona de responsabilitate a testorilor, dar nu evenimente complexe.
Acest lucru ajută foarte mult să ne clarificăm instrumentele și abordările privind testarea bazelor de date, API etc. Totuși, pe de o parte, nu motivează implicarea în crearea unui produs mai calitativ nu doar a testării. Iar pe de altă parte, testorii nu devin mai implicați în proces pentru a gândi la obiectivul global al produsului și la componenta sa de afaceri.
Conduc un departament mare, organizez multe interviuri, care de fapt permit să îmi fac o idee despre starea industriei în ansamblu. De obicei, colegii noștri lucrează în medii enterprise și au o zonă de responsabilitate clar definită. Cei care lucrează la proiecte internaționale folosesc diferite tipuri de testare: ei pot efectua teste de încărcare, teste de performanță și, uneori, teste de securitate, pentru că acestea cu adevărat ajută echipa să asigure calitatea produsului.
Mi-ar plăcea să văd că și în Rusia colegii încep să se gândească la faptul că industria nu se termină doar la testarea funcțională.
— Pentru aceasta, organizăm noua conferință QualityConf, dedicată calității ca o disciplină unitară. Poți să ne oferi mai multe detalii despre conceptul conferinței și care este scopul principal al acesteia?
Anastasia: Vrem să creăm o comunitate de oameni interesați să dezvolte produse de calitate. Să le oferim o platformă unde pot veni, să asculte prezentări și să plece de la conferință cu o înțelegere concretă despre ce trebuie să schimbe pentru a îmbunătăți calitatea.
Adesea aud acum solicitări din partea consultanței cu privire la ce să facă atunci când există probleme cu testarea și calitatea. Atunci când începi să comunici cu echipele, observi că problema nu este de fapt în testeri, ci în modul în care este structurat procesul. De exemplu, atunci când dezvoltatorii consideră că sunt responsabili doar pentru scrierea codului, responsabilitatea lor se termină exact în momentul în care transmit sarcina la testare.
Nu toată lumea se gândește că un cod prost scris și o arhitectură slabă pot provoca probleme mari pentru proiect. Nu se gândesc la costul greșelilor, la faptul că bug-urile care ajung în producție pot duce la cheltuieli mari pentru companie și echipă. Nu există o cultură de a reflecta asupra acestora. Vreau ca la conferință să începem să o răspândim.
Înțeleg că aceasta nu este o inovație. Edward Deming, autorul celor 14 principii ale calității, vorbea despre costul erorii încă din secolul trecut. Pe această carte se bazează asigurarea calității ca disciplină, dar, din păcate, dezvoltarea modernă uită despre acest aspect.
— Vei aborda teme legate de testare și instrumente?
Anastasia: Accept că vor fi prezentări despre instrumente. Există instrumente destul de universale, cu ajutorul cărora companiile și echipele pot influența produsul.
Toate prezentările vor fi unite printr-o misiune comună: a transmite publicului că prin acest abordare, instrument, metodă, proces sau tip de testare am influențat calitatea produsului și am îmbunătățit viața clientului.
Cu siguranță nu vor fi prezentări despre instrumente doar de dragul instrumentului. Toate prezentările incluse în program vor fi unite de un scop comun.
— Cine crezi că va fi interesat de ceea ce spui, pe cine vezi ca invitați la conferință?
Anastasia: Avem vorbitori pentru dezvoltatori care le pasă de soarta proiectului, produsului sau sistemului lor. De asemenea, va fi interesant pentru testerii și, din câte cred eu, în special pentru manageri. Prin manageri, mă refer la persoanele care iau decizii și pot influența soarta și dezvoltarea produsului, sistemului sau echipei în sine.
Aceștia sunt oameni care se întreabă cum să îmbunătățească calitatea produsului sau sistemului. La conferința noastră, vor afla despre diverse complexe de evenimente și vor putea înțelege ce nu este în regulă acum și ce trebuie schimbat.
Cred că principalul criteriu este să înțelegi că există o problemă cu calitatea și să vrei să influențezi situația. Probabil că nu vom reuși să ajungem din prima la cei care consideră că merge și așa.
— Ce părere ai, a ajuns industria să discute nu doar despre testare, ci și despre cultura calității?
Anastasia: Consider că a ajuns. Multe companii se îndepărtează acum de abordarea tradițională Waterfall în favoarea Agile. Se pune accent pe client, iar oamenii din echipe încep cu adevărat să se gândească la cum să creeze un produs de calitate. Chiar și în companiile enterprise, se produce o reorientare spre îmbunătățirea calității.
Judecând după numărul de întrebări care apar în comunitate, cred că este deja timpul. Nu sunt sigură că va fi o revoluție pe scară largă, dar mi-aș dori ca această schimbare de mentalitate să aibă loc.
— S-a înțeles! Vom încuraja cultura și vom schimba mentalitatea.
Conferința despre dezvoltarea de calitate a produselor IT va avea loc în Moscova pe 7 iunie. Știți din ce etape este format un produs de calitate, avem exemple de succes în combaterea bug-urilor, am testat metode populare în practică – avem nevoie de experiența voastră. proiectele voastre până pe 1 mai, iar Comitetul Programului va ajuta la focalizarea temei pentru o coerență generală a conferinței.
Alăturați-vă , unde discutăm despre calitate și conferință, abonați-vă la , pentru a fi la curent cu știrile programului.
Sursa: habr.com
