{"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\/it\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","title":{"rendered":"Chi risponder\u00e0 della qualit\u00e0?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, Habr!<\/p>\n

Abbiamo un nuovo argomento importante: lo sviluppo di prodotti IT di qualit\u00e0. Parliamo spesso su HighLoad++ di come rendere i servizi sovraccarichi rapidi, e su Frontend Conf di come avere un'interfaccia utente fantastica che non rallenti. Abbiamo regolarmente argomenti sul testing, e DevOpsConf sull'unione di diversi processi, incluso il testing. Ma riguardo a ci\u00f2 che potremmo definire qualit\u00e0 nel complesso, e come lavorarci in modo integrato, non ne parliamo mai.<\/p>\n

Correggiamo questo in QualityConf<\/a><\/noindex>\u00a0\u2014 svilupperemo una cultura che considera la qualit\u00e0 del prodotto finale per l'utente in ogni fase dello sviluppo. L'abitudine a non limitarsi alla propria zona di responsabilit\u00e0 e a associare la qualit\u00e0 non solo ai tester.<\/p>\n

Dopo il salto parleremo con la presidente del comitato programmatico, responsabile del testing in Tinkoff.Business, creatrice della community QA di lingua russa Anastasia Aseeva-Nguyen<\/b> sullo stato dell'industria QA e sulla missione della nuova conferenza.<\/p>\n

\"Chi
\n<\/a><\/noindex>
\n\u2014 Ciao, Nastya. Raccontaci un po' di te.<\/em><\/strong><\/p>\n

\"ChiAnastasia<\/strong>: Guida il testing in banca, responsabile di un team molto grande: siamo pi\u00f9 di 90 persone. Abbiamo una linea di business importante, ci occupiamo dell'ecosistema per le persone giuridiche.<\/p>\n

Ho studiato matematica e fisica e inizialmente volevo diventare programmista. Ma quando ho ricevuto un'offerta interessante, ho deciso di provare a farmi strada come tester. Stranamente, mi sono ritrovata in questo ruolo. Ora vedo tutto il mio lavoro proprio in questo settore.<\/p>\n

Sono un'appassionata sostenitrice della disciplina Quality Assurance. Mi importa quali prodotti vengono creati, come si affronta la qualit\u00e0 in azienda, nel team e, in generale, nel processo di sviluppo.<\/p><\/blockquote>\n

\nPer me \u00e8 evidente che la comunit\u00e0 in questa direzione non \u00e8 abbastanza matura<\/strong>, almeno in Russia. Non sempre comprendiamo che garantire la qualit\u00e0 non significa solo testare l'applicazione per verificarne la conformit\u00e0 ai requisiti. Vorrei cambiare questa situazione.<\/p>\n

\u2014 Usando i termini Quality Assurance e testing. Nella mente del pubblico, questi due termini spesso si sovrappongono. Qual \u00e8 la loro differenza, se ci si approfondisce?<\/em><\/strong><\/p>\n

Anastasia:<\/strong> In realt\u00e0, non si distinguono. Il testing \u00e8 parte della disciplina del Quality Assurance, \u00e8 un'attivit\u00e0 diretta: il fatto stesso che io stia testando qualcosa. Ci sono in realt\u00e0 molti tipi di testing, e diversi tipi di testing sono gestiti da persone molto diverse. Ma in Russia, quando \u00e8 emersa la moda dei fornitori di servizi, che forniscono tester alle aziende, il testing si \u00e8 ridotto a un'unica tipologia.<\/p>\n

Nella maggior parte dei casi ci si limita solo al testing funzionale: si verifica che ci\u00f2 che i programmatori hanno codificato corrisponda alle specifiche, e basta.<\/p>\n

\u2014 Puoi raccontarmi, per favore, quali altri sono i settori della qualit\u00e0? Cosa altro, oltre al testing, \u00e8 coinvolto?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Il Quality Assurance riguarda, innanzitutto, la creazione di un prodotto di qualit\u00e0. In altre parole, ci poniamo la domanda su quali attributi di qualit\u00e0 debba possedere il nostro prodotto. Di conseguenza, se lo comprendiamo, possiamo confrontare chi influisce su questi attributi di qualit\u00e0. Non importa, sviluppatore, project manager o product owner<\/strong>\u00a0\u2014 \u00e8 una persona che influisce sullo sviluppo del prodotto, sul suo backlog, sulla sua strategia.<\/p>\n

Il tester inizia a comprendere meglio il proprio ruolo. Capisce che il suo compito non \u00e8 solo testare in base ai requisiti, ma anche testare i requisiti stessi, mettere in discussione le formulazioni provenienti dal product owner, rivelare tutti i requisiti impliciti e le aspettative del cliente. Quando forniamo una nuova funzionalit\u00e0 al nostro cliente, dobbiamo realmente soddisfare le sue aspettative e risolvere i suoi problemi. Se consideriamo tutti gli attributi di qualit\u00e0, il cliente sar\u00e0 soddisfatto e comprender\u00e0 che l'azienda il cui prodotto sta utilizzando si prende davvero cura dei suoi interessi, e non sta semplicemente seguendo il principio di \"far uscire una funzionalit\u00e0 a tutti i costi\".<\/p>\n

\u2014 Sembra che ci\u00f2 che hai descritto sia il compito del product owner. In sostanza, non riguarda il testing e non riguarda la qualit\u00e0, riguarda davvero il product management, giusto?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: In parte. Il Quality Assurance non \u00e8 una disciplina di cui si occupa una singola persona. Ora c'\u00e8 un approccio popolare nel testing, che si chiama Agile Testing<\/strong>. Nella sua definizione si afferma chiaramente che si tratta di un approccio di squadra ai test, che include un insieme specifico di pratiche. La responsabilit\u00e0 dell\u2019implementazione di questo approccio ricade su tutta la squadra, non \u00e8 necessario che ci sia un tester nel team. Tutta la squadra \u00e8 focalizzata sul fornire valore al cliente e assicurarsi che questo valore soddisfi le sue aspettative.<\/p>\n

\u2014 Risulta quindi che la qualit\u00e0 si interseca quasi con tutte le discipline circostanti, imponendo dei limiti a tutto ci\u00f2 che ci circonda?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Esatto. Quando ci pensiamo, vogliamo creare un prodotto di qualit\u00e0, iniziamo a riflettere su diversi attributi della qualit\u00e0. Ad esempio, come verificare che abbiamo realmente sviluppato una funzionalit\u00e0 che sia necessaria per il nostro cliente.<\/p>\n

Qui emerge un tipo di test, come UAT<\/strong> (user acceptance testing). Sfortunatamente, in Russia \u00e8 raramente praticato, ma a volte \u00e8 presente nei team SCRUM, come demo per il cliente finale. Nelle aziende estere \u00e8 un tipo di test piuttosto comune. Prima di aprire la funzionalit\u00e0 a tutti i clienti, prima facciamo l'UAT, cio\u00e8 invitiamo il consumatore finale, che effettua i test e fornisce immediatamente un feedback \u2014 se il prodotto corrisponde alle aspettative e risolve i problemi. Solo dopo avviene la scalabilit\u00e0 per tutti gli altri clienti.<\/p>\n

Quindi ci orientiamo verso il business, verso il cliente finale, ma nel frattempo non dimentichiamo la tecnologia<\/strong>. Anche la tecnologia influisce notevolmente sulla qualit\u00e0 del prodotto. Se abbiamo una cattiva architettura, non saremo in grado di rilasciare rapidamente funzionalit\u00e0 e soddisfare le aspettative del cliente. Possono sorgere molti bug durante il tentativo di scalare, o durante un tentativo di refactoring possiamo rompere qualcosa. Tutto questo influenzer\u00e0 la soddisfazione del cliente.<\/p>\n

Da questo punto di vista, l'architettura deve essere tale da permetterci di scrivere codice pulito, in grado di apportare rapidamente modifiche e senza paura di rompere tutto. Affinch\u00e9 le iterazioni di sviluppo non si protraggano per mesi semplicemente perch\u00e9 abbiamo cos\u00ec tanto legacy e sono necessari lunghi periodi di test.<\/p>\n

\u2014 In sintesi, sono gi\u00e0 coinvolti sviluppatori, architetti, product manager, product owner, e stessi tester. Chi altro \u00e8 coinvolto nel processo di assicurazione della qualit\u00e0?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Ora immaginiamo che abbiamo gi\u00e0 consegnato la funzionalit\u00e0 al cliente. \u00c8 ovvio che dobbiamo tenere sotto controllo la qualit\u00e0 del prodotto, anche quando \u00e8 in produzione. A questo punto possono manifestarsi situazioni con scenari non evidenti, i cosiddetti bug.<\/p>\n

La prima domanda \u00e8: come gestiamo questi bug dopo che abbiamo rilasciato il prodotto? Come rispondiamo, ad esempio, al carico? Il cliente non sar\u00e0 molto soddisfatto se la pagina ci mette pi\u00f9 di 30 secondi a caricarsi.<\/p>\n

Qui entra in gioco l'operativit\u00e0 o, come la si chiama adesso, DevOps<\/strong>. In effetti, queste sono le persone responsabili dell'operativit\u00e0 del prodotto quando \u00e8 gi\u00e0 in produzione. Ci\u00f2 include vari tipi di monitoraggio. Esiste persino un sottotipo di testing, il testing in produzione, quando ci permettiamo di non testare nulla prima del rilascio e testiamo direttamente in produzione. Queste sono una serie di misure dal punto di vista dell'organizzazione dell'infrastruttura, che consentono di reagire rapidamente a un incidente, influenzarlo e correggerlo.<\/p>\n

Anche l'infrastruttura \u00e8 importante. Ci sono spesso situazioni in cui durante il test non possiamo essere certi che abbiamo davvero tutto ci\u00f2 che vorremmo dare al cliente. Rilasciamo in produzione e iniziamo a catturare situazioni non evidenti. E tutto ci\u00f2 accade perch\u00e9 l'infrastruttura nel test non corrisponde a quella in produzione. Da qui emerge un nuovo tipo di testing \u2014 il testing dell'infrastruttura<\/strong>. Include diverse configurazioni, impostazioni, migrazioni di database, ecc.<\/p>\n

Da qui sorge la domanda: forse il team ha bisogno di utilizzare l'infrastruttura come codice.<\/p>\n

Credo che l'infrastruttura influisca direttamente sulla qualit\u00e0 del prodotto.<\/p><\/blockquote>\n

\nSpero che alla conferenza ci sar\u00e0 una presentazione con un caso reale. Scriveteci se siete pronti a raccontare dalla vostra esperienza come l'infrastruttura come codice influisce sulla qualit\u00e0. L'infrastruttura come codice consente di controllare pi\u00f9 facilmente tutte le impostazioni e testare ci\u00f2 che altrimenti sarebbe semplicemente impossibile. Pertanto, nel processo di sviluppo di un prodotto di qualit\u00e0 \u00e8 coinvolta anche l'operativit\u00e0.<\/p>\n

\u2014 E per quanto riguarda l'analisi e la documentazione?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Questo \u00e8 pi\u00f9 pertinente ai sistemi enterprise. Quando parliamo di enterprise, ci vengono subito in mente persone come analisti e analisti di sistemi. A volte sono chiamati scrittori tecnici. Ricevono l'incarico di scrivere una specifica e lo portano a termine, ad esempio, in un mese.<\/p>\n

\u00c8 stato dimostrato pi\u00f9 volte che la redazione di una tale documentazione porta a iterazioni di sviluppo molto lunghe e iterazioni estese di perfezionamento, poich\u00e9 durante il processo di test emergono bug e hanno inizio i ritorni. Di conseguenza, si generano molti cicli che aumentano il costo dello sviluppo. Inoltre, questo pu\u00f2 introdurre vulnerabilit\u00e0. Sembrerebbe che abbiamo scritto codice di riferimento, ma poi abbiamo apportato modifiche che rompono un'architettura perfettamente concepita.<\/p>\n

Ne risulta un prodotto di qualit\u00e0 non del tutto soddisfacente, poich\u00e9 nell'architettura sono gi\u00e0 apparse toppe, il codice in alcune parti non \u00e8 adeguatamente coperto da test, perch\u00e9 le scadenze sono pressanti e bisogna risolvere pi\u00f9 rapidamente tutti i bug. E tutto ci\u00f2 accade perch\u00e9 nella specifica iniziale non sono stati considerati tutti gli aspetti da realizzare.<\/p>\n

Gli sviluppatori non sono malintenzionati e non scrivono volontariamente codice con errori.<\/p><\/blockquote>\n

\nSe avessimo pensato inizialmente a una specifica che includesse tutti i punti necessari, tutto sarebbe stato implementato esattamente come doveva essere. Ma questa \u00e8 una utopia.<\/p>\n

Probabilmente, scrivere una specifica ideale di 100 pagine \u00e8 impossibile. Pertanto \u00e8 necessario riflettere su metodi alternativi di redazione della documentazione<\/strong>, specificazione e definizione di compiti che ci avvicinino a far s\u00ec che lo sviluppatore faccia precisamente ci\u00f2 che \u00e8 necessario.<\/p>\n

Qui vengono in mente approcci che derivano dall'Agile: user stories con criteri di accettazione. Questo \u00e8 maggiormente applicabile a team che crescono attraverso piccole iterazioni.<\/p>\n

\u2014 Cosa ne pensi del testing di usabilit\u00e0, della facilit\u00e0 d'uso del prodotto e del design?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Questo \u00e8 un aspetto molto importante, poich\u00e9 nella squadra ci sono designer. Spesso i designer sono considerati come un servizio: o un reparto design o un designer in outsourcing. Spesso si verificano situazioni in cui sembra che il designer abbia ascoltato il product manager e abbia fatto ci\u00f2 che ha capito. Ma quando iniziamo l'iterazione, si scopre che in realt\u00e0 non \u00e8 stato fatto quello che ci aspettavamo: il designer ha dimenticato qualcosa, non ha pianificato completamente il comportamento, perch\u00e9 non \u00e8 parte del team e non \u00e8 nel contesto, o lo sviluppatore frontend non ha capito a pieno il suo layout. Potrebbero essere necessarie diverse iterazioni solo a causa del fatto che c'\u00e8 un problema con la comprensione del design da parte dello sviluppatore frontend.<\/p>\n

In aggiunta, c'\u00e8 un altro problema. Al momento i sistemi di design stanno guadagnando popolarit\u00e0. Sono molto in voga, ma i benefici non sono del tutto evidenti.<\/p>\n

Mi confronto con l'opinione secondo cui i sistemi di design, da un lato, semplificano lo sviluppo, ma dall'altro impongono molte restrizioni all'interfaccia.<\/p><\/blockquote>\n

\nDi conseguenza, non realizziamo esattamente la funzionalit\u00e0 che il cliente desidera, ma quella comoda per noi, perch\u00e9 abbiamo gi\u00e0 dei componenti definiti da cui possiamo crearla.<\/p>\n

Credo che sia importante prestare attenzione a questo tema e riflettere se, nel tentativo di semplificare il lavoro sul design, stiamo realmente risolvendo i problemi dei clienti.<\/p>\n

\u2014 Si presenta sorprendentemente molti temi legati alla Quality Assurance. In Russia c'\u00e8 una conferenza dove si possono discutere tutti?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: C'\u00e8 la conferenza pi\u00f9 antica nel campo del testing, che quest'anno si terr\u00e0 per la 25\u00aa volta e si chiama proprio cos\u00ec \u2014 Conferenza sulla qualit\u00e0 SQA Days. Principalmente si discutono strumenti e approcci specifici per il testing per i tester funzionali. Di solito, nelle presentazioni degli SQA Days si esaminano approfonditamente aree specifiche nelle responsabilit\u00e0 dei tester stessi, ma non eventi complessivi.<\/p>\n

Questo aiuta molto a comprendere i vari strumenti e approcci su come testare i database, le API, ecc. Tuttavia, da un lato, non motiva a coinvolgere nella creazione di un prodotto di maggiore qualit\u00e0 non solo il testing. E dall'altro, i tester non diventano pi\u00f9 coinvolti nel processo per pensare all'obiettivo globale del prodotto e alla sua componente commerciale.<\/p>\n

Dirigo un grande reparto, svolgo molti colloqui che in realt\u00e0 consentono di rappresentare lo stato del settore nel suo complesso. Di solito, i nostri ragazzi lavorano in ambito enterprise, e hanno un'area di responsabilit\u00e0 chiara. I colleghi che lavorano a progetti internazionali utilizzano diversi tipi di testing: possono effettuare test di carico, test di prestazione e a volte anche test di sicurezza (security testing), perch\u00e9 contribuiscono realmente a garantire la qualit\u00e0 del prodotto.<\/p>\n

Mi piacerebbe che anche in Russia i ragazzi cominciassero a riflettere sul fatto che nel testing funzionale il settore non si esaurisce.<\/p>\n

\u2014 Per questo stiamo organizzando una nuova conferenza QualityConf, dedicata alla qualit\u00e0 come disciplina olistica. Raccontami di pi\u00f9 sull'idea, qual \u00e8 l'obiettivo principale della conferenza?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Vogliamo creare una comunit\u00e0 di persone interessate a realizzare prodotti di qualit\u00e0. Offrire uno spazio dove possano venire, ascoltare le relazioni e uscire dalla conferenza con una comprensione chiara di cosa devono cambiare in loro stessi per migliorare la qualit\u00e0.<\/p>\n

Spesso sento ora la richiesta da parte del consulting su cosa fare quando ci sono problemi con i test e con la qualit\u00e0. Quando inizi a parlare con i team, vedi che il problema non \u00e8 nei tester stessi, ma nel modo in cui \u00e8 strutturato il processo. Ad esempio, quando i programmatori pensano di essere responsabili solo per la scrittura del codice, la loro responsabilit\u00e0 finisce esattamente nel momento in cui consegnano il compito al testing.<\/p>\n

Non tutti riflettono sul fatto che un codice mal scritto e di scarsa qualit\u00e0 con una cattiva architettura pu\u00f2 portare a grandi problemi per il progetto. Non riflettono sul costo degli errori, sul fatto che i bug che arrivano in produzione possono generare grandi spese per l'azienda e per il team. Non c'\u00e8 una cultura di pensare a questo. Voglio che durante la conferenza iniziamo a diffonderla.<\/p>\n

Capisco che non si tratta di innovazione. Edward Deming, autore dei 14 principi di qualit\u00e0, scriveva del costo degli errori gi\u00e0 nel secolo scorso. Questa idea \u00e8 alla base del Quality Assurance come disciplina, ma, sfortunatamente, lo sviluppo moderno se ne dimentica.<\/p>\n

\u2014 Intendete toccare anche temi direttamente legati ai test e agli strumenti?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Ammetto che ci saranno relazioni sugli strumenti. Ci sono strumenti abbastanza universali grazie ai quali le aziende e i team possono influenzare il prodotto.<\/p>\n

Tutte le relazioni saranno globalmente unite da una comune missione: comunicare al pubblico che grazie a questo approccio, strumento, metodo, processo, tipo di test abbiamo influenzato la qualit\u00e0 del prodotto e migliorato la vita del cliente.<\/p><\/blockquote>\n

\nNon avremo sicuramente relazioni su strumenti per il gusto di avere strumenti. Tutte le relazioni che entreranno nel programma saranno unite da un obiettivo comune.<\/p>\n

\u2014 A chi sar\u00e0 interessante ci\u00f2 di cui parli, chi vedi come ospiti della conferenza?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Avremo relazioni per sviluppatori che si prendono cura del destino del loro progetto, prodotto o sistema. Sar\u00e0 interessante anche per i tester e, a mio avviso, soprattutto per i manager. Con manager intendo quelle persone che prendono decisioni e possono influenzare il destino e lo sviluppo del prodotto, del sistema e del team incluso.<\/p>\n

Queste sono persone che si chiedono come migliorare la qualit\u00e0 del prodotto e del sistema. Alla nostra conferenza, scopriranno vari complessi eventi e potranno capire cosa non va al momento e cosa deve essere cambiato.<\/p>\n

Penso che il criterio principale sia comprendere che c'\u00e8 qualcosa che non va con la qualit\u00e0 e voler influenzare questo. Probabilmente non riusciremo a farci ascoltare al primo tentativo da chi pensa che vada bene cos\u00ec.<\/p>\n

\u2014 Cosa ne pensi, l'industria \u00e8 pronta per parlare non solo di testing, ma anche di cultura della qualit\u00e0?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Penso di s\u00ec. Al momento molte aziende si stanno allontanando dall'approccio tradizionale Waterfall verso Agile. C'\u00e8 un'orientamento verso il cliente, e le persone nei team stanno realmente iniziando a riflettere su come creare un prodotto di qualit\u00e0. Anche nelle aziende enterprise si sta avviando una ri-orientazione al miglioramento della qualit\u00e0.<\/p>\n

A giudicare dal numero di richieste che emergono nella comunit\u00e0, credo sia arrivato il momento. Non sono sicura che sar\u00e0 una rivoluzione su larga scala, ma mi piacerebbe che questo cambiamento di mentalit\u00e0 avvenisse.<\/p>\n

\u2014 D'accordo! Lavoreremo per instillare la cultura e cambiare la mentalit\u00e0.<\/em><\/strong><\/p>\n

Conferenza sulla sviluppo qualitativo dei prodotti IT QualityConf<\/a><\/noindex> si svolger\u00e0 a Mosca il 7 giugno<\/strong>. Sapete quali fasi compongono un prodotto di qualit\u00e0, abbiamo casi di successo nella lotta contro i bug in produzione, nella nostra pratica abbiamo testato tecniche popolari \u2014 abbiamo bisogno della vostra esperienza. Invia<\/a><\/noindex> le tue candidature entro il 1 maggio<\/strong>, e il Comitato Programmatico aiuter\u00e0 a focalizzare il tema per l'unit\u00e0 complessiva della conferenza.<\/p>\n

Collegati al chat<\/a><\/noindex>, dove discutiamo questioni di qualit\u00e0 e la conferenza, iscriviti a Canale Telegram<\/a><\/noindex>, per rimanere aggiornato sulle novit\u00e0 del programma.<\/p><\/blockquote>\n

Fonte: 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\udd47Chi si assumer\u00e0 la responsabilit\u00e0 della qualit\u00e0? | ProHoster","description":"Ciao, Habr! Abbiamo un nuovo importante argomento \u2014 sviluppo qualitativo dei prodotti IT.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/31264","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=31264"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/31264\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/23230"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=31264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=31264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=31264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}