¿Quién es responsable de la calidad?

¡Hola, Habr!

Tenemos un nuevo tema importante: el desarrollo de alta calidad de productos TI. En HighLoad++ hablamos a menudo sobre cómo agilizar los servicios ocupados, y en Frontend Conf hablamos de una interfaz de usuario interesante que no se ralentiza. Regularmente tenemos temas sobre pruebas y DevOpsConf sobre la combinación de diferentes procesos, incluidas las pruebas. Pero sobre lo que se puede llamar calidad en general y cómo trabajar en ello de manera integral, no.

Arreglemos esto CalidadConf — desarrollaremos una cultura de pensar en la calidad del producto final para el usuario en cada etapa de desarrollo. El hábito de no centrarse en su área de responsabilidad y asociar la calidad no solo con los evaluadores.

Debajo del corte hablaremos con el jefe del comité del programa, jefe de pruebas de Tinkoff.Business, creador de la comunidad de control de calidad de habla rusa. Anastasia Aseeva-Nguyen sobre el estado de la industria del control de calidad y la misión de la nueva conferencia.

-Hola Nastia. Por favor, cuéntenos acerca de usted.

Anastasia: Gestiono las pruebas en un banco, soy responsable de un equipo muy grande: somos más de 90 personas. Tenemos una importante línea de negocio, somos responsables del ecosistema de las personas jurídicas.

Estudié mecánica y matemáticas y al principio quería ser programador. Pero cuando recibí una oferta interesante, decidí probarme como tester. Por extraño que parezca, ésta resultó ser mi vocación. Ahora veo todo mi trabajo en esta industria.

Soy un ferviente partidario de la disciplina de Garantía de Calidad. No me es indiferente qué productos se crean, cómo se trata la calidad en la empresa, en el equipo y, en principio, en el proceso de desarrollo.

Es obvio para mi que la comunidad en esta dirección no es lo suficientemente madura, al menos en Rusia. No siempre entendemos que el aseguramiento de la calidad no es solo el hecho de probar una aplicación para comprobar que cumple con los requisitos. Me gustaría cambiar esta situación.

— Utiliza las palabras Garantía de calidad y pruebas. A los ojos del ciudadano medio, estos dos términos muy a menudo se superponen. ¿En qué se diferencian si profundizas?

Anastasia Más bien, no son diferentes. Las pruebas son parte de la disciplina de Garantía de Calidad; es una actividad directa: el hecho mismo de que estoy probando algo. En realidad, existen muchos tipos de pruebas y una variedad de personas son responsables de los diferentes tipos de pruebas. Pero aquí en Rusia, cuando apareció una ola de subcontratistas que suministran probadores a las empresas, las pruebas se redujeron a un solo tipo.

En la mayoría de los casos, se limitan únicamente a pruebas funcionales: comprueban que lo que los desarrolladores han codificado cumple con la especificación y eso es todo.

— Por favor díganos ¿qué otras disciplinas de garantía de calidad existen? ¿Qué más se incluye aquí, además de las pruebas?

Anastasia: El aseguramiento de la calidad consiste, ante todo, en crear un producto de calidad. Es decir, nos preguntamos qué atributos de calidad debe tener nuestro producto. En consecuencia, si entendemos esto, podemos comparar quién influye en estos atributos de calidad. No importa, desarrollador, director de proyectos o especialista en productos Es una persona que influye en el desarrollo de un producto, su cartera de pedidos y su estrategia.

El evaluador se vuelve más consciente de su papel. Entiende que su tarea no es sólo probar el cumplimiento de los requisitos, sino también probar los requisitos, cuestionar las formulaciones que provienen del especialista del producto y revelar todos los requisitos y expectativas implícitos del cliente. Cuando ofrecemos nuevas funciones a nuestros clientes, debemos cumplir verdaderamente con sus expectativas y resolver sus problemas. Si pensamos en todos los atributos de la calidad, el cliente quedará satisfecho y comprenderá que la empresa cuyo producto utiliza realmente se preocupa por sus intereses y no trabaja según el principio de "sólo para lanzar una característica".

— Parece que lo que acabas de describir es tarea de un especialista de producto. En principio, no se trata de pruebas ni de calidad; en general, se trata de gestión del producto, ¿no?

Anastasia: Incluido. El Aseguramiento de la Calidad no es una disciplina de la cual una persona específica sea responsable. Ahora existe una dirección popular en las pruebas, un enfoque llamado Pruebas ágiles. Su definición establece claramente que se trata de un enfoque de equipo para las pruebas, que incluye un determinado conjunto de prácticas. Todo el equipo es responsable de implementar este enfoque; ni siquiera es necesario que haya un tester en el equipo. Todo el equipo se centra en ofrecer valor al cliente y garantizar que el valor cumpla con las expectativas del cliente.

— ¿Resulta que la calidad se cruza con casi todas las disciplinas circundantes, imponiendo un marco a todo lo que nos rodea?

Anastasia: Bien. Cuando pensamos en cómo queremos crear un producto de calidad, empezamos a pensar en los diversos atributos de la calidad. Por ejemplo, cómo comprobar que realmente hemos creado la función que nuestro cliente necesita.

Aquí es donde entra en juego este tipo de pruebas: UAT (Pruebas de aceptación del usuario). Desafortunadamente, rara vez se practica en Rusia, pero a veces está presente en los equipos SCRUM como demostración para el cliente final. Este es un tipo de prueba bastante común en empresas extranjeras. Antes de abrir la funcionalidad a todos los clientes, primero hacemos UAT, es decir, invitamos al usuario final a que pruebe e inmediatamente dé su opinión: si el producto realmente cumple con las expectativas y resuelve el problema. Sólo después de esto se produce el escalado a todos los demás clientes.

Es decir, nos centramos en el negocio, en el cliente final, pero al mismo tiempo no te olvides de la tecnología. La calidad del producto también depende en gran medida de la tecnología. Si tenemos una mala arquitectura, no podremos lanzar funciones rápidamente y cumplir con las expectativas de los clientes. Puede haber muchos errores al intentar escalar, o al intentar refactorizar podemos romper algo. Todo esto repercutirá en la satisfacción del cliente.

Desde este punto de vista, la arquitectura debe ser tal que podamos escribir código limpio que nos permita realizar cambios rápidamente y no tener miedo de estropearlo todo. Para que las iteraciones de revisión no se extiendan durante varios meses simplemente porque tenemos mucho legado y necesitamos realizar etapas de prueba largas.

— En total, ya están involucrados desarrolladores, arquitectos, científicos de producto, gerentes de producto y los propios evaluadores. ¿Quién más participa en el proceso de garantía de calidad?

Anastasia: Ahora imaginemos que ya hemos entregado la función al cliente. Obviamente, es necesario controlar la calidad del producto incluso cuando ya está en producción. En esta etapa pueden aparecer situaciones con escenarios no obvios, los llamados errores.

La primera pregunta es ¿cómo solucionamos estos errores una vez que ya hemos lanzado el producto? ¿Cómo reaccionamos, por ejemplo, ante el estrés? El cliente no estará muy contento si la página tarda más de 30 segundos en cargarse.

Aquí es donde entra en juego la explotación o, como la llaman ahora, DevOps. De hecho, estas son las personas que se encargan de operar el producto cuando ya está en producción. Esto incluye varios tipos de seguimiento. Incluso existe un subtipo de prueba: la prueba en producción, cuando nos permitimos no probar algo antes del lanzamiento y probarlo inmediatamente en producción. Se trata de una serie de medidas desde el punto de vista de la organización de la infraestructura que permiten responder rápidamente a un incidente, influir en él y corregirlo.

La infraestructura también es importante. A menudo hay situaciones en las que, durante una prueba, es imposible asegurarnos de que realmente tenemos todo lo que nos gustaría darle al cliente. Lo implementamos en producción y comenzamos a detectar situaciones no obvias. Y todo porque la infraestructura en prueba no se corresponde con la infraestructura en producción. Esto conduce a un nuevo tipo de prueba: pruebas de infraestructura. Se trata de diversas configuraciones, ajustes, migración de bases de datos, etc.

Esto plantea la pregunta: tal vez el equipo necesite utilizar la infraestructura como código.

Creo que la infraestructura afecta directamente la calidad del producto.

Espero que en la conferencia haya un informe con un caso real. Escríbanos si está listo para contarnos desde su propia experiencia cómo la infraestructura como código afecta la calidad. La infraestructura como código hace que sea más fácil verificar todas las configuraciones y probar cosas que de otro modo simplemente no serían posibles. Por tanto, la operación también está involucrada en el proceso de desarrollo de un producto de calidad.

— ¿Qué pasa con el análisis y la documentación?

Anastasia: Esto se aplica más a los sistemas empresariales. Cuando hablamos de empresa, inmediatamente nos vienen a la mente personas como analistas y analistas de sistemas. A veces se les llama redactores técnicos. Reciben la tarea de redactar una especificación y completarla, por ejemplo, durante un mes.

Se ha demostrado repetidamente que escribir dicha documentación conduce a iteraciones de desarrollo y refinamiento muy largas, porque durante el proceso de prueba se identifican errores y comienzan las devoluciones. Como resultado, existen muchos bucles que aumentan los costos de desarrollo. Además, esto puede introducir vulnerabilidades. Parece que escribimos un código de referencia, pero luego hicimos cambios que rompen la arquitectura perfectamente pensada.

El resultado final es un producto que no es del todo de alta calidad, porque ya han aparecido parches en la arquitectura, el código en algunos lugares no está suficientemente cubierto por las pruebas, porque los plazos se están agotando y todos los errores deben corregirse rápidamente. Y todo porque la especificación original no tuvo en cuenta todos los puntos que deben implementarse.

Los desarrolladores no son una plaga y no escriben código con errores a propósito.

Si inicialmente hubiéramos pensado en una especificación que cubriera todos los puntos necesarios, entonces todo se habría implementado exactamente como era necesario. Pero esto es una utopía.

Probablemente sea imposible escribir una especificación perfecta de 100 páginas. Es por eso Necesito pensar en formas alternativas de escribir documentación., especificaciones, establecimiento de tareas que nos acercarían a garantizar que el desarrollador haga exactamente lo que se necesita.

Aquí me vienen a la mente enfoques de Agile: historias de usuarios con criterios de aceptación. Esto es más aplicable a equipos que se desarrollan en pequeñas iteraciones.

— ¿Qué pasa con las pruebas de usabilidad, la usabilidad del producto y el diseño?

Anastasia: Este es un punto muy importante, porque hay diseñadores en el equipo. La mayoría de las veces, los diseñadores son utilizados como un servicio, ya sea por un departamento de diseño o por un diseñador subcontratado. A menudo hay situaciones en las que parece que el diseñador escuchó al especialista del producto e hizo lo que entendió. Pero cuando comenzamos la iteración, resulta que lo que realmente se hizo no fue lo que se esperaba: el diseñador olvidó algo, no pensó completamente en el comportamiento, porque no está en el equipo ni en el contexto o en el frente. -El desarrollador final no entendió completamente su diseño. Es posible que sean necesarias varias iteraciones simplemente porque hay un problema con la comprensión del diseño por parte del desarrollador front-end.

Además hay un problema más. Los sistemas de diseño están ganando popularidad. Están de moda, pero sus beneficios no son del todo obvios.

Me encuentro con la opinión de que los sistemas de diseño, por un lado, simplifican el desarrollo, pero por otro, imponen muchas restricciones a la interfaz.

Como resultado, no hacemos la característica que el cliente quiere, sino la que nos conviene, porque ya tenemos ciertos cubos a partir de los cuales podemos hacerlo.

Creo que este es un tema que vale la pena analizar y preguntarnos si al intentar facilitar el diseño en realidad estamos resolviendo un problema del cliente.

— Hay una sorprendente cantidad de temas relacionados con la Garantía de Calidad. ¿Hay una conferencia en Rusia donde se puedan discutir todos ellos?

Anastasia: Existe la conferencia de pruebas más antigua, que se llevará a cabo por 25ª vez este año y se llama Conferencia de Garantía de Calidad de los Días SQA. Principalmente analiza herramientas y enfoques de prueba específicos para probadores funcionales. Como regla general, los informes de los SQA Days examinan en profundidad áreas específicas en el área de responsabilidad de los propios evaluadores, pero no actividades complejas.

Esto ayuda mucho a comprender diferentes herramientas y enfoques, cómo probar bases de datos, API, etc. Pero al mismo tiempo, por un lado, no motiva a implicar más que simples pruebas en la creación de un mejor producto. Por otro lado, los testers no se involucran más en el proceso para pensar en el objetivo global del producto y su componente comercial.

Dirijo un departamento grande y realizo muchas entrevistas que realmente brindan información sobre el estado de la industria en su conjunto. Como regla general, nuestros muchachos trabajan en empresas y tienen un área de responsabilidad clara. Los colegas que trabajan en proyectos extranjeros utilizan diferentes tipos de pruebas: ellos mismos pueden realizar pruebas de carga, pruebas de rendimiento e incluso, a veces, pruebas de seguridad, porque realmente ayudan al equipo a garantizar la calidad del producto.

Me gustaría que los chicos de Rusia también empezaran a pensar que la industria no termina con las pruebas funcionales.

— Para ello organizamos un nuevo congreso, QualityConf, dedicado a la calidad como disciplina integral. Cuéntanos más sobre la idea, ¿cuál es el objetivo principal de la conferencia?

Anastasia: Queremos crear una comunidad de personas interesadas en fabricar productos de calidad. Ofrezca una plataforma donde puedan venir, escuchar informes e irse después de la conferencia con una comprensión específica de lo que se debe cambiar para mejorar la calidad.

Hoy en día escucho a menudo consultas de consultoría sobre qué hacer cuando hay problemas con las pruebas y la calidad. Cuando empiezas a comunicarte con los equipos, ves que el problema no está en los evaluadores en sí, sino en cómo está estructurado el proceso. Por ejemplo, cuando los desarrolladores creen que son responsables únicamente de escribir el código, su responsabilidad termina exactamente en el momento en que entregan la tarea a las pruebas.

No todo el mundo piensa en el hecho de que un código mal escrito, de baja calidad y con una arquitectura deficiente amenaza con grandes problemas para el proyecto. No piensan en el coste de los errores, que los errores que acaban en producción pueden suponer grandes costes para la empresa y el equipo. No hay cultura para pensar en esto. Quiero que comencemos a distribuirlo en la conferencia.

Entiendo que esto no es una innovación. Edward Deming, el autor de los 14 principios de la calidad, escribió sobre el coste de un error en el siglo pasado. El aseguramiento de la calidad como disciplina se basa en este libro, pero, desafortunadamente, el desarrollo moderno lo olvida.

— ¿Planeas tocar temas directamente sobre pruebas y herramientas?

Anastasia: Admito que habrá informes sobre herramientas. Existen herramientas bastante universales con las que las empresas y los equipos pueden influir en el producto.

Todos los informes estarán globalmente unidos por una misión común: transmitir a la audiencia que con la ayuda de este enfoque, herramienta, método, proceso, tipo de prueba, hemos influido en la calidad del producto y mejorado la vida del cliente.

Definitivamente no tendremos informes sobre una herramienta por el simple hecho de ser una herramienta. Todos los informes incluidos en el programa estarán unidos por un objetivo común.

— ¿A quién le interesará lo que usted habla, a quién ve como invitados a la conferencia?

Anastasia: Tendremos informes para los desarrolladores que se preocupan por el destino de su proyecto, producto o sistema. Asimismo, será de interés para los evaluadores y, me parece, especialmente para los directivos. Por gerentes me refiero a personas que toman decisiones y también pueden influir en el destino y el desarrollo de un producto, sistema o equipo.

Son personas que se preguntan cómo mejorar la calidad de un producto o sistema. En nuestra conferencia conocerán diversos conjuntos de medidas y podrán comprender qué les pasa ahora y qué es necesario cambiar.

Creo que el criterio principal es comprender que algo anda mal con la calidad y querer influir en ello. Probablemente no podremos llegar a las personas que piensan que esto será suficiente la primera vez.

— ¿Cree que la industria en su conjunto está madura para hablar no sólo de pruebas, sino también de una cultura de calidad?

Anastasia: Creo que he madurado. Ahora muchas empresas se están alejando del enfoque tradicional en cascada hacia Agile. Hay un enfoque en el cliente, las personas en los equipos realmente están empezando a pensar en cómo crear un producto de calidad. Incluso las empresas empresariales están volviendo a centrarse en mejorar la calidad.

A juzgar por la cantidad de peticiones que están surgiendo en la comunidad, creo que ya es el momento. No estoy seguro, por supuesto, de que esta sea una revolución a gran escala, pero me gustaría que esta revolución en la conciencia se produjera.

- ¡Acordado! Inculcaremos cultura y cambiaremos la conciencia.

Conferencia sobre desarrollo de alta calidad de productos TI. CalidadConf состоитися en Moscú el 7 de junio. Usted sabe qué etapas componen un producto de alta calidad, tenemos casos de lucha exitosa contra errores en producción, hemos probado métodos populares en nuestra práctica; necesitamos su experiencia. Enviar su solicitudes antes del 1 de mayo, y el Comité del Programa ayudará a centrar el tema para la integridad general de la conferencia.

Conectarse a charlar, en el que discutimos temas de calidad y la conferencia, suscríbete a Canal de telegramaspara estar al día con las novedades del programa.

Fuente: habr.com