{"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\/es\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","title":{"rendered":"\u00bfQui\u00e9n responder\u00e1 por la calidad?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00a1Hola, Habr!<\/p>\n

Tenemos un nuevo tema importante: el desarrollo de productos IT de calidad. Hablamos a menudo en HighLoad++ sobre c\u00f3mo hacer que los servicios sobrecargados sean r\u00e1pidos, y en Frontend Conf sobre la creaci\u00f3n de una interfaz de usuario incre\u00edble que no se ralentice. Regularmente discutimos temas sobre pruebas, y en DevOpsConf sobre la integraci\u00f3n de diferentes procesos, incluyendo las pruebas. Sin embargo, no hemos abordado lo que se puede considerar calidad en general y c\u00f3mo trabajar de manera integral en ello.<\/p>\n

Lo corregiremos a QualityConf<\/a><\/noindex>\u00a0\u2014 fomentaremos la cultura de pensar en la calidad del producto final para el usuario en cada etapa del desarrollo. Cultivaremos el h\u00e1bito de no centrarnos \u00fanicamente en nuestra \u00e1rea de responsabilidad y asociar la calidad no solo con los testers.<\/p>\n

Debajo hablaremos con la jefa del comit\u00e9 del programa, l\u00edder de pruebas en Tinkoff.Biz, creadora de la comunidad QA de habla rusa. Anastasia Aseeva-Nguen<\/b> sobre el estado de la industria QA y la misi\u00f3n de la nueva conferencia.<\/p>\n

\"\u00bfQui\u00e9n
\n<\/a><\/noindex>
\n\u2014 Hola Nastya, cu\u00e9ntame un poco sobre ti.<\/em><\/strong><\/p>\n

\"\u00bfQui\u00e9nAnastasia<\/strong>: Dirijo las pruebas en el banco y soy responsable de un equipo muy grande: somos m\u00e1s de 90 personas. Nuestra l\u00ednea de negocio es importante, y nos encargamos del ecosistema para entidades legales.<\/p>\n

Estudi\u00e9 en la facultad de matem\u00e1ticas y originalmente quer\u00eda ser programadora. Pero cuando apareci\u00f3 una oferta interesante, decid\u00ed probarme como tester. Aunque parezca extra\u00f1o, result\u00f3 ser mi vocaci\u00f3n. Ahora veo todo mi trabajo en esta industria.<\/p>\n

Soy una ferviente defensora de la disciplina de Quality Assurance. Me importa qu\u00e9 productos se crean, c\u00f3mo se percibe la calidad en la empresa, en el equipo y, en general, en el proceso de desarrollo.<\/p><\/blockquote>\n

\nMe resulta evidente que la comunidad en este \u00e1mbito no est\u00e1 lo suficientemente madura<\/strong>, al menos en Rusia. No siempre entendemos que garantizar la calidad no es solo la cuesti\u00f3n de probar la aplicaci\u00f3n para que cumpla con los requisitos. Quisiera cambiar esta situaci\u00f3n.<\/p>\n

\u2014 Usas los t\u00e9rminos Quality Assurance y pruebas. Para el com\u00fan de la gente, estos dos t\u00e9rminos a menudo se cruzan. \u00bfCu\u00e1les son sus diferencias, si se profundiza?<\/em><\/strong><\/p>\n

Anastasia:<\/strong> En realidad, no difieren. La prueba es parte de la disciplina de Aseguramiento de Calidad, es una actividad directa: el mero hecho de que estoy probando algo. Existen muchos tipos de pruebas y diferentes personas son responsables de cada tipo. Sin embargo, en Rusia, cuando apareci\u00f3 la ola de subcontratistas que proporcionan testers a las empresas, la prueba se redujo a un \u00fanico tipo.<\/p>\n

En la mayor\u00eda de los casos, se limitan solo a las pruebas funcionales: verifican que lo que han codificado los desarrolladores cumpla con la especificaci\u00f3n y todo.<\/p>\n

\u2014 Cu\u00e9ntame, por favor, \u00bfqu\u00e9 otras disciplinas de aseguramiento de calidad existen? \u00bfQu\u00e9 m\u00e1s, adem\u00e1s de las pruebas, se incluye aqu\u00ed?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: El Aseguramiento de Calidad es, ante todo, sobre crear un producto de calidad. Es decir, nos hacemos la pregunta de qu\u00e9 atributos de calidad debe tener nuestro producto. En consecuencia, si comprendemos esto, podemos identificar qui\u00e9n influye en estos atributos de calidad. No importa, si es un desarrollador, un gerente de proyectos o un product owner.<\/strong>\u00a0\u2014 es la persona que influye en el desarrollo del producto, en su backlog, en su estrategia.<\/p>\n

El tester comienza a comprender mejor su papel. \u00c9l entiende que su tarea no es solo probar la conformidad con los requisitos, sino tambi\u00e9n probar los requisitos, cuestionar las formulaciones que provienen del product owner, desenterrar todos los requisitos impl\u00edcitos y las expectativas del cliente. Cuando proporcionamos una nueva funcionalidad a nuestro cliente, realmente debemos satisfacer sus expectativas y resolver su dolor. Si pensamos en todos los atributos de calidad, el cliente estar\u00e1 satisfecho y comprender\u00e1 que la empresa cuyo producto est\u00e1 utilizando realmente se preocupa por sus intereses y no trabaja con el principio de 'solo lanzar una caracter\u00edstica'.<\/p>\n

\u2014 Parece que lo que acabas de describir es una tarea del product owner. En principio, no se trata de pruebas ni de calidad, sino de gesti\u00f3n de productos, \u00bfverdad?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: En parte. El Aseguramiento de Calidad no es una disciplina a la que se le asigna una persona concreta. Actualmente, hay una tendencia popular en las pruebas, un enfoque llamado Pruebas \u00c1giles<\/strong>. Su definici\u00f3n indica claramente que es un enfoque \u00e1gil para las pruebas que incluye un conjunto espec\u00edfico de pr\u00e1cticas. Todo el equipo es responsable de implementar este enfoque, no es necesario que haya un probador en el equipo. Todo el equipo est\u00e1 orientado a entregar valor al cliente y a asegurarse de que ese valor cumpla con sus expectativas.<\/p>\n

\u2014 Entonces, \u00bfla calidad se intersecta casi con todas las disciplinas relacionadas, imponiendo l\u00edmites a todo a su alrededor?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Correcto. Cuando pensamos en crear un producto de calidad, comenzamos a considerar varios atributos de calidad. Por ejemplo, \u00bfc\u00f3mo verificar que realmente hemos creado una caracter\u00edstica que necesita nuestro cliente?<\/p>\n

Aqu\u00ed entra en juego un tipo de pruebas llamado UAT<\/strong> (pruebas de aceptaci\u00f3n de usuario). Lamentablemente, en Rusia este tipo de pruebas se practica raramente, aunque a veces est\u00e1 presente en equipos SCRUM como demostraci\u00f3n para el cliente final. En empresas extranjeras, este tipo de pruebas es bastante com\u00fan. Antes de abrir la funcionalidad a todos los clientes, primero hacemos UAT, lo que significa que invitamos al consumidor final, quien realiza la prueba y proporciona retroalimentaci\u00f3n de inmediato: si el producto cumple con las expectativas y resuelve el problema. Solo despu\u00e9s de esto se realiza la escalabilidad para todos los dem\u00e1s clientes.<\/p>\n

Es decir, estamos enfocados en el negocio, en el cliente final, pero al mismo tiempo no olvidamos la tecnolog\u00eda<\/strong>. La calidad del producto tambi\u00e9n depende en gran medida de la tecnolog\u00eda. Si tenemos una mala arquitectura, no podremos lanzar caracter\u00edsticas r\u00e1pidamente y cumplir con las expectativas del cliente. Pueden surgir muchos errores al intentar escalar, o al intentar realizar una refactorizaci\u00f3n, podemos romper algo. Todo esto influye en la satisfacci\u00f3n del cliente.<\/p>\n

Desde este punto de vista, la arquitectura debe ser tal que podamos escribir c\u00f3digo limpio que permita realizar cambios r\u00e1pidamente y no temer que lo rompa todo. Para que las iteraciones de mejora no se prolonguen durante meses solo porque tenemos tanto legado y necesitamos realizar largos per\u00edodos de prueba.<\/p>\n

\u2014 Entonces ya est\u00e1n involucrados desarrolladores, arquitectos, gerentes de producto, gerentes de producto, y los mismos probadores. \u00bfQui\u00e9n m\u00e1s est\u00e1 involucrado en el proceso de aseguramiento de la calidad?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Ahora supongamos que ya hemos entregado la funci\u00f3n al cliente. Es evidente que debemos supervisar la calidad del producto, incluso cuando ya est\u00e1 en producci\u00f3n. En esta etapa, pueden aparecer situaciones con escenarios poco obvios, conocidos como errores.<\/p>\n

La primera pregunta es: \u00bfc\u00f3mo manejamos estos errores despu\u00e9s de haber lanzado el producto? \u00bfC\u00f3mo respondemos, por ejemplo, a la carga? El cliente no estar\u00e1 muy satisfecho si la p\u00e1gina tarda m\u00e1s de 30 segundos en cargar.<\/p>\n

Aqu\u00ed entra en juego la operaci\u00f3n o, como se dice ahora, DevOps<\/strong>. De hecho, son las personas responsables de la operaci\u00f3n del producto una vez que ya est\u00e1 en producci\u00f3n. Esto incluye varios tipos de monitoreo. Incluso existe un subtipo de prueba: la prueba en producci\u00f3n, donde nos permitimos no probar algo antes del lanzamiento y lo probamos directamente en producci\u00f3n. Se trata de una serie de actividades desde el punto de vista de la organizaci\u00f3n de la infraestructura, que permiten reaccionar r\u00e1pidamente a un incidente, influir en \u00e9l y corregirlo.<\/p>\n

La infraestructura tambi\u00e9n es importante. A menudo hay situaciones cuando durante las pruebas, no se puede confirmar que realmente tenemos todo lo que quisi\u00e9ramos darle al cliente. Lanzamos en producci\u00f3n y comenzamos a detectar situaciones poco obvias. Y todo porque la infraestructura en las pruebas no coincide con la infraestructura en producci\u00f3n. De aqu\u00ed surge un nuevo tipo de prueba: la prueba de infraestructura<\/strong>. Estas son diversas configuraciones, ajustes, migraci\u00f3n de bases de datos, etc.<\/p>\n

De ah\u00ed surge la pregunta: tal vez el equipo deber\u00eda usar infraestructura como c\u00f3digo.<\/p>\n

Creo firmemente que la infraestructura influye directamente en la calidad del producto.<\/p><\/blockquote>\n

\nEspero que haya una presentaci\u00f3n en la conferencia con un caso real. Escr\u00edbanos si est\u00e1n dispuestos a compartir su experiencia sobre c\u00f3mo la infraestructura como c\u00f3digo influye en la calidad. La infraestructura como c\u00f3digo permite verificar m\u00e1s f\u00e1cilmente todas las configuraciones y probar lo que de otra manera ser\u00eda simplemente imposible. Por lo tanto, la operaci\u00f3n tambi\u00e9n se involucra en el proceso de desarrollo de un producto de calidad.<\/p>\n

\u2014 \u00bfY qu\u00e9 pasa con la anal\u00edtica y la documentaci\u00f3n?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Esto se relaciona m\u00e1s con los sistemas empresariales. Cuando hablamos de empresa, vienen a la mente personas como analistas y analistas de sistemas. A veces se les llama redactores t\u00e9cnicos. Reciben la tarea de redactar una especificaci\u00f3n y la llevan a cabo, por ejemplo, durante un mes.<\/p>\n

Se ha demostrado en m\u00faltiples ocasiones que escribir esta documentaci\u00f3n conduce a iteraciones de desarrollo muy prolongadas y a extensos procesos de mejora, ya que durante las pruebas se descubren errores, lo que provoca devoluciones. Como resultado, aparecen muchos bucles que aumentan el coste del desarrollo. Adem\u00e1s, esto puede introducir vulnerabilidades. Parece que hemos escrito c\u00f3digo de referencia, pero luego hacemos cambios que rompen la arquitectura perfectamente planificada.<\/p>\n

Al final, el producto no resulta ser de buena calidad, porque ya han aparecido parches en la arquitectura, el c\u00f3digo en algunas \u00e1reas no est\u00e1 suficientemente cubierto por pruebas, ya que los plazos aprietan y hay que cerrar errores r\u00e1pidamente. Todo esto se debe a que en la especificaci\u00f3n inicial no se tuvieron en cuenta todos los aspectos que deb\u00edan implementarse.<\/p>\n

Los desarrolladores no son villanos y no escriben intencionadamente c\u00f3digo con errores.<\/p><\/blockquote>\n

\nSi desde un principio hubi\u00e9ramos elaborado una especificaci\u00f3n que abarcara todos los aspectos necesarios, todo se habr\u00eda implementado tal como deb\u00eda. Pero eso es una utop\u00eda.<\/p>\n

Probablemente, no sea posible escribir una especificaci\u00f3n perfecta de 100 p\u00e1ginas. Por lo tanto, es necesario pensar en formas alternativas de redactar documentaci\u00f3n,<\/strong>de especificaci\u00f3n, de planteamiento de tareas, que nos acerquen a que los desarrolladores hagan exactamente lo que se necesita.<\/p>\n

Aqu\u00ed se me vienen a la mente enfoques de Agile: historias de usuario con criterios de aceptaci\u00f3n. Esto es m\u00e1s aplicable para equipos que se desarrollan en peque\u00f1as iteraciones.<\/p>\n

\u2014 \u00bfQu\u00e9 hay sobre las pruebas de usabilidad, la comodidad de uso del producto, el dise\u00f1o?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Este es un punto muy importante, porque en el equipo hay dise\u00f1adores. La mayor\u00eda de las veces, se utilizan dise\u00f1adores como un servicio: ya sea un departamento de dise\u00f1adores o un dise\u00f1ador en outsourcing. Frecuentemente, ocurren situaciones en las que parece que el dise\u00f1ador escuch\u00f3 al product owner y hizo lo que entendi\u00f3. Pero cuando se entra en la iteraci\u00f3n, se descubre que en realidad no se hizo lo que se esperaba: el dise\u00f1ador olvid\u00f3 algo, no pens\u00f3 completamente en el comportamiento, porque no est\u00e1 en el equipo y no est\u00e1 en contexto, o el desarrollador front-end no entendi\u00f3 completamente su dise\u00f1o. Puede que se necesiten varias iteraciones solo debido a problemas de comprensi\u00f3n del dise\u00f1o por parte del desarrollador front-end.<\/p>\n

Adem\u00e1s, hay otro problema. Actualmente, los sistemas de dise\u00f1o est\u00e1n ganando popularidad. Est\u00e1n en auge, pero los beneficios que aportan no son del todo evidentes.<\/p>\n

Me encuentro con la opini\u00f3n de que los sistemas de dise\u00f1o, por un lado, simplifican el desarrollo, pero por el otro, imponen muchas restricciones en la interfaz.<\/p><\/blockquote>\n

\nAl final, no estamos creando la funcionalidad que el cliente desea, sino la que nos resulta conveniente, porque ya tenemos ciertos bloques a partir de los cuales podemos construirla.<\/p>\n

Me parece que vale la pena prestar atenci\u00f3n a este tema y reflexionar si realmente, al intentar simplificar el trabajo de dise\u00f1o, estamos resolviendo el dolor del cliente.<\/p>\n

\u2014 Surgen sorprendentemente muchos temas relacionados con la calidad del software. \u00bfHay una conferencia en Rusia donde se puedan discutir todos ellos?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Hay una conferencia de pruebas muy antigua, que este a\u00f1o se llevar\u00e1 a cabo por 25\u00aa vez y se llama Conferencia de Aseguramiento de la Calidad SQA Days. Principalmente, en ella se discuten herramientas y enfoques espec\u00edficos de pruebas para los evaluadores funcionales. Generalmente, en las ponencias de SQA Days se abordan profundamente \u00e1reas espec\u00edficas en la zona de responsabilidad de los propios evaluadores, pero no eventos complejos.<\/p>\n

Esto ayuda mucho a entender las diferentes herramientas y enfoques sobre c\u00f3mo probar bases de datos, API, etc. Pero, por un lado, no motiva a involucrar en la creaci\u00f3n de un producto de mayor calidad no solo las pruebas. Y, por otro lado, los evaluadores no se involucran m\u00e1s en el proceso para pensar en el objetivo global del producto y su componente comercial.<\/p>\n

Dirijo un gran departamento, realizo muchas entrevistas, que en realidad permiten tener una idea del estado de la industria en su conjunto. Generalmente, nuestros chicos trabajan en empresas grandes y tienen un \u00e1rea de responsabilidad clara. Los colegas que trabajan en proyectos internacionales utilizan diferentes tipos de pruebas: pueden realizar pruebas de carga, pruebas de rendimiento e incluso a veces pruebas de seguridad, porque realmente ayudan al equipo a asegurar la calidad del producto.<\/p>\n

Me gustar\u00eda que aqu\u00ed en Rusia los chicos tambi\u00e9n comenzaran a pensar que en las pruebas funcionales la industria no termina.<\/p>\n

\u2014 Por eso estamos organizando la nueva conferencia QualityConf, que se dedica a la calidad como una disciplina integral. Cu\u00e9ntame m\u00e1s sobre la idea, \u00bfcu\u00e1l es el objetivo principal de la conferencia?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Queremos crear una comunidad de personas interesadas en hacer productos de calidad. Ofrecer un espacio al que puedan venir, escuchar charlas y salir despu\u00e9s de la conferencia con una comprensi\u00f3n concreta de lo que necesitan cambiar en s\u00ed mismos para mejorar la calidad.<\/p>\n

A menudo escucho solicitudes de consultor\u00eda sobre qu\u00e9 hacer cuando hay problemas con las pruebas y la calidad. Cuando comienzas a hablar con los equipos, ves que el problema no est\u00e1 en los propios testers, sino en c\u00f3mo se establece el proceso. Por ejemplo, cuando los desarrolladores creen que son responsables solo de escribir c\u00f3digo, su responsabilidad termina en el momento exacto en que entregan la tarea para pruebas.<\/p>\n

No todos piensan que un c\u00f3digo mal escrito, de baja calidad y con una mala arquitectura puede acarrear grandes problemas para el proyecto. No se reflexiona sobre el coste de los errores, sobre el hecho de que los bugs que llegan a producci\u00f3n pueden traducirse en grandes gastos para la empresa y el equipo. No hay una cultura de pensar en esto. Quiero que en la conferencia empecemos a difundirla.<\/p>\n

Entiendo que esto no es una innovaci\u00f3n. Edward Deming, autor de los 14 postulados de calidad, ya hablaba del coste del error en el siglo pasado. Esta obra es la base de Quality Assurance como disciplina, pero, desafortunadamente, el desarrollo moderno lo olvida.<\/p>\n

\u2014 \u00bfY planean tocar temas directamente relacionados con las pruebas y herramientas?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Admito que habr\u00e1 charlas sobre herramientas. Existen herramientas bastante universales que las empresas y equipos pueden utilizar para influir en el producto.<\/p>\n

Todas las charlas estar\u00e1n globalmente unidas por una misi\u00f3n com\u00fan: transmitir a la audiencia que, con este enfoque, herramienta, m\u00e9todo, proceso o tipo de prueba, hemos influido en la calidad del producto y mejorado la vida del cliente.<\/p><\/blockquote>\n

\nNo habr\u00e1 charlas sobre herramientas por el simple hecho de tener herramientas. Todas las presentaciones que se incluyan en el programa tendr\u00e1n un objetivo com\u00fan.<\/p>\n

\u2014 \u00bfA qui\u00e9n le interesar\u00e1 lo que est\u00e1s diciendo, a qui\u00e9n ves como invitados de la conferencia?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Tendremos presentaciones para desarrolladores que se preocupan por el futuro de su proyecto, producto o sistema. Tambi\u00e9n ser\u00e1 interesante para los testers y, como creo, especialmente para los gerentes. Por gerentes me refiero a las personas que toman decisiones y pueden influir en el destino y desarrollo del producto, del sistema y del equipo.<\/p>\n

Son personas que se preguntan c\u00f3mo mejorar la calidad del producto o del sistema. En nuestra conferencia, aprender\u00e1n sobre diferentes conjuntos de actividades y podr\u00e1n comprender qu\u00e9 les est\u00e1 fallando en este momento, qu\u00e9 necesitan cambiar.<\/p>\n

Creo que el principal criterio es entender que hay algo mal con la calidad y querer influir en ello. Probablemente no lograremos llegar a las personas que creen que est\u00e1 bien as\u00ed desde el primer intento.<\/p>\n

\u2014 \u00bfQu\u00e9 piensas, ha madurado la industria en su conjunto para hablar no solo sobre testing, sino sobre la cultura de calidad?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Creo que s\u00ed. Actualmente, muchas empresas se est\u00e1n alejando del enfoque tradicional Waterfall hacia Agile. Se est\u00e1 orientando hacia el cliente, y las personas en los equipos realmente comienzan a pensar en c\u00f3mo crear un producto de calidad. Incluso en empresas del tipo enterprise, hay una reorientaci\u00f3n hacia la mejora de la calidad.<\/p>\n

A juzgar por la cantidad de demandas que surgen en la comunidad, creo que ya es hora. No estoy segura, por supuesto, de que se trate de una revoluci\u00f3n a gran escala, pero me gustar\u00eda que este cambio de mentalidad ocurriera.<\/p>\n

\u2014 \u00a1De acuerdo! Vamos a fomentar la cultura y transformar la mentalidad.<\/em><\/strong><\/p>\n

Conferencia sobre el desarrollo de productos IT de calidad QualityConf<\/a><\/noindex> se llevar\u00e1 a cabo en Mosc\u00fa el 7 de junio<\/strong>. Sabes, de qu\u00e9 etapas se compone un producto de calidad, tenemos casos de \u00e9xito en la lucha contra errores en producci\u00f3n, hemos probado en nuestra pr\u00e1ctica metodolog\u00edas populares \u2014 necesitamos tu experiencia. Env\u00edanos<\/a><\/noindex> tu solicitud antes del 1 de mayo<\/strong>, y el Comit\u00e9 de Programa ayudar\u00e1 a enfocar el tema para la coherencia general de la conferencia.<\/p>\n

\u00danete al chat<\/a><\/noindex>, donde discutimos asuntos de calidad y la conferencia, suscr\u00edbete a Canal de Telegram<\/a><\/noindex>, para estar al tanto de las noticias del programa.<\/p><\/blockquote>\n

Fuente: 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\u00bfQui\u00e9n ser\u00e1 responsable de la calidad? | ProHoster","description":"\u00a1Hola, Habr! Tenemos un nuevo tema importante: desarrollo de productos IT de calidad.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/31264","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=31264"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/31264\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/23230"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=31264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=31264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=31264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}