{"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\/nl\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","title":{"rendered":"Wie is verantwoordelijk voor de kwaliteit?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, Habr!<\/p>\n

Wij hebben een nieuw belangrijk onderwerp - de kwalitatieve ontwikkeling van IT-producten. We spreken vaak op HighLoad++ over hoe je drukbezette services snel maakt, en op Frontend Conf over een geweldig gebruikersinterface dat niet hapert. We hebben regelmatig onderwerpen over testen, en DevOpsConf over het combineren van verschillende processen, inclusief testen. Maar over wat we als kwaliteit in zijn geheel kunnen beschouwen, en hoe we daar op een samenhangende manier mee om kunnen gaan - daar hebben we het niet over.<\/p>\n

Laten we dit aanpassen naar QualityConf<\/a><\/noindex>\u00a0we zullen de cultuur ontwikkelen om over de kwaliteit van het eindproduct voor de gebruiker na te denken in elke ontwikkelingsfase. De gewoonte om niet vast te blijven zitten in je eigen verantwoordelijkheidsgebied, en om kwaliteit niet alleen te associ\u00ebren met testers.<\/p>\n

Onder de kat zullen we praten met het hoofd van het programmacomit\u00e9, de directeur van testen bij Tinkoff.Business, de oprichter van de Russische QA-gemeenschap Anastasia Aseeva-Nguyen<\/b> over de staat van de QA-industrie en de missie van de nieuwe conferentie.<\/p>\n

\"Wie
\n<\/a><\/noindex>
\n- Nastya, hallo. Vertel alsjeblieft iets over jezelf.<\/em><\/strong><\/p>\n

\"WieAnastasia<\/strong>: Ik leid de testen bij de bank, ik ben verantwoordelijk voor een heel groot team - we zijn met meer dan 90 mensen. We hebben een belangrijke bedrijfslijn, we zijn verantwoordelijk voor het ecosysteem voor rechtspersonen.<\/p>\n

Ik heb gestudeerd op de mechanische en wiskundige faculteit en wilde oorspronkelijk programmeur worden. Maar toen ik een interessant aanbod kreeg, besloot ik het als tester te proberen. Vreemd genoeg bleek dit mijn roeping te zijn. Nu zie ik al mijn werk precies in deze sector.<\/p>\n

Ik ben een fervent voorstander van de discipline Quality Assurance. Ik geef om welke producten worden gecre\u00eberd, hoe er in het bedrijf, het team en in het algemeen in het ontwikkelingsproces met kwaliteit wordt omgegaan.<\/p><\/blockquote>\n

\nVoor mij is het duidelijk dat de gemeenschap op dit vlak niet genoeg volwassen is<\/strong>, althans in Rusland. We begrijpen niet altijd dat kwaliteitsborging niet alleen het feit omvat van het testen van de applicatie op overeenstemming met de vereisten. Ik zou deze situatie graag willen veranderen.<\/p>\n

- Je gebruikt de woorden Quality Assurance en testen. Voor het grote publiek komen deze twee termen vaak overeen. Wat is het verschil als je dieper graaft?<\/em><\/strong><\/p>\n

Anastasia:<\/strong> Ze verschillen eigenlijk weinig. Testen is een onderdeel van de discipline Quality Assurance, en het is een directe activiteit - het feit dat ik iets aan het testen ben. Er zijn eigenlijk heel veel soorten testen, en verschillende typen testen worden door verschillende mensen uitgevoerd. Maar in Rusland, toen de golf van outsourcers opkwam die testers naar bedrijven leverden, werd testen gereduceerd tot \u00e9\u00e9n enkel type.<\/p>\n

In de meeste gevallen beperken ze zich tot functioneel testen: ze controleren of hetgeen de ontwikkelaars hebben gecodeerd overeenkomt met de specificaties en that's it.<\/p>\n

Vertel me alsjeblieft, welke andere disciplines van kwaliteitsborging zijn er nog? Wat valt er behalve testen nog meer onder?<\/em><\/strong><\/p>\n

Anastasia<\/strong>Quality Assurance gaat in de eerste plaats over het cre\u00ebren van een kwaliteitsproduct. Dat betekent dat we ons de vraag stellen, met welke kwaliteitsattributen ons product moet beschikken. Als we dit begrijpen, kunnen we in kaart brengen wie invloed heeft op deze kwaliteitsattributen. Het maakt niet uit, of het nu de ontwikkelaar, projectmanager of productmanager is.<\/strong>\u00a0Dat is iemand die invloed heeft op de ontwikkeling van het product, op de backlog ervan, op de strategie.<\/p>\n

De tester begint zijn rol beter te beseffen. Hij begrijpt dat zijn taak niet alleen is om te testen op overeenstemming met de eisen, maar ook om de vereisten te testen, de formuleringen die van de productmanager komen in twijfel te trekken, en alle impliciete vereisten en verwachtingen van de klant aan het licht te brengen. Wanneer we nieuwe functionaliteit aan onze klant leveren, moeten we zijn verwachtingen echt vervullen en zijn pijnpunten oplossen. Als we over alle kwaliteitsattributen nadenken, zal de klant tevreden zijn en begrijpen dat het bedrijf wiens product hij gebruikt, echt om zijn belangen geeft en niet werkt volgens het principe 'gewoon een feature uitbrengen'.<\/p>\n

Het lijkt erop dat wat je nu beschrijft, de taak van de productmanager is. Dat gaat eigenlijk niet over testen en niet over kwaliteit - dat gaat allesbehalve over productmanagement, toch?<\/em><\/strong><\/p>\n

Anastasia<\/strong>In dat opzicht. Quality Assurance is geen discipline waarvoor \u00e9\u00e9n specifieke persoon verantwoordelijk is. Er is momenteel een populaire richting in testen, een aanpak die Agile Testing heet. Agile Testing<\/strong>In its definition, it explicitly states that this is a team approach to testing, which involves a certain set of practices. The entire team is responsible for implementing this approach, and it's not even necessary for there to be a tester in the team. The whole team is focused on delivering value to the client, and ensuring that this value meets their expectations.<\/p>\n

So, does it turn out that quality intersects with almost every surrounding discipline, imposing constraints on everything around?<\/em><\/strong><\/p>\n

Anastasia<\/strong>That's right. When we consider what we want to create a quality product, we start thinking about various attributes of quality. For example, how to verify that we've actually implemented a feature that our client needs.<\/p>\n

This brings to mind a type of testing known as UAT<\/strong> (user acceptance testing). Unfortunately, it is rarely practiced in Russia, but sometimes it is present in SCRUM teams as a demo for the end client. In foreign companies, this type of testing is quite common. Before opening functionality to all clients, we first conduct UAT, which means inviting the end user to test and provide immediate feedback on whether the product meets expectations and solves the pain points. Only after that does scaling occur for all other clients.<\/p>\n

So, we focus on business and the end client, but at the same time we do not forget about technology.<\/strong>The quality of the product also greatly depends on technology. If we have poor architecture, we will not be able to quickly release features and meet client expectations. There may be many bugs when trying to scale, or we might break something during refactoring. All of this will affect client satisfaction.<\/p>\n

From this perspective, the architecture should be such that we can write clean code that allows for quick modifications without fearing that we will break everything. So that iterations of improvement do not stretch over several months just because we have so much legacy and long testing phases are needed.<\/p>\n

So far, developers, architects, product specialists, product managers, and testers are already involved. Who else is involved in the quality assurance process?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Laten we ons nu voorstellen dat we de functionaliteit al aan de klant hebben geleverd. Het is duidelijk dat we de productkwaliteit moeten bewaken, zelfs wanneer het al in productie is. In deze fase kunnen zich situaties voordoen met onduidelijke scenario's, die zogenaamde bugs.<\/p>\n

De eerste vraag is: hoe gaan we met deze bugs om nadat we het product al hebben vrijgegeven? Hoe reageren we bijvoorbeeld op de belasting? Een klant zal niet erg tevreden zijn als de pagina meer dan 30 seconden laadt.<\/p>\n

Hier komt operaties in beeld of, zoals het tegenwoordig wordt genoemd, DevOps<\/strong>. In feite zijn dit de mensen die verantwoordelijk zijn voor de operatie van het product wanneer het al in productie is. Dit omvat verschillende soorten monitoring. Er is zelfs een sub-soort van testen - testen in productie, waarbij we ons permitteren iets niet te testen voordat het wordt uitgerold en het meteen in productie testen. Dit is een reeks maatregelen vanuit het perspectief van infrastructuurorganisatie die ons in staat stelt snel te reageren op incidenten, invloed uit te oefenen en ze te corrigeren.<\/p>\n

Infrastructuur is ook belangrijk. Vaak zijn er situaties waarin we tijdens de test niet zeker kunnen zijn dat we echt alles hebben wat we de klant zouden willen bieden. We rollen het uit naar productie en beginnen onduidelijke situaties te ontdekken. En dat komt omdat de infrastructuur in de test niet overeenkomt met de infrastructuur in productie. Hieruit voortvloeit een nieuw soort testen - infrastructuurtesten<\/strong>. Dit omvat verschillende configuraties, instellingen, migratie van databases, enzovoort.<\/p>\n

Hier rijst de vraag - misschien moet het team infrastructuur als code gebruiken.<\/p>\n

Ik geloof dat de infrastructuur directe invloed heeft op de kwaliteit van het product.<\/p><\/blockquote>\n

\nIk hoop dat er op de conferentie een presentatie zal zijn met een echt geval. Laat het ons weten als je bereid bent je ervaringen te delen over hoe infrastructuur als code de kwaliteit be\u00efnvloedt. Infrastructuur als code maakt het eenvoudiger om alle instellingen te controleren en te testen wat anders gewoon onmogelijk zou zijn. Daarom wordt ook operaties betrokken bij het proces van het ontwikkelen van een kwaliteitsproduct.<\/p>\n

\u2014 En wat betreft analytics en documentatie?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Dit heeft meer te maken met enterprise-systemen. Wanneer we over enterprise praten, komen onmiddellijk mensen zoals analisten en systeemanalisten in gedachten. Soms worden ze technische schrijvers genoemd. Ze krijgen de opdracht om een specificatie te schrijven en voeren deze bijvoorbeeld gedurende een maand uit.<\/p>\n

Het is herhaaldelijk bewezen dat het schrijven van dergelijke documentatie leidt tot zeer lange ontwikkelingscycli en langdurige iteraties van aanpassingen, omdat tijdens het testen fouten aan het licht komen, wat leidt tot terugvallen. Hierdoor ontstaan er veel lusjes die de kosten van ontwikkeling verhogen. Bovendien kan dit kwetsbaarheden introduceren. We hebben blijkbaar een referentiecode geschreven, maar daarna hebben we wijzigingen aangebracht die de perfect doordachte architectuur verstoren.<\/p>\n

Uiteindelijk resulteert dit in een product van niet al te hoge kwaliteit, omdat de architectuur al patchwork vertoont, de code op sommige plaatsen niet voldoende is getest, omdat de deadlines dichterbij komen; er moet sneller worden ingespeeld op alle fouten. Dit alles doordat niet alle punten in de oorspronkelijke specificatie zijn meegenomen die gerealiseerd moesten worden.<\/p>\n

Ontwikkelaars zijn geen kwaadwillenden en schrijven niet opzettelijk code met fouten.<\/p><\/blockquote>\n

\nAls we aanvankelijk de specificatie zorgvuldig hadden overwogen, waarin alle noodzakelijke punten waren belicht, dan zou alles precies zo zijn gerealiseerd als nodig was. Maar dit is een utopie.<\/p>\n

Het is waarschijnlijk onmogelijk om een ideale specificatie van 100 pagina's te schrijven. Daarom moeten we nadenken over alternatieve manieren om documentatie te schrijven<\/strong>, specificeren, en taken te formuleren die ons dichter bij het doel brengen dat de ontwikkelaar precies doet wat nodig is.<\/p>\n

Hier komt een benadering uit Agile in gedachten \u2014 gebruikersverhalen met acceptatiecriteria. Dit is meer van toepassing op teams die zich in kleine iteraties ontwikkelen.<\/p>\n

\u2014 Wat betreft gebruiksvelijkheidstests, het gebruiksgemak van het product, design?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Dit is een heel belangrijk punt, omdat er ontwerpers in het team zijn. Vaak worden ontwerpers gebruikt als een dienst \u2014 ofwel een ontwerpersteam, ofwel een freelancer. Vaak komen we situaties tegen waarin het lijkt alsof de ontwerper gedaan heeft wat de productmanager begreep. Maar wanneer we beginnen met de iteratie, blijkt dat het in feite niet is wat we verwachtten: de ontwerper is iets vergeten, heeft het gedrag niet volledig doordacht omdat hij niet in het team zit en niet in de context of de front-endontwikkelaar heeft zijn ontwerp niet goed begrepen. Meerdere iteraties kunnen nodig zijn, alleen maar omdat er een probleem is met het begrip van het ontwerp door de front-end ontwikkelaar.<\/p>\n

Bovendien is er nog een probleem. Momenteel krijgen ontwerpsystemen veel aandacht. Ze zijn populair, maar het voordeel ervan is niet helemaal duidelijk.<\/p>\n

Ik kom het idee tegen dat ontwerpsystemen aan de ene kant de ontwikkeling vereenvoudigen, maar aan de andere kant veel beperkingen opleggen aan de interface.<\/p><\/blockquote>\n

\nUiteindelijk maken we niet de functie die de klant wil, maar een versie die ons uitkomt, omdat we al bepaalde componenten hebben waaruit we deze kunnen maken.<\/p>\n

Ik denk dat het belangrijk is om hier aandacht aan te besteden en ons af te vragen of we in onze poging om het ontwerp gemakkelijker te maken, daadwerkelijk de pijn van de klant oplossen.<\/p>\n

\u2014 Het blijkt dat er verrassend veel onderwerpen zijn met betrekking tot Quality Assurance. Is er in Rusland een conferentie waar al deze onderwerpen kunnen worden besproken?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Er is de oudste conferentie over testen, die dit jaar voor de 25e keer plaatsvindt en gewoon de Quality Assurance Conference SQA Days heet. Meestal worden daar tools en specifieke testbenaderingen voor functionele testers besproken. Gewoonlijk worden bij SQA Days specifieke gebieden binnen de verantwoordelijkheidszone van de testers diepgaand behandeld, maar geen complexe evenementen.<\/p>\n

Dit helpt enorm bij het begrijpen van verschillende tools en methoden, zoals hoe je databases, API's, enz. test. Maar enerzijds motiveert dit niet om meer betrokken te raken bij het cre\u00ebren van een kwalitatief beter product, buiten alleen de testen. Aan de andere kant worden testers niet meer betrokken bij het proces om na te denken over het globale doel van het product en de zakelijke component ervan.<\/p>\n

Ik leid een grote afdeling en voer veel sollicitatiegesprekken die in feite de staat van de sector in zijn geheel reflecteren. Gewoonlijk werken onze jongens in enterprise en hebben ze een duidelijke verantwoordelijkheidszone. Collega's die aan buitenlandse projecten werken, gebruiken verschillende soorten testen: ze kunnen zelf load testing, performance testing en soms zelfs security testing uitvoeren, omdat ze de teams echt helpen om kwaliteitsvolle producten te leveren.<\/p>\n

Ik zou willen dat onze jongens in Rusland ook zouden beginnen na te denken over het feit dat de sector niet eindigt bij functioneel testen.<\/p>\n

\u2014 Daarom organiseren we de nieuwe conferentie QualityConf, die gewijd is aan kwaliteit als een geheel discipline. Kun je meer vertellen over het concept, wat is het belangrijkste doel van de conferentie?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: We willen een gemeenschap cre\u00ebren van mensen die ge\u00efnteresseerd zijn in het maken van kwaliteitsproducten. Een platform bieden waar ze kunnen komen, presentaties kunnen luisteren en na de conferentie met een concreet begrip weggaan van wat ze moeten veranderen om de kwaliteit te verbeteren.<\/p>\n

Ik hoor momenteel vaak aanvragen vanuit consulting over wat te doen wanneer er problemen zijn met testen en kwaliteit. Wanneer je begint te communiceren met teams, zie je dat het probleem niet bij de testers zelf ligt, maar bij hoe het proces is opgebouwd. Bijvoorbeeld, wanneer ontwikkelaars denken dat ze alleen verantwoordelijk zijn voor het schrijven van code, eindigt hun verantwoordelijkheid op het moment dat ze de taak voor testen overdragen.<\/p>\n

Niet iedereen denkt aan het feit dat slecht geschreven, kwalitatief slechte code met een slechte architectuur grote problemen voor een project kan betekenen. Ze denken niet aan de kosten van fouten, aan het feit dat bugs die in productie komen, kunnen leiden tot hoge kosten voor het bedrijf en het team. Er is geen cultuur om hierover na te denken. Ik wil dat we op de conferentie beginnen deze cultuur te verspreiden.<\/p>\n

Ik begrijp dat dit geen innovatie is. Edward Deming, de auteur van de 14 kwaliteitsprincipes, schreef al in de vorige eeuw over de kosten van fouten. Deze boek vormt de basis van Quality Assurance als discipline, maar helaas vergeet de moderne ontwikkeling dit.<\/p>\n

\u2014 Overweeg je om thema's die specifiek gericht zijn op testen en tools aan te snijden?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Ik zie mogelijkheden dat er presentaties over tools zullen zijn. Er zijn voldoende universele tools waarmee bedrijven en teams invloed kunnen uitoefenen op het product.<\/p>\n

Alle presentaties zullen globaal worden verenigd door \u00e9\u00e9n gemeenschappelijke missie: het publiek duidelijk maken dat we met deze aanpak, tool, methode, proces, type testen de kwaliteit van het product hebben be\u00efnvloed en het leven van de klant hebben verbeterd.<\/p><\/blockquote>\n

\nWe zullen zeker geen presentaties hebben over tools alleen omwille van de tools. Alle presentaties die in het programma komen, zullen een gemeenschappelijk doel hebben.<\/p>\n

\u2014 Voor wie zal het interessant zijn waarover je spreekt, wie zie je als gasten van de conferentie?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: We will have presentations for developers who care about the fate of their project, product, and system. Similarly, this will be interesting for testers and, as I believe, especially for managers. By managers, I mean those who make decisions and can influence the fate and development of the product, system, or team.<\/p>\n

These are people who ask the question - how to improve the quality of the product and system. At our conference, they will learn about various sets of measures and be able to understand what is currently lacking and what needs to change.<\/p>\n

I think the main criterion is to understand that something is wrong with quality and to want to influence it. Probably, we will not reach those who think that everything is fine on the first attempt.<\/p>\n

\u2014 What do you think, has the industry matured to talk not just about testing but about quality culture?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: I believe it has. Many companies are moving away from the traditional Waterfall approach towards Agile. There is a focus on the client, and people in teams are really beginning to think about how to create a quality product. Even in enterprise companies, there is a shift towards enhancing quality.<\/p>\n

Judging by the number of requests arising in the community, I believe it's time. I'm not sure, of course, that this will be a massive revolution, but I would like this shift in mindset to occur.<\/p>\n

\u2014 Agreed! We will cultivate culture and change mindsets.<\/em><\/strong><\/p>\n

Conference on quality IT product development QualityConf<\/a><\/noindex> plaatsvinden in Moscow on June 7<\/strong>. You know, what stages contribute to a quality product, we have successful cases of battling bugs in production, and we've checked popular methods in practice \u2014 we need your experience. Send us<\/a><\/noindex> your applications by May 1<\/strong>, and the Program Committee will help focus the topic for the overall coherence of the conference.<\/p>\n

Join the chat<\/a><\/noindex>, where we discuss quality issues and the conference, subscribe to Telegram-kanaal<\/a><\/noindex>, to stay updated on program news.<\/p><\/blockquote>\n

Bron: 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\udd47 Who is responsible for quality? | ProHoster","description":"Hello, Habr! We have a new important topic \u2014 quality IT product development.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/31264","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=31264"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/31264\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/23230"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=31264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=31264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=31264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}