{"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 arendamine. R\u00e4\u00e4gime tihti HighLoad++-l, kuidas muuta koormatud teenuseid kiireks, ja Frontend Conf'is \u2013 \u00e4gedast kasutajaliidesest, mis ei takkardu. Meil on regulaarselt teemasid testimise kohta, ja DevOpsConf'is r\u00e4\u00e4gime erinevate protsesside, sealhulgas testimise, \u00fchendamisest. Aga kvaliteedi kui terviku \u00fcle ja selle kompleksse arendamise \u00fcle ei ole juttu.<\/p>\n

Parandame selle QualityConf<\/a><\/noindex>\u00a0\u2013 arendame kultuuri, kus m\u00f5eldakse kvaliteedile l\u00f5pptootes igas arendusetapis. Harjumust mitte j\u00e4\u00e4da kinni oma vastutusalasse ning seostada kvaliteeti mitte ainult testijatega.<\/p>\n

Allpool r\u00e4\u00e4gime programmidirektori, Tinkoff.Businessi testimise juhataja ja vene keelsete QA-kogukonna looja Anastasija Asejeva-Ngueniga<\/b> QA-sektori seisundist ja uue konverentsi missioonist.<\/p>\n

\"Kes
\n<\/a><\/noindex>
\n\u2013 Nastja, tere. R\u00e4\u00e4gi palun endast.<\/em><\/strong><\/p>\n

\"KesAnastasija<\/strong>: Juhtin testimist pangas, vastutame v\u00e4ga suure meeskonna eest \u2013 meid on \u00fcle 90 inimese. Meil on oluline \u00e4risektor, vastutame \u00e4ri\u00fchingute \u00f6kos\u00fcsteemi eest.<\/p>\n

Olen \u00f5ppinud 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\u00fc\u00fcd n\u00e4en kogu oma t\u00f6\u00f6d just selles valdkonnas.<\/p>\n

Olen tulihingeline kvaliteedi tagamise distsipliini toetaja. Mind ei j\u00e4ta k\u00fclmaks, milliseid tooteid luuakse, kuidas suhtutakse kvaliteeti ettev\u00f5ttes, meeskonnas ja p\u00f5him\u00f5tteliselt ka arendusprotsessis.<\/p><\/blockquote>\n

\nMinu jaoks on ilmne, et kogukond selles suunas on veel piisavalt k\u00fcps<\/strong>, v\u00e4hemalt Venemaal. Me ei pruugi alati m\u00f5ista, et kvaliteedi tagamine ei ole ainult asjaolu, et testime rakendust n\u00f5uetele vastavuse osas. Tahaksin muuta seda olukorda.<\/p>\n

\u2013 Sa kasutad termineid Quality Assurance ja testimine. Tavalise inimese silmis \u00fcksteisega kohtuvad need kaks m\u00f5istet v\u00e4ga tihti. Kuidas nad omavahel erinevad, kui s\u00fcvitsiminevat anal\u00fc\u00fcsida?<\/em><\/strong><\/p>\n

Anastasija:<\/strong> Tegelikult ei ole nad v\u00e4ga erinevad. Testimine on osa kvaliteedi tagamise distsipliinist, see on otsene tegevus \u2014 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\u00e4lja hulk outsourcer'eid, kes toovad ettev\u00f5tetesse testijaid, on testimine kahanenud \u00fcheks ainsaks liikmiseks.<\/p>\n

Enamasti piirdutakse ainult funktsionaalse testimisega: kontrollitakse, kas see, mis arendajate poolt kirjutati, vastab spetsifikatsioonile ja on k\u00f5ik.<\/p>\n

\u2014 R\u00e4\u00e4gi palun, milliseid teisi kvaliteedi tagamise distsipliine on veel olemas? Mis veel peale testimise siia kuulub?<\/em><\/strong><\/p>\n

Anastasija<\/strong>: Kvaliteedi tagamine on eelk\u00f5ige kvaliteetse toote loomine. Teisis\u00f5nu, me k\u00fcsime endalt, milliste kvaliteedi atribuutidega peab meie toode olema varustatud. Seega, kui me selle m\u00f5istame, saame me v\u00f5rrelda, kes m\u00f5jutab neid kvaliteedi atribuute. Pole oluline, kas see on arendaja, projektijuht v\u00f5i tootearendaja<\/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\u00f5uetele, vaid ka testeerida n\u00f5udeid, seada kahtluse alla tootekujundajatelt saadud s\u00f5nastusi, paljastada k\u00f5ik varjatud n\u00f5uded ja kliendi ootused. Kui me toome meie kliendile uusi funktsioone, peame t\u00f5eliselt rahuldama tema ootused ja lahendama tema probleemid. Kui m\u00f5tleme k\u00f5igile kvaliteedi atribuutidele, siis on klient rahul ja m\u00f5istab, et ettev\u00f5te, mille toodet ta kasutab, t\u00f5eliselt hoolib tema huvidest ja ei tegutse ainult p\u00f5him\u00f5ttel \u201eainult toote v\u00e4ljalaskmine\u201c.<\/p>\n

\u2014 Tundub, et see, mida sa just kirjeldasid, on tootekujundaja \u00fclesanne. See ei ole p\u00f5him\u00f5tteliselt testimise ega kvaliteedi kohta \u2014 see on \u00fcldse toote juhtimise kohta, eks?<\/em><\/strong><\/p>\n

Anastasija<\/strong>: Kaasa arvatud. Kvaliteedi tagamine ei ole distsipliin, mille eest vastutab \u00fcks kindel inimene. Praegu on testimises populaarne suundumus, l\u00e4henemine, mida nimetatakse Agile Testimiseks<\/strong>Tema m\u00e4\u00e4ratlus \u00fctleb, et see on meeskondlik l\u00e4henemine testimisele, mis h\u00f5lmab kindlat praktika kogumit. Selle l\u00e4henemise rakendamise eest vastutab kogu meeskond, isegi kui meeskonnas ei ole testijat. Kogu meeskond suunab oma t\u00e4helepanu sellele, et pakkuda v\u00e4\u00e4rtust kliendile ja et see v\u00e4\u00e4rtus vastaks tema ootustele.<\/p>\n

\u2014 Ehk siis kvaliteet kattub peaaegu k\u00f5igi \u00fcmbritsevate distsipliinidega, seades piirid k\u00f5igile asjaoludele?<\/em><\/strong><\/p>\n

Anastasija<\/strong>: T\u00e4iesti \u00f5ige. Kui m\u00f5tleme sellele, et soovime luua kvaliteetset produktsiooni, hakkame m\u00f5tlema erinevatele kvaliteedi atribuutidele. N\u00e4iteks, kuidas kontrollida, et oleme t\u00f5epoolest loonud funktsiooni, mis on meie kliendile vajalik.<\/p>\n

Siinkohal tuleb jutuks selline testimise t\u00fc\u00fcp nagu UAT<\/strong> (kasutajate aktsepteerimistestimine). Kahjuks praktiseeritakse seda Venemaal harva, kuid see on m\u00f5nikord olemas SCRUM-meeskondades l\u00f5ppklientide demona. V\u00e4lisfirmades on see \u00fcsna levinud testimise liik. Enne kui avame funktsionaalsuse k\u00f5igile klientidele, teeme esmalt UAT-i, 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 k\u00f5ikide teiste klientide jaoks laiendamine.<\/p>\n

Seega, me suuname end \u00e4ri, l\u00f5ppklient, kuid samas ei unusta tehnoloogiat<\/strong>. Toote kvaliteet s\u00f5ltub tugevalt ka tehnoloogiast. Kui meie arhitektuur on halb, ei saa me funktsioone kiiresti v\u00e4lja anda ja ei vasta kliendi ootustele. V\u00f5ib esineda palju vigu, kui proovime suurendada m\u00f5\u00f5detavust, v\u00f5i refaktoreerimise k\u00e4igus v\u00f5ime midagi katki teha. See k\u00f5ik m\u00f5jutab kliendi rahulolu.<\/p>\n

Nii et arhitektuur peab olema selline, et saaksime kirjutada puhta koodi, mis v\u00f5imaldab kiiresti muudatusi teha ja ei pea kartma, et l\u00f5hume k\u00f5ik \u00e4ra. Et arendus iteratsioonid ei veniks mitme kuu jooksul lihtsalt selle p\u00e4rast, et meil on nii palju p\u00e4randit ja pikad testimise etapid on vajalikud.<\/p>\n

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

Anastasija<\/strong>: N\u00fc\u00fcd kujutame ette, et oleme juba kliendile teenuse k\u00e4tte toimetanud. Ilmselgelt tuleb toote kvaliteeti j\u00e4lgida ka siis, kui see on juba tootmisprotsessis. Sel hetkel v\u00f5ivad ilmneda olukorrad, mis p\u00f5hinevad mitmetes mitte-eeldatavates stsenaariumides, nii-\u00f6elda vead.<\/p>\n

Esimene k\u00fcsimus on - kuidas me nendega vigadega t\u00f6\u00f6tame p\u00e4rast seda, kui toode on juba v\u00e4lja antud? Kuidas me n\u00e4iteks reageerime koormusele? Klient ei ole v\u00e4ga rahul, kui leht laadib rohkem kui 30 sekundit.<\/p>\n

Siia m\u00e4ngu astub t\u00f6\u00f6tlus v\u00f5i, nagu n\u00fc\u00fcd \u00f6eldakse, DevOps<\/strong>. Tegelikult on need inimesed, kes vastutavad toote t\u00f6\u00f6keskkonna eest, kui see on tootmisprotsessis. Siia kuuluvad erinevad j\u00e4lgimise viisid. On isegi alaliik testimisest - testimine tootmisprotsessis, kui lubame endale mitte testida midagi enne v\u00e4ljalaskmist ja testime seda kohe tootmisprotsessis. Need on mitmed meetmed, mis on seotud infrastruktuuri korraldamisega ja mis v\u00f5imaldavad kiiresti reageerida juhtumile, m\u00f5jutada seda, parandada.<\/p>\n

Infrastruktuur on samuti oluline. Tihti juhtub, et testimise ajal ei \u00f5nnestu meil t\u00f5eliselt veenduda, et meil on k\u00f5ik, mida sooviksime kliendile pakkuda. K\u00e4ivitame tootmisprotsessis - ja hakkame tabama mitte-eeldatavaid olukordi. Ja see k\u00f5ik tuleneb sellest, et testimisprotsessi infrastruktuur ei vasta tootmisprotsessi infrastruktuurile. Sealt tuleb uus testimisviis - infrastruktuuri testimine<\/strong>. Need on erinevad konfiguratsioonid, seaded, andmebaaside migratsioon jne.<\/p>\n

Siit tekib k\u00fcsimus - kas meeskond peaks kasutama infrastruktuuri kui koodi.<\/p>\n

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

\nLoodan, et konverentsil on ettekandega reaalne juhtum. Kirjuta meile, kui oled valmis oma kogemust jagama, kuidas infrastruktuur kui kood m\u00f5jutab kvaliteeti. Infrastruktuur kui kood v\u00f5imaldab lihtsamalt kontrollida k\u00f5iki seadistusi ja testida seda, mida muidu lihtsalt ei saaks. Seega kaasatakse kvaliteetse toote arendamise protsessi ka hooldamine.<\/p>\n

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

Anastasija<\/strong>: See puudutab rohkem ettev\u00f5tte s\u00fcsteeme. Kui r\u00e4\u00e4gime ettev\u00f5tte tasemest, tulevad kohe meelde sellised inimesed nagu anal\u00fc\u00fctikud ja s\u00fcsteemianal\u00fc\u00fctikud. M\u00f5nikord nimetatakse neid ka tehnilisteks toimetajateks. Nad saavad \u00fclesande kirjutada spetsifikatsiooni ja t\u00e4idavad seda n\u00e4iteks kuu aega.<\/p>\n

Kordu on korduvalt t\u00f5estatud, et sellise dokumentatsiooni kirjutamine viib v\u00e4ga pikkade arendus- ja t\u00e4iustamisiteratsioonideni, kuna testimise k\u00e4igus tuvastatakse vigu ja algavad tagasitoomised. Tulemuseks on palju sildu, mis t\u00f5stavad arenduskulusid. Lisaks v\u00f5ib see tuua kaasa haavatavusi. Tundub, et oleme kirjutanud etalonkoode, kuid seej\u00e4rel teeme muudatusi, mis rikuvad perfektse arhitektuuri.<\/p>\n

L\u00f5pptulemusena saame mitte p\u00e4ris kvaliteetse toote, kuna arhitektuuri on juba tekkinud lapit\u00f6\u00f6d, kood on m\u00f5nes kohas ebapiisavalt testitud, kuna t\u00e4htaegade t\u00f5ttu tuleb kiiremini k\u00f5ik vead likvideerida. K\u00f5ik see tuleneb sellest, et algses spetsifikatsioonis ei olnud arvestatud k\u00f5iki aspekte, mida oleks pidanud rakendama.<\/p>\n

Arendajad ei ole halvad poisid ja nad ei kirjuta teadlikult vigu sisaldavat koodi.<\/p><\/blockquote>\n

\nKui oleksime alguses hoolikalt l\u00e4bi m\u00f5elnud spetsifikatsiooni, kus oleks kajastatud k\u00f5ik vajalikud aspektid, oleks k\u00f5ik rakendatud just nii, nagu peab. Kuid see j\u00e4\u00e4b utoopiaks.<\/p>\n

V\u00f5ib-olla ei ole ideaalset 100-lehek\u00fcljelist spetsifikatsiooni v\u00f5imalik kirjutada. Seet\u00f5ttu tuleb m\u00f5elda alternatiivsetele viisidele dokumentatsiooni,<\/strong>spetsifikatsiooni ja \u00fclesannete seadmiseks, mis tooksid meid l\u00e4hemale sellele, et arendaja teeks just seda, mida on vaja.<\/p>\n

Siin tulevad meelde Agile'i l\u00e4henemised \u2013 kasutajate lood koos vastuv\u00f5tmise kriteeriumidega. See on rohkem rakendatav meeskondadele, kes arenevad v\u00e4ikeste iteratsioonidega.<\/p>\n

\u2013 Kuidas on kasutatavustestimise, toote kasutusmugavuse ja disainiga?<\/em><\/strong><\/p>\n

Anastasija<\/strong>: See on v\u00e4ga oluline moment, kuna meeskonnas on disainerid. K\u00f5ige sagedamini kasutatakse disainereid teenusena \u2013 kas disainimeeskond v\u00f5i disainer v\u00e4lishankena. Tihti juhtub, et disainer on tundunud, et kuulab tootearendajat ja teeb selle, mida ta m\u00f5tles. Kuid kui l\u00e4heme iteratsiooni, selgub, et tegelikult ei ole tehtud seda, mida ootasime: disainer j\u00e4ttis midagi k\u00f5rvale, ei m\u00f5elnud k\u00e4itumist l\u00f5puni l\u00e4bi, kuna ta ei olnud meeskonnas ja kontekstis, v\u00f5i es front-end arendaja ei saanud tema kujundusest l\u00f5puni aru. V\u00f5ib osutuda vajalikuks mitu iteratsiooni ainult seet\u00f5ttu, et front-end arendajal on probleem disaini arusaamisega.<\/p>\n

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

I encounter the opinion that design systems, on one hand, simplify development, but on the other hand, impose many restrictions on the interface.<\/p><\/blockquote>\n

\nAs 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.<\/p>\n

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

\u2014 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?<\/em><\/strong><\/p>\n

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

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

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

I would like our guys in Russia to also start considering that the industry does not end with functional testing.<\/p>\n

\u2014 Meie eesm\u00e4rgiks on korraldada uus QualityConf konverents, mis keskendub kvaliteedile kui terviklikule distsipliinile. R\u00e4\u00e4gi plaanist l\u00e4hemalt, mis on konverentsi peamine eesm\u00e4rk?<\/em><\/strong><\/p>\n

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

Tihti kuulen n\u00f5udmiseid konsultatsioonifirmadelt, et mida teha, kui esinevad probleemid testimisega ja kvaliteediga. Kui hakkad meeskondadega suhtlema, n\u00e4ed, et probleem ei ole asjades ise, vaid selles, kuidas on protsess \u00fcles ehitatud. N\u00e4iteks, kui arendajad arvavad, et nad on vastutavad ainult koodi kirjutamise eest, l\u00f5ppeb nende vastutus just siis, kui nad on \u00fclesande testimisele \u00fcle andnud.<\/p>\n

Kaugeltki mitte k\u00f5ik ei m\u00f5tle sellele, et kohmakalt kirjutatud n\u00f5rk kood kehva arhitektuuriga toob projektile suuri probleeme. Nad ei m\u00f5tle vigade maksma minekule, et vead, mis j\u00f5uavad tootmisse, v\u00f5ivad ettev\u00f5ttele ja meeskonnale p\u00f5hjustada suuri kulusid. Siin on puudu kultuur m\u00f5elda sellele. Soovin, et konverentsil hakkaksime seda levitama.<\/p>\n

Ma m\u00f5istan, et see ei ole innovatsioon. Edward Deming, 14 kvaliteedisammude autori, r\u00e4\u00e4kis vigade kulust juba eelmisel sajandil. Selle raamatu p\u00f5hjal on \u00fcles ehitatud Quality Assurance kui distsipliin, kuid kahjuks unustab t\u00e4nap\u00e4eva arendus selle.<\/p>\n

\u2014 Kas kavatsete k\u00e4sitleda ka teemasid, mis otseselt puudutavad testimist ja t\u00f6\u00f6riistu?<\/em><\/strong><\/p>\n

Anastasija<\/strong>: Arvan, et ettekanded t\u00f6\u00f6riistade kohta on v\u00f5imalikud. On piisavalt universaalseid t\u00f6\u00f6riistu, millega ettev\u00f5tted ja meeskonnad saavad toodet m\u00f5jutada.<\/p>\n

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

\nMeil ei ole kindlasti ettekandeid, mis k\u00e4sitlevad t\u00f6\u00f6riistu pelgalt t\u00f6\u00f6riistade p\u00e4rast. K\u00f5ik ettekanded, mis saavad programmi, on \u00fchendatud \u00fchise eesm\u00e4rgiga.<\/p>\n

\u2014 Kellele on huvitav see, millest sa r\u00e4\u00e4gid, kedasi n\u00e4ed konverentsi k\u00fclalistena?<\/em><\/strong><\/p>\n

Anastasija<\/strong>: Meil on ettekanded arendajatele, kellele ei ole \u00fcksk\u00f5ik oma projekti, toote, s\u00fcsteemi saatuse \u00fcle. Samuti huvitab see testijate, ja, nagu mulle tundub, eriti juhtide jaoks. Juhtide all m\u00f5tlen ma inimesi, kes teevad otsuseid ja saavad m\u00f5jutada toote, s\u00fcsteemi, meeskonna ning sellega seonduvat arengut.<\/p>\n

Need on inimesed, kes k\u00fcsivad endalt \u2013 kuidas parandada toote, s\u00fcsteemi kvaliteeti. Meie konverentsil saavad nad teada erinevatest meetmest ning saavad aru, mis neil praegu puudu 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. Ilmselt ei \u00f5nnestu meil esimesel korral j\u00f5uda inimesteni, kes arvavad, et k\u00f5ik on korras.<\/p>\n

\u2014 Kuidas sa arvad, kas t\u00f6\u00f6stus on \u00fcldiselt k\u00fcps, et r\u00e4\u00e4kida mitte lihtsalt testimisest, vaid kvaliteedikultuurist?<\/em><\/strong><\/p>\n

Anastasija<\/strong>: Ma arvan, et on. Praegu liiguvad paljud ettev\u00f5tted traditsioonilisest Waterfall l\u00e4henemisest Agile suunas. Klientidele orienteeritakse, inimesed meeskondades hakkavad t\u00f5siselt m\u00f5tlema, kuidas luua kvaliteetset toodet. Isegi suurtes ettev\u00f5tetes toimuvad \u00fcmberorienteerumised kvaliteedi parandamiseks.<\/p>\n

Olles n\u00e4inud, kui palju k\u00fcsimusi tekib kogukonnas, arvan, et on juba aeg. Ma ei ole muidugi kindel, et see saab olema ulatuslik revolutsioon, kuid loodaksin, et see meelemuutus toimub.<\/p>\n

\u2014 Kokku leppimist! Hakkame kasvatama kultuuri ja muutma teadvust.<\/em><\/strong><\/p>\n

Konverents kvaliteetse IT-toodete arendamisest QualityConf<\/a><\/noindex> toimub Moskvas 7. juunil<\/strong>. Teate, millistest etappidest koosneb kvaliteetne toode, meil on eelnevalt edukate vigade lahendamise juhtumid, oleme oma praktikas katsetanud tuntud meetodeid \u2013 vajame teie kogemust. Saatke<\/a><\/noindex> oma taotlusi hiljemalt 1. maid<\/strong>, ja Programmikomitee aitab teemade fookusele keskenduda konverentsi \u00fcldise terviklikkuse jaoks.<\/p>\n

Liituge vestlusgrupiga<\/a><\/noindex>, kus arutame kvaliteedi ja konverentsiga seotud k\u00fcsimusi, j\u00e4lgige meie Telegrami kanalit<\/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\udd47 Kes vastutab kvaliteedi eest? | ProHoster","description":"Tere, Habr! Meil on uus oluline teema \u2013 kvaliteetne IT-toodete arendamine.","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.","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}]}}