{"id":31264,"date":"2019-10-31T21:40:21","date_gmt":"2019-10-31T18:40:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kto-otvetit-za-kachestvo\/"},"modified":"2019-10-31T21:40:21","modified_gmt":"2019-10-31T18:40:21","slug":"kto-otvetit-za-kachestvo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","title":{"rendered":"Kes vastutab kvaliteedi eest?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere, Habr!<\/p>\n

Meil on uus oluline teema \u2013 kvaliteetne IT-toodete arendus. R\u00e4\u00e4gime sageli HighLoad++-l, kuidas muuta koormatud teenuseid kiireks, ja Frontend Confis \u2013 suurep\u00e4rasest kasutajaliidest, mis ei k\u00fclmuta. Regulaarsetel \u00fcritustel k\u00e4sitleme testimist, samuti DevOpsConfis erinevate protsesside \u00fchendamist, sealhulgas testimist. Kuid kvaliteedi laiemast m\u00f5istmisest ja kompleksest t\u00f6\u00f6st selle nimel ei r\u00e4\u00e4gita.<\/p>\n

Parandame selle QualityConf<\/a><\/noindex>\u00a0\u2013 me edendame kultuuri, kus m\u00f5eldakse l\u00f5ppkasutaja toote kvaliteedile iga arendusetapi jooksul. Harjumust mitte j\u00e4\u00e4da kinni oma vastutusalasse ning seostada kvaliteeti mitte ainult testijatega.<\/p>\n

Allpool r\u00e4\u00e4gime programmi komitee juhiga, Tinkoff.Bisnessi testimise juhiga, vene keelt k\u00f5neleva QA-\u00fchiskonna looja Anastasia Aseeva-Ngueniga<\/b> QA-valdkonna olukorrast ja uue konverentsi missioonist.<\/p>\n

\"Kes
\n<\/a><\/noindex>
\n\u2013 Nastja, tere! Palun r\u00e4\u00e4gi meile endast.<\/em><\/strong><\/p>\n

\"KesAnastasia<\/strong>: Ma juhin testimist pangas, vastutan v\u00e4ga suure meeskonna eest \u2014 meid on \u00fcle 90 inimese. Meil on oluline \u00e4riliin, me vastutame \u00e4ri\u00fchingute \u00f6kos\u00fcsteemi eest.<\/p>\n

\u00d5ppisin matemaatika- ja loodusteaduste osakonnas ja algselt tahtsin saada programmeerijaks. Kuid kui sain huvitava ettepaneku, otsustasin proovida end testijana. Ootamatult osutus see minu kutsumuseks. N\u00fc\u00fcd n\u00e4en kogu oma t\u00f6\u00f6d just selles valdkonnas.<\/p>\n

Olen Quality Assurance\u2019i innukas toetaja. Mind huvitab, milliseid tooteid luuakse, kuidas kvaliteediga ettev\u00f5ttes, meeskonnas ja \u00fcldiselt arendusprotsessis suhtutakse.<\/p><\/blockquote>\n

\nMinu jaoks on ilmne, et kogukond selles suunas on piisavalt k\u00fcps<\/strong>, v\u00e4hemalt Venemaal. Me ei m\u00f5ista alati, et kvaliteedi tagamine ei t\u00e4henda ainult rakenduse testimist n\u00f5uetele vastavuse osas. Sooviksin seda olukorda muuta.<\/p>\n

\u2014 Sa kasutad termineid Quality Assurance ja testimine. Tavaoma silmis kattuvad need kaks m\u00f5istet v\u00e4ga tihti. Milles need erinevad, kui s\u00fcvitsi kaevata?<\/em><\/strong><\/p>\n

Anastasia:<\/strong> Tegelikult nad ei erine. Testimine on osa kvaliteedi tagamise distsipliinist, see on otsene tegevus - lihtsalt fakt, et ma midagi testin. Testimise liike on t\u00f5eliselt palju, ja erinevate testimisliikide eest vastutavad t\u00e4iesti erinevad inimesed. Ent meil Eestis, kui tuli sisse voog outsourced'i teenuseid, kes toovad testijaid ettev\u00f5tetesse, on testimine piirdunud peamiselt \u00fche liigiga.<\/p>\n

Enamikul juhtudel piirdutakse ainult funktsionaalsete testidega: kontrollitakse, kas see, mis arendajate poolt on kirjutatud, vastab spetsifikatsioonile.<\/p>\n

\u2014 Palun r\u00e4\u00e4gi, millised on veel kvaliteedi tagamise distsipliinid? Mis veel peale testimise siia kuulub?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Kvaliteedi tagamine on eelk\u00f5ige seotud kvaliteetsete toodete loomisega. See t\u00e4hendab, et me k\u00fcsimise, millised kvaliteedi atribuudid peaks meie tootel olema. Vastavalt sellele, kui me seda m\u00f5istame, saame v\u00f5rrelda, kes m\u00f5jutab neid kvaliteedi atribuute. Ei ole oluline, kas see on arendaja, projektijuht v\u00f5i tootejuht<\/strong>\u00a0\u2014 see on inimene, kes m\u00f5jutab toote arengut, selle backlog'i ja strateegiat.<\/p>\n

Testija hakkab paremini m\u00f5istma oma rolli. Ta m\u00f5istab, et tema \u00fclesanne ei ole mitte ainult testida vastavust n\u00f5udmistele, vaid ka testida n\u00f5udmisi, seada kahtluse alla tootejuhi v\u00e4ljendused, paljastada k\u00f5ik varjatud n\u00f5udmised ja kliendi ootused. Kui me tarnime oma kliendile uue funktsionaalsuse, peame t\u00f5eliselt rahuldama tema ootusi ja lahendama tema valupunkte. Kui me m\u00f5tleme k\u00f5igile kvaliteedi \u0430\u0442\u0440\u0438\u0431\u00fc\u00fctidele, on klient rahul ja ta m\u00f5istab, et ettev\u00f5te, mille toodet ta kasutab, t\u00f5eliselt hoolib tema huvidest, mitte ei t\u00f6\u00f6ta p\u00f5him\u00f5ttel \u201elihtsalt lase funktsionaalsus v\u00e4lja\u201d.<\/p>\n

\u2014 Tundub, et see, mida sa praegu kirjeldasid, on tootejuhi \u00fclesanne. See ei ole p\u00f5him\u00f5tteliselt testimise ega kvaliteedi k\u00fcsimus \u2014 see on tegelikult seotud tootehaldusega, eks?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Sealhulgas. Kvaliteedi tagamine ei ole distsipliin, mille eest vastutab \u00fcks konkreetne inimene. Praegu on testimises populaarne suundumus, l\u00e4henemine, mida nimetatakse Agile Testing<\/strong>. Selle m\u00e4\u00e4ratlemisel \u00f6eldakse selgelt, et see on meeskonna l\u00e4henemine testimisele, mis h\u00f5lmab teatud praktikate komplekti. Selle l\u00e4henemise elluviimise eest vastutab kogu meeskond, isegi ei ole vajalik, et meeskonnas oleks testija. Kogu meeskond on suunatud sellele, et pakkuda v\u00e4\u00e4rtust kliendile ning et see v\u00e4\u00e4rtus vastaks tema ootustele.<\/p>\n

\u2014 Tundub, et kvaliteet katab peaaegu k\u00f5ik \u00fcmbritsevad distsipliinid, seades piirid k\u00f5igele \u00fcmber?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: \u00d5ige. Kui m\u00f5tleme, et soovime luua kvaliteetset toodet, hakkame m\u00f5tlema erinevatele kvaliteediomadustele. N\u00e4iteks, kuidas kontrollida, et oleme tegelikult loonud funktsiooni, mis on meie kliendile vajalik.<\/p>\n

Siin kerkib esile selline testimise t\u00fc\u00fcp nagu UAT<\/strong> (user acceptance testing). Kahjuks on see Venemaal harva praktiseeritav, kuid m\u00f5nikord esineb see SCRUM meeskondades, kui demo l\u00f5ppkasutajale. L\u00e4\u6d77\u5916 \u043a\u043e\u043c\u043f\u0430\u043d\u00fdes on see \u00fcsna levinud testimismeetod. Enne, kui avame funktsionaalsuse k\u00f5igile klientidele, teeme esmalt UAT, kutsudes l\u00f5ppkasutaja, kes viib l\u00e4bi testimise ja annab kohe tagasisidet \u2014 kas toode vastab ootustele ja lahendab probleemi. Alles p\u00e4rast seda toimub laienemine k\u00f5igile teistele klientidele.<\/p>\n

See t\u00e4hendab, et suuname oma t\u00e4helepanu \u00e4ridele, l\u00f5ppkasutajatele, kuid samas ei unusta tehnoloogiat<\/strong>. Tehnoloogia kvaliteet m\u00f5jutab tugevalt ka toote kvaliteeti. Kui meil on halb arhitektuur, siis ei saa me funktsioone kiiresti v\u00e4lja anda, et vastata kliendi ootustele. Laiendamisel v\u00f5ivad tekkida palju vigu v\u00f5i refaktoreerimise katsetamisel v\u00f5ime midagi katki teha. K\u00f5ik see m\u00f5jutab kliendirahulolu.<\/p>\n

Sellest vaatenurgast peab arhitektuur olema selline, et suudame kirjutada puhta koodi, mis v\u00f5imaldab kiireid muudatusi teha, kartmata, et k\u00f5ik laguneb. Iteratsioonid ei tohi venida mitme kuuni lihtsalt seet\u00f5ttu, et meil on nii palju p\u00e4randkoodi ja testimise etappide jaoks on vaja teha pikaajalisi protseduure.<\/p>\n

\u2014 Kokku on juba kaasatud arendajad, arhitekid, tootejuhid, tootearendajad, testijad. Kes veel on kvaliteedi tagamise protsessis kaasatud?<\/em><\/strong><\/p>\n

Anastasia<\/strong>N\u00fc\u00fcd kujutame ette, et oleme juba kliendile omaduse tarninud. Ilmselgelt tuleb toote kvaliteedi \u00fcle j\u00e4relevalvet teostada, isegi kui see on juba tootmisel. Sellel etapil v\u00f5ivad ilmneda olukorrad, kus esinevad mitteilmsed stsenaariumid, nn vead.<\/p>\n

Esimene k\u00fcsimus on - kuidas me nende vigadega tegeleme p\u00e4rast seda, kui toode on v\u00e4lja lastud? Kuidas me n\u00e4iteks reageerime koormusele? Klient ei ole eriti rahul, kui leht laadib rohkem kui 30 sekundit.<\/p>\n

Siin tuleb m\u00e4ngu ekspluateerimine v\u00f5i, nagu n\u00fc\u00fcd \u00f6eldakse, DevOps<\/strong>. Tegelikkuses on need inimesed, kes vastutavad toote t\u00f6\u00f6 korraldamise eest, kui see on juba tootmises. Siia kuuluvad erinevad j\u00e4lgimise viisid. On isegi alaliik testimisest \u2014 tootmises testimine, kus me lubame endale midagi mitte testida enne juurutamist ja testime kohe tootmises. See on rida tegevusi infrastruktuuri korraldamise osas, mis v\u00f5imaldavad kiiresti reageerida s\u00fcndmusele, m\u00f5jutada seda ja parandada.<\/p>\n

Infrastruktuur on samuti oluline. Tihti tekivad olukorrad, kus testi ajal ei suuda me veenduda, et meil on t\u00f5eliselt k\u00f5ik see, mida me soovime kliendile pakkuda. Juurutame tootmisse \u2014 ja hakkame tabama ebatavalisi olukordi. Ja see k\u00f5ik juhtub, kuna testi infrastruktuur ei vasta tootmise infrastruktuurile. Siit tuleneb uus testimise liik \u2014 infrastruktuuri testimine<\/strong>. See h\u00f5lmab erinevaid konfiguratsioone, seadistusi, andmebaaside migreerimist jne.<\/p>\n

Siit tekib k\u00fcsimus \u2014 v\u00f5ib-olla peab meeskond kasutama infrastruktuuri kui koodi.<\/p>\n

Usun, et infrastruktuur m\u00f5jutab otseselt toote kvaliteeti.<\/p><\/blockquote>\n

\nLoodan, et konverentsil tehakse ettekandeid reaalsete juhtumite p\u00f5hjal. Kirjutage meile, kui olete valmis r\u00e4\u00e4kima oma kogemustest, kuidas infrastruktuur kui kood m\u00f5jutab kvaliteeti. Infrastruktuur kui kood v\u00f5imaldab h\u00f5lpsamini kontrollida k\u00f5iki seadistusi ja testida seda, mida muidu lihtsalt ei oleks v\u00f5imalik. Seet\u00f5ttu kaasatakse kvaliteetse toote arendusprotsessi ka hooldus.<\/p>\n

\u2014 Aga mis on anal\u00fc\u00fctika ja dokumentatsiooni suhtes?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: See kehtib rohkem enterprise s\u00fcsteemide kohta. Kui r\u00e4\u00e4gime enterprise'ist, tulevad kohe meelde sellised inimesed nagu anal\u00fc\u00fctikud ja s\u00fcsteemianal\u00fc\u00fctikud. M\u00f5nikord nimetatakse neid tehnilisteks kirjanikeks. Nad saavad \u00fclesande kirjutada spetsifikatsiooni ja t\u00e4idavad seda n\u00e4iteks kuu aega.<\/p>\n

On t\u00f5estatud, et sellise dokumentatsiooni koostamine viib pikaajaliste arendus- ja t\u00e4iustamisetappideni, kuna testimise k\u00e4igus tuvastatakse vigu, mille t\u00f5ttu algavad tagasitulekud. Tulemuseks on palju silmuseid, mis suurendavad arenduskulusid. Lisaks v\u00f5ivad need tuua kaasa haavatavusi. Me oleme k\u00fcll saanud kirjutada malli koodi, kuid seej\u00e4rel tehtud muudatused v\u00f5ivad rikkuda ideaalselt l\u00e4bim\u00f5eldud arhitektuuri.<\/p>\n

Kokkuv\u00f5ttes saame mitte t\u00e4iesti kvaliteetse toote, kuna arhitektuuri on juba tekkinud plaasterdusi, kood on m\u00f5nes kohas piisavalt katmata testidega, kuna t\u00e4htaeg pingutab ja k\u00f5ik vead tuleb kiirelt parandada. Ja see k\u00f5ik juhtus, kuna algses spetsifikatsioonis ei olnud arvesse v\u00f5etud k\u00f5iki teemasid, mis tuleb ellu viia.<\/p>\n

Arendajad ei ole kahjurid ega kirjuta teadlikult vale koodi.<\/p><\/blockquote>\n

\nKui oleksime alguses v\u00e4lja m\u00f5elnud spetsifikatsiooni, mis kataks k\u00f5ik vajalikud aspektid, oleks k\u00f5ik ellu viidud just nii, nagu vaja. Kuid see on utoopia.<\/p>\n

T\u00f5en\u00e4oliselt ei ole ideaalset 100-lehek\u00fcljelist spetsifikatsiooni v\u00f5imalik kirjutada. Seet\u00f5ttu tuleb m\u00f5elda alternatiivsetele viisidele dokumentatsiooni kirjutamiseks<\/strong>, spetsifitseerimisele, \u00fclesannete seadmiseks, mis viiks meid l\u00e4hemale sellele, et arendaja teeks t\u00f5eliselt vajalikku.<\/p>\n

Siia tuleb meelde Agile'i l\u00e4henemine \u2014 kasutajaloode koos aktsepteerimise kriteeriumidega. See sobib rohkem meeskondadele, kes arenevad v\u00e4ikeste iteratsioonide kaudu.<\/p>\n

\u2014 Kuidas on kasutatavuse testimise, toote kasutusmugavuse ja disainiga?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: See on v\u00e4ga oluline punkt, sest meeskonnas on disainerid. Enamasti kasutatakse disainereid teenusena \u2014 kas disainerite osakond v\u00f5i v\u00e4liskaudse disainerina. Tihti esinevad olukorrad, kus disainer on k\u00fcll toote t\u00f6\u00f6tajat kuulnud ja tegi seda, mida ta m\u00f5istis. Kuid kui hakkame iteratsiooni, selgub, et tegelikult ei ole tehtud seda, mida oodati: disainer unustas midagi, ei m\u00f5elnud tervikuna k\u00e4itumist l\u00e4bi, sest ta ei ole meeskonnas ega kontekstis, v\u00f5i front-end arendaja ei m\u00f5istnud l\u00f5puni tema maketti. V\u00f5ib osutuda vajalikuks mitu iteratsiooni ainult sellep\u00e4rast, et esineb probleem front-end arendaja arusaamises disainist.<\/p>\n

Lisaks on olemas veel \u00fcks probleem. Praegu on disainis\u00fcsteemid j\u00e4rjest populaarsemad. Need on m\u00fc\u00fcgis, kuid nende kasu ei ole sugugi ilmne.<\/p>\n

Ma kohtan arvamust, et disainis\u00fcsteemid, \u00fchelt poolt, lihtsustavad arendust, kuid teiselt poolt toovad nad kaasa palju piiranguid liidesele.<\/p><\/blockquote>\n

\nKokkuv\u00f5ttes ei tee me sellist funktsiooni, mida klient soovib, vaid sellise, mis on meile mugav, sest meil on juba teatud t\u00fckkidest, millest me saame selle teha.<\/p>\n

Mulle tundub, et sellele teemale tasub t\u00e4helepanu p\u00f6\u00f6rata ja m\u00f5elda, kas t\u00f5epoolest p\u00fc\u00fcdes disaini t\u00f6\u00f6d lihtsustada, me lahendame kliendi muret.<\/p>\n

\u2014 Tulemuseks on \u00fcllatavalt palju teemasid, mis on seotud kvaliteedi tagamisega. Venemaal on konverents, kus saab k\u00f5iki neid arutada?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Eestis toimub vanim teste konverents, mis sel aastal toimub juba 25. korda ja kannab nime \u2013 kvaliteedi tagamise konverents SQA Days. Konverentsil arutatakse peamiselt t\u00f6\u00f6riistu ja konkreetseid testimise l\u00e4henemisviise funktsionaalsetele testijatele. T\u00fc\u00fcpiliselt k\u00e4sitletakse SQA Days ettekannetes s\u00fcvitsi teste areaale, mis kuuluvad testijate vastutusvaldkonda, kuid mitte keeruliste k\u00fcsimustega.<\/p>\n

See aitab t\u00f5eliselt erinevates t\u00f6\u00f6riistades ja l\u00e4henemisviisides 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\u00fcljest ei muutu testijad protsessi osas aktiivsemaks, et m\u00f5elda toote globaalsele eesm\u00e4rgile ja selle \u00e4rilistele aspektidele.<\/p>\n

Ma juhin suurt osakonda, viin l\u00e4bi palju intervjuusid, mis tegelikult annavad \u00fclevaate kogu valdkonna seisust. Reeglina t\u00f6\u00f6tavad meie inimesed enterprise-sektoris ja neil on selged vastutusvaldkonnad. Kollegid, kes t\u00f6\u00f6tavad rahvusvahelistes projektides, rakendavad erinevaid testimise liike: nad saavad ise teha koormustestimist, j\u00f5udlustestimist ja isegi m\u00f5nikord turvatestimist, sest nad t\u00f5epoolest aitavad meeskonnal tagada toote kvaliteeti.<\/p>\n

Mulle oleks hea meel, kui meie Venemaal inimesed hakkaksid ka m\u00f5tlema, et funktsionaalne testimine ei ole ainus, millega ala piirdub.<\/p>\n

\u2014 Selleks me korraldame uut konverentsi QualityConf, mis on p\u00fchendatud kvaliteedile kui terviklikule distsipliinile. R\u00e4\u00e4gi ideest l\u00e4hemalt, mis on konverentsi peamine eesm\u00e4rk?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: 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.<\/p>\n

Viimasel ajal kuulen sageli n\u00f5udmist konsultatsioonidelt, mis puudutab seda, mida teha, kui esinevad probleemid testimise ja kvaliteediga. Kui hakata suhtlema meeskondadega, siis n\u00e4ha, et probleem ei ole mitte testijates endis, vaid selles, kuidas protsess on \u00fcles ehitatud. N\u00e4iteks kui arendajad arvavad, et nad vastutavad ainult koodi kirjutamise eest, l\u00f5peb nende vastutus kohe, kui nad on \u00fclesande testimiseks \u00fcle andnud.<\/p>\n

Kuid mitte k\u00f5ik ei m\u00f5tle sellele, et halvasti kirjutatud ja kehva arhitektuuriga kood toob projektile kaasa suured probleemid. Nad ei m\u00f5tle vigade hinnale, sellele, et tootmisse j\u00f5udnud vead v\u00f5ivad p\u00f5hjustada suuri kulusid ettev\u00f5ttele ja meeskonnale. Puudub kultuur selle \u00fcle m\u00f5elda. Soovin, et konverentsil hakkaksime seda levitama.<\/p>\n

M\u00f5istan, et see ei ole innovatsioon. Edward Deming, kvaliteedi 14 postulaadi autor, kirjutas vigade hinnast juba eelmisel sajandil. Selle raamatu p\u00f5hjal on v\u00e4lja kujunenud kvaliteedi tagamine kui distsipliin, kuid kahjuks unustatakse t\u00e4nap\u00e4eva arenduses see.<\/p>\n

\u2014 Kas plaanite k\u00e4sitleda teemasid, mis k\u00e4sitlevad otse testimist ja t\u00f6\u00f6riistu?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Ma arvan, et tulevad ettekanded t\u00f6\u00f6riistade kohta. On olemas piisavalt universaalseid t\u00f6\u00f6riistu, millega ettev\u00f5tted ja meeskonnad saavad tootele m\u00f5ju avaldada.<\/p>\n

K\u00f5ik ettekanded \u00fchendatakse globaalselt \u00fche \u00fchise missiooniga: edastada publikule, et selle l\u00e4henemise, t\u00f6\u00f6riista, meetodi, protsessi, testimise t\u00fc\u00fcbi abil oleme m\u00f5jutanud toote kvaliteeti ja parendanud kliendi elu.<\/p><\/blockquote>\n

\nMeil ei tule ettekandeid t\u00f6\u00f6riista p\u00e4rast, vaid k\u00f5ik ettekanded, mis programmi satuvad, on koondatud \u00fchise eesm\u00e4rgi \u00fcmber.<\/p>\n

\u2014 Kellega sa loodad, et see, millest sa r\u00e4\u00e4gid, huvitab? Keda sa n\u00e4ed konverentsi k\u00fclalistena?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Meil on ettekanded arendajatele, kellele ei ole oma projekti, toote, s\u00fcsteemi saatus \u00fcksk\u00f5ik. Testijatele on see samuti huvitav ja, nagu mulle tundub, eriti juhtidele. Juhi all m\u00f5tlen inimesi, kes teevad otsuseid ja saavad m\u00f5jutada toote, s\u00fcsteemi, meeskonna saatust ja arengut.<\/p>\n

Need on inimesed, kes m\u00f5tlevad, kuidas parandada toote ja s\u00fcsteemi kvaliteeti. Meie konverentsil saavad nad teada erinevatest tegevuskavadest ja m\u00f5istavad, mis neil praegu valesti on ja mida on vaja muuta.<\/p>\n

Arvan, et peamine kriteerium on aru saada, et kvaliteediga on midagi valesti ja soovida sellele m\u00f5ju avaldada. T\u00f5en\u00e4oliselt ei \u00f5nnestu meil esimesel katsel j\u00f5uda inimesteni, kes arvavad, et k\u00f5ik on nii h\u00e4sti.<\/p>\n

\u2014 Kuidas arvad, kas t\u00f6\u00f6stus on tervikuna k\u00fcpseks saanud, et r\u00e4\u00e4kida mitte ainult testimisest, vaid kvaliteedikultuurist?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Ma arvan, et on k\u00fcps. Praegu liiguvad paljud ettev\u00f5tted traditsioonilisest Waterfall l\u00e4henemisest Agile suunas. Orienteeritakse kliendile, meeskondades hakkavad inimesed t\u00f5eliselt m\u00f5tlema, kuidas luua kvaliteetne toode. Isegi suurtes ettev\u00f5tetes toimub suuna muutus kvaliteedi t\u00f5usu suunas.<\/p>\n

L\u00e4htuvalt kogusest, mis on kogukonnas k\u00fcsitud, arvan, et on juba aeg. Ma ei ole muidugi kindel, et see oleks ulatuslik revolutsioon, kuid ma sooviksin, et see m\u00f5tteviisi muutus toimuks.<\/p>\n

\u2014 Leppisime! Toome kultuuri ja muudame m\u00f5ttelaadi.<\/em><\/strong><\/p>\n

Konverents kvaliteetsete IT-toodete arendamisest QualityConf<\/a><\/noindex> toimub Moskvas 7. juunil<\/strong>. Kas teate, millised etapid moodustavad kvaliteetse toote, meil on edukate veaparanduste juhtumid, ja oma praktikas oleme testinud populaarseid meetodeid \u2014 me vajame teie kogemust. Saada<\/a><\/noindex> oma taotlusi 1. maiks<\/strong>, ja programmi komitee aitab konverentsi teema keskmesse tuua.<\/p>\n

Liituge chatiga<\/a><\/noindex>, kus arutame kvaliteedi ja konverentsi k\u00fcsimusi, j\u00e4lgige Telegrami kanaleid<\/a><\/noindex>, et olla kursis programmi uudistega.<\/p><\/blockquote>\n

Allikas: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0423\u00a0\u043d\u0430\u0441 \u043d\u043e\u0432\u0430\u044f \u0432\u0430\u0436\u043d\u0430\u044f \u0442\u0435\u043c\u0430\u00a0\u2014 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 IT-\u043f\u0440\u043e\u0434\u0443\u043a\u0442\u043e\u0432. \u041c\u044b\u00a0\u0447\u0430\u0441\u0442\u043e \u0433\u043e\u0432\u043e\u0440\u0438\u043c \u043d\u0430\u00a0HighLoad++, \u043a\u0430\u043a \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u043d\u0430\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b \u0431\u044b\u0441\u0442\u0440\u044b\u043c\u0438, \u0430\u00a0\u043d\u0430\u00a0Frontend Conf\u00a0\u2014 \u043a\u043b\u0430\u0441\u0441\u043d\u044b\u0439 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0438\u0439 \u0438\u043d\u0442\u0435\u0440\u0444\u0435\u0439\u0441, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043d\u0435\u00a0\u0442\u043e\u0440\u043c\u043e\u0437\u0438\u0442. \u0423\u00a0\u043d\u0430\u0441 \u0440\u0435\u0433\u0443\u043b\u044f\u0440\u043d\u043e \u0435\u0441\u0442\u044c \u0442\u0435\u043c\u044b \u043f\u0440\u043e \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435, \u0438\u00a0DevOpsConf \u043f\u0440\u043e \u043e\u0431\u044a\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u0435 \u0440\u0430\u0437\u043d\u044b\u0445 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0432, \u0432\u043a\u043b\u044e\u0447\u0430\u044f \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435. \u0410\u00a0\u043f\u0440\u043e\u00a0\u0442\u043e, \u0447\u0442\u043e \u043c\u043e\u0436\u043d\u043e \u043d\u0430\u0437\u0432\u0430\u0442\u044c \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u043e \u0432\u00a0\u0446\u0435\u043b\u043e\u043c, \u0438\u00a0\u043a\u0430\u043a \u043d\u0430\u0434 \u043d\u0438\u043c \u043a\u043e\u043c\u043f\u043b\u0435\u043a\u0441\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c\u00a0\u2014 \u043d\u0435\u0442. \u0418\u0441\u043f\u0440\u0430\u0432\u0438\u043c \u044d\u0442\u043e \u043d\u0430 QualityConf\u00a0\u2014 \u0431\u0443\u0434\u0435\u043c \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":23230,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31264","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Kes vastutab kvaliteedi eest? | ProHoster","description":"Tere, Habr! Meil on uus oluline teema - kvaliteetne IT-toodete arendus. Me r\u00e4\u00e4gime sageli HighLoad++ konverentsil, kuidas teha koormatavaid teenuseid kiireks, ja Frontend Conf'il - \u00e4gedast kasutajaliidest, mis ei pelga kiirusprobleeme. Meil on regulaarselt teemasid testimise kohta ning DevOpsConf'ist, mis k\u00e4sitleb erinevate protsesside, sealhulgas testimise, \u00fchendamist. Kuid sellest, mida v\u00f5ib nimetada kvaliteediks tervikuna, ja kuidas selle kallal komplekselt t\u00f6\u00f6tada - seda ei ole. Parandame selle QualityConf'il - arendame edasi.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0442\u043e \u043e\u0442\u0432\u0435\u0442\u0438\u0442 \u0437\u0430 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u043e? | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0423 \u043d\u0430\u0441 \u043d\u043e\u0432\u0430\u044f \u0432\u0430\u0436\u043d\u0430\u044f \u0442\u0435\u043c\u0430 \u2014 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 IT-\u043f\u0440\u043e\u0434\u0443\u043a\u0442\u043e\u0432. \u041c\u044b \u0447\u0430\u0441\u0442\u043e \u0433\u043e\u0432\u043e\u0440\u0438\u043c \u043d\u0430 HighLoad++, \u043a\u0430\u043a \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u043d\u0430\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b \u0431\u044b\u0441\u0442\u0440\u044b\u043c\u0438, \u0430 \u043d\u0430 Frontend Conf \u2014 \u043a\u043b\u0430\u0441\u0441\u043d\u044b\u0439 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0438\u0439 \u0438\u043d\u0442\u0435\u0440\u0444\u0435\u0439\u0441, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043d\u0435 \u0442\u043e\u0440\u043c\u043e\u0437\u0438\u0442. \u0423 \u043d\u0430\u0441 \u0440\u0435\u0433\u0443\u043b\u044f\u0440\u043d\u043e \u0435\u0441\u0442\u044c \u0442\u0435\u043c\u044b \u043f\u0440\u043e \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435, \u0438 DevOpsConf \u043f\u0440\u043e \u043e\u0431\u044a\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u0435 \u0440\u0430\u0437\u043d\u044b\u0445 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0432, \u0432\u043a\u043b\u044e\u0447\u0430\u044f \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435. \u0410 \u043f\u0440\u043e \u0442\u043e, \u0447\u0442\u043e \u043c\u043e\u0436\u043d\u043e \u043d\u0430\u0437\u0432\u0430\u0442\u044c \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u043e \u0432 \u0446\u0435\u043b\u043e\u043c, \u0438 \u043a\u0430\u043a \u043d\u0430\u0434 \u043d\u0438\u043c \u043a\u043e\u043c\u043f\u043b\u0435\u043a\u0441\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u2014 \u043d\u0435\u0442. \u0418\u0441\u043f\u0440\u0430\u0432\u0438\u043c \u044d\u0442\u043e \u043d\u0430 QualityConf \u2014 \u0431\u0443\u0434\u0435\u043c \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0442\u044c","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:40:21+00:00","article:modified_time":"2019-10-31T18:40:21+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31264","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 05:19:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:19:50","updated":"2026-01-21 05:19:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/31264","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=31264"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/31264\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/23230"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=31264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=31264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=31264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}