¡Hola, Habr!
Tenemos un nuevo tema importante: el desarrollo de productos IT de calidad. Hablamos a menudo en HighLoad++ sobre cómo hacer que los servicios sobrecargados sean rápidos, y en Frontend Conf sobre la creación de una interfaz de usuario increíble que no se ralentice. Regularmente discutimos temas sobre pruebas, y en DevOpsConf sobre la integración de diferentes procesos, incluyendo las pruebas. Sin embargo, no hemos abordado lo que se puede considerar calidad en general y cómo trabajar de manera integral en ello.
Lo corregiremos a — fomentaremos la cultura de pensar en la calidad del producto final para el usuario en cada etapa del desarrollo. Cultivaremos el hábito de no centrarnos únicamente en nuestra área de responsabilidad y asociar la calidad no solo con los testers.
Debajo hablaremos con la jefa del comité del programa, líder de pruebas en Tinkoff.Biz, creadora de la comunidad QA de habla rusa. Anastasia Aseeva-Nguen sobre el estado de la industria QA y la misión de la nueva conferencia.
— Hola Nastya, cuéntame un poco sobre ti.
Anastasia: Dirijo las pruebas en el banco y soy responsable de un equipo muy grande: somos más de 90 personas. Nuestra línea de negocio es importante, y nos encargamos del ecosistema para entidades legales.
Estudié en la facultad de matemáticas y originalmente quería ser programadora. Pero cuando apareció una oferta interesante, decidí probarme como tester. Aunque parezca extraño, resultó ser mi vocación. Ahora veo todo mi trabajo en esta industria.
Soy una ferviente defensora de la disciplina de Quality Assurance. Me importa qué productos se crean, cómo se percibe la calidad en la empresa, en el equipo y, en general, en el proceso de desarrollo.
Me resulta evidente que la comunidad en este ámbito no está lo suficientemente madura, al menos en Rusia. No siempre entendemos que garantizar la calidad no es solo la cuestión de probar la aplicación para que cumpla con los requisitos. Quisiera cambiar esta situación.
— Usas los términos Quality Assurance y pruebas. Para el común de la gente, estos dos términos a menudo se cruzan. ¿Cuáles son sus diferencias, si se profundiza?
Anastasia: 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ó la ola de subcontratistas que proporcionan testers a las empresas, la prueba se redujo a un único tipo.
En la mayoría de los casos, se limitan solo a las pruebas funcionales: verifican que lo que han codificado los desarrolladores cumpla con la especificación y todo.
— Cuéntame, por favor, ¿qué otras disciplinas de aseguramiento de calidad existen? ¿Qué más, además de las pruebas, se incluye aquí?
Anastasia: El Aseguramiento de Calidad es, ante todo, sobre crear un producto de calidad. Es decir, nos hacemos la pregunta de qué atributos de calidad debe tener nuestro producto. En consecuencia, si comprendemos esto, podemos identificar quién influye en estos atributos de calidad. No importa, si es un desarrollador, un gerente de proyectos o un product owner. — es la persona que influye en el desarrollo del producto, en su backlog, en su estrategia.
El tester comienza a comprender mejor su papel. Él entiende que su tarea no es solo probar la conformidad con los requisitos, sino también probar los requisitos, cuestionar las formulaciones que provienen del product owner, desenterrar todos los requisitos implícitos 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á satisfecho y comprenderá que la empresa cuyo producto está utilizando realmente se preocupa por sus intereses y no trabaja con el principio de 'solo lanzar una característica'.
— 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ón de productos, ¿verdad?
Anastasia: 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 Ágiles. Su definición indica claramente que es un enfoque ágil para las pruebas que incluye un conjunto específico de prácticas. Todo el equipo es responsable de implementar este enfoque, no es necesario que haya un probador en el equipo. Todo el equipo está orientado a entregar valor al cliente y a asegurarse de que ese valor cumpla con sus expectativas.
— Entonces, ¿la calidad se intersecta casi con todas las disciplinas relacionadas, imponiendo límites a todo a su alrededor?
Anastasia: Correcto. Cuando pensamos en crear un producto de calidad, comenzamos a considerar varios atributos de calidad. Por ejemplo, ¿cómo verificar que realmente hemos creado una característica que necesita nuestro cliente?
Aquí entra en juego un tipo de pruebas llamado UAT (pruebas de aceptación de usuario). Lamentablemente, en Rusia este tipo de pruebas se practica raramente, aunque a veces está presente en equipos SCRUM como demostración para el cliente final. En empresas extranjeras, este tipo de pruebas es bastante común. 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ón de inmediato: si el producto cumple con las expectativas y resuelve el problema. Solo después de esto se realiza la escalabilidad para todos los demás clientes.
Es decir, estamos enfocados en el negocio, en el cliente final, pero al mismo tiempo no olvidamos 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 características rápidamente y cumplir con las expectativas del cliente. Pueden surgir muchos errores al intentar escalar, o al intentar realizar una refactorización, podemos romper algo. Todo esto influye en la satisfacción del cliente.
Desde este punto de vista, la arquitectura debe ser tal que podamos escribir código limpio que permita realizar cambios rápidamente 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íodos de prueba.
— Entonces ya están involucrados desarrolladores, arquitectos, gerentes de producto, gerentes de producto, y los mismos probadores. ¿Quién más está involucrado en el proceso de aseguramiento de la calidad?
Anastasia: Ahora supongamos que ya hemos entregado la función al cliente. Es evidente que debemos supervisar la calidad del producto, incluso cuando ya está en producción. En esta etapa, pueden aparecer situaciones con escenarios poco obvios, conocidos como errores.
La primera pregunta es: ¿cómo manejamos estos errores después de haber lanzado el producto? ¿Cómo respondemos, por ejemplo, a la carga? El cliente no estará muy satisfecho si la página tarda más de 30 segundos en cargar.
Aquí entra en juego la operación o, como se dice ahora, DevOps. De hecho, son las personas responsables de la operación del producto una vez que ya está en producción. Esto incluye varios tipos de monitoreo. Incluso existe un subtipo de prueba: la prueba en producción, donde nos permitimos no probar algo antes del lanzamiento y lo probamos directamente en producción. Se trata de una serie de actividades desde el punto de vista de la organización de la infraestructura, que permiten reaccionar rápidamente a un incidente, influir en él y corregirlo.
La infraestructura también es importante. A menudo hay situaciones cuando durante las pruebas, no se puede confirmar que realmente tenemos todo lo que quisiéramos darle al cliente. Lanzamos en producción y comenzamos a detectar situaciones poco obvias. Y todo porque la infraestructura en las pruebas no coincide con la infraestructura en producción. De aquí surge un nuevo tipo de prueba: la prueba de infraestructura. Estas son diversas configuraciones, ajustes, migración de bases de datos, etc.
De ahí surge la pregunta: tal vez el equipo debería usar infraestructura como código.
Creo firmemente que la infraestructura influye directamente en la calidad del producto.
Espero que haya una presentación en la conferencia con un caso real. Escríbanos si están dispuestos a compartir su experiencia sobre cómo la infraestructura como código influye en la calidad. La infraestructura como código permite verificar más fácilmente todas las configuraciones y probar lo que de otra manera sería simplemente imposible. Por lo tanto, la operación también se involucra en el proceso de desarrollo de un producto de calidad.
— ¿Y qué pasa con la analítica y la documentación?
Anastasia: Esto se relaciona más 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écnicos. Reciben la tarea de redactar una especificación y la llevan a cabo, por ejemplo, durante un mes.
Se ha demostrado en múltiples ocasiones que escribir esta documentación 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ás, esto puede introducir vulnerabilidades. Parece que hemos escrito código de referencia, pero luego hacemos cambios que rompen la arquitectura perfectamente planificada.
Al final, el producto no resulta ser de buena calidad, porque ya han aparecido parches en la arquitectura, el código en algunas áreas no está suficientemente cubierto por pruebas, ya que los plazos aprietan y hay que cerrar errores rápidamente. Todo esto se debe a que en la especificación inicial no se tuvieron en cuenta todos los aspectos que debían implementarse.
Los desarrolladores no son villanos y no escriben intencionadamente código con errores.
Si desde un principio hubiéramos elaborado una especificación que abarcara todos los aspectos necesarios, todo se habría implementado tal como debía. Pero eso es una utopía.
Probablemente, no sea posible escribir una especificación perfecta de 100 páginas. Por lo tanto, es necesario pensar en formas alternativas de redactar documentación,de especificación, de planteamiento de tareas, que nos acerquen a que los desarrolladores hagan exactamente lo que se necesita.
Aquí se me vienen a la mente enfoques de Agile: historias de usuario con criterios de aceptación. Esto es más aplicable para equipos que se desarrollan en pequeñas iteraciones.
— ¿Qué hay sobre las pruebas de usabilidad, la comodidad de uso del producto, el diseño?
Anastasia: Este es un punto muy importante, porque en el equipo hay diseñadores. La mayoría de las veces, se utilizan diseñadores como un servicio: ya sea un departamento de diseñadores o un diseñador en outsourcing. Frecuentemente, ocurren situaciones en las que parece que el diseñador escuchó al product owner y hizo lo que entendió. Pero cuando se entra en la iteración, se descubre que en realidad no se hizo lo que se esperaba: el diseñador olvidó algo, no pensó completamente en el comportamiento, porque no está en el equipo y no está en contexto, o el desarrollador front-end no entendió completamente su diseño. Puede que se necesiten varias iteraciones solo debido a problemas de comprensión del diseño por parte del desarrollador front-end.
Además, hay otro problema. Actualmente, los sistemas de diseño están ganando popularidad. Están en auge, pero los beneficios que aportan no son del todo evidentes.
Me encuentro con la opinión de que los sistemas de diseño, por un lado, simplifican el desarrollo, pero por el otro, imponen muchas restricciones en la interfaz.
Al 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.
Me parece que vale la pena prestar atención a este tema y reflexionar si realmente, al intentar simplificar el trabajo de diseño, estamos resolviendo el dolor del cliente.
— Surgen sorprendentemente muchos temas relacionados con la calidad del software. ¿Hay una conferencia en Rusia donde se puedan discutir todos ellos?
Anastasia: Hay una conferencia de pruebas muy antigua, que este año se llevará a cabo por 25ª vez y se llama Conferencia de Aseguramiento de la Calidad SQA Days. Principalmente, en ella se discuten herramientas y enfoques específicos de pruebas para los evaluadores funcionales. Generalmente, en las ponencias de SQA Days se abordan profundamente áreas específicas en la zona de responsabilidad de los propios evaluadores, pero no eventos complejos.
Esto ayuda mucho a entender las diferentes herramientas y enfoques sobre cómo probar bases de datos, API, etc. Pero, por un lado, no motiva a involucrar en la creación de un producto de mayor calidad no solo las pruebas. Y, 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, 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 área 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.
Me gustaría que aquí en Rusia los chicos también comenzaran a pensar que en las pruebas funcionales la industria no termina.
— Por eso estamos organizando la nueva conferencia QualityConf, que se dedica a la calidad como una disciplina integral. Cuéntame 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. Ofrecer un espacio al que puedan venir, escuchar charlas y salir después de la conferencia con una comprensión concreta de lo que necesitan cambiar en sí mismos para mejorar la calidad.
A menudo escucho solicitudes de consultoría sobre qué hacer cuando hay problemas con las pruebas y la calidad. Cuando comienzas a hablar con los equipos, ves que el problema no está en los propios testers, sino en cómo se establece el proceso. Por ejemplo, cuando los desarrolladores creen que son responsables solo de escribir código, su responsabilidad termina en el momento exacto en que entregan la tarea para pruebas.
No todos piensan que un código 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ón 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.
Entiendo que esto no es una innovación. 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.
— ¿Y planean tocar temas directamente relacionados con las pruebas y herramientas?
Anastasia: Admito que habrá charlas sobre herramientas. Existen herramientas bastante universales que las empresas y equipos pueden utilizar para influir en el producto.
Todas las charlas estarán globalmente unidas por una misión común: transmitir a la audiencia que, con este enfoque, herramienta, método, proceso o tipo de prueba, hemos influido en la calidad del producto y mejorado la vida del cliente.
No habrá charlas sobre herramientas por el simple hecho de tener herramientas. Todas las presentaciones que se incluyan en el programa tendrán un objetivo común.
— ¿A quién le interesará lo que estás diciendo, a quién ves como invitados de la conferencia?
Anastasia: Tendremos presentaciones para desarrolladores que se preocupan por el futuro de su proyecto, producto o sistema. También será 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.
Son personas que se preguntan cómo mejorar la calidad del producto o del sistema. En nuestra conferencia, aprenderán sobre diferentes conjuntos de actividades y podrán comprender qué les está fallando en este momento, qué necesitan cambiar.
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á bien así desde el primer intento.
— ¿Qué piensas, ha madurado la industria en su conjunto para hablar no solo sobre testing, sino sobre la cultura de calidad?
Anastasia: Creo que sí. Actualmente, muchas empresas se están alejando del enfoque tradicional Waterfall hacia Agile. Se está orientando hacia el cliente, y las personas en los equipos realmente comienzan a pensar en cómo crear un producto de calidad. Incluso en empresas del tipo enterprise, hay una reorientación hacia la mejora de la calidad.
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ón a gran escala, pero me gustaría que este cambio de mentalidad ocurriera.
— ¡De acuerdo! Vamos a fomentar la cultura y transformar la mentalidad.
Conferencia sobre el desarrollo de productos IT de calidad se llevará a cabo en Moscú el 7 de junio. Sabes, de qué etapas se compone un producto de calidad, tenemos casos de éxito en la lucha contra errores en producción, hemos probado en nuestra práctica metodologías populares — necesitamos tu experiencia. tu solicitud antes del 1 de mayo, y el Comité de Programa ayudará a enfocar el tema para la coherencia general de la conferencia.
Únete al , donde discutimos asuntos de calidad y la conferencia, suscríbete a , para estar al tanto de las noticias del programa.
Fuente: habr.com
