Përshëndetje, Habr!
Ne kemi një temë të re të rëndësishme - zhvillimin e cilësishëm të produkteve IT. Shpesh flasim në HighLoad++ se si t'i bëjmë shërbimet me ngarkesë të lartë të shpejtë, dhe në Frontend Conf - një ndërfaqe të shkëlqyer përdoruesi që nuk ngadalëson. Rregullisht kemi tema lidhur me testimin, dhe DevOpsConf për integrimin e proceseve të ndryshme, duke përfshirë testimin. Por për atë që mund të quhet cilësi në përgjithësi dhe si mund të punojmë mbi të në mënyrë komplekse - nuk ka.
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 fokusuar vetëm në zonën tuaj të përgjegjësisë, dhe për të lidhur cilësinë jo vetëm me testuesit.
Më poshtë do të bisedojmë me kryetarin e komitetit programor, drejtuesin e testimit në Tinkoff.Biznes, krijuesin e komunitetit QA në gjuhën ruse Anastasia Aseeva-Nguyen rreth gjendjes së industrisë QA dhe misionit të konferencës së re.
- Nastya, përshëndetje. Të lutem, tregoni për veten.
Anastasia: Unë drejtoj testimin në bankë, kam përgjegjësinë për një ekip shumë të madh - kemi më shumë se 90 njerëz. Ne kemi një linjë të rëndësishme biznesi, ne jemi përgjegjës për ekosistemin për persona juridikë.
Kam studiuar në matematike dhe fillimisht doja të bëhem programues. Por kur më doli një ofertë interesante, vendosa të provoj veten si testuese. Siç ndodh ndonjëherë, kjo e gjeti të qenë thirrja ime. Tani, gjithë punën time e shoh pikërisht në këtë industri.
Unë jam një adhurues i pasionuar i disiplinës Quality Assurance. Më intereson se cilat produkte po krijohen, si përqendrohet cilësia 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, të paktën në Rusi. Nuk e kuptojmë gjithmonë se sigurimi i cilësisë nuk është vetëm fakti se po testojmë aplikacionin për përputhshmëri me kërkesat. Do të doja të ndihmoja në ndryshimin e kësaj situate.
- Përdor fjalët Quality Assurance dhe testim. Në sytë e publikut, këto dy terma shpesh ndërthuren. Çfarë i ndan ato, nëse thellohemi?
Anastasia: Në fakt, ato nuk ndahen. Testimi është një pjesë e disiplinës së Quality Assurance; është veprimtaria direkte - fakti se unë po testoj diçka. Ka shumë forma testimi, dhe për forma të ndryshme testimi përgjigjen njerëz të ndryshëm. Por në Rusi, kur erdhen valët e jashtme që ofrojnë testues për kompanitë, testimi përfundoi në një lloj të vetëm.
Në shumicën e rasteve, kufizohen vetëm në testimin funksional: kontrollojnë se gjithçka që kanë koduar zhvilluesit përputhet me specifikimet dhe kaq.
- Të lutem, tregoni për disa disiplinat e tjera të sigurimit të cilësisë? Çfarë tjetër, përveç testimit, përfshihet këtu?
Anastasia: Quality Assurance është, para se gjithash, për krijimin e një produkti cilësor. Pra, ne pyesim veten se cilat atributet e cilësisë duhet të ketë produkti ynë. Në përputhje, nëse kuptojmë këtë, mund të përputhim se kush ndikon në këto atributet e cilësisë. Nuk ka rëndësi, zhvillues, menaxher projekti ose produktolog ato janë persona që ndikojnë në zhvillimin e produktit, në backlogun e tij, në strategjinë e tij.
Testuesi fillon ta kuptojë më mirë rolin e tij. Ai kupton se detyra e tij nuk është vetëm të testojë përputhjen me kërkesat, por edhe të testojë kërkesat, të vërë në pikëpyetje formulimet që vijnë nga produktologu, të zbulojë të gjitha kërkesat e padukshme dhe pritjet e klientit. Kur ne ofrojmë një funksionalitet të ri për klientin tonë, ne duhet të plotësojmë vërtet pritjet e tij dhe të zgjidhim dhimbjen e tij. Nëse ne mendojmë për të gjitha atributet e cilësisë, klienti do të jetë i kënaqur dhe do të kuptojë se kompania, produktin e së cilës po përdor, me të vërtetë i intereson atij, dhe nuk punon sipas parimit "thjesht të lëshojmë një veçori."
- Duket se ajo që sapo përshkrove, është detyra e produktologut. Në përgjithësi, kjo nuk ka të bëjë me testimin dhe cilësinë - kjo është për menaxhimin e produktit, apo jo?
Anastasia: Po, përfshirë. Quality Assurance nuk është një disiplinë për të cilën përgjigjet një person i caktuar. Tani ka një drejtim të njohur në testim, një qasje që quhet Agile Testing. Në përkufizimin e saj, është qartë se kjo është një qasje ekipore ndaj testimit, e cila përfshin një grup praktikash të caktuara. Për implementimin e kësaj qasje përgjigjet e gjithë ekipi, nuk është e domosdoshme që në ekip të ketë një testues. E gjithë ekipi është i orientuar për të ofruar vlerë për klientin dhe që kjo vlerë t'i përgjigjet pritjeve të tij.
— Prahët, a ndodhet që cilësia të prekë pothuajse të gjitha disiplinat përreth, duke vendosur kufij për gjithçka?
Anastasia: E saktë. Kur mendojmë për atë që duam të krijojmë një produkt cilësor, fillojmë të mendojmë për atributet e ndryshme të cilësisë. Për shembull, si të verifikojmë që me të vërtetë kemi realizuar një tipar që është i nevojshëm për klientin tonë.
Këtu del në pah një formë testimi si UAT (testimi i pranueshmërisë nga përdoruesi). Fatkeqësisht, në Rusi ai praktikisht nuk praktikohen, por ndonjëherë është i pranishëm në ekipet SCRUM, si një demostratë për klientin përfundimtar. Në kompanitë e huaja, ky është një lloj testimi mjaft i zakonshëm. Para se të hapim funksionalitetin për të gjithë klientët, fillimisht e bëjmë UAT, dmth. ftojmë konsumatorin përfundimtar, i cili kryen testimin dhe menjëherë jep feedback - a përputhet produkti me pritjet dhe zgjidh dhimbjet. Vetëm pas kësaj ndodh zgjerimi për të gjithë klientët e tjerë.
Pra, ne orientoheshim në biznes, në klientin përfundimtar, por në të njëjtën kohë nuk e harrojmë teknologjinë. Nga teknologjitë varet shumë cilësia e produktit. Nëse kemi një arkitekturë të keqe, nuk do të jemi në gjendje të lëshojmë shpejt tipare dhe të përputhemi me pritjet e klientit. Mund të ketë shumë bugs gjatë përpjekjes për të zgjeruar, ose gjatë përpjekjeve për të bërë refaktorim mund të thyejmë diçka. Të gjitha këto do të ndikojnë në kënaqësinë e klientit.
Nga kjo këndvështrim, arkitektura duhet të jetë e tillë që të mund të shkruajmë kod të pastër, i cili lejon të bëjmë ndryshime shpejt dhe të mos kemi frikë se do të shkatërrojmë gjithçka. Me qëllim që iteracionet përmirësuese të mos zgjaten për disa muaj thjesht sepse kemi aq shumë trashëgimi dhe duhet të bëjmë etapa të gjata testimi.
— Pra, tashmë kemi 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 imagjinoni se ne tashmë i kemi dorëzuar klientit një tipar. E qartë, cilësia e produktit duhet të ndiqet edhe kur ai është tashmë në prodhim. Në këtë fazë, mund të shfaqen situata me skenarë të paqartë, këto quhen bugs.
Pyetja e parë - si punojmë me këto bugs pasi kemi lëshuar produktin? Si reagojmë, për shembull, ndaj ngarkesës? Klienti do të jetë jo shumë i kënaqur nëse faqja ngarkohet për më shumë se 30 sekonda.
Këtu hyjnë në lojë operacionet ose, siç i quajnë tani, DevOps. Në fakt, këta janë njerëz që janë përgjegjës për funksionimin e produktit, kur ai është tashmë në prodhim. Këtu përfshihen lloje të ndryshme monitorimi. Ka edhe një nënlloj testimi - testimi në prodhim, kur na lejohet të mos testojmë diçka para publikimit dhe ta testojmë menjëherë në prodhim. Këto janë një sërë aktivitetesh nga pika e organizatës së infrastrukturës, të cilat lejojnë të reagojmë shpejt ndaj incidenteve, të ndikojmë në to, dhe t'i riparojmë.
Infrastruktura është gjithashtu e rëndësishme. Shpesh ndodhin situata kur gjatë testit, nuk është e mundur të sigurohemi që kemi të gjithë atë që dëshironim t'i ofronim klientit. E publikojmë në prodhim - dhe fillojmë të gjejmë situata të paqartë. Dhe të gjitha këto ndodhin sepse infrastruktura në test nuk përputhet me infrastrukturën në prodhim. Nga kjo lind një lloj testi i ri - testimi i infrastrukturës. Këtu përfshihen konfigurime të ndryshme, cilësime, migrimi i bazave të të dhënave, etj.
Këtu lind pyetja - ndoshta ekipi duhet të përdorë infrastrukturën si kod.
Unë besoj se infrastruktura ndikon drejtpërdrejt në cilësinë e produktit.
Shpresoj se në konferencë do të ketë një referat me një rast real. Na shkruani, nëse jeni të gatshëm të flisni për përvojën tuaj se si infrastruktura si kod ndikon në cilësinë. Infrastruktura si kod mundëson të kontrolloni më lehtë të gjitha cilësimet dhe të testoni atë që në të kundërt do të ishte thjesht e pamundur. Prandaj, në procesin e zhvillimit të një produkti cilësor, përfshihet edhe operacioni.
— Dhe çfarë për analitikën dhe dokumentacionin?
Anastasia: Kjo i përket më shumë sistemeve enterprise. Kur flasim për enterprise, në mendje menjëherë vijnë njerëz si analistët dhe analistët e sistemeve. Ndonjëherë ata quhen krijues të dokumentacioneve. Ata marrin një detyrë për të shkruar specifikime dhe e përmbushin atë, për shembull, brenda një muaji.
Është provuar shumë herë se shkrimi i tillë i dokumentacionit çon në iteracione shumë të gjata të zhvillimit dhe të sistemimit, sepse gjatë testimit zbulohet një numër gabimesh, duke shkaktuar kthime. Si rezultat, krijohen shumë cikle që rrisin kostot e zhvillimit. Për më tepër, kjo mund të sjellë dobësi. Duket se kemi shkruar kodin standard, por më pas kemi bërë modifica që prishin arkitekturën e menduar në mënyrë të përsosur.
Si rezultat, nuk arrijmë një produkt të cilësisë së lartë, sepse në arkitekturë kanë filluar të shfaqen patch-e, kodet në disa vende nuk janë të mbuluara mjaftueshëm me teste, sepse afatet po shtyjnë, duhet të mbyllen sa më shpejt të mundemi të gjitha gabimet. Dhe kjo ndodh për shkak se në specifikimin e fillimit nuk ishin marrë parasysh të gjitha aspektet që duhej të realizoheshin.
Zhvilluesit nuk janë të dëmshëm dhe nuk shkruajnë kode me gabime me qëllim.
Po të kishim menduar fillimisht specifikimin, në të cilin do ishin përfshirë të gjitha momentet e nevojshme, gjithçka do ishte realizuar ashtu siç duhej. Por kjo është utopi.
Ndoshta nuk është e mundur të shkruhet një specifikim ideal në 100 faqe. Prandaj duhet të mendojmë për mënyra alternative të shkruajtjes së dokumentacionit, specifikimeve, dorezimit të detyrave që do na afronin drejt realizimit të asaj që zhvilluesi duhet të bëjë.
Këtu vijnë në mendje qasjet nga Agile - historitë e përdoruesve me kriteret e pranimit. Kjo është më shumë e përshtatshme për ekipet që e zhvillojnë punën në iteracione të vogla.
- Çfarë është me testimin e përdorshmërisë, lehtësisë së përdorimit të produktit, dizajnit?
Anastasia: Ky është një moment shumë i rëndësishëm, sepse në ekip ka dizajnerë. Shpeshherë, dizajnerët trajtohen si një shërbim - ose një departament dizajni, ose një dizajner në jashtë. Shpesh ndodhin situata kur duket se dizajneri e ka dëgjuar produktologun dhe ka bërë atë që ka kuptuar. Por kur fillojmë iteracionin, zbulojmë se në të vërtetë është bërë diçka tjetër nga ajo që prisnim: dizajneri ka harruar diçka, nuk e ka menduar deri në fund sjelljen sepse ai nuk është në ekip dhe në kontekst, ose zhvilluesi i front-end nuk e ka kuptuar deri në fund modelin e tij. Mund të nevojiten disa iteracione vetëm për shkak se ka një problem me kuptimin e dizajnit nga zhvilluesi i front-end.
Për më tepër, ka një problem tjetër. Tani po fiton popullaritet sistemi i dizajnit. Ata janë në trend, por përfitimi nga ta nuk është krejtësisht i qartë.
Jam ballë përballë mendimit se sistemet e dizajnit, nga njëra anë, e thjeshtojnë zhvillimin, ndërsa nga ana tjetër - imponojnë shumë kufizime mbi ndërfaqen.
Si rezultat, ne krijojmë një veçori që klienti do të dëshironte ta merrte, por që është e përshtatshme për ne, sepse ne kemi tashmë disa kubikë nga të cilët mund ta bëjmë.
Më duket se është e rëndësishme të tërheqim vëmendjen në këtë temë dhe të pyesim veten nëse në përpjekjen për të thjeshtuar punën në dizajn ne zgjidhim dhimbjen e klientit.
- Kështu, ka një numër të mahnitshëm temash që lidhen me Sigurinë e Cilësisë. A ka një konferencë në Rusi ku mund t'i diskutojmë të gjitha kë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 qasjet specifike të testimit për testuesit funksionalë. Zakonisht, në paraqitjet e SQA Days shqyrtohen thellësisht fusha specifike në përgjegjësinë e vetë testuesve, por jo ngjarje të përbashkëta.
Kjo ndihmon shumë për të kuptuar mjete të ndryshme dhe qasje se si të testosh bazat e të dhënave, API, etj. Por nga njëra anë, nuk motivon të angazhohen në krijimin e një produkti më cilësor jo vetëm testimi. Nga ana tjetër, testuesit nuk angazhohen më shumë në proces, për të menduar për qëllimin global të produktit dhe komponentin e tij biznesor.
Unë drejtoj një departament të madh, zhvilloj shumë intervista që në të vërtetë lejojnë për të paraqitur gjendjen e industrisë në përgjithësi. Zakonisht, djemtë tanë punojnë në enterprises dhe kanë një zonë të qartë përgjegjësie. Kolegët që punojnë në projekte ndërkombëtare përdorin lloje të ndryshme testimi: ata vetë mund të bëjnë testimin e ngarkesës, testimin e performancës, dhe madje ndonjëherë testimin e sigurisë (security testing), sepse ata vërtet ndihmojnë ekipin për të siguruar cilësinë e produktit.
Do të dëshiroja që djemtë tanë në Rusi gjithashtu të fillonin të mendonin se industria nuk përfundon me testimin funksional.
— Ne për këtë kemi organizuar konferencën e re QualityConf, e cila është përkushtuar cilësisë si një disiplinë të tërë. Mund të na tregosh më shumë për idenë, cila është qëllimi kryesor i konferencës?
Anastasia: Ne duam të krijojmë një komunitet njerëzish të interesuar për të prodhuar produkte me cilësi të lartë. Të ofrojmë një platformë ku ata të mund të vijnë, të dëgjojnë prezantime dhe të dalin nga konferenca me një kuptim të qartë se çfarë duhet të ndryshojnë për të përmirësuar cilësinë.
Shumë shpesh dëgjoj tani kërkesat nga konsulenca, çfarë duhet të bëjmë kur ka probleme me testimin, me cilësinë. Kur fillon të bisedosh me ekipet, sheh se problemi nuk është te testuesit, por tek mënyra se si është organizuar procesi. Për shembull, kur zhvilluesit mendojnë se ata janë përgjegjës vetëm për shkruarjen e kodit, përgjegjësia e tyre përfundon pikërisht në momentin kur e kalojnë detyrën për testim.
Nuk mendojnë të gjithë se kodi i shkruar keq me një arkitekturë të dobët sjell probleme të mëdha për projektin. Nuk mendojnë për koston e gabimeve, se defektet që kalojnë në prodhim mund të rezultojnë në shpenzime të mëdha për kompaninë dhe ekipin. Nuk ka një kulturë që të mendohet për këtë. Dua që në konferencë të fillojmë ta përhapim këtë kulturë.
E kuptoj që kjo nuk është një inovacion. Edward Deming, autori i 14 postulave të cilësisë, ka shkruar për kostot e gabimeve që në shekullin e kaluar. Kjo është baza mbi të cilën mbështetet Sigurimi i Cilësisë si disiplinë, por, fatkeqësisht, zhvillimi modern e ka harruar këtë.
— A planifikoni të diskutoni tema të drejtpërdrejta mbi testimin dhe mjetet?
Anastasia: Pranoj se do të ketë prezantime mbi mjete. Ka mjete mjaft universale, me ndihmën e të cilave kompanitë dhe ekipet mund të ndikojnë në produkt.
Të gjitha prezantimet do të bashkohen nën një qëllim të vetëm: të shpallin për publikun se me ndihmën e këtij qasje, mjeti, metode, procesi, lloj testimi ne kemi avancuar cilësinë e produktit dhe kemi përmirësuar jetën e klientit.
Nuk do të kemi prezantime për mjete thjesht për t'i pasur ato. Të gjitha prezantimet që do të përfshihet në program do të përfshijnë një qëllim të përbashkët.
— Kush do të jetë i interesuar për atë që po thua, kë shikon si mysafirë të konferencës?
Anastasia: Do të kemi prezantime për zhvilluesit, të cilëve u intereson fati i projektit të tyre, produktit, sistemit. Njësoj do t'u interesojë testuesve dhe, siç mendoj, veçanërisht menaxherëve. Nga menaxherët kuptoj ata që marrin vendime dhe mund të ndikojnë në fatin dhe zhvillimin e produktit, sistemit, ekipit gjithashtu.
Këta janë njerëz që pyesin se si të përmirësojnë cilësinë e produktit, sistemit. Në konferencën tonë ata do të mësojnë rreth kompleksitetit të aktiviteteve dhe do të mund të kuptojnë se çfarë nuk shkon aktualisht, çfarë duhet të ndryshojnë.
Mendoj se kriteri kryesor është të kuptosh që diçka nuk shkon me cilësinë dhe të kesh dëshirë të ndikosh në të. Ndoshta, nga hera e parë nuk do të arrijmë të tërheqim ata që mendojnë se gjithçka është në rregull.
— Si mendon, industria në tërësi është e gatshme për të diskutuar jo thjesht për testimin, por për kulturën e cilësisë?
Anastasia: Unë mendoj se është e gatshme. Tani shumë kompani po kalojnë nga qasja tradicionale Waterfall në atë Agile. Po orientohen drejt klientit, njerëzit në skuadra vërtet po fillojnë të mendojnë sesi të krijojnë produkte me cilësi të lartë. Edhe në kompanitë enterprise vidhet përqendrimi mbi rritjen e cilësisë.
Duke gjykuar nga numri i kërkesave që dalin në komunitet, mendoj se ka ardhur koha. Nuk jam e sigurt se kjo do të jetë një revolucion masiv, por do të më pëlqente të ndodhte ky ndryshim në mendje.
— Marrëveshje! Do t'i japim prioritet kulturës dhe do të ndryshojmë mendësinë.
Konferenca për zhvillimin e produkteve IT me cilësi do të ndodhi në Moskë më 7 qershor. E dini, nga cilët etapa përbën produktin me cilësi, kemi raste suksesi të luftës me defektet në prodhim, kemi tested metode të njohura - na nevojitet përvoja juaj. kërkesat tuaja deri më 1 maj , ndërsa Komiteti Programor do të ndihmojë në fokusimin e temës për kohezionin e përgjithshëm të konferencës.Bashkohuni në
bisedën , për të qenë në dijeni të lajmeve të programit. , чтобы быть в курсе новостей программы.
Burimi: habr.com
