Hola Habr!
Tenemos un nuevo tema importante: el desarrollo de alta calidad de productos de TI. A menudo hablamos en HighLoad ++ sobre cómo hacer que los servicios ocupados sean rápidos, y en Frontend Conf, una interfaz de usuario genial que no se ralentiza. Regularmente tenemos temas sobre pruebas y DevOpsConf sobre la combinación de diferentes procesos, incluidas las pruebas. Pero sobre qué calidad se puede llamar en su conjunto y cómo trabajar en ella de manera integral, no.
Vamos a arreglarlo en
QualityConf : desarrollaremos una cultura de pensar acerca de la calidad del producto final para el usuario en cada etapa de desarrollo. El hábito de no obsesionarse con su área de responsabilidad y asociar la calidad no solo con los evaluadores.
Bajo el corte, hablaremos con el jefe del comité del programa, el jefe de pruebas en Tinkoff
Business , el creador de la comunidad de control de calidad de habla rusa
Anastasia Aseeva-Nguyen sobre el estado de la industria de control de calidad y la misión de la nueva conferencia.
- Nastya, hola. Cuéntanos sobre ti.
Anastasia : Lidero las pruebas en el banco, soy responsable de un equipo muy grande, somos más de 90. Tenemos una importante línea de negocios, somos responsables del ecosistema de las personas jurídicas.
Estudié en mehmat e inicialmente quería ser programador. Pero cuando tuve una oferta interesante, decidí probarme como probador. Por extraño que parezca, esto resultó ser mi vocación. Ahora veo todo mi trabajo en esta industria.
Soy un ardiente adherente de la disciplina de Garantía de Calidad. No me importa qué productos se crean, cómo se relacionan con la calidad en la empresa, en el equipo y, en principio, en el proceso de desarrollo.
Para mí es obvio 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 cumplir con los requisitos. Me gustaría cambiar esta situación.
- Usas las palabras Garantía de calidad y pruebas. A los ojos del hombre promedio, estos dos términos se cruzan muy a menudo. ¿En qué se diferencian si cavas profundamente?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, hay muchos tipos de pruebas, y diferentes personas son responsables de los diferentes tipos de pruebas. Pero en Rusia, cuando hubo una ola de subcontratistas que suministraron probadores a la compañía, las pruebas se redujeron a una sola vista.
En la mayoría de los casos, se limitan solo a las pruebas funcionales: verifican que lo que los desarrolladores han compilado cumple con las especificaciones y eso es todo.
- Dime, por favor, ¿qué otras disciplinas de aseguramiento de la calidad hay? ¿Qué más, además de las pruebas, incluye?Anastasia : Aseguramiento de la calidad se trata, en primer lugar, de 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, el
desarrollador, gerente de proyecto o gerente de producto es una persona que influye en el desarrollo de un producto, su cartera de pedidos, su estrategia.
El probador es más consciente de su papel. Él entiende que su tarea no es solo evaluar el cumplimiento de los requisitos, sino también evaluar los requisitos, cuestionar el lenguaje que proviene del tecnólogo del producto y revelar todos los requisitos y expectativas implícitos del cliente. Cuando entregamos una nueva funcionalidad a nuestro cliente, debemos realmente cumplir con sus expectativas y resolver su dolor. Si pensamos en todos los atributos de calidad, el cliente estará satisfecho y comprenderá que la empresa cuyo producto utiliza realmente se preocupa por sus intereses y no funciona según el principio de "solo lanzar una función".
- Parece que lo que acaba de describir es tarea del tecnólogo del producto. Esto, en principio, no se trata de pruebas y no de calidad: generalmente se trata de la gestión de productos, ¿no?Anastasia : Incluyendo. El aseguramiento de la calidad no es la disciplina de la que una persona específica es responsable. Ahora hay una dirección popular en las pruebas, un enfoque llamado
Agile Testing . En su definición, parece sencillo que este sea un enfoque de equipo para las pruebas, que incluye un cierto conjunto de prácticas. Todo el equipo es responsable de implementar este enfoque, ni siquiera es necesario que un probador esté en el equipo. Todo el equipo está enfocado en entregar valor al cliente, y para que este valor cumpla con sus expectativas.
- ¿Resulta que la calidad se cruza con casi todas las disciplinas circundantes, imponiendo un marco en todo lo que hay a su alrededor?Anastasia : Cierto. Cuando pensamos en lo que queremos crear un producto de calidad, comenzamos a pensar en los diversos atributos de calidad. Por ejemplo, cómo verificar que realmente hicimos una función que nuestro cliente necesita.
Este tipo de prueba aparece como
UAT (prueba de aceptación del usuario). Desafortunadamente, en Rusia rara vez se practica, pero a veces está presente en los equipos SCRUM, como una demostración para el cliente final. En las empresas extranjeras, este es un tipo de prueba bastante común. Antes de abrir la funcionalidad a todos los clientes, primero hacemos UAT, es decir, invitamos al usuario final que realiza las pruebas e inmediatamente brinda retroalimentación: ¿el producto realmente cumple con las expectativas y resuelve el dolor? Solo después de esto es la escala a todos los demás clientes.
Es decir, nos centramos en los negocios, en el cliente final, pero al mismo tiempo
no nos olvidamos de la tecnología . La calidad del producto también depende en gran medida de la tecnología. Si tenemos una arquitectura pobre, no podremos lanzar características rápidamente y cumplir con las expectativas del cliente. Puede haber muchos errores al intentar escalar, o al intentar refactorizar, podemos romper algo. Todo esto afectará la satisfacción del cliente.
Desde este punto de vista, la arquitectura debe ser tal que podamos escribir código limpio que nos permita hacer cambios rápidamente y no tener miedo de romperlo todo. Para que las iteraciones de refinamiento no se alarguen durante varios meses simplemente porque tenemos muchos legados y necesitamos hacer largos pasos de prueba.
- En total, los desarrolladores, arquitectos, expertos en productos, gerentes de productos, probadores mismos ya están involucrados. ¿Quién más participa en el proceso de garantía de calidad?Anastasia : Ahora imagine que ya hemos entregado una función a un cliente. Obviamente, debe controlar la calidad del producto y cuándo ya está en producción. En esta etapa, pueden aparecer situaciones con escenarios no obvios, los llamados errores.
La primera pregunta es ¿cómo trabajamos con estos errores después de que ya hayamos lanzado el producto? ¿Cómo reaccionamos, por ejemplo, a la carga? El cliente no estará muy satisfecho si la página se carga durante más de 30 segundos.
Aquí es
donde entra en juego
la explotación o, como lo llaman ahora,
DevOps . De hecho, se trata de personas responsables del funcionamiento del producto cuando ya está a la venta. Esto incluye varios tipos de monitoreo. Incluso hay un subtipo de prueba: prueba en el producto, cuando nos permitimos no probar algo antes de lanzarlo y probarlo inmediatamente en el producto. Esta es una serie de medidas desde el punto de vista de la organización de la infraestructura que le permiten responder rápidamente a un incidente, influirlo y corregirlo.
La infraestructura también es importante. A menudo hay situaciones en las que durante la prueba es imposible asegurarse de que realmente tengamos todo lo que nos gustaría darle al cliente. Llegamos a la producción y comenzamos a detectar situaciones no obvias. Y todo porque la infraestructura en la prueba no coincide con la infraestructura en el producto. Esto conduce a un nuevo tipo de prueba:
pruebas de infraestructura . Estas son varias configuraciones, configuraciones, migración de bases de datos, etc.
Esto plantea la pregunta: quizás el equipo necesite usar la infraestructura como código.
Creo que la infraestructura afecta directamente la calidad del producto.
Espero que la conferencia tenga un informe con un caso real. Escríbanos si está listo para saber por 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 algo que de otro modo sería simplemente imposible. Por lo tanto, la explotació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 empresas, inmediatamente nos vienen a la mente personas como analistas y analistas de sistemas. A veces se les llama escritores técnicos. Reciben una tarea para escribir una especificación y completarla, por ejemplo, un mes.
Se ha demostrado repetidamente que escribir dicha documentación conduce a iteraciones muy largas de desarrollo y largas iteraciones de refinamiento, porque durante el proceso de prueba se detectan errores, comienzan los retornos. Como resultado, hay muchos bucles que aumentan el costo de desarrollo. Además, esto podría introducir vulnerabilidades. Parece que hemos escrito el código de referencia, pero luego hicimos cambios que rompen la arquitectura perfectamente pensada.
El resultado es un producto de no tan alta calidad, ya que los parches ya han aparecido en la arquitectura, el código en algunos lugares no está suficientemente cubierto por las pruebas, debido a que los plazos se están agotando, debe cerrar todos los errores más rápido. Y todo porque en la especificación original no se tuvieron en cuenta todos los puntos que deben implementarse.
Los desarrolladores no son plagas y no escriben específicamente código con errores.
Si inicialmente pensáramos en una especificación en la que se cubrirían todos los puntos necesarios, entonces todo se implementaría exactamente como debería. Pero esto es utopía.
Probablemente sea imposible escribir una especificación perfecta de 100 páginas. Por
lo tanto,
debemos pensar en formas alternativas de escribir documentación , especificar y establecer tareas que nos acerquen al hecho de que el desarrollador hace exactamente lo que necesitamos.
Aquí vienen los enfoques ágiles: historias de usuarios con criterios de aceptación. Esto es más aplicable para equipos que se desarrollan en pequeñas iteraciones.
- ¿Qué pasa con las pruebas de usabilidad, usabilidad del producto, diseño?Anastasia : Este es un punto muy importante, porque hay diseñadores en el equipo. Muy a menudo, los diseñadores lo usan como un servicio, ya sea el departamento de diseño o el diseñador subcontratado. A menudo hay situaciones en las que el diseñador parece haber escuchado al tecnólogo del producto e hizo lo que entendió. Pero cuando comenzamos la iteración, resulta que lo que realmente no se esperaba se hizo: el diseñador olvidó algo, no pensó en el comportamiento porque no estaba en el equipo o en el contexto, o el desarrollador front-end no lo entendió completamente diseño Puede tomar varias iteraciones solo porque hay un problema con la comprensión del diseño por parte del desarrollador front-end.
Además hay otro problema. Los sistemas de diseño están ganando popularidad. Están exagerados, pero los beneficios de ellos no son del todo obvios.
Me encuentro con la opinión de que los sistemas de diseño, por un lado, simplifican el desarrollo y, por otro lado, imponen muchas restricciones en la interfaz.
Como resultado, no creamos una característica que el cliente quiera recibir, sino una que sea conveniente para nosotros, porque ya tenemos ciertos cubos desde los cuales podemos hacerla.
Me parece que debe prestar atención a este tema y pensar si realmente resolvemos el dolor del cliente en un intento de simplificar el trabajo de diseño.
- Resulta sorprendentemente muchos temas relacionados con el aseguramiento de la calidad. ¿Hay una conferencia en Rusia en la que todos puedan ser discutidos?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 SQA Days. Discute principalmente herramientas y enfoques de prueba específicos para probadores funcionales. Como regla general, los informes sobre los días SQA examinan a fondo áreas específicas en el área de responsabilidad de los probadores, pero no eventos complejos.
Ayuda mucho a comprender varias herramientas y enfoques, cómo probar bases de datos, API, etc. Pero al mismo tiempo, por un lado, no motiva involucrar no solo las pruebas en la creación de un mejor producto. Por otro lado, los evaluadores no se involucran más en el proceso para pensar en el objetivo global del producto y su componente comercial.
Dirijo un gran departamento, realizo muchas entrevistas, lo que de hecho nos permite presentar el estado de la industria en su conjunto. Como regla, nuestros muchachos trabajan en empresas y tienen un área clara de responsabilidad. Los colegas que trabajan en proyectos extranjeros utilizan diferentes tipos de pruebas: ellos mismos pueden hacer pruebas de estrés, pruebas de rendimiento e incluso a veces pruebas de seguridad, porque realmente ayudan al equipo a proporcionar calidad al producto.
Me gustaría que nuestros muchachos en Rusia también comiencen a pensar que la industria no termina con las pruebas funcionales.
- Para esto estamos organizando una nueva conferencia QualityConf, que se dedica a la calidad como disciplina holística. 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 hacer productos de calidad. Ofrezca una plataforma donde puedan venir, escuchar informes y salir después de la conferencia con una comprensión concreta de lo que debe cambiarse en su lugar para mejorar la calidad.
A menudo, ahora escucho una solicitud de consulta sobre qué hacer cuando hay problemas con las pruebas, con la calidad. Cuando comienzas a hablar con los equipos, ves que el problema no está en los probadores, sino en la forma en que se construye el proceso. Por ejemplo, cuando los desarrolladores creen que solo son responsables de escribir el código, su responsabilidad termina exactamente en el momento en que transfirieron la tarea a la prueba.
No todos piensan que un código de baja calidad mal escrito con una arquitectura pobre plantea grandes problemas para el proyecto. No piense en el costo de los errores, ya que los errores que se introdujeron en la producción pueden generar grandes costos para la empresa y el equipo. No hay cultura para pensarlo. Quiero que comencemos a distribuirlo en la conferencia.
Entiendo que esto no es una innovación. Edward Deming, autor de 14 postulados de calidad, escribió sobre el costo del error en el siglo pasado. Este libro se basa en el aseguramiento de la calidad como disciplina, pero, desafortunadamente, el desarrollo moderno lo olvida.
- ¿Planea tocar temas directamente sobre pruebas y herramientas?Anastasia : Admito que habrá informes sobre las herramientas. Existen herramientas bastante universales por las cuales las empresas y los equipos pueden influir en un producto.
Todos los informes estarán unidos globalmente por una misión común: transmitir a la audiencia que con 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 la herramienta por el bien de la herramienta. Todos los informes que entran en el programa estarán unidos por un objetivo común.
- ¿Quién estará interesado en lo que estás hablando, a quién ves como invitados de la conferencia?Anastasia : Tendremos informes para desarrolladores que no sean indiferentes al destino de su proyecto, producto, sistema. Será igualmente interesante para los evaluadores y, me parece, especialmente para los gerentes. Por gerentes, me refiero a las personas que toman decisiones y pueden influir en el destino y el desarrollo de un producto, sistema y equipo también.
Estas son personas que se preguntan cómo mejorar la calidad de un producto, sistema. En nuestra conferencia, aprenderán sobre varios complejos de eventos y podrán entender lo que no está bien con lo que debe cambiarse.
Creo que el criterio principal es entender que algo está mal con la calidad y querer influir en ella. Probablemente, la primera vez que lleguemos a personas que creen que funcionará, no tendremos éxito.
- ¿Crees que la industria en su conjunto ha madurado para hablar no solo de pruebas, sino también de una cultura de calidad?Anastasia : Creo que he madurado. Ahora muchas compañías se están alejando del enfoque tradicional de Waterfall 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 en empresas-empresas, hay una reorientación para mejorar la calidad.
A juzgar por la cantidad de consultas que surgen en la comunidad, creo que es hora. No estoy seguro, por supuesto, de que sea una revolución a gran escala, pero me gustaría que ocurriera este cambio de conciencia.
- De acuerdo! Inculcaremos una cultura y volveremos la mente.Una conferencia sobre el desarrollo de calidad de los productos IT QualityConf se llevará a cabo en Moscú el 7 de junio . Ya sabe en qué etapas se compone un producto de alta calidad, hay casos de lucha exitosa con errores en la tienda en existencia, hemos probado métodos populares en nuestra práctica: necesitamos su experiencia. Envíe sus solicitudes antes del 1 de mayo , y el Comité del Programa ayudará a enfocar el tema para la integridad general de la conferencia.
Conéctese a un chat en el que discutiremos problemas de calidad y una conferencia, suscríbase al canal Telegram para mantenerse al tanto de las noticias del programa.