Tere Habr!
Meil on uus oluline teema - IT-toodete kvaliteetne arendus. HighLoad++ puhul räägime sageli sellest, kuidas kiireid teenuseid kiireks muuta, ja Frontend Confis räägime lahedast kasutajaliidest, mis ei aeglustu. Meil on regulaarselt teemasid testimise kohta ja DevOpsConf erinevate protsesside, sealhulgas testimise kombineerimise kohta. Kuid selle kohta, mida üldiselt võib nimetada kvaliteediks ja kuidas sellega kõikehõlmavalt töötada - ei.
Teeme selle korda — arendame igas arendusetapis kasutaja jaoks lõpptoote kvaliteedile mõtlemise kultuuri. Harjumus mitte keskenduda oma vastutusvaldkonnale ja seostada kvaliteeti mitte ainult testijatega.
Lõike all räägime programmikomitee juhi, Tinkoff.Businessi testimise juhiga, venekeelse QA kogukonna loojaga Anastasia Aseeva-Nguyen QA tööstuse olukorrast ja uue konverentsi missioonist.
- Nastia tere. Palun rääkige meile endast.
Anastasia: Ma juhin pangas testimist, vastutan väga suure meeskonna eest – meid on üle 90 inimese. Meil on oluline ärivaldkond, vastutame juriidiliste isikute ökosüsteemi eest.
Õppisin mehaanikat ja matemaatikat ning tahtsin alguses saada programmeerijaks. Aga kui sain huvitava pakkumise, otsustasin end testijana proovida. Kummalisel kombel osutus see minu kutsumuseks. Nüüd näen kogu oma tööd selles valdkonnas.
Olen kvaliteedi tagamise distsipliini tulihingeline järgija. Ma ei ole ükskõikne, milliseid tooteid luuakse, kuidas suhtutakse kvaliteeti ettevõttes, meeskonnas ja põhimõtteliselt ka arendusprotsessis.
Minu jaoks on see ilmselge sellesuunaline kogukond ei ole piisavalt küps, vähemalt Venemaal. Me ei saa alati aru, et kvaliteedi tagamine ei ole ainult taotluse nõuetele vastavuse testimise fakt. Tahaks seda olukorda muuta.
— Kasutate sõnu kvaliteedi tagamine ja testimine. Tavainimese silmis need kaks mõistet väga sageli kattuvad. Kuidas need erinevad, kui kaevate sügavale?
Anastasia: Pigem ei erine nad üksteisest. Testimine on osa kvaliteeditagamise distsipliinist, see on otsene tegevus – juba tõsiasi, et ma midagi testin. Testimise tüüpe on tegelikult palju ja eri tüüpi testimise eest vastutavad erinevad inimesed. Kuid siin Venemaal, kui tekkis allhankijate laine, kes tarnivad ettevõtetele testereid, taandus testimine ühte tüüpi.
Enamasti piirdutakse vaid funktsionaalse testimisega: kontrollitakse, kas arendajate poolt kodeeritu vastab spetsifikatsioonile ja ongi kõik.
— Rääkige palun, millised on veel kvaliteedi tagamise erialad? Mida siin lisaks testimisele veel kaasatakse?
Anastasia: Kvaliteedi tagamine seisneb ennekõike kvaliteetse toote loomises. See tähendab, et me küsime endalt, millised kvaliteediomadused peaksid meie tootel olema. Seega, kui me sellest aru saame, saame võrrelda, kes neid kvaliteediomadusi mõjutab. vahet pole, arendaja, projektijuht või tootespetsialist on isik, kes mõjutab toote arengut, selle mahajäämust ja strateegiat.
Testija saab oma rollist teadlikumaks. Ta mõistab, et tema ülesanne ei ole mitte ainult nõuetele vastavust testida, vaid ka nõudeid testida, tootespetsialistilt tulevaid koostisi kahtluse alla seada ning kõiki kliendi kaudseid nõudeid ja ootusi paljastada. Kui pakume oma klientidele uusi funktsioone, peame tõeliselt vastama nende ootustele ja lahendama nende valu. Kui mõelda kõigile kvaliteedi atribuutidele, jääb klient rahule ja mõistab, et ettevõte, mille toodet ta kasutab, hoolib tõesti tema huvidest ega tööta põhimõttel "lihtsalt funktsiooni väljalaskmiseks".
— Tundub, et see, mida te just kirjeldasite, on tootespetsialisti ülesanne. See ei puuduta põhimõtteliselt testimist ega kvaliteeti - üldiselt on see tootehaldus, kas pole?
Anastasia: Kaasa arvatud. Kvaliteedi tagamine ei ole distsipliin, mille eest vastutab üks konkreetne isik. Nüüd on testimisel populaarne suund, lähenemine nimega Agiilne testimine. Tema definitsioon ütleb selgelt, et see on meeskondlik lähenemine testimisele, mis hõlmab teatud praktikaid. Selle lähenemisviisi rakendamise eest vastutab kogu meeskond; pole isegi vaja, et meeskonnas oleks testija. Kogu meeskond on keskendunud kliendile väärtuse pakkumisele ja selle tagamisele, et väärtus vastaks kliendi ootustele.
— Selgub, et kvaliteet ristub peaaegu kõigi ümbritsevate erialadega, kehtestades kõigele ümbritsevale raamistiku?
Anastasia: Õige. Kui mõtleme sellele, kuidas tahame kvaliteetset toodet luua, hakkame mõtlema erinevatele kvaliteedi atribuutidele. Näiteks kuidas kontrollida, kas me tõesti tegime selle funktsiooni, mida meie klient vajab.
Siin tulevadki seda tüüpi testid: UAT (kasutaja aktsepteerimise testimine). Kahjuks kasutatakse seda Venemaal harva, kuid mõnikord on see SCRUM-i meeskondades lõppkliendi demona olemas. See on välismaistes ettevõtetes üsna levinud testimisviis. Enne funktsionaalsuse avamist kõikidele klientidele teeme esmalt ära UAT ehk kutsume kohale lõppkasutaja, kes testib ja annab kohe tagasisidet - kas toode tõesti vastab ootustele ja lahendab valu. Alles pärast seda toimub skaleerimine kõikidele teistele klientidele.
See tähendab, et keskendume ärile, lõppkliendile, kuid samal ajal ärge unustage tehnoloogiat. Toote kvaliteet sõltub suuresti ka tehnoloogiast. Kui meil on halb arhitektuur, ei suuda me funktsioone kiiresti vabastada ja klientide ootusi täita. Skaleerimisel võib esineda palju vigu või taastekke proovimisel võime midagi rikkuda. Kõik see mõjutab klientide rahulolu.
Sellest vaatenurgast peaks arhitektuur olema selline, et saaksime kirjutada puhta koodi, mis võimaldab meil kiiresti muudatusi teha ja mitte karta, et rikume kõik ära. Et läbivaatamise iteratsioonid ei kestaks mitu kuud lihtsalt seetõttu, et meil on nii palju pärandit ja me peame tegema pikki testimisetappe.
— Kokku on juba kaasatud arendajad, arhitektid, tooteteadlased, tootejuhid ja testijad ise. Kes veel osalevad kvaliteedi tagamise protsessis?
Anastasia: Nüüd kujutame ette, et oleme funktsiooni juba kliendile edastanud. Ilmselgelt tuleb toote kvaliteeti jälgida ka siis, kui see on juba tootmises. Selles etapis võivad ilmneda ebaselgete stsenaariumitega olukorrad, nn vead.
Esimene küsimus on, kuidas me nende vigadega hakkama saame pärast seda, kui oleme toote juba välja andnud? Kuidas me näiteks stressile reageerime? Klient ei ole väga rahul, kui lehe laadimine võtab aega üle 30 sekundi.
Siin tuleb mängu ekspluateerimine või, nagu nad seda praegu nimetavad, DevOps. Tegelikult on need inimesed, kes vastutavad toote käitamise eest, kui see on juba tootmises. See hõlmab erinevat tüüpi jälgimist. On isegi testimise alamliik – tootmisel testimine, kui lubame endale midagi enne juurutamist mitte testida ja testime seda kohe tootmises. See on infrastruktuuri korraldamise seisukohast meetmete sari, mis võimaldab kiiresti reageerida juhtumile, seda mõjutada ja parandada.
Tähtis on ka infrastruktuur. Tihti tuleb ette olukordi, kus testimise käigus ei ole võimalik veenduda, et meil on tõesti kõik, mida sooviksime kliendile kinkida. Viime selle tootmisse ja hakkame tabama ebaselgeid olukordi. Ja kõik sellepärast, et testis olev infrastruktuur ei vasta tootmises olevale infrastruktuurile. See viib uut tüüpi testimiseni - infrastruktuuri testimine. Need on erinevad konfiguratsioonid, sätted, andmebaasi migreerimine jne.
See tõstatab küsimuse – võib-olla peab meeskond koodina kasutama infrastruktuuri.
Usun, et infrastruktuur mõjutab otseselt toote kvaliteeti.
Loodan, et konverentsil tuleb aruanne reaalse juhtumiga. Kirjutage meile, kui olete valmis meile oma kogemusest rääkima, kuidas infrastruktuur kui kood mõjutab kvaliteeti. Taristu kui kood muudab lihtsamaks kõikide seadistuste kontrollimise ja asjade testimise, mis muidu lihtsalt pole võimalikud. Seetõttu on kvaliteetse toote väljatöötamise protsessi kaasatud ka operatsioon.
— Aga analüütika ja dokumentatsioon?
Anastasia: see kehtib rohkem ettevõtete süsteemide kohta. Kui me räägime ettevõtlusest, siis meenuvad kohe sellised inimesed nagu analüütikud ja süsteemianalüütikud. Neid nimetatakse mõnikord tehnilisteks kirjutajateks. Nad saavad ülesande kirjutada spetsifikatsioon ja täita seda näiteks kuu aega.
Korduvalt on tõestatud, et sellise dokumentatsiooni kirjutamine toob kaasa väga pikki arendusiteratsioone ja pikki täiustamise iteratsioone, sest testimise käigus tuvastatakse vead ja algab tagastamine. Selle tulemusena on palju silmuseid, mis suurendavad arenduskulusid. Lisaks võib see kaasa tuua turvaauke. Tundub, et oleme viitekoodi kirjutanud, kuid siis tegime muudatusi, mis purustavad ideaalselt läbimõeldud arhitektuuri.
Lõpptulemus on mitte läbinisti kvaliteetne toode, sest arhitektuuris on juba tekkinud plaastrid, kood pole kohati piisavalt testidega kaetud, kuna tähtajad hakkavad otsa saama, kõik vead tuleb kiiresti sulgeda. Ja kõik sellepärast, et esialgne spetsifikatsioon ei võtnud arvesse kõiki rakendamist vajavaid punkte.
Arendajad ei ole kahjurid ega kirjuta tahtlikult vigadega koodi.
Kui oleksime algselt mõelnud läbi spetsifikatsiooni, mis oleks hõlmanud kõik vajalikud punktid, siis oleks kõik ellu viidud täpselt nii nagu vaja. Kuid see on utoopia.
Tõenäoliselt on võimatu kirjutada täiuslikku 100-leheküljelist spetsifikatsiooni. Sellepärast tuleb mõelda dokumentide kirjutamise alternatiivsetele viisidele, spetsifikatsioonid, ülesannete seadmine, mis viiks meid lähemale sellele, et arendaja teeb täpselt seda, mida vaja.
Siin meenuvad Agile’i lähenemised – kasutajalood aktsepteerimiskriteeriumitega. See on rohkem rakendatav meeskondade jaoks, kes arenevad väikeste iteratsioonidena.
— Aga kasutatavuse testimine, toote kasutatavus, disain?
Anastasia: See on väga oluline punkt, sest meeskonnas on disainerid. Kõige sagedamini kasutatakse disainereid teenusena – kas disainiosakonna või allhanke disaineri poolt. Tihti tuleb ette olukordi, kus tundub, et disainer kuulas tootespetsialisti ja tegi seda, millest aru sai. Aga kui me iteratsiooni alustame, selgub, et see, mida tegelikult tehti, ei olnud see, mida oodati: disainer unustas midagi, ei mõelnud käitumist täielikult läbi, kuna ta pole meeskonnas ega kontekstis ega ees. -end arendaja ei saanud selle paigutusest täielikult aru. See võib võtta mitu iteratsiooni lihtsalt seetõttu, et esiotsa arendajal on probleeme disainist arusaamisega.
Lisaks on veel üks probleem. Disainisüsteemid koguvad nüüd populaarsust. Need on reklaamitud, kuid nende eelised pole täiesti ilmsed.
Kohtan arvamust, et disainisüsteemid ühest küljest lihtsustavad arendust, teisalt aga seavad liidesele palju piiranguid.
Selle tulemusena ei tee me seda funktsiooni, mida klient soovib, vaid sellist, mis on meile mugav, sest meil on juba teatud kuubikud, millest saame seda teha.
Ma arvan, et see on teema, millele tasub pilk peale visata ja mõelda, kas disaini lihtsamaks muutmisel lahendame tegelikult kliendi valupunkti.
— Kvaliteeditagamisega seotud teemasid on üllatavalt palju. Kas Venemaal on mõni konverents, kus saab neid kõiki arutada?
Anastasia: Toimub vanim testimiskonverents, mis sel aastal toimub juba 25. korda ja kannab nime SQA Days Quality Assurance Conference. Peamiselt käsitletakse tööriistu ja spetsiifilisi testimismeetodeid funktsionaalsete testijate jaoks. Reeglina uuritakse SQA Daysi aruannetes põhjalikult konkreetseid valdkondi testijate endi vastutusalas, kuid mitte keerulisi tegevusi.
See aitab palju mõista erinevaid tööriistu ja lähenemisviise, kuidas testida andmebaase, API-sid jne. Aga samas ei motiveeri see ühelt poolt kaasama parema toote loomisesse rohkemat kui lihtsalt testimist. Teisest küljest ei osale testijad protsessis rohkem, et mõelda toote ja selle ärikomponendi globaalsele eesmärgile.
Ma juhin suurt osakonda ja viin läbi palju intervjuusid, mis annavad tõeliselt ülevaate tööstuse olukorrast tervikuna. Reeglina töötavad meie poisid ettevõtetes ja neil on selge vastutusvaldkond. Välisprojektides töötavad kolleegid kasutavad erinevat tüüpi testimist: nad saavad ise teha koormustesti, jõudlustesti ja mõnikord isegi turvatesti, sest need aitavad meeskonnal tõesti toote kvaliteeti tagada.
Tahaksin, et ka Venemaa poisid hakkaksid arvama, et tööstus ei lõpe funktsionaalse testimisega.
— Selleks korraldame uue konverentsi QualityConf, mis on pühendatud kvaliteedile kui lahutamatule distsipliinile. Räägi ideest lähemalt, mis on konverentsi põhieesmärk?
Anastasia: Soovime luua kogukonna inimestest, kes on huvitatud kvaliteetsete toodete valmistamisest. Pakkuge platvormi, kuhu nad saavad tulla, aruandeid kuulata ja pärast konverentsi lahkuda konkreetse arusaamaga, mida on vaja kvaliteedi parandamiseks muuta.
Tänapäeval kuulen sageli konsultandilt palvet, mida teha, kui testimise ja kvaliteediga on probleeme. Kui hakkate meeskondadega suhtlema, näete, et probleem ei ole mitte testijates endis, vaid selles, kuidas protsess on üles ehitatud. Näiteks kui arendajad usuvad, et nad vastutavad ainult koodi kirjutamise eest, lõpeb nende vastutus täpselt hetkel, kui nad ülesande testimisele üle annavad.
Mitte igaüks ei mõtle sellele, et halvasti kirjutatud, madala kvaliteediga kood kehva arhitektuuriga ähvardab projekti jaoks suuri probleeme. Nad ei mõtle vigade maksumusele, et tootmisse sattunud vead võivad ettevõttele ja meeskonnale suuri kulusid kaasa tuua. Puudub kultuur, et sellele mõelda. Tahan, et hakkaksime seda konverentsil levitama.
Ma saan aru, et see pole uuendus. 14 kvaliteedipõhimõtte autor Edward Deming kirjutas vea maksumusest juba eelmisel sajandil. Kvaliteedi tagamine kui distsipliin põhineb sellel raamatul, kuid kahjuks unustab kaasaegne areng selle.
— Kas kavatsete puudutada otseselt testimise ja tööriistade teemasid?
Anastasia: Tunnistan, et tööriistade kohta tuleb aruandeid. On olemas üsna universaalsed tööriistad, millega ettevõtted ja meeskonnad saavad toodet mõjutada.
Kõiki aruandeid ühendab globaalselt üks ühine missioon: anda publikule teada, et selle lähenemise, tööriista, meetodi, protsessi, testimise tüübi abil oleme mõjutanud toote kvaliteeti ja parandanud kliendi eluiga.
Me kindlasti ei koosta aruandeid tööriista kohta tööriista huvides. Kõiki programmi kuuluvaid aruandeid ühendab ühine eesmärk.
— Keda hakkab huvitama, millest te räägite, keda näete konverentsi külalistena?
Anastasia: Meil on aruanded arendajatele, kes hoolivad oma projekti, toote või süsteemi saatusest. Samuti pakub see huvi testijatele ja mulle tundub, et eriti juhtidele. Juhtide all pean silmas inimesi, kes teevad otsuseid ja saavad mõjutada ka toote, süsteemi, meeskonna saatust ja arengut.
Need on inimesed, kes mõtlevad, kuidas toote või süsteemi kvaliteeti parandada. Meie konverentsil õpivad nad tundma erinevaid meetmete komplekte ja saavad aru, mis neil praegu viga on ja mida on vaja muuta.
Ma arvan, et peamine kriteerium on aru saada, et kvaliteedis on midagi valesti, ja tahta seda mõjutada. Tõenäoliselt ei jõua me nende inimesteni, kes arvavad, et see läheb esimest korda.
— Kas teie arvates on tööstus tervikuna küps rääkima mitte ainult testimisest, vaid ka kvaliteedikultuurist?
Anastasia: Ma arvan, et olen küpseks saanud. Nüüd on paljud ettevõtted eemaldumas traditsioonilisest Waterfalli lähenemisviisist Agile'i suunas. Tekib kliendikesksus, inimesed meeskondades hakkavad tõesti mõtlema, kuidas kvaliteetset toodet luua. Isegi ettevõtted keskenduvad kvaliteedi parandamisele.
Otsustades kogukonnas tekkivate taotluste arvu järgi, usun, et on aeg. Ma ei ole muidugi kindel, et see tuleb laiaulatuslik revolutsioon, kuid ma tahaksin, et see teadvuse revolutsioon juhtuks.
- Nõus! Me sisendame kultuuri ja muudame teadvust.
IT-toodete kvaliteetse arendamise konverents toimub Moskvas 7. juunil. Teate, millistest etappidest koosneb kvaliteetne toode, meil on juhtumeid, kuidas edukalt võidelda vigadega tootmises, oleme oma praktikas katsetanud populaarseid meetodeid - vajame teie kogemusi. nende avaldusi enne 1. maidja programmikomitee aitab keskenduda teemale konverentsi üldise terviklikkuse tagamiseks.
Ühenda , milles arutame kvaliteediküsimusi ja konverentsi, tellige et olla kursis programmiuudistega.
Allikas: www.habr.com