Kes vastutab kvaliteedi eest?

Tere, Habr!

Meil on uus oluline teema – kvaliteetne IT-toodete arendamine. Räägime tihti HighLoad++-l, kuidas muuta koormatud teenuseid kiireks, ja Frontend Conf'is – ägedast kasutajaliidesest, mis ei takkardu. Meil on regulaarselt teemasid testimise kohta, ja DevOpsConf'is räägime erinevate protsesside, sealhulgas testimise, ühendamisest. Aga kvaliteedi kui terviku üle ja selle kompleksse arendamise üle ei ole juttu.

Parandame selle QualityConf – arendame kultuuri, kus mõeldakse kvaliteedile lõpptootes igas arendusetapis. Harjumust mitte jääda kinni oma vastutusalasse ning seostada kvaliteeti mitte ainult testijatega.

Allpool räägime programmidirektori, Tinkoff.Businessi testimise juhataja ja vene keelsete QA-kogukonna looja Anastasija Asejeva-Ngueniga QA-sektori seisundist ja uue konverentsi missioonist.

– Nastja, tere. Räägi palun endast.

Anastasija: Juhtin testimist pangas, vastutame väga suure meeskonna eest – meid on üle 90 inimese. Meil on oluline ärisektor, vastutame äriühingute ökosüsteemi eest.

Olen õppinud matemaatika ja informaatika erialal ning algselt tahtsin saada programmeerijaks. Kuid kui mulle tuli huvitav pakkumine, otsustasin proovida end testijana. Ometi osutus see minu kutsumuseks. Nüüd näen kogu oma tööd just selles valdkonnas.

Olen tulihingeline kvaliteedi tagamise distsipliini toetaja. Mind ei jäta külmaks, milliseid tooteid luuakse, kuidas suhtutakse kvaliteeti ettevõttes, meeskonnas ja põhimõtteliselt ka arendusprotsessis.

Minu jaoks on ilmne, et kogukond selles suunas on veel piisavalt küps, vähemalt Venemaal. Me ei pruugi alati mõista, et kvaliteedi tagamine ei ole ainult asjaolu, et testime rakendust nõuetele vastavuse osas. Tahaksin muuta seda olukorda.

– Sa kasutad termineid Quality Assurance ja testimine. Tavalise inimese silmis üksteisega kohtuvad need kaks mõistet väga tihti. Kuidas nad omavahel erinevad, kui süvitsiminevat analüüsida?

Anastasija: Tegelikult ei ole nad väga erinevad. Testimine on osa kvaliteedi tagamise distsipliinist, see on otsene tegevus — iseenesest on see, et ma midagi testin. Testimise liike on tegelikult palju, ja erinevate testimiste eest vastutavad erinevad inimesed. Kuid meil Venemaal, kui ilmus välja hulk outsourcer'eid, kes toovad ettevõtetesse testijaid, on testimine kahanenud üheks ainsaks liikmiseks.

Enamasti piirdutakse ainult funktsionaalse testimisega: kontrollitakse, kas see, mis arendajate poolt kirjutati, vastab spetsifikatsioonile ja on kõik.

— Räägi palun, milliseid teisi kvaliteedi tagamise distsipliine on veel olemas? Mis veel peale testimise siia kuulub?

Anastasija: Kvaliteedi tagamine on eelkõige kvaliteetse toote loomine. Teisisõnu, me küsime endalt, milliste kvaliteedi atribuutidega peab meie toode olema varustatud. Seega, kui me selle mõistame, saame me võrrelda, kes mõjutab neid kvaliteedi atribuute. Pole oluline, kas see on arendaja, projektijuht või tootearendaja — 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õuetele, vaid ka testeerida nõudeid, seada kahtluse alla tootekujundajatelt saadud sõnastusi, paljastada kõik varjatud nõuded ja kliendi ootused. Kui me toome meie kliendile uusi funktsioone, peame tõeliselt rahuldama tema ootused ja lahendama tema probleemid. Kui mõtleme kõigile kvaliteedi atribuutidele, siis on klient rahul ja mõistab, et ettevõte, mille toodet ta kasutab, tõeliselt hoolib tema huvidest ja ei tegutse ainult põhimõttel „ainult toote väljalaskmine“.

— Tundub, et see, mida sa just kirjeldasid, on tootekujundaja ülesanne. See ei ole põhimõtteliselt testimise ega kvaliteedi kohta — see on üldse toote juhtimise kohta, eks?

Anastasija: Kaasa arvatud. Kvaliteedi tagamine ei ole distsipliin, mille eest vastutab üks kindel inimene. Praegu on testimises populaarne suundumus, lähenemine, mida nimetatakse Agile TestimiseksTema määratlus ütleb, et see on meeskondlik lähenemine testimisele, mis hõlmab kindlat praktika kogumit. Selle lähenemise rakendamise eest vastutab kogu meeskond, isegi kui meeskonnas ei ole testijat. Kogu meeskond suunab oma tähelepanu sellele, et pakkuda väärtust kliendile ja et see väärtus vastaks tema ootustele.

— Ehk siis kvaliteet kattub peaaegu kõigi ümbritsevate distsipliinidega, seades piirid kõigile asjaoludele?

Anastasija: Täiesti õige. Kui mõtleme sellele, et soovime luua kvaliteetset produktsiooni, hakkame mõtlema erinevatele kvaliteedi atribuutidele. Näiteks, kuidas kontrollida, et oleme tõepoolest loonud funktsiooni, mis on meie kliendile vajalik.

Siinkohal tuleb jutuks selline testimise tüüp nagu UAT (kasutajate aktsepteerimistestimine). Kahjuks praktiseeritakse seda Venemaal harva, kuid see on mõnikord olemas SCRUM-meeskondades lõppklientide demona. Välisfirmades on see üsna levinud testimise liik. Enne kui avame funktsionaalsuse kõigile klientidele, teeme esmalt UAT-i, kutsudes lõppkasutaja, kes viib läbi testimise ja annab kohe tagasisidet — kas toode vastab ootustele ja lahendab probleemi. Alles pärast seda toimub kõikide teiste klientide jaoks laiendamine.

Seega, me suuname end äri, lõppklient, kuid samas ei unusta tehnoloogiat. Toote kvaliteet sõltub tugevalt ka tehnoloogiast. Kui meie arhitektuur on halb, ei saa me funktsioone kiiresti välja anda ja ei vasta kliendi ootustele. Võib esineda palju vigu, kui proovime suurendada mõõdetavust, või refaktoreerimise käigus võime midagi katki teha. See kõik mõjutab kliendi rahulolu.

Nii et arhitektuur peab olema selline, et saaksime kirjutada puhta koodi, mis võimaldab kiiresti muudatusi teha ja ei pea kartma, et lõhume kõik ära. Et arendus iteratsioonid ei veniks mitme kuu jooksul lihtsalt selle pärast, et meil on nii palju pärandit ja pikad testimise etapid on vajalikud.

— Kokku on nüüd kaasatud arendajad, arhitekid, tootearendajad, tootejuhid, testijad. Kes veel on kaasatud kvaliteedi tagamise protsessi?

Anastasija: Nüüd kujutame ette, et oleme juba kliendile teenuse kätte toimetanud. Ilmselgelt tuleb toote kvaliteeti jälgida ka siis, kui see on juba tootmisprotsessis. Sel hetkel võivad ilmneda olukorrad, mis põhinevad mitmetes mitte-eeldatavates stsenaariumides, nii-öelda vead.

Esimene küsimus on - kuidas me nendega vigadega töötame pärast seda, kui toode on juba välja antud? Kuidas me näiteks reageerime koormusele? Klient ei ole väga rahul, kui leht laadib rohkem kui 30 sekundit.

Siia mängu astub töötlus või, nagu nüüd öeldakse, DevOps. Tegelikult on need inimesed, kes vastutavad toote töökeskkonna eest, kui see on tootmisprotsessis. Siia kuuluvad erinevad jälgimise viisid. On isegi alaliik testimisest - testimine tootmisprotsessis, kui lubame endale mitte testida midagi enne väljalaskmist ja testime seda kohe tootmisprotsessis. Need on mitmed meetmed, mis on seotud infrastruktuuri korraldamisega ja mis võimaldavad kiiresti reageerida juhtumile, mõjutada seda, parandada.

Infrastruktuur on samuti oluline. Tihti juhtub, et testimise ajal ei õnnestu meil tõeliselt veenduda, et meil on kõik, mida sooviksime kliendile pakkuda. Käivitame tootmisprotsessis - ja hakkame tabama mitte-eeldatavaid olukordi. Ja see kõik tuleneb sellest, et testimisprotsessi infrastruktuur ei vasta tootmisprotsessi infrastruktuurile. Sealt tuleb uus testimisviis - infrastruktuuri testimine. Need on erinevad konfiguratsioonid, seaded, andmebaaside migratsioon jne.

Siit tekib küsimus - kas meeskond peaks kasutama infrastruktuuri kui koodi.

Usun, et infrastruktuur mõjutab otseselt toote kvaliteeti.

Loodan, et konverentsil on ettekandega reaalne juhtum. Kirjuta meile, kui oled valmis oma kogemust jagama, kuidas infrastruktuur kui kood mõjutab kvaliteeti. Infrastruktuur kui kood võimaldab lihtsamalt kontrollida kõiki seadistusi ja testida seda, mida muidu lihtsalt ei saaks. Seega kaasatakse kvaliteetse toote arendamise protsessi ka hooldamine.

— Aga mis analüütika ja dokumentatsiooniga?

Anastasija: See puudutab rohkem ettevõtte süsteeme. Kui räägime ettevõtte tasemest, tulevad kohe meelde sellised inimesed nagu analüütikud ja süsteemianalüütikud. Mõnikord nimetatakse neid ka tehnilisteks toimetajateks. Nad saavad ülesande kirjutada spetsifikatsiooni ja täidavad seda näiteks kuu aega.

Kordu on korduvalt tõestatud, et sellise dokumentatsiooni kirjutamine viib väga pikkade arendus- ja täiustamisiteratsioonideni, kuna testimise käigus tuvastatakse vigu ja algavad tagasitoomised. Tulemuseks on palju sildu, mis tõstavad arenduskulusid. Lisaks võib see tuua kaasa haavatavusi. Tundub, et oleme kirjutanud etalonkoode, kuid seejärel teeme muudatusi, mis rikuvad perfektse arhitektuuri.

Lõpptulemusena saame mitte päris kvaliteetse toote, kuna arhitektuuri on juba tekkinud lapitööd, kood on mõnes kohas ebapiisavalt testitud, kuna tähtaegade tõttu tuleb kiiremini kõik vead likvideerida. Kõik see tuleneb sellest, et algses spetsifikatsioonis ei olnud arvestatud kõiki aspekte, mida oleks pidanud rakendama.

Arendajad ei ole halvad poisid ja nad ei kirjuta teadlikult vigu sisaldavat koodi.

Kui oleksime alguses hoolikalt läbi mõelnud spetsifikatsiooni, kus oleks kajastatud kõik vajalikud aspektid, oleks kõik rakendatud just nii, nagu peab. Kuid see jääb utoopiaks.

Võib-olla ei ole ideaalset 100-leheküljelist spetsifikatsiooni võimalik kirjutada. Seetõttu tuleb mõelda alternatiivsetele viisidele dokumentatsiooni,spetsifikatsiooni ja ülesannete seadmiseks, mis tooksid meid lähemale sellele, et arendaja teeks just seda, mida on vaja.

Siin tulevad meelde Agile'i lähenemised – kasutajate lood koos vastuvõtmise kriteeriumidega. See on rohkem rakendatav meeskondadele, kes arenevad väikeste iteratsioonidega.

– Kuidas on kasutatavustestimise, toote kasutusmugavuse ja disainiga?

Anastasija: See on väga oluline moment, kuna meeskonnas on disainerid. Kõige sagedamini kasutatakse disainereid teenusena – kas disainimeeskond või disainer välishankena. Tihti juhtub, et disainer on tundunud, et kuulab tootearendajat ja teeb selle, mida ta mõtles. Kuid kui läheme iteratsiooni, selgub, et tegelikult ei ole tehtud seda, mida ootasime: disainer jättis midagi kõrvale, ei mõelnud käitumist lõpuni läbi, kuna ta ei olnud meeskonnas ja kontekstis, või es front-end arendaja ei saanud tema kujundusest lõpuni aru. Võib osutuda vajalikuks mitu iteratsiooni ainult seetõttu, et front-end arendajal on probleem disaini arusaamisega.

On the other hand, there is another issue. Design systems are gaining popularity right now. They are in vogue, but the benefits they offer are not entirely clear.

I encounter the opinion that design systems, on one hand, simplify development, but on the other hand, impose many restrictions on the interface.

As a result, we end up creating not the feature that the client wants, but one that is convenient for us because we already have certain components that we can use to build it.

It seems to me that we should pay attention to this topic and think about whether in trying to simplify the design work we are truly addressing the clients' needs.

— It turns out there are quite a few topics related to Quality Assurance. Is there a conference in Russia where all of them can be discussed?

Anastasija: There is the oldest conference on testing, which will be held for the 25th time this year and is called the SQA Days Quality Assurance Conference. It mainly covers tools and specific testing approaches for functional testers. Typically, presentations at SQA Days delve deeply into specific areas of responsibility for the testers themselves, rather than comprehensive events.

This greatly helps to understand the various tools and methods for testing databases, APIs, etc. However, on one hand, it doesn't motivate others involved in creating a higher-quality product beyond just testing. On the other hand, testers do not become more engaged in the process to think about the overall goal of the product and its business aspect.

I lead a large department and conduct many interviews, which actually allow me to represent the overall state of the industry. Typically, our people work in enterprise environments and have clear areas of responsibility. Colleagues who work on foreign projects use different types of testing: they can conduct load testing, performance testing, and even sometimes security testing, because they truly help the team ensure the product's quality.

I would like our guys in Russia to also start considering that the industry does not end with functional testing.

— Meie eesmärgiks on korraldada uus QualityConf konverents, mis keskendub kvaliteedile kui terviklikule distsipliinile. Räägi plaanist lähemalt, mis on konverentsi peamine eesmärk?

Anastasija: Me soovime luua kogukonna inimesi, kes on huvitatud kvaliteetsete toodete valmistamisest. Pakume platvormi, kuhu nad saavad tulla, kuulata ettekandeid ja lahkuda konverentsilt konkreetse arusaamaga, mida tuleb enda juures muuta kvaliteedi parandamiseks.

Tihti kuulen nõudmiseid konsultatsioonifirmadelt, et mida teha, kui esinevad probleemid testimisega ja kvaliteediga. Kui hakkad meeskondadega suhtlema, näed, et probleem ei ole asjades ise, vaid selles, kuidas on protsess üles ehitatud. Näiteks, kui arendajad arvavad, et nad on vastutavad ainult koodi kirjutamise eest, lõppeb nende vastutus just siis, kui nad on ülesande testimisele üle andnud.

Kaugeltki mitte kõik ei mõtle sellele, et kohmakalt kirjutatud nõrk kood kehva arhitektuuriga toob projektile suuri probleeme. Nad ei mõtle vigade maksma minekule, et vead, mis jõuavad tootmisse, võivad ettevõttele ja meeskonnale põhjustada suuri kulusid. Siin on puudu kultuur mõelda sellele. Soovin, et konverentsil hakkaksime seda levitama.

Ma mõistan, et see ei ole innovatsioon. Edward Deming, 14 kvaliteedisammude autori, rääkis vigade kulust juba eelmisel sajandil. Selle raamatu põhjal on üles ehitatud Quality Assurance kui distsipliin, kuid kahjuks unustab tänapäeva arendus selle.

— Kas kavatsete käsitleda ka teemasid, mis otseselt puudutavad testimist ja tööriistu?

Anastasija: Arvan, et ettekanded tööriistade kohta on võimalikud. On piisavalt universaalseid tööriistu, millega ettevõtted ja meeskonnad saavad toodet mõjutada.

Kõik ettekanded on globaalselt ühendatud ühe üldise missiooniga: edastada publikule, et selle lähenemise, tööriista, meetodi, protsessi, testimise tüübi abil oleme mõjutanud toote kvaliteeti ja parandanud kliendi elu.

Meil ei ole kindlasti ettekandeid, mis käsitlevad tööriistu pelgalt tööriistade pärast. Kõik ettekanded, mis saavad programmi, on ühendatud ühise eesmärgiga.

— Kellele on huvitav see, millest sa räägid, kedasi näed konverentsi külalistena?

Anastasija: Meil on ettekanded arendajatele, kellele ei ole ükskõik oma projekti, toote, süsteemi saatuse üle. Samuti huvitab see testijate, ja, nagu mulle tundub, eriti juhtide jaoks. Juhtide all mõtlen ma inimesi, kes teevad otsuseid ja saavad mõjutada toote, süsteemi, meeskonna ning sellega seonduvat arengut.

Need on inimesed, kes küsivad endalt – kuidas parandada toote, süsteemi kvaliteeti. Meie konverentsil saavad nad teada erinevatest meetmest ning saavad aru, mis neil praegu puudu on ja mida on vaja muuta.

Arvan, et peamine kriteerium on aru saada, et kvaliteediga on midagi valesti, ja soovida sellele mõju avaldada. Ilmselt ei õnnestu meil esimesel korral jõuda inimesteni, kes arvavad, et kõik on korras.

— Kuidas sa arvad, kas tööstus on üldiselt küps, et rääkida mitte lihtsalt testimisest, vaid kvaliteedikultuurist?

Anastasija: Ma arvan, et on. Praegu liiguvad paljud ettevõtted traditsioonilisest Waterfall lähenemisest Agile suunas. Klientidele orienteeritakse, inimesed meeskondades hakkavad tõsiselt mõtlema, kuidas luua kvaliteetset toodet. Isegi suurtes ettevõtetes toimuvad ümberorienteerumised kvaliteedi parandamiseks.

Olles näinud, kui palju küsimusi tekib kogukonnas, arvan, et on juba aeg. Ma ei ole muidugi kindel, et see saab olema ulatuslik revolutsioon, kuid loodaksin, et see meelemuutus toimub.

— Kokku leppimist! Hakkame kasvatama kultuuri ja muutma teadvust.

Konverents kvaliteetse IT-toodete arendamisest QualityConf toimub Moskvas 7. juunil. Teate, millistest etappidest koosneb kvaliteetne toode, meil on eelnevalt edukate vigade lahendamise juhtumid, oleme oma praktikas katsetanud tuntud meetodeid – vajame teie kogemust. Saatke oma taotlusi hiljemalt 1. maid, ja Programmikomitee aitab teemade fookusele keskenduda konverentsi üldise terviklikkuse jaoks.

Liituge vestlusgrupiga, kus arutame kvaliteedi ja konverentsiga seotud küsimusi, jälgige meie Telegrami kanalit, et olla kursis programmi uudistega.

Allikas: habr.com