Tere, Habr!
Meil on uus oluline teema – kvaliteetne IT-toodete arendus. Räägime sageli HighLoad++-l, kuidas muuta koormatud teenuseid kiireks, ja Frontend Confis – suurepärasest kasutajaliidest, mis ei külmuta. Regulaarsetel üritustel käsitleme testimist, samuti DevOpsConfis erinevate protsesside ühendamist, sealhulgas testimist. Kuid kvaliteedi laiemast mõistmisest ja kompleksest tööst selle nimel ei räägita.
Parandame selle – me edendame kultuuri, kus mõeldakse lõppkasutaja toote kvaliteedile iga arendusetapi jooksul. Harjumust mitte jääda kinni oma vastutusalasse ning seostada kvaliteeti mitte ainult testijatega.
Allpool räägime programmi komitee juhiga, Tinkoff.Bisnessi testimise juhiga, vene keelt kõneleva QA-ühiskonna looja Anastasia Aseeva-Ngueniga QA-valdkonna olukorrast ja uue konverentsi missioonist.
– Nastja, tere! Palun räägi meile endast.
Anastasia: Ma juhin testimist pangas, vastutan väga suure meeskonna eest — meid on üle 90 inimese. Meil on oluline äriliin, me vastutame äriühingute ökosüsteemi eest.
Õppisin matemaatika- ja loodusteaduste osakonnas ja algselt tahtsin saada programmeerijaks. Kuid kui sain huvitava ettepaneku, otsustasin proovida end testijana. Ootamatult osutus see minu kutsumuseks. Nüüd näen kogu oma tööd just selles valdkonnas.
Olen Quality Assurance’i innukas toetaja. Mind huvitab, milliseid tooteid luuakse, kuidas kvaliteediga ettevõttes, meeskonnas ja üldiselt arendusprotsessis suhtutakse.
Minu jaoks on ilmne, et kogukond selles suunas on piisavalt küps, vähemalt Venemaal. Me ei mõista alati, et kvaliteedi tagamine ei tähenda ainult rakenduse testimist nõuetele vastavuse osas. Sooviksin seda olukorda muuta.
— Sa kasutad termineid Quality Assurance ja testimine. Tavaoma silmis kattuvad need kaks mõistet väga tihti. Milles need erinevad, kui süvitsi kaevata?
Anastasia: Tegelikult nad ei erine. Testimine on osa kvaliteedi tagamise distsipliinist, see on otsene tegevus - lihtsalt fakt, et ma midagi testin. Testimise liike on tõeliselt palju, ja erinevate testimisliikide eest vastutavad täiesti erinevad inimesed. Ent meil Eestis, kui tuli sisse voog outsourced'i teenuseid, kes toovad testijaid ettevõtetesse, on testimine piirdunud peamiselt ühe liigiga.
Enamikul juhtudel piirdutakse ainult funktsionaalsete testidega: kontrollitakse, kas see, mis arendajate poolt on kirjutatud, vastab spetsifikatsioonile.
— Palun räägi, millised on veel kvaliteedi tagamise distsipliinid? Mis veel peale testimise siia kuulub?
Anastasia: Kvaliteedi tagamine on eelkõige seotud kvaliteetsete toodete loomisega. See tähendab, et me küsimise, millised kvaliteedi atribuudid peaks meie tootel olema. Vastavalt sellele, kui me seda mõistame, saame võrrelda, kes mõjutab neid kvaliteedi atribuute. Ei ole oluline, kas see on arendaja, projektijuht või tootejuht — see on inimene, kes mõjutab toote arengut, selle backlog'i ja strateegiat.
Testija hakkab paremini mõistma oma rolli. Ta mõistab, et tema ülesanne ei ole mitte ainult testida vastavust nõudmistele, vaid ka testida nõudmisi, seada kahtluse alla tootejuhi väljendused, paljastada kõik varjatud nõudmised ja kliendi ootused. Kui me tarnime oma kliendile uue funktsionaalsuse, peame tõeliselt rahuldama tema ootusi ja lahendama tema valupunkte. Kui me mõtleme kõigile kvaliteedi атрибüütidele, on klient rahul ja ta mõistab, et ettevõte, mille toodet ta kasutab, tõeliselt hoolib tema huvidest, mitte ei tööta põhimõttel „lihtsalt lase funktsionaalsus välja”.
— Tundub, et see, mida sa praegu kirjeldasid, on tootejuhi ülesanne. See ei ole põhimõtteliselt testimise ega kvaliteedi küsimus — see on tegelikult seotud tootehaldusega, eks?
Anastasia: Sealhulgas. Kvaliteedi tagamine ei ole distsipliin, mille eest vastutab üks konkreetne inimene. Praegu on testimises populaarne suundumus, lähenemine, mida nimetatakse Agile Testing. Selle määratlemisel öeldakse selgelt, et see on meeskonna lähenemine testimisele, mis hõlmab teatud praktikate komplekti. Selle lähenemise elluviimise eest vastutab kogu meeskond, isegi ei ole vajalik, et meeskonnas oleks testija. Kogu meeskond on suunatud sellele, et pakkuda väärtust kliendile ning et see väärtus vastaks tema ootustele.
— Tundub, et kvaliteet katab peaaegu kõik ümbritsevad distsipliinid, seades piirid kõigele ümber?
Anastasia: Õige. Kui mõtleme, et soovime luua kvaliteetset toodet, hakkame mõtlema erinevatele kvaliteediomadustele. Näiteks, kuidas kontrollida, et oleme tegelikult loonud funktsiooni, mis on meie kliendile vajalik.
Siin kerkib esile selline testimise tüüp nagu UAT (user acceptance testing). Kahjuks on see Venemaal harva praktiseeritav, kuid mõnikord esineb see SCRUM meeskondades, kui demo lõppkasutajale. Lä海外 компанýes on see üsna levinud testimismeetod. Enne, kui avame funktsionaalsuse kõigile klientidele, teeme esmalt UAT, kutsudes lõppkasutaja, kes viib läbi testimise ja annab kohe tagasisidet — kas toode vastab ootustele ja lahendab probleemi. Alles pärast seda toimub laienemine kõigile teistele klientidele.
See tähendab, et suuname oma tähelepanu äridele, lõppkasutajatele, kuid samas ei unusta tehnoloogiat. Tehnoloogia kvaliteet mõjutab tugevalt ka toote kvaliteeti. Kui meil on halb arhitektuur, siis ei saa me funktsioone kiiresti välja anda, et vastata kliendi ootustele. Laiendamisel võivad tekkida palju vigu või refaktoreerimise katsetamisel võime midagi katki teha. Kõik see mõjutab kliendirahulolu.
Sellest vaatenurgast peab arhitektuur olema selline, et suudame kirjutada puhta koodi, mis võimaldab kiireid muudatusi teha, kartmata, et kõik laguneb. Iteratsioonid ei tohi venida mitme kuuni lihtsalt seetõttu, et meil on nii palju pärandkoodi ja testimise etappide jaoks on vaja teha pikaajalisi protseduure.
— Kokku on juba kaasatud arendajad, arhitekid, tootejuhid, tootearendajad, testijad. Kes veel on kvaliteedi tagamise protsessis kaasatud?
AnastasiaNüüd kujutame ette, et oleme juba kliendile omaduse tarninud. Ilmselgelt tuleb toote kvaliteedi üle järelevalvet teostada, isegi kui see on juba tootmisel. Sellel etapil võivad ilmneda olukorrad, kus esinevad mitteilmsed stsenaariumid, nn vead.
Esimene küsimus on - kuidas me nende vigadega tegeleme pärast seda, kui toode on välja lastud? Kuidas me näiteks reageerime koormusele? Klient ei ole eriti rahul, kui leht laadib rohkem kui 30 sekundit.
Siin tuleb mängu ekspluateerimine või, nagu nüüd öeldakse, DevOps. Tegelikkuses on need inimesed, kes vastutavad toote töö korraldamise eest, kui see on juba tootmises. Siia kuuluvad erinevad jälgimise viisid. On isegi alaliik testimisest — tootmises testimine, kus me lubame endale midagi mitte testida enne juurutamist ja testime kohe tootmises. See on rida tegevusi infrastruktuuri korraldamise osas, mis võimaldavad kiiresti reageerida sündmusele, mõjutada seda ja parandada.
Infrastruktuur on samuti oluline. Tihti tekivad olukorrad, kus testi ajal ei suuda me veenduda, et meil on tõeliselt kõik see, mida me soovime kliendile pakkuda. Juurutame tootmisse — ja hakkame tabama ebatavalisi olukordi. Ja see kõik juhtub, kuna testi infrastruktuur ei vasta tootmise infrastruktuurile. Siit tuleneb uus testimise liik — infrastruktuuri testimine. See hõlmab erinevaid konfiguratsioone, seadistusi, andmebaaside migreerimist jne.
Siit tekib küsimus — võib-olla peab meeskond kasutama infrastruktuuri kui koodi.
Usun, et infrastruktuur mõjutab otseselt toote kvaliteeti.
Loodan, et konverentsil tehakse ettekandeid reaalsete juhtumite põhjal. Kirjutage meile, kui olete valmis rääkima oma kogemustest, kuidas infrastruktuur kui kood mõjutab kvaliteeti. Infrastruktuur kui kood võimaldab hõlpsamini kontrollida kõiki seadistusi ja testida seda, mida muidu lihtsalt ei oleks võimalik. Seetõttu kaasatakse kvaliteetse toote arendusprotsessi ka hooldus.
— Aga mis on analüütika ja dokumentatsiooni suhtes?
Anastasia: See kehtib rohkem enterprise süsteemide kohta. Kui räägime enterprise'ist, tulevad kohe meelde sellised inimesed nagu analüütikud ja süsteemianalüütikud. Mõnikord nimetatakse neid tehnilisteks kirjanikeks. Nad saavad ülesande kirjutada spetsifikatsiooni ja täidavad seda näiteks kuu aega.
On tõestatud, et sellise dokumentatsiooni koostamine viib pikaajaliste arendus- ja täiustamisetappideni, kuna testimise käigus tuvastatakse vigu, mille tõttu algavad tagasitulekud. Tulemuseks on palju silmuseid, mis suurendavad arenduskulusid. Lisaks võivad need tuua kaasa haavatavusi. Me oleme küll saanud kirjutada malli koodi, kuid seejärel tehtud muudatused võivad rikkuda ideaalselt läbimõeldud arhitektuuri.
Kokkuvõttes saame mitte täiesti kvaliteetse toote, kuna arhitektuuri on juba tekkinud plaasterdusi, kood on mõnes kohas piisavalt katmata testidega, kuna tähtaeg pingutab ja kõik vead tuleb kiirelt parandada. Ja see kõik juhtus, kuna algses spetsifikatsioonis ei olnud arvesse võetud kõiki teemasid, mis tuleb ellu viia.
Arendajad ei ole kahjurid ega kirjuta teadlikult vale koodi.
Kui oleksime alguses välja mõelnud spetsifikatsiooni, mis kataks kõik vajalikud aspektid, oleks kõik ellu viidud just nii, nagu vaja. Kuid see on utoopia.
Tõenäoliselt ei ole ideaalset 100-leheküljelist spetsifikatsiooni võimalik kirjutada. Seetõttu tuleb mõelda alternatiivsetele viisidele dokumentatsiooni kirjutamiseks, spetsifitseerimisele, ülesannete seadmiseks, mis viiks meid lähemale sellele, et arendaja teeks tõeliselt vajalikku.
Siia tuleb meelde Agile'i lähenemine — kasutajaloode koos aktsepteerimise kriteeriumidega. See sobib rohkem meeskondadele, kes arenevad väikeste iteratsioonide kaudu.
— Kuidas on kasutatavuse testimise, toote kasutusmugavuse ja disainiga?
Anastasia: See on väga oluline punkt, sest meeskonnas on disainerid. Enamasti kasutatakse disainereid teenusena — kas disainerite osakond või väliskaudse disainerina. Tihti esinevad olukorrad, kus disainer on küll toote töötajat kuulnud ja tegi seda, mida ta mõistis. Kuid kui hakkame iteratsiooni, selgub, et tegelikult ei ole tehtud seda, mida oodati: disainer unustas midagi, ei mõelnud tervikuna käitumist läbi, sest ta ei ole meeskonnas ega kontekstis, või front-end arendaja ei mõistnud lõpuni tema maketti. Võib osutuda vajalikuks mitu iteratsiooni ainult sellepärast, et esineb probleem front-end arendaja arusaamises disainist.
Lisaks on olemas veel üks probleem. Praegu on disainisüsteemid järjest populaarsemad. Need on müügis, kuid nende kasu ei ole sugugi ilmne.
Ma kohtan arvamust, et disainisüsteemid, ühelt poolt, lihtsustavad arendust, kuid teiselt poolt toovad nad kaasa palju piiranguid liidesele.
Kokkuvõttes ei tee me sellist funktsiooni, mida klient soovib, vaid sellise, mis on meile mugav, sest meil on juba teatud tükkidest, millest me saame selle teha.
Mulle tundub, et sellele teemale tasub tähelepanu pöörata ja mõelda, kas tõepoolest püüdes disaini tööd lihtsustada, me lahendame kliendi muret.
— Tulemuseks on üllatavalt palju teemasid, mis on seotud kvaliteedi tagamisega. Venemaal on konverents, kus saab kõiki neid arutada?
Anastasia: Eestis toimub vanim teste konverents, mis sel aastal toimub juba 25. korda ja kannab nime – kvaliteedi tagamise konverents SQA Days. Konverentsil arutatakse peamiselt tööriistu ja konkreetseid testimise lähenemisviise funktsionaalsetele testijatele. Tüüpiliselt käsitletakse SQA Days ettekannetes süvitsi teste areaale, mis kuuluvad testijate vastutusvaldkonda, kuid mitte keeruliste küsimustega.
See aitab tõeliselt erinevates tööriistades ja lähenemisviisides orienteeruda, kuidas testida andmebaase, API-sid jne. Kuid samas ei motiveeri see kaasama mitte ainult testimist, vaid aitab kaasa ka kvaliteetsemate produktide loomisele. Teisest küljest ei muutu testijad protsessi osas aktiivsemaks, et mõelda toote globaalsele eesmärgile ja selle ärilistele aspektidele.
Ma juhin suurt osakonda, viin läbi palju intervjuusid, mis tegelikult annavad ülevaate kogu valdkonna seisust. Reeglina töötavad meie inimesed enterprise-sektoris ja neil on selged vastutusvaldkonnad. Kollegid, kes töötavad rahvusvahelistes projektides, rakendavad erinevaid testimise liike: nad saavad ise teha koormustestimist, jõudlustestimist ja isegi mõnikord turvatestimist, sest nad tõepoolest aitavad meeskonnal tagada toote kvaliteeti.
Mulle oleks hea meel, kui meie Venemaal inimesed hakkaksid ka mõtlema, et funktsionaalne testimine ei ole ainus, millega ala piirdub.
— Selleks me korraldame uut konverentsi QualityConf, mis on pühendatud kvaliteedile kui terviklikule distsipliinile. Räägi ideest lähemalt, mis on konverentsi peamine eesmärk?
Anastasia: Me tahame luua kogukonna, kus inimesed on huvitatud kvaliteetsete toodete arendamisest. Soovime pakkuda platvormi, kuhu nad saavad tulla, kuulata ettekandeid ja lahkuda konverentsilt konkreetse arusaamaga, mida nad peavad enda juures muutma kvaliteedi parandamiseks.
Viimasel ajal kuulen sageli nõudmist konsultatsioonidelt, mis puudutab seda, mida teha, kui esinevad probleemid testimise ja kvaliteediga. Kui hakata suhtlema meeskondadega, siis näha, et probleem ei ole mitte testijates endis, vaid selles, kuidas protsess on üles ehitatud. Näiteks kui arendajad arvavad, et nad vastutavad ainult koodi kirjutamise eest, lõpeb nende vastutus kohe, kui nad on ülesande testimiseks üle andnud.
Kuid mitte kõik ei mõtle sellele, et halvasti kirjutatud ja kehva arhitektuuriga kood toob projektile kaasa suured probleemid. Nad ei mõtle vigade hinnale, sellele, et tootmisse jõudnud vead võivad põhjustada suuri kulusid ettevõttele ja meeskonnale. Puudub kultuur selle üle mõelda. Soovin, et konverentsil hakkaksime seda levitama.
Mõistan, et see ei ole innovatsioon. Edward Deming, kvaliteedi 14 postulaadi autor, kirjutas vigade hinnast juba eelmisel sajandil. Selle raamatu põhjal on välja kujunenud kvaliteedi tagamine kui distsipliin, kuid kahjuks unustatakse tänapäeva arenduses see.
— Kas plaanite käsitleda teemasid, mis käsitlevad otse testimist ja tööriistu?
Anastasia: Ma arvan, et tulevad ettekanded tööriistade kohta. On olemas piisavalt universaalseid tööriistu, millega ettevõtted ja meeskonnad saavad tootele mõju avaldada.
Kõik ettekanded ühendatakse globaalselt ühe ühise missiooniga: edastada publikule, et selle lähenemise, tööriista, meetodi, protsessi, testimise tüübi abil oleme mõjutanud toote kvaliteeti ja parendanud kliendi elu.
Meil ei tule ettekandeid tööriista pärast, vaid kõik ettekanded, mis programmi satuvad, on koondatud ühise eesmärgi ümber.
— Kellega sa loodad, et see, millest sa räägid, huvitab? Keda sa näed konverentsi külalistena?
Anastasia: Meil on ettekanded arendajatele, kellele ei ole oma projekti, toote, süsteemi saatus ükskõik. Testijatele on see samuti huvitav ja, nagu mulle tundub, eriti juhtidele. Juhi all mõtlen inimesi, kes teevad otsuseid ja saavad mõjutada toote, süsteemi, meeskonna saatust ja arengut.
Need on inimesed, kes mõtlevad, kuidas parandada toote ja süsteemi kvaliteeti. Meie konverentsil saavad nad teada erinevatest tegevuskavadest ja mõistavad, mis neil praegu valesti on ja mida on vaja muuta.
Arvan, et peamine kriteerium on aru saada, et kvaliteediga on midagi valesti ja soovida sellele mõju avaldada. Tõenäoliselt ei õnnestu meil esimesel katsel jõuda inimesteni, kes arvavad, et kõik on nii hästi.
— Kuidas arvad, kas tööstus on tervikuna küpseks saanud, et rääkida mitte ainult testimisest, vaid kvaliteedikultuurist?
Anastasia: Ma arvan, et on küps. Praegu liiguvad paljud ettevõtted traditsioonilisest Waterfall lähenemisest Agile suunas. Orienteeritakse kliendile, meeskondades hakkavad inimesed tõeliselt mõtlema, kuidas luua kvaliteetne toode. Isegi suurtes ettevõtetes toimub suuna muutus kvaliteedi tõusu suunas.
Lähtuvalt kogusest, mis on kogukonnas küsitud, arvan, et on juba aeg. Ma ei ole muidugi kindel, et see oleks ulatuslik revolutsioon, kuid ma sooviksin, et see mõtteviisi muutus toimuks.
— Leppisime! Toome kultuuri ja muudame mõttelaadi.
Konverents kvaliteetsete IT-toodete arendamisest toimub Moskvas 7. juunil. Kas teate, millised etapid moodustavad kvaliteetse toote, meil on edukate veaparanduste juhtumid, ja oma praktikas oleme testinud populaarseid meetodeid — me vajame teie kogemust. oma taotlusi 1. maiks, ja programmi komitee aitab konverentsi teema keskmesse tuua.
Liituge , kus arutame kvaliteedi ja konverentsi küsimusi, jälgige , et olla kursis programmi uudistega.
Allikas: habr.com
