Përshëndetje, Habr!
Kemi një temë të re të rëndësishme - zhvillimi cilësor i produkteve IT. Shpesh flasim në HighLoad++ se si të bëjmë shërbimet e ngarkuara të shpejta, ndërsa në Frontend Conf - një ndërfaqe përdoruesi fantastike që nuk ngadalëson. Rregullisht kemi tema për testimin, dhe në DevOpsConf flasim për integrimin e proceseve të ndryshme, përfshirë testimin. Por për atë që mund të quhet cilësi në përgjithësi dhe si të punojmë kompleks mbi të - nuk kemi.
Do ta rregullojmë këtë në — do të zhvillojmë kulturën e mendimit për cilësinë e produktit përfundimtar për përdoruesin në çdo fazë të zhvillimit. Një zakon për të mos u përqendruar vetëm në zonën tonë të përgjegjësisë dhe për ta lidhur cilësinë jo vetëm me testuesit.
Poshtë do të flasim me kryetarin e komitetit programor, drejtorin e testimit në Tinkoff.Biznes, krijuesin e komunitetit QA në gjuhën ruse Anastasija Aseeva-Nguen për gjendjen e industrisë QA dhe misionin e konferencës së re.
— Nastya, përshëndetje. Të lutem, trego pak për veten.
Anastasia: Unë drejtoj testimin në bankë, përgjigjem për një ekip shumë të madh - kemi më shumë se 90 njerëz. Ne kemi një linjë të rëndësishme biznesi, ne përgjigjemi për ekosistemin për personat juridikë.
Kam studiuar në mekanikë dhe matematikë dhe fillimisht doja të bëhesha programues. Por kur më erdhi një ofertë interesante, vendosa të provoja veten si testuese. Siç është e çuditshme, kjo u bë thirrja ime. Tani e shoh të gjithë punën time në këtë industri.
Unë jam një adhurues i zellshëm i disiplinës së Quality Assurance. Më intereson se çfarë produkte krijohen, si i kushtohet rëndësi cilësisë në kompani, në ekip dhe në përgjithësi në procesin e zhvillimit.
Për mua është e qartë se komuniteti në këtë drejtim nuk është mjaft i pjekur, së paku në Rusi. Nuk e kuptojmë gjithmonë se sigurimi i cilësisë nuk është vetëm fakti i testimit të aplikacionit sipas kërkesave. Do të doja të ndryshoja këtë situatë.
— Ti përdor fjalët Quality Assurance dhe testim. Në sytë e një lajthitësi, këto dy terma shpesh i përfshijnë njëri-tjetrin. Çfarë i ndan ato, nëse e shqyrton thellë?
Anastasija: Në shumë raste nuk dallohen. Testimi është një pjesë e disiplinës së Sigurimit të Cilësisë, kjo është një aktivitet i drejtpërdrejtë – vetë fakti që unë po testoj diçka. Ka shumë lloje testimi në të vërtetë, dhe për lloje të ndryshme testimi janë përgjegjës njerëz të ndryshëm. Por, në Rusi, kur erdhi vala e outsourcing-ut që ofronte testues për kompani, testimi u kufizua në një lloj të vetëm.
Në shumicën e rasteve kufizohen vetëm në testimin funksional: kontrollojnë nëse ajo që kanë koduar zhvilluesit përputhet me specifikimin dhe gjithçka.
— Trego, të lutem, cilat janë disiplinat e tjera të sigurimit të cilësisë? Çfarë tjetër përveç testimit përfshihet këtu?
Anastasia: Sigurimi i Cilësisë është, para së gjithash, për krijimin e një produkti cilësor. Pra, ne pyesim se me cilët atribute cilësie duhet të disponojë produkti ynë. Përkatësisht, nëse e kuptojmë këtë, mund të krahasojmë se kush ndikon në këto atribute cilësie. Nuk ka rëndësi, zhvilluesi, menaxheri i projektit ose produktologu — është një person që ndikon në zhvillimin e produktit, në backlog-un e tij, në strategjinë e tij.
Testuesi fillon të kuptojë më mirë rolin e tij. Ai kupton se detyra e tij nuk është vetëm të testojë për përputhshmëri me kërkesat, por edhe të testojë kërkesat, të vërë në dyshim formulimet që vijnë nga produktologu, të zbulojë të gjitha kërkesat dhe pritjet e papara të klientit. Kur ne i ofrojmë një funksionalitet të ri klientit tonë, ne duhet të plotësojmë vërtet pritjet e tij dhe të zgjidhim shqetësimin e tij. Nëse do të mendojmë për të gjitha atributet e cilësisë, klienti do të jetë i kënaqur dhe do të kuptojë se kompania, produktin e të cilit po e përdor, vërtetë kujdeset për interesat e tij, dhe nuk punon me parimin "të shpërbëj një karakteristikë".
— Më duket se ajo që po e përshkruan tani është detyra e produktologut. Në parim, kjo nuk ka të bëjë me testimin dhe cilësinë – kjo është krejtësisht për menaxhimin e produktit, apo jo?
Anastasia: Po, deri diku. Sigurimi i Cilësisë nuk është një disiplinë për të cilën përgjigjet një person konkret. Tani ka një qasje të njohur në testim, e cila quhet Testimi AgileNë përkufizimin e tij thuhet qartë se është një qasje ekipore ndaj testimit, e cila përfshin një grup të caktuar praktikash. Për realizimin e kësaj qasjeje është përgjegjëse të gjithë ekipi, nuk është e nevojshme që në ekip të ketë patjetër një testues. I gjithë ekipi është orientuar për të ofruar vlerë për klientin dhe që kjo vlerë të përputhet me pritshmëritë e tij.
Pra, duket se cilësia ndërthuret pothuajse me të gjitha disiplinat përreth, duke vendosur kufij për gjithçka rreth?
Anastasia: E saktë. Kur mendojmë për të krijuar një produkt cilësor, fillojmë të mendojmë për atributet e ndryshme të cilësisë. Për shembull, si të verifikojmë që kemi realizuar me të vërtetë një funksion që i nevojitet klientit tonë.
Këtu del një lloj testimi, si UAT (testimi i pranimit nga përdoruesi). Fatkeqësisht, në Rusi ai praktikohet rrallë, por ndonjëherë është i pranishëm në ekipet SCRUM, si një demonstrim për klientin përfundimtar. Në kompanitë jashtë vendit, kjo është një formë testimi mjaft e zakonshme. Para se të hapim funksionalitetin për të gjithë klientët, ne fillimisht bëjmë UAT, dmth. ftojmë përdoruesin përfundimtar, i cili kryen testimin dhe menjëherë jep feedback - nëse produkti në të vërtetë përputhet me pritshmëritë dhe zgjidh dhimbjen. Vetëm pas kësaj ndodh zgjerimi për të gjithë klientët e tjerë.
Kështu që ne orientoheni në biznes, në klientin përfundimtar, por në të njëjtën kohë nuk harrojmë për teknologjinë. Cilësia e produktit varet gjithashtu shumë nga teknologjitë. Nëse kemi një arkitekturë të dobët, nuk do ta kemi të lehtë të publikojmë shpejt funksionet dhe të përputhemi me pritshmëritë e klientit. Mund të ketë shumë defekte kur përpiqemi të zgjerim, apo kur përpiqemi të bëjmë refaktorizimin ne mund të thyejmë diçka. E gjithë kjo do të ndikojë në kënaqësinë e klientit.
Nga kjo pikëpamje, arkitektura duhet të jetë e tillë që ne të mund të shkruajmë kod të pastër, i cili do të lejojë që të bëjmë shpejt ndryshime dhe të mos kemi frikë se do të thyejmë gjithçka. Që iteracionet e përmirësimit mos të zgjaten për muaj të tërë thjesht sepse kemi aq shumë legjaci, dhe duhet të kryejmë faza testimi të gjata.
Pra, tashmë janë të përfshirë zhvilluesit, arkitektët, produktologët, menaxherët e produkteve, vetë testuesit. Kush tjetër është i përfshirë në procesin e sigurimit të cilësisë?
Anastasia: Tani, le të imagjinojmë se ne tashmë ia kemi dorëzuar klientit këtë tipar. Është e qartë se menaxhimi i cilësisë së produktit është i rëndësishëm, edhe kur ai është në prodhim. Në këtë fazë, situatat me skenarë jo të dukshëm, të njohura si të mbeturina, mund të dalin në pah.
Pyetja e parë është se si punojmë me këto të mbeturina pasi e kemi lëshuar produktin? Si reagojmë, për shembull, ndaj ngarkesës? Klienti nuk do të jetë shumë i kënaqur nëse faqja ngarkohet për më shumë se 30 sekonda.
Këtu hyn në lojë operimi ose, siç e quajnë tani, DevOps. Në fakt, këta janë njerëzit që janë përgjegjës për operimin e produktit kur ai është tashmë në prodhim. Këtu përfshihen lloje të ndryshme monitorimi. Ka edhe një nënkategori të testimit - testimi në prodhim, kur ne i lejojmë vetes të mos testojmë diçka para lëshimit dhe ta testojmë menjëherë në prodhim. Ky është një seri masash, përballet nga pikëpamja e organizimit të infrastrukturës, që lejojnë reagimin e shpejtë ndaj incidenteve, ndikuar në to, dhe korrigjimin e tyre.
Infrastruktura është gjithashtu e rëndësishme. Shpesh ndodhin situata ku në kohën e testit, e pamundësueshme të sigurohemi se ne fakt kemi gjithçka që dëshirojmë t'i japim klientit. Lëshojmë në prodhim – dhe fillojmë të kapim situata të jo të dukshme. Dhe e gjitha kjo ndodh sepse infrastruktura në test nuk përputhet me infrastrukturen në prodhim. Këtu del një lloj i ri testimi — testimi i infrastrukturës. Këtu përfshihen konfiguracione të ndryshme, rregullime, migrimi i bazave të të dhënave, etj.
Këtu lind pyetja — ndoshta ekipi duhet të përdorë infrastruktura si kod.
Unë besoj se infrastruktura ndikon drejtpërdrejt në cilësinë e produktit.
Shpresoj se në konferencë do të ketë një prezantim me një rast real. Na shkruani nëse jeni të gatshëm të flisni nga përvoja juaj se si infrastruktura si kod ndikon në cilësi. Infrastruktura si kod lejon të kontrollohet më lehtë të gjitha rregullimet dhe të testojnë atë që përndryshe do të ishte e pamundur. Prandaj në procesin e zhvillimit të një produkti cilësor përfshihet edhe operimi.
— Dhe si qëndron çështja e analitikës dhe dokumentacionit?
Anastasia: Kjo i referohet më shumë sistemeve enterprise. Kur flasim për enterprise, menjëherë në mendje vijnë njerëz si analistët dhe analistët sistemorë. Ndonjëherë ato quhen shkrimtarë teknikë. Ata marrin një detyrë për të shkruar specifikimin dhe e realizojnë atë, për shembull, brenda një muaji.
Ka provuar disa herë se shkruarja e dokumentacionit të tillë çon në iteracione shumë të gjata zhvillimi dhe iteracione të gjata për përmirësime, sepse gjatë procesit të testimit dalin defekte dhe fillojnë kthimet. Në rezultat, shfaqen shumë qarqe që rrisin koston e zhvillimit. Për më tepër, kjo mund të sjellë vulnerabilitete. Ne sikur e kemi shkruar kodin referencë, por më pas bëmë ndryshime që shkatërrojnë arkitekturën e menduar në mënyrë ideale.
Si rezultat, kemi një produkt jo të mirë, sepse në arkitekturë tashmë janë shfaqur patch, kodi në disa vende nuk është mbuluar mjaftueshëm me teste, sepse afatet po ngushtohen dhe duhet të mbyllen sa më shpejt të jetë e mundur të gjithë defektet. Dhe kjo ndodh sepse në specifikimin fillestar nuk u morën parasysh të gjitha aspektet që duhej të realizoheshin.
Zhvilluesit nuk janë shkaktarë dhe nuk shkruajnë kod me qëllim gabimesh.
Nëse do të kishim menduar fillimisht një specifikim, në të cilin do të ishin përfshirë të gjitha aspektet e nevojshme, gjithçka do të realizohej pikërisht ashtu siç duhet. Por kjo është një utopi.
Ndoshta, të shkruash një specifikim të përsosur në 100 faqe është e pamundur. Prandaj duhet të mendojmë për mënyra alternative të shkruarjes së dokumentacionit, specifikimit, vendosjes së detyrave, që do të na afronin më afër realizimit të asaj që zhvilluesi të bënte pikërisht atë që duhet.
Këtu më vjen në mendje qasja nga Agile - historitë e përdoruesve me kriteret e pranimit. Kjo është më shumë e aplikueshme për ekipet që evolucionojnë në iteracione të vogla.
— Çfarë është për testimin e përdorshmërisë, lehtësinë e përdorimit të produktit, dizajnin?
Anastasia: Ky është një moment shumë i rëndësishëm, sepse në ekip ka dizajnerë. Zakonisht përdoren dizajnerët si një shërbim — ose një departament dizajni, ose një dizajner i jashtëm. Fatkeqësisht, ndodhin situata kur duket se dizajneri e dëgjoi produktologun dhe kreu atë që kuptoi. Por kur fillojmë iteracionin, zbulojmë se në të vërtetë nuk është bërë ashtu siç pritej: dizajneri harroi diçka, nuk e mendoi deri në fund funksionimin, sepse ai nuk është në ekip dhe nuk ndodhet në kontekst, ose zhvilluesi i frontend-it nuk e kuptoi plotësisht skicën e tij. Mund të nevojiten disa iteracione vetëm për shkak se ka një problem me kuptimin e dizajnit nga ana e zhvilluesit të frontend-it.
Përveç kësaj, ka një problem tjetër. Tani janë në rritje popullaritetin e sistemet e dizajnit. Ato janë në trend, por përfitimi nga to nuk është krejtësisht i qartë.
Kam hasur në mendimin se sistemet e dizajnit, nga njëra anë, e thjeshtojnë zhvillimin, por nga ana tjetër, imponojnë shumë kufizime në ndërfaqe.
Në përfundim, ne nuk po bëjmë një veçori të tillë që klienti dëshiron të marrë, por një të tillë që na përshtatet ne, sepse ne tashmë kemi disa kubikë nga të cilët mund ta ndërtojmë.
Më duket se duhet të kushtohet vëmendje kësaj teme dhe të mendohet, a e zgjidhim me të vërtetë dhimbjen e klientëve në përpjekjen për të thjeshtuar punën në dizajn.
— Kështu që duket se ka shumë tema që lidhen me Sigurinë e Cilësisë. Në Rusi ka një konferencë ku mund të diskutohet për to?
Anastasia: Ka konferencën më të vjetër për testimin, e cila këtë vit do të mbahet për herë të 25-të dhe quhet — Konferenca për sigurimin e cilësisë SQA Days. Kryesisht në të diskutohen mjetet dhe qasje të caktuara të testimit për testuesit funksionalë. Zakonisht, në prezantimet në SQA Days shqyrtohen thellësisht fushat specifike në zonën e përgjegjësisë së vetë testuesve, por jo aktivitetet kumulative.
Kjo ndihmon shumë për të kuptuar mjetet dhe qasjet e ndryshme se si të testohen bazat e të dhënave, API etj. Por nga njëra anë, nuk motivon përfshirjen në krijimin e një produkti më cilësor jo vetëm nga testimi. Ndërsa nga ana tjetër, testuesit nuk bëhen më të angazhuar në proces, për të menduar për qëllimin global të produktit dhe komponentin e tij biznesor.
Unë drejtoj një departament të madh, realizoj shumë intervista që në të vërtetë pasqyrojnë gjendjen e industrisë në përgjithësi. Zakonisht, djemtë tanë punojnë në enterprise, dhe ata kanë një zonë të qartë përgjegjësie. Kolegët që punojnë në projekte ndërkombëtare përdorin lloje të ndryshme testimi: ata mund të realizojnë teste ngarkese, teste performancës, dhe madje ndonjëherë teste sigurie, sepse ata vërtet ndihmojnë ekipin të sigurojë cilësinë e produktit.
Më pëlqen të mendoj që edhe në Rusia djemtë duhet të fillojnë të mendojnë se industria nuk përfundon me testimin funksional.
— Për këtë po organizojmë një konferencë të re QualityConf, e cila është e dedikuar cilësisë si një disiplinë tërësore. Mund të na tregosh më shumë për konceptin, cili është qëllimi kryesor i konferencës?
Anastasia: Ne duam të krijojmë një komunitet njerëzish të interesuar në të bërit e produkteve me cilësi të lartë. Të ofrojmë një platformë ku ata mund të vijnë, të dëgjojnë ligjërata dhe të dalin pas konferencës me një kuptim të qartë se çfarë duhet të ndryshojnë për të përmirësuar cilësinë.
Së shumti tani po dëgjoj kërkesat nga konsulenca për atë se çfarë të bëjmë kur ka probleme me testimin dhe cilësinë. Kur fillon të bisedosh me ekipet, shikon se problemi nuk është te vetë testuesit, por te mënyra se si është ndërtuar procesi. Për shembull, kur zhvilluesit mendojnë se janë përgjegjës vetëm për shkrimin e kodit, përgjegjësia e tyre përfundon pikërisht në momentin që ata e kalojnë detyrën në testim.
Nuk të gjithë mendojnë që kodi me cilësi të dobët, me arkitekturë të keqe, sjell probleme të mëdha për projektin. Nuk mendohet rreth kostos së gabimeve, se defektet që kalojnë në prodhim mund të sjellin kosto të mëdha për kompaninë dhe ekipin. Nuk ka një kulturë për të menduar rreth kësaj. Dua që gjatë konferencës të fillojmë ta përhapim këtë kulturë.
E kuptoj që kjo nuk është një inovatë. Edward Deming, autori i 14 postulateve të cilësisë, kishte shkruar për koston e gabimeve që në shekullin e kaluar. Kjo libër është baza e Quality Assurance si një disiplinë, por fatkeqësisht, zhvillimi modern e harron këtë.
— A do të planifikoni të diskutoni tema drejtpërdrejt në lidhje me testimin dhe mjetet?
Anastasia: Pranoj që do të ketë prezantime mbi mjetet. Ka mjaft mjete universale me anë të të cilave kompanitë dhe ekipet mund të ndikojnë në produkt.
Të gjitha prezantimet do të jenë globalisht të bashkuara nga një mision të përbashkët: të komunikojnë me audiencën se me anë të këtij qasje, mjeti, metode, procesi, tipit të testimit ne ndikojmë në cilësinë e produktit dhe përmirësojmë jetën e klientit.
Sigurisht që nuk do të kem prezantime për mjetin për vetë mjetin. Të gjitha prezantimet që do të përfshihen në program do të kenë një qëllim të përbashkët.
— Kush do të ketë interes për atë që po thua, kë keni parasysh si mysafirë të konferencës?
Anastasia: Ne do të kemi prezantime për zhvilluesit, të cilët nuk janë indiferentë ndaj fatit të projektit të tyre, produktit, sistemit. Po ashtu, do të jetë interesante për testuesit dhe, siç mendoj, veçanërisht për menaxherët. Me menaxherët kam parasysh ata që marrin vendime dhe mund të ndikojnë në fatin dhe zhvillimin e produktit, sistemit, ekipit gjithashtu.
Këta janë njerëz që bëjnë pyetje se si të rrisin cilësinë e produktit, sistemit. Në konferencën tonë ata do të mësojnë për komplekset e ndryshme të aktiviteteve dhe do të mund të kuptojnë se çfarë nuk është mirë tani, çfarë duhet të ndryshojnë.
Mendoj se kriteri kryesor është të kuptohet se diçka nuk është mirë me cilësinë dhe të dëshirohet të ndikosh në këtë. Ndoshta, nuk do të arrijmë të arrijmë te njerëzit që mendojnë se gjithçka është në rregull nga hera e parë.
— Si e mendon, industria në tërësi ka arritur në një pikë ku mund të flitet jo thjesht për testimin, por për kulturën e cilësisë?
Anastasia: Unë mendoj se ka arritur. Tani shumë kompani po largohen nga qasja tradicionale Waterfall drejt Agile. Po ndodh orientimi ndaj klientit, njerëzit në ekipe vërtet po fillojnë të mendojnë për mënyrat se si të krijojnë një produkt cilësor. Edhe në kompanitë enterprise ndodhin riorientime për rritjen e cilësisë.
Duke parë numrin e kërkesave që ndodhin në komunitet, mendoj se tashmë është koha. Nuk jam e sigurt, sigurisht, që do të jetë një revolucion i madh, por do të doja që ky ndryshim në mendje të ndodhte.
— Marrëveshje! Do të punojmë për të kultivuar kulturën dhe ndryshuar mendimin.
Konferenca për zhvillimin cilësor të produkteve IT do të ndodhë në Moskë më 7 qershorDini, se nga çfarë fazash përbëhet një produkt i mirë, kemi raste të suksesshme të luftimit të defekteve në prodhim, dhe kemi verifikuar metodologjitë populare në praktikën tonë — na nevojitet eksperienca juaj. të tuat kërkesat deri më 1 maj, dhe Komiteti Programor do të ndihmojë në fokusimin e temës për një koherencë të përgjithshme të konferencës.
Bashkohuni me , ku diskutojmë çështjet e cilësisë dhe konferencën, abonohuni në , për t'u mbajtur të informuar mbi lajmet e programit.
Burimi: habr.com
