{"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\/da\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","title":{"rendered":"Hvem st\u00e5r til ansvar for kvaliteten?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hello, Habr!<\/p>\n

Vi har et nyt vigtigt emne - kvalitetsudvikling af IT-produkter. Vi taler ofte p\u00e5 HighLoad++, om hvordan man g\u00f8r belastede tjenester hurtigere, og p\u00e5 Frontend Conf - en fantastisk brugergr\u00e6nseflade, der ikke h\u00e6nger. Vi har regelm\u00e6ssigt emner om testning, og DevOpsConf handler om at forene forskellige processer, herunder testning. Men om det, man kan kalde kvalitet generelt, og hvordan man arbejder omfattende med det - der er der ingen.<\/p>\n

Lad os rette dette til QualityConf<\/a><\/noindex>\u00a0\u2013 vi vil udvikle kulturen for at t\u00e6nke p\u00e5 kvaliteten af det endelige produkt for brugeren p\u00e5 hver udviklingsfase. En vane med ikke at kaste sig ind i sit eget ansvarsomr\u00e5de og associere kvalitet ikke kun med testere.<\/p>\n

Under overskriften taler vi med hovedet for programkomiteen, lederen af testning hos Tinkoff.Business, skaberen af det russisktalende QA-f\u00e6llesskab Anastasia Aseeva-Nguen<\/b> om tilstanden i QA-branchen og missionen for den nye konference.<\/p>\n

\"Hvem
\n<\/a><\/noindex>
\n\u2013 Hej Nastya. Fort\u00e6l venligst lidt om dig selv.<\/em><\/strong><\/p>\n

\"HvemAnastasia<\/strong>: Jeg leder testningen i banken, hvor jeg har ansvaret for et meget stort team - vi er over 90 personer. Vi har en vigtig forretningslinje, vi st\u00e5r for \u00f8kosystemet for juridiske personer.<\/p>\n

Jeg har studeret matematik og oprindeligt \u00f8nsket at blive programm\u00f8r. Men da jeg fik et sp\u00e6ndende tilbud, besluttede jeg at pr\u00f8ve mig som tester. Som m\u00e6rkeligt det kan lyde, viste det sig at v\u00e6re min kald. Nu ser jeg hele mit arbejde pr\u00e6cist i denne branche.<\/p>\n

Jeg er en fervent tilh\u00e6nger af disciplinen Quality Assurance. Jeg er ikke ligeglad med, hvilke produkter der skabes, hvordan kvaliteten bliver behandlet i virksomheden, i teamet og generelt i udviklingsprocessen.<\/p><\/blockquote>\n

\nFor mig er det \u00e5benlyst, at f\u00e6llesskabet p\u00e5 dette omr\u00e5de er utilstr\u00e6kkeligt modent<\/strong>, i det mindste i Rusland. Vi forst\u00e5r ikke altid, at kvalitetssikring kun er selve testen af applikationen for at opfylde kravene. Jeg vil gerne \u00e6ndre denne situation.<\/p>\n

\u2013 Du bruger ord som Quality Assurance og testning. I almindelige menneskers \u00f8jne krydser disse to termer ofte hinanden. Hvordan adskiller de sig, hvis man graver dybt?<\/em><\/strong><\/p>\n

Anastasia:<\/strong> Det adskiller sig ikke rigtig. Testning er en del af disciplinen Quality Assurance, det er en direkte aktivitet \u2013 selve faktum, at jeg tester noget. Der findes faktisk mange forskellige former for testning, og forskellige personer ansvarer for de forskellige typer testning. Men i Rusland, da b\u00f8lgen af outsourcere dukkede op, der leverede testere til virksomheder, blev testning reduceret til \u00e9n type.<\/p>\n

I de fleste tilf\u00e6lde begr\u00e6nser man sig kun til funktionel testning: man tjekker, at det, udviklerne har kodet, lever op til specifikationen og alt.<\/p>\n

\u2013 Fort\u00e6l mig venligst, hvilke andre discipliner inden for kvalitetssikring der findes? Hvad andet end testning indg\u00e5r i dette?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Quality Assurance handler f\u00f8rst og fremmest om at skabe et kvalitetsprodukt. Det vil sige, at vi stiller os sp\u00f8rgsm\u00e5let, hvilke kvalitetsattributter vores produkt skal have. Hvis vi forst\u00e5r dette, kan vi matche, hvem der p\u00e5virker disse kvalitetsattributter. Uanset om det er udvikleren, projektlederen eller produktlederen<\/strong>\u00a0\u2013 det er en person, der p\u00e5virker produktets udvikling, dets backlog, dets strategi.<\/p>\n

Testeren begynder bedre at forst\u00e5 sin rolle. Han forst\u00e5r, at hans opgave ikke kun er at teste for overensstemmelse med kravene, men ogs\u00e5 at teste kravene, stille sp\u00f8rgsm\u00e5l ved formuleringer, der kommer fra produktlederen, og afd\u00e6kke alle de implicitte krav og forventninger fra kunden. N\u00e5r vi leverer ny funktionalitet til vores kunde, skal vi virkelig im\u00f8dekomme hans forventninger og l\u00f8se hans problemer. Hvis vi t\u00e6nker p\u00e5 alle kvalitetsattributterne, vil kunden v\u00e6re tilfreds og forst\u00e5, at virksomheden, hvis produkt han bruger, virkelig cares om hans interesser og ikke arbejder efter princippet \"bare for at f\u00e5 en funktion ud af d\u00f8ren.\"<\/p>\n

\u2013 Det virker som om, det, du lige har beskrevet, er produktlederens opgave. Det handler grundl\u00e6ggende ikke om testning eller kvalitet \u2013 det handler overhovedet om produktstyring, ikke?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Det er delvist rigtigt. Quality Assurance er ikke en disciplin, som kun \u00e9n konkret person har ansvaret for. Der er i \u00f8jeblikket en popul\u00e6r retning inden for testning, en tilgang kaldet Agile Testing<\/strong>I definitionen siger det klart, at det er en teamtilgang til testning, som inkluderer et bestemt s\u00e6t praksisser. Implementeringen af denne tilgang er et ansvar for hele teamet, og det er ikke n\u00f8dvendigt, at der er en tester i teamet. Hele teamet fokuserer p\u00e5 at levere v\u00e6rdi til kunden, og at denne v\u00e6rdi opfylder hans forventninger.<\/p>\n

\u2014 S\u00e5 kvalitet passerer n\u00e6ppe ikke ind i n\u00e6sten alle omkringliggende discipliner og l\u00e6gger rammer for alt omkring os?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Korrekt. N\u00e5r vi overvejer, hvad vi vil skabe et kvalitetsprodukt, begynder vi at t\u00e6nke over forskellige kvalitetsattributter. For eksempel, hvordan vi kan tjekke, om vi faktisk har lavet en funktion, der er n\u00f8dvendig for vores kunde.<\/p>\n

Her dukker en testtype op, kaldet UAT<\/strong> (user acceptance testing). Desv\u00e6rre praktiseres det sj\u00e6ldent i Rusland, men det findes nogle gange i SCRUM-hold som en demo for den endelige kunde. I udenlandske virksomheder er det en ret udbredt testtype. F\u00f8r vi \u00e5bner funktionaliteten for alle kunder, laver vi f\u00f8rst UAT, det vil sige, vi inviterer den endelige forbruger, som udf\u00f8rer testningen og straks giver feedback - om produktet virkelig lever op til forventningerne og l\u00f8ser behovet. F\u00f8rst efter dette sker der en skalering til alle de andre kunder.<\/p>\n

S\u00e5 vi fokuserer p\u00e5 virksomheden, p\u00e5 den endelige kunde, men vi glemmer ikke teknologien<\/strong>. Kvaliteten af produktet afh\u00e6nger ogs\u00e5 i h\u00f8j grad af teknologierne. Hvis vi har en d\u00e5rlig arkitektur, kan vi ikke hurtigt frigive funktioner og leve op til kundens forventninger. Der kan v\u00e6re mange fejl, n\u00e5r vi fors\u00f8ger at skalere, eller under fors\u00f8g p\u00e5 at lave refaktorering, kan vi \u00f8del\u00e6gge noget. Alt dette vil p\u00e5virke kundetilfredsheden.<\/p>\n

Fra denne synsvinkel skal arkitekturen v\u00e6re s\u00e5dan, at vi kan skrive ren kode, som g\u00f8r det muligt at foretage hurtige \u00e6ndringer uden frygt for, at vi \u00f8del\u00e6gger alt. For at iterationerne af forbedringer ikke str\u00e6kker sig over flere m\u00e5neder bare fordi vi har s\u00e5 meget legacy, og der er behov for lange testfaser.<\/p>\n

\u2014 Samlet set er udviklere, arkitekter, produktfolk, produktledere og selve testerne allerede involveret. Hvem ellers er involveret i kvalitetssikringsprocessen?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Lad os forestille os, at vi allerede har leveret en funktion til kunden. Det er tydeligt, at man skal holde \u00f8je med produktkvaliteten, n\u00e5r det allerede er i produktion. I denne fase kan der opst\u00e5 situationer med uventede scenarier, s\u00e5kaldte bugs.<\/p>\n

Det f\u00f8rste sp\u00f8rgsm\u00e5l er - hvordan arbejder vi med disse bugs, efter vi har udgivet produktet? Hvordan reagerer vi for eksempel p\u00e5 belastningen? Kunden vil ikke v\u00e6re s\u00e6rlig tilfreds, hvis siden loader i mere end 30 sekunder.<\/p>\n

Her tr\u00e6der drift eller, som det nu kaldes, DevOps<\/strong>. Faktisk er det mennesker, der er ansvarlige for driften af produktet, n\u00e5r det allerede er i produktion. Dette omfatter forskellige former for overv\u00e5gning. Der er endda en underkategori af testning - testning i produktion, hvor vi tillader os ikke at teste noget f\u00f8r udgivelsen og tester det straks i produktion. Det er en r\u00e6kke aktiviteter fra et perspektiv af infrastrukturorganisation, der g\u00f8r det muligt hurtigt at reagere p\u00e5 en h\u00e6ndelse, p\u00e5virke den og rette fejlen.<\/p>\n

Infrastrukturen er ogs\u00e5 vigtig. Der opst\u00e5r ofte situationer, hvor det under test er umuligt at sikre, at vi virkelig har alt det, vi gerne vil give kunden. Vi udgiver i produktion - og begynder at opleve uventede situationer. Og det hele skyldes, at infrastrukturen i testen ikke svarer til infrastrukturen i produktionen. Heraf opst\u00e5r en ny form for testning - infrastrukturtestning<\/strong>. Dette inkluderer forskellige konfigurationer, indstillinger, migrering af databaser osv.<\/p>\n

Her opst\u00e5r sp\u00f8rgsm\u00e5let - er det muligt, at teamet skal bruge infrastruktur som kode.<\/p>\n

Jeg tror p\u00e5, at infrastrukturen direkte p\u00e5virker produktkvaliteten.<\/p><\/blockquote>\n

\nJeg h\u00e5ber, at der vil v\u00e6re et opl\u00e6g med en reel case p\u00e5 konferencen. Skriv til os, hvis du er klar til at dele din erfaring om, hvordan infrastruktur som kode p\u00e5virker kvaliteten. Infrastrukturen som kode g\u00f8r det lettere at kontrollere alle indstillinger og teste det, der ellers ville v\u00e6re umuligt. Derfor involveres driften ogs\u00e5 i processen med at udvikle et kvalitetsprodukt.<\/p>\n

\u2014 Hvad med analyser og dokumentation?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Dette vedr\u00f8rer mere enterprise-systemer. N\u00e5r vi taler om enterprise, t\u00e6nker man straks p\u00e5 personer som analytikere og systemanalytikere. Nogle gange kaldes de tekniske skribenter. De f\u00e5r en opgave om at skrive en specifikation og udf\u00f8rer den, for eksempel p\u00e5 en m\u00e5ned.<\/p>\n

Det er gentagne gange bevist, at udarbejdelsen af s\u00e5dan dokumentation f\u00f8rer til meget lange udviklingsiterationer og forl\u00e6ngede forbedringsfaser, fordi fejl opdages i testprocessen, hvilket resulterer i tilbagesendelser. Dette skaber mange sl\u00f8jfer, der \u00f8ger udviklingsomkostningerne. Derudover kan det introducere s\u00e5rbarheder. Vi har tilsyneladende skrevet referencekode, men derefter foretaget \u00e6ndringer, der bryder den velovervejede arkitektur.<\/p>\n

Resultatet bliver ikke et s\u00e6rlig kvalitetsprodukt, fordi der allerede er kommet lapper i arkitekturen, og koden er ikke tilstr\u00e6kkeligt d\u00e6kket af tests i nogle omr\u00e5der, fordi tidsfristerne presser, og vi skal hurtigere f\u00e5 lukket alle fejl. Alt dette skyldes, at ikke alle punkter, der skulle implementeres, blev overvejet i den oprindelige specifikation.<\/p>\n

Udviklere er ikke skurke og skriver ikke bevidst kode med fejl.<\/p><\/blockquote>\n

\nHvis vi fra starten havde overvejet en specifikation, der d\u00e6kkede alle n\u00f8dvendige punkter, ville alt have blevet gennemf\u00f8rt som det skulle. Men det er utopi.<\/p>\n

M\u00e5ske er det umuligt at skrive en perfekt specifikation p\u00e5 100 sider. Derfor b\u00f8r vi overveje alternative m\u00e5der at skrive dokumentation p\u00e5<\/strong>, specificering, opgavestilling, som bringer os t\u00e6ttere p\u00e5, at udvikleren laver pr\u00e6cis det, der er n\u00f8dvendigt.<\/p>\n

Her kommer tilgange fra Agile i tankerne \u2013 brugerhistorier med acceptkriterier. Dette er mere anvendeligt for hold, der udvikler sig i sm\u00e5 iterationer.<\/p>\n

\u2013 Hvad med usability-testning, brugervenlighed af produktet, design?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Det er et meget vigtigt punkt, fordi der er designere i teamet. Ofte anvendes designere som en service \u2013 enten et designerteam eller en designer p\u00e5 outsourcing. Ofte opst\u00e5r situationer, hvor designeren tilsyneladende har lyttet til produktlederen og gjort, hvad han forstod. Men n\u00e5r vi g\u00e5r i gang med iterationen, viser det sig, at det faktisk ikke er gjort, som forventet: designeren har glemt noget, ikke t\u00e6nkt fuldt ud p\u00e5 opf\u00f8relsen, fordi han ikke er i teamet og ikke i konteksten, eller frontend-udvikleren har ikke helt forst\u00e5et hans layout. Det kan v\u00e6re n\u00f8dvendigt med flere iterationer kun fordi der er et problem med forst\u00e5elsen af designet fra frontend-udviklerens side.<\/p>\n

Der er ogs\u00e5 et andet problem. Designsystemer vinder i \u00f8jeblikket popularitet. De er p\u00e5 mode, men fordelene ved dem er ikke helt \u00e5benlyse.<\/p>\n

Jeg st\u00f8der p\u00e5 meninger om, at designsystemer p\u00e5 den ene side forenkler udviklingen, men p\u00e5 den anden side p\u00e5l\u00e6gger de mange begr\u00e6nsninger p\u00e5 gr\u00e6nsefladen.<\/p><\/blockquote>\n

\nI sidste ende laver vi ikke den funktion, som kunden \u00f8nsker at f\u00e5, men en, der er praktisk for os, fordi vi allerede har visse moduler, som vi kan bruge til at lave den.<\/p>\n

Jeg synes, det er v\u00e6rd at overveje dette emne og t\u00e6nke over, om vi i fors\u00f8get p\u00e5 at forenkle designarbejdet virkelig l\u00f8ser kundens problem.<\/p>\n

\u2014 Det viser sig at v\u00e6re utroligt mange emner relateret til kvalitetssikring. Er der en konference i Rusland, hvor man kan diskutere dem alle?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Der er en meget gammel konference om testning, der i \u00e5r afholdes for 25. gang og hedder \u2013 Konference om kvalitetssikring SQA Days. P\u00e5 den diskuteres der prim\u00e6rt om v\u00e6rkt\u00f8jer og specifikke tilgang til testning for funktionelle testere. Som regel bliver specifikke omr\u00e5der inden for testernes ansvar dybtg\u00e5ende behandlet i pr\u00e6sentationerne p\u00e5 SQA Days, men ikke komplekse emner.<\/p>\n

Det hj\u00e6lper virkelig med at forst\u00e5 forskellige v\u00e6rkt\u00f8jer og tilgange til, hvordan man tester databaser, API'er osv. Men p\u00e5 den anden side motiverer det ikke til at involvere andre aspekter i skabelsen af et kvalitetsprodukt end bare testning. Og testerne bliver ikke mere involverede i processen for at t\u00e6nke p\u00e5 det overordnede m\u00e5l for produktet og dets forretningskomponent.<\/p>\n

Jeg leder en stor afdeling, har mange interviews, som faktisk giver et overblik over tilstanden i branchen som helhed. Som regel arbejder vores folk i enterprise, og de har et klart ansvarsomr\u00e5de. Kollegaer, der arbejder p\u00e5 udenlandske projekter, bruger forskellige former for testning: de kan selv udf\u00f8re belastningstest, pr\u00e6stationstest og endda nogle gange sikkerhedstest, fordi de virkelig hj\u00e6lper teamet med at sikre kvaliteten af produktet.<\/p>\n

Jeg \u00f8nsker, at vores folk i Rusland ogs\u00e5 begynder at overveje, at branchen ikke slutter med funktionel testning.<\/p>\n

\u2014 For this reason, we are organizing a new conference called QualityConf, which is dedicated to quality as an integral discipline. Can you tell us more about the concept and the main goal of the conference?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: We want to create a community of individuals interested in producing quality products. To provide a platform where they can come, listen to lectures, and leave the conference with a concrete understanding of what they need to change in order to improve quality.<\/p>\n

I often hear requests from consulting about what to do when there are issues with testing and quality. When you start communicating with the teams, you realize that the problem is not with the testers themselves, but with how the process is structured. For example, when developers believe that they are only responsible for writing code, their responsibility ends exactly the moment they hand over the task to testing.<\/p>\n

Not everyone considers that poorly written, low-quality code with bad architecture poses significant risks for the project. They don\u2019t think about the costs of mistakes, about how bugs that make it to production can lead to substantial expenses for the company and team. There is no culture of thinking about this. I want us to start spreading it at the conference.<\/p>\n

I understand that this is not an innovation. Edward Deming, the author of the 14 quality principles, wrote about the cost of mistakes back in the last century. Quality Assurance as a discipline is based on this book, but unfortunately, modern development tends to forget about it.<\/p>\n

\u2014 Will you directly address topics related to testing and tools?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: I assume there will be talks about tools. There are quite universal tools that companies and teams can use to influence the product.<\/p>\n

All presentations will be globally united by one common mission: to convey to the audience that with the help of this approach, tool, method, process, or type of testing, we impacted the quality of the product and improved the client\u2019s experience.<\/p><\/blockquote>\n

\nWe will definitely not have presentations about tools just for the sake of it. All presentations that will be included in the program will be united by a common goal.<\/p>\n

\u2014 Who do you think will be interested in what you are talking about? Who do you see as guests at the conference?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Vi vil have pr\u00e6sentationer for udviklere, der er bekymrede for deres projekts, produkts eller systems sk\u00e6bne. Det vil ogs\u00e5 v\u00e6re interessant for testere og, som jeg ser det, is\u00e6r for ledere. Med ledere mener jeg personer, der tr\u00e6ffer beslutninger og kan p\u00e5virke udviklingen af produktet, systemet og teamet.<\/p>\n

Det er mennesker, der stiller sp\u00f8rgsm\u00e5let - hvordan kan man forbedre kvaliteten af produktet eller systemet. P\u00e5 vores konference vil de l\u00e6re om forskellige s\u00e6t af foranstaltninger og kunne forst\u00e5, hvad der ikke fungerer for dem i \u00f8jeblikket, og hvad der skal \u00e6ndres.<\/p>\n

Jeg mener, at hovedkriteriet er at forst\u00e5, at der er noget galt med kvaliteten og at \u00f8nske at p\u00e5virke det. Det bliver nok ikke muligt at n\u00e5 igennem til folk, der mener, at alt er i orden, ved f\u00f8rste fors\u00f8g.<\/p>\n

\u2014 Hvad mener du, er branchen generelt klar til at tale ikke bare om testning, men om kvalitetens kultur?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Jeg mener, at det er den. Mange virksomheder g\u00e5r nu v\u00e6k fra den traditionelle Waterfall-tilgang mod Agile. Der er en orientering mod kunden, og folk i teamene begynder virkelig at t\u00e6nke over, hvordan man skaber et kvalitetsprodukt. Selv i enterprise-virksomheder sker der en omorientering mod at forbedre kvaliteten.<\/p>\n

Hvis vi ser p\u00e5 antallet af foresp\u00f8rgsler, der opst\u00e5r i samfundet, mener jeg, at det er tid. Jeg er dog ikke sikker p\u00e5, at det vil v\u00e6re en massiv revolution, men jeg ville \u00f8nske, at denne \u00e6ndring i bevidsthed finder sted.<\/p>\n

\u2014 Aftale! Vi vil fremme kulturen og \u00e6ndre bevidstheden.<\/em><\/strong><\/p>\n

Konferencen om kvalitetsudvikling af IT-produkter QualityConf<\/a><\/noindex> i efter\u00e5ret i \u00e5r. Specifikt drejer det sig om version 69, som vil v\u00e6re tilg\u00e6ngelig i september. I ESR-versioner af Firefox vil Flash-underst\u00f8ttelsen blive opretholdt indtil slutningen af 2020. I de almindelige versioner kan man dog tvinge aktivering af Flash via about:config. i Moskva den 7. juni<\/strong>. Ved du, hvilke faser der udg\u00f8r et kvalitetsprodukt, vi har tilf\u00e6lde af succesfuld bek\u00e6mpelse af fejl i produktionen, og vi har ogs\u00e5 afpr\u00f8vet popul\u00e6re metoder i vores praksis - vi har brug for din erfaring. Send<\/a><\/noindex> dine ans\u00f8gninger inden 1. maj<\/strong>, og det videnskabelige udvalg vil hj\u00e6lpe med at fokusere emnet for konferencens samlede sammenh\u00e6ng.<\/p>\n

Deltag i chatten<\/a><\/noindex>, hvor vi diskuterer kvalitetsproblemer og konferencen, og tilmeld dig \"Zefira\" er blevet forladt. Skaberens identitet af \"Zefira\" er ikke lykkedes at finde.<\/a><\/noindex>, s\u00e5 du kan holde dig opdateret om programmets nyheder.<\/p><\/blockquote>\n

Kilde: 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\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\udd47Hvem vil tage ansvar for kvaliteten? | ProHoster","description":"Hej, Habr! Vi har et nyt vigtigt emne - kvalitetsudvikling af IT-produkter.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/31264","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=31264"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/31264\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/23230"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=31264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=31264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=31264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}