{"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 \u00e8 responsabile della qualit\u00e0?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, Habr!<\/p>\n

Abbiamo un nuovo tema importante: lo sviluppo di prodotti IT di qualit\u00e0. Parliamo spesso di HighLoad++ su come rendere i servizi sovraccaricati veloci, e al Frontend Conf di un'interfaccia utente fantastica che non rallenta. Affrontiamo regolarmente argomenti sul testing e a DevOpsConf sulla fusione di diversi processi, incluso il testing. Ma riguardo a cosa si pu\u00f2 considerare qualit\u00e0 in generale e come lavorare su di essa in modo complesso - non se ne parla.<\/p>\n

Correggeremo questo in QualityConf<\/a><\/noindex>\u00a0\u2014 svilupperemo una cultura di pensiero sulla qualit\u00e0 del prodotto finale per l'utente a ogni fase dello sviluppo. L'abitudine a non rimanere bloccati nella propria area di responsabilit\u00e0 e associare la qualit\u00e0 non solo ai tester.<\/p>\n

Sotto parleremo con la presidente del comitato programmatorio, responsabile del testing in Tinkoff.Bussiness, fondatrice della comunit\u00e0 QA di lingua russa Anastasia Aseeva-Nguyen<\/b> sulla situazione del settore QA e la 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, sono responsabile di un team molto ampio \u2014 siamo pi\u00f9 di 90 persone. Gestiamo una linea di business importante, ci occupiamo dell'ecosistema per le aziende.<\/p>\n

Ho studiato matematica e informatica e inizialmente volevo diventare programmatrice. Ma quando mi \u00e8 stata proposta un'opportunit\u00e0 interessante, ho deciso di provare il ruolo di tester. Stranamente, questo si \u00e8 rivelato essere la mia vocazione. Oggi vedo il mio lavoro esclusivamente in questo settore.<\/p>\n

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

\nPer me \u00e8 evidente che la comunit\u00e0 in questo settore \u00e8 insufficientemente matura<\/strong>, almeno in Russia. Non sempre comprendiamo che la garanzia di qualit\u00e0 non \u00e8 solo il semplice fatto di testare un'applicazione per verificarne la conformit\u00e0 ai requisiti. Vorrei cambiare questa situazione.<\/p>\n

\u2014 Usi le parole Quality Assurance e testing. Nella percezione dell'opinione pubblica, questi due termini si sovrappongono molto spesso. In cosa si differenziano, se approfondiamo?<\/em><\/strong><\/p>\n

Anastasia:<\/strong> In realt\u00e0, non si distinguono. Il testing \u00e8 parte della disciplina Quality Assurance, \u00e8 un'attivit\u00e0 diretta \u2014 il semplice fatto di testare qualcosa. Ci sono davvero molti tipi di testing, e diverse persone sono responsabili per i vari tipi di test. Tuttavia, in Russia, con l'emergere di una nuova ondata di outsourcing che fornisce tester alle aziende, il testing si \u00e8 ridotto a un'unica forma.<\/p>\n

Nella maggior parte dei casi ci si limita solo al testing funzionale: si verifica se ci\u00f2 che gli sviluppatori hanno codificato corrisponde alle specifiche e basta.<\/p>\n

\u2014 Puoi raccontarci, per favore, quali sono le altre discipline dell'assicurazione della qualit\u00e0? Cosa altro, oltre al testing, \u00e8 incluso?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: 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 dovrebbe avere il nostro prodotto. Pertanto, se comprendiamo questo, possiamo confrontare chi influisce su questi attributi di qualit\u00e0. Non importa, se \u00e8 uno sviluppatore, un project manager o un product owner<\/strong>\u00a0\u2014 \u00e8 la persona che influisce sullo sviluppo del prodotto, sul suo backlog, sulla sua strategia.<\/p>\n

Il tester inizia a comprendere meglio il proprio ruolo. Comprende che il suo compito non \u00e8 solo quello di testare la conformit\u00e0 ai requisiti, ma anche di mettere in discussione le formulazioni provenienti dal product manager, di svelare tutti i requisiti e le aspettative non esplicite del cliente. Quando forniamo una nuova funzionalit\u00e0 al nostro cliente, dobbiamo davvero soddisfare le sue aspettative e risolvere il suo problema. Se consideriamo tutti gli attributi della qualit\u00e0, il cliente sar\u00e0 soddisfatto e capir\u00e0 che l'azienda il cui prodotto utilizza si prende davvero cura dei suoi interessi, e non lavora secondo il principio del \"basta rilasciare una funzione\".<\/p>\n

\u2014 Sembra che ci\u00f2 che hai descritto sia il compito del product manager. In effetti, non riguarda il collaudo e nemmeno la qualit\u00e0 \u2014 riguarda totalmente il product management, giusto?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Esatto. La Quality Assurance non \u00e8 una disciplina di cui \u00e8 responsabile una sola persona. Ora c'\u00e8 una direzione popolare nel testing, un approccio 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 certo insieme di pratiche. L'intera squadra \u00e8 responsabile dell'implementazione di questo approccio, non \u00e8 necessario che ci sia un tester nel team. L'intera squadra \u00e8 orientata a fornire valore al cliente e a garantire che questo valore corrisponda alle sue aspettative.<\/p>\n

\u2014 Quindi, la qualit\u00e0 tocca quasi tutte le discipline circostanti, imponendo limiti a tutto ci\u00f2 che \u00e8 intorno?<\/em><\/strong><\/p>\n

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

Qui emerge un tipo di test come UAT<\/strong> (user acceptance testing). Purtroppo, in Russia \u00e8 raro che venga praticato, ma a volte \u00e8 presente nei team SCRUM, come demo per il cliente finale. Nelle aziende estere, questo \u00e8 un tipo di testing abbastanza comune. Prima di aprire la funzionalit\u00e0 a tutti i clienti, facciamo prima il UAT, invitando il consumatore finale che esegue il testing e fornisce immediatamente feedback \u2014 se il prodotto soddisfa davvero le aspettative e risolve un problema. Solo dopo questo avviene la scalabilit\u00e0 per tutti gli altri clienti.<\/p>\n

Vale a dire, ci focalizziamo sul business, sul cliente finale, ma non dimentichiamo la tecnologia<\/strong>. La qualit\u00e0 del prodotto dipende molto anche dalle tecnologie. Se abbiamo una cattiva architettura, non saremo in grado di rilasciare rapidamente le funzionalit\u00e0 e soddisfare le aspettative del cliente. Possono esserci molti bug quando si cerca di scalare, o durante un tentativo di refactoring potremmo rompere qualcosa. Tutto ci\u00f2 influenzer\u00e0 la soddisfazione del cliente.<\/p>\n

Da questo punto di vista, l'architettura deve essere tale da permetterci di scrivere codice pulito, che consenta di apportare modifiche rapidamente e senza temere che tutto si rompa. Affinch\u00e9 le iterazioni di miglioramento non si allunghino per mesi solo perch\u00e9 abbiamo cos\u00ec tanto legacy e dobbiamo effettuare lunghe fasi di testing.<\/p>\n

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

Anastasia<\/strong>: Immaginiamo ora di aver gi\u00e0 consegnato una funzionalit\u00e0 al cliente. \u00c8 ovvio che dobbiamo monitorare la qualit\u00e0 del prodotto anche quando \u00e8 in produzione. In questa fase possono emergere situazioni con scenari non ovvi, i cosiddetti bug.<\/p>\n

La prima domanda \u00e8: come gestiamo questi bug dopo aver gi\u00e0 rilasciato il prodotto? Ad esempio, come reagiamo ai carichi? Il cliente non sar\u00e0 molto contento se la pagina impiega pi\u00f9 di 30 secondi a caricarsi.<\/p>\n

Qui entra in gioco l'operativit\u00e0 o, come viene chiamato ora, DevOps<\/strong>. In sostanza, queste sono persone responsabili dell'operativit\u00e0 del prodotto una volta che \u00e8 in produzione. Ci sono vari tipi di monitoraggio inclusi. Esiste persino una sottocategoria di test \u2014 test in produzione, dove ci permettiamo di non testare qualcosa fino al rollout e testiamo direttamente in produzione. Si tratta di una serie di attivit\u00e0 dal punto di vista organizzativo dell'infrastruttura che consentono di rispondere rapidamente a un incidente, influenzarlo e correggerlo.<\/p>\n

Anche l'infrastruttura \u00e8 importante. Ci sono spesso situazioni in cui durante i test non \u00e8 possibile accertarsi che abbiamo davvero tutto ci\u00f2 che volevamo offrire al cliente. Lanciamo in produzione \u2014 e iniziamo a rilevare situazioni non evidenti. E tutto ci\u00f2 accade perch\u00e9 l'infrastruttura in test non corrisponde a quella in produzione. Da qui nasce un nuovo tipo di test \u2014 test dell'infrastruttura<\/strong>. Queste includono varie configurazioni, impostazioni, migrazione di database, ecc.<\/p>\n

Da qui sorge la domanda: forse il team dovrebbe 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. Scrivici se sei pronto a condividere la tua esperienza su 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 viene 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 legato ai sistemi enterprise. Quando parliamo di enterprise, ci vengono in mente persone come analisti e analisti di sistema. A volte vengono chiamati anche 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 scrittura di tale documentazione porta a iterazioni di sviluppo molto lunghe e a iterazioni di rifinitura prolungate, poich\u00e9 durante il processo di test emergono bug e iniziano i resi. Di conseguenza, si creano moltissimi cicli che aumentano il costo dello sviluppo. Inoltre, questo pu\u00f2 introdurre vulnerabilit\u00e0. Sembrava che avessimo scritto codice standard, ma poi abbiamo fatto cambiamenti che rompono un'architettura perfettamente elaborata.<\/p>\n

Il risultato finale \u00e8 un prodotto di qualit\u00e0 non del tutto soddisfacente, poich\u00e9 nell'architettura sono gi\u00e0 emerse patch, il codice in alcune aree non \u00e8 sufficientemente coperto dai test, a causa di scadenze ravvicinate, bisogna chiudere rapidamente tutti i bug. E tutto ci\u00f2 accade perch\u00e9 nella specifica iniziale non erano stati considerati tutti gli aspetti da implementare.<\/p>\n

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

\nSe avessimo originariamente pianificato una specifica che includesse tutti gli aspetti necessari, tutto sarebbe stato implementato esattamente come richiesto. Ma questa \u00e8 un'utopia.<\/p>\n

Probabilmente scrivere una specifica perfetta di 100 pagine \u00e8 impossibile. Quindi \u00e8 necessario riflettere su metodi alternativi per redigere la documentazione<\/strong>, specificazione, assegnazione di compiti che ci avvicinano a far s\u00ec che il developer faccia esattamente ci\u00f2 che serve.<\/p>\n

Qui vengono in mente approcci da Agile \u2014 storie utente con criteri di accettazione. Questo \u00e8 pi\u00f9 applicabile per i team che crescono con piccole iterazioni.<\/p>\n

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

Anastasia<\/strong>: Questo \u00e8 un aspetto molto importante, perch\u00e9 nel team ci sono designer. Spesso i designer vengono utilizzati come servizio \u2014 o un dipartimento di designer, o un designer esternalizzato. Si presentano frequentemente situazioni in cui sembrerebbe che il designer abbia ascoltato il product manager e abbia fatto ci\u00f2 che ha capito. Ma quando passiamo all'iterazione, si scopre che in realt\u00e0 non \u00e8 stato fatto ci\u00f2 che ci si aspettava: il designer ha dimenticato qualcosa, non ha pensato completamente al comportamento, perch\u00e9 non \u00e8 nel team e non \u00e8 nel contesto, o lo sviluppatore front-end non ha capito completamente il suo layout. Potrebbero essere necessarie diverse iterazioni solo a causa del malinteso del design da parte dello sviluppatore front-end.<\/p>\n

Inoltre, c'\u00e8 un altro problema. Le design system stanno diventando sempre pi\u00f9 popolari. Sono di tendenza, ma i vantaggi non sono del tutto evidenti.<\/p>\n

Mi capita di sentire l'opinione che le design system, da un lato, semplifichino lo sviluppo, ma dall'altro lato impongano molte limitazioni all'interfaccia.<\/p><\/blockquote>\n

\nIn definitiva, non stiamo implementando una funzionalit\u00e0 che il cliente desidera, ma piuttosto una che \u00e8 comoda per noi, perch\u00e9 abbiamo gi\u00e0 a disposizione determinati componenti dai quali possiamo realizzarla.<\/p>\n

Mi sembra che valga la pena prestare attenzione a questo argomento e riflettere se, nel tentativo di semplificare il lavoro sul design, stiamo davvero affrontando il dolore del cliente.<\/p>\n

\u2014 Ne conseguono molte tematiche legate al Quality Assurance. In Russia c'\u00e8 una conferenza dove si possono discutere tutti questi argomenti?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: C'\u00e8 la conferenza pi\u00f9 antica sul testing, che quest'anno si svolger\u00e0 per la 25\u00aa volta e si chiama SQA Days. Durante questo evento si discutono principalmente strumenti e approcci specifici al testing per i tester funzionali. Di solito, le presentazioni di SQA Days approfondiscono aree specifiche nelle responsabilit\u00e0 dei tester, piuttosto che eventi complessi.<\/p>\n

Questo aiuta molto a capire i vari strumenti e approcci per testare database, API, ecc. Tuttavia, da un lato non motiva a coinvolgere nel creare un prodotto pi\u00f9 qualitativo, non solo il testing. Dall'altro, i tester non diventano pi\u00f9 coinvolti nel processo per riflettere sull'obiettivo globale del prodotto e sulla sua componente commerciale.<\/p>\n

Dirigo un grande reparto, conduco molti colloqui che realmente permettono di comprendere lo stato dell'industria in generale. Di solito, i nostri ragazzi lavorano in ambito enterprise e hanno una chiara area di responsabilit\u00e0. I colleghi impegnati in progetti internazionali usano diversi tipi di testing: possono effettuare test di carico, test delle prestazioni e, talvolta, anche test di sicurezza, perch\u00e9 realmente aiutano il team a garantire la qualit\u00e0 del prodotto.<\/p>\n

Mi piacerebbe che anche in Russia i ragazzi iniziassero a riflettere sul fatto che il testing funzionale non rappresenta tutta l'industria.<\/p>\n

\u2014 Per questo stiamo organizzando una nuova conferenza QualityConf, dedicata alla qualit\u00e0 come disciplina globale. Racconta 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 relazioni e uscire dalla conferenza con una comprensione concreta di cosa devono cambiare per migliorare la qualit\u00e0.<\/p>\n

Spesso sento parlare di richieste da parte delle aziende di consulenza riguardo a cosa fare quando ci sono problemi con i test e la qualit\u00e0. Quando inizi a dialogare con i team, noti che il problema non risiede nei tester stessi, ma nel modo in cui \u00e8 strutturato il processo. Ad esempio, quando gli sviluppatori credono di essere responsabili solo per la scrittura del codice, la loro responsabilit\u00e0 termina esattamente nel momento in cui trasferiscono il compito ai test.<\/p>\n

Non tutti considerano che un codice scadente e mal strutturato pu\u00f2 comportare grandi problemi per il progetto. Non riflettono sul costo degli errori, sul fatto che i bug, se arrivano in produzione, possono comportare costi elevati per l'azienda e il team. Non c'\u00e8 cultura a riguardo. Vorrei che durante la conferenza iniziasse a diffondersi.<\/p>\n

Capisco che non si tratta di un'innovazione. Edward Deming, autore dei 14 postulati della qualit\u00e0, parlava del costo dell'errore gi\u00e0 nel secolo scorso. Questo libro \u00e8 alla base del Quality Assurance come disciplina, ma, sfortunatamente, la moderna sviluppo tende a dimenticarlo.<\/p>\n

\u2014 Prevedete di trattare anche argomenti direttamente legati ai test e agli strumenti?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Considero che ci saranno presentazioni sugli strumenti. Ci sono strumenti abbastanza universali che le aziende e i team possono utilizzare per influire sul prodotto.<\/p>\n

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

\nNon avremo certamente presentazioni sugli strumenti per il solo piacere di farlo. Tutte le presentazioni che faranno parte del programma saranno unite da un obiettivo comune.<\/p>\n

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

Anastasia<\/strong>: Avremo presentazioni per sviluppatori che si prendono a cuore il destino del loro progetto, prodotto o sistema. Sar\u00e0 interessante anche per i tester e, come mi sembra, soprattutto per i manager. Per manager intendo persone che prendono decisioni e possono influenzare il destino e lo sviluppo del prodotto, del sistema e del team.<\/p>\n

Queste sono persone che si pongono la domanda su come migliorare la qualit\u00e0 del prodotto e del sistema. Alla nostra conferenza, scopriranno diversi complessi di attivit\u00e0 e potranno capire cosa non va attualmente e cosa deve essere cambiato.<\/p>\n

Penso che il criterio principale sia riconoscere che c'\u00e8 qualcosa che non va con la qualit\u00e0 e voler avere un impatto su di essa. Probabilmente, non riusciremo a far breccia nelle persone che pensano che vada bene cos\u00ec al primo tentativo.<\/p>\n

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

Anastasia<\/strong>: Credo di s\u00ec. Attualmente, molte aziende si stanno allontanando dall'approccio tradizionale Waterfall a favore dell'Agile. C'\u00e8 un orientamento verso il cliente, e le persone nei team stanno veramente iniziando a riflettere su come creare prodotti di qualit\u00e0. Anche nelle aziende enterprise si sta verificando un riposizionamento verso l'aumento della qualit\u00e0.<\/p>\n

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

\u2014\u00a0D'accordo! Promuoveremo la cultura e cambieremo la mentalit\u00e0.<\/em><\/strong><\/p>\n

Conferenza sulla qualit\u00e0 nello sviluppo di prodotti IT QualityConf<\/a><\/noindex> si terr\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 e abbiamo testato pratiche popolari nella nostra esperienza \u2014 ci serve la vostra esperienza. Inviateci<\/a><\/noindex> le vostre candidature entro il 1 maggio<\/strong>, e il Comitato Programmatico vi aiuter\u00e0 a focalizzare il tema per una maggiore coesione della conferenza.<\/p>\n

Collegati al chat<\/a><\/noindex>, dove discutiamo le questioni di qualit\u00e0 e la conferenza, iscriviti al 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 occuper\u00e0 della qualit\u00e0? | ProHoster","description":"Ciao, Habr! Abbiamo un nuovo argomento importante: lo sviluppo di prodotti IT di alta qualit\u00e0. Parliamo spesso di come rendere i servizi ad alta richiesta veloci durante HighLoad++, e di interfacce utente eccezionali che non rallentano al Frontend Conf. Abbiamo regolarmente temi sul testing e DevOpsConf che riguardano l'integrazione di diversi processi, incluso il testing. Ma non esiste una discussione su cosa si possa considerare qualit\u00e0 in generale e come affrontarla in modo complessivo. Risolveremo questo al QualityConf: svilupperemo.","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. \u041c\u044b \u0447\u0430\u0441\u0442\u043e \u0433\u043e\u0432\u043e\u0440\u0438\u043c \u043d\u0430 HighLoad++, \u043a\u0430\u043a \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u043d\u0430\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b \u0431\u044b\u0441\u0442\u0440\u044b\u043c\u0438, \u0430 \u043d\u0430 Frontend Conf \u2014 \u043a\u043b\u0430\u0441\u0441\u043d\u044b\u0439 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0438\u0439 \u0438\u043d\u0442\u0435\u0440\u0444\u0435\u0439\u0441, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043d\u0435 \u0442\u043e\u0440\u043c\u043e\u0437\u0438\u0442. \u0423 \u043d\u0430\u0441 \u0440\u0435\u0433\u0443\u043b\u044f\u0440\u043d\u043e \u0435\u0441\u0442\u044c \u0442\u0435\u043c\u044b \u043f\u0440\u043e \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435, \u0438 DevOpsConf \u043f\u0440\u043e \u043e\u0431\u044a\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u0435 \u0440\u0430\u0437\u043d\u044b\u0445 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0432, \u0432\u043a\u043b\u044e\u0447\u0430\u044f \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435. \u0410 \u043f\u0440\u043e \u0442\u043e, \u0447\u0442\u043e \u043c\u043e\u0436\u043d\u043e \u043d\u0430\u0437\u0432\u0430\u0442\u044c \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u043e \u0432 \u0446\u0435\u043b\u043e\u043c, \u0438 \u043a\u0430\u043a \u043d\u0430\u0434 \u043d\u0438\u043c \u043a\u043e\u043c\u043f\u043b\u0435\u043a\u0441\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u2014 \u043d\u0435\u0442. \u0418\u0441\u043f\u0440\u0430\u0432\u0438\u043c \u044d\u0442\u043e \u043d\u0430 QualityConf \u2014 \u0431\u0443\u0434\u0435\u043c \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0442\u044c","og:url":"https:\/\/prohoster.info\/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}]}}