¡Hola!  Estoy encantado de compartir cómo logré mejorar nuestro flujo de lanzamiento en un 20 % mediante la implementación de un rol de control de calidad del sistema.  Dado que mi empresa es una típica empresa de productos, los equipos no se dividen por producto sino por componentes. Gracias a ello, por un lado, conseguimos formar equipos potentes con “poseedores” del conocimiento. Pero, por otro lado, los roles dentro de las unidades están relativamente aislados y diferentes conjuntos de habilidades y experiencia imponen sus limitaciones. Por ejemplo, a veces necesito mover un probador del equipo de backend al frontend o viceversa.  Esto llevó al hecho de que había una cuestión de orquestación efectiva dentro de los equipos de control de calidad y gestión de la interacción entre equipos. Lo cual, por supuesto, finalmente afectó el flujo de lanzamiento.   Liberar el flujo antes de los cambios  Antes de los cambios, nuestro flujo de lanzamiento se veía así:   Una   es un documento que describe las necesidades, expectativas y especificaciones detalladas para una característica, sistema, producto o proyecto específico dentro de una empresa. Sirve como puente entre las partes interesadas del negocio y los equipos de desarrollo o implementación, asegurando una comprensión clara de lo que se debe lograr y cómo se alinea con los   comerciales generales. Debe contener escenarios detallados que describan cómo los usuarios interactuarán con la función. El propietario de la característica (FO) tiene la tarea de formular los requisitos comerciales. especificación de requisitos comerciales (BRS) objetivos  Una   es un documento completo que describe la descripción detallada de lo que se espera que logre un sistema de software. Por ejemplo, cómo y qué comandos interactúan, por qué protocolo y qué datos se transmitirán. Si el equipo que trabaja en la función utiliza una interfaz gráfica, el SRS debe incluir diseños de la función que se está desarrollando. La característica Arquitecto es responsable de escribir SRS. especificación de requisitos de software (SRS)    : un conjunto de casos que el propietario de una función verifica antes de aceptar una función. Después de describir los documentos, procedemos a implementar la función. Cuando el primer equipo termina de desarrollar y probar su parte de la función, se transfiere al segundo equipo. El segundo equipo realiza la integración/desarrollo/prueba y lo pasa a la siguiente unidad. Y así sucesivamente hasta que todos los equipos de componentes que participan en el desarrollo de funciones pasen por este flujo. FO valida la función y se envía a la versión. Plan de acción de calidad (QAP)   Problemas de flujo de liberación  Entonces, todo parece estar bien: documentos, solicitudes, casos de aceptación. Sin embargo, encontramos las siguientes dificultades en este proceso:   Problemas por parte de QA:  La prueba de requisitos comienza solo después del desarrollo. Las tareas que ya han sido implementadas por los desarrolladores, junto con sus requisitos, se entregan al equipo de control de calidad. Pero, como sabemos, puede haber errores en los requisitos.  Encontrar al equipo responsable de un error lleva bastante tiempo porque no siempre está claro qué casos ya han sido probados por otros equipos.  Sin reutilización de artefactos de prueba. Como parte de la prueba de una función, los equipos de control de calidad preparan conjuntos de datos de prueba similares. Pero debido al aislamiento y la estrecha especialización de los equipos, no podían transmitirse estos datos entre sí.   Problemas por parte de FO:  Debido a las muchas funciones, escribir QAP lleva mucho tiempo.  La validación de la función se produce después del desarrollo por parte de todos los equipos. En nuestro caso, esto alarga significativamente el flujo de lanzamiento debido a muchos problemas de integración.  La preparación del entorno de prueba también es precisa debido a la complejidad del producto y el volumen de integraciones entre equipos. Diferentes equipos están probando sus componentes simultáneamente, lo que aumenta los riesgos de combinar, cambiar o eliminar datos.   Control de calidad del sistema en el flujo de lanzamiento actualizado  Para facilitar la interacción efectiva entre equipos entre los equipos de control de calidad y reducir el flujo de lanzamiento, introdujimos el rol del sistema de control de calidad.  Esto ayudó a aliviar la carga de trabajo en la forma de escribir casos de aceptación con FO y aceleró la escritura de escenarios de prueba, introdujo pruebas intermedias del componente de características antes de pasarlo al siguiente equipo y también cambió el trabajo lento de preparar la prueba. entorno al control de calidad del sistema, teniendo en cuenta todos los matices y requisitos de los equipos para integraciones y datos de prueba.  El control de calidad del sistema se ha convertido en un vínculo entre los requisitos técnicos y comerciales de cada función y el producto en su conjunto.  Incorporación para control de calidad del sistema  Para comprender todo el ciclo de lanzamiento, los QA del sistema deben comprender cómo funciona un ciclo de lanzamiento específico en cada equipo. La incorporación suele durar unos tres meses, ya que el control de calidad del sistema pasa de 2 a 3 semanas en cada equipo, comprendiendo sus ciclos de lanzamiento específicos.  Resultados del nuevo proceso  Ahora estamos probando los requisitos de BRS/SRS de los propietarios y arquitectos de funciones. La detección temprana de errores genera ahorros de costos para la empresa.  Hemos establecido un espacio de control de calidad entre equipos, donde los artefactos de prueba se adjuntan a cada función: requisitos comerciales, requisitos técnicos, casos de aceptación, casos de otros equipos, datos de prueba. Esto ayudó significativamente a todos los equipos de control de calidad a estar en un solo contexto y reutilizar los datos de manera efectiva.  Aceleró el proceso de localización de errores porque el control de calidad del sistema tiene conjuntos de casos de prueba de todos los equipos.  Dado que el control de calidad del sistema está escribiendo casos de aceptación para cada equipo, esta es una excelente sugerencia para acelerar y mejorar la calidad de las pruebas.  El proceso de integración se ha vuelto sencillo ya que la función se valida mediante casos de aceptación después de cada comando.  Habiendo eliminado una parte significativa de la carga del FO, se aceleró la aceptación de características y la preparación de un soporte de integración con datos de prueba.  En general, aceleró el flujo de lanzamiento en un 15-20 % y redujo la cantidad de errores de integración a casi la mitad, ya que ahora los detectamos tanto en la etapa de redacción de los requisitos de BRS y SRS como durante las integraciones del equipo en el marco del desarrollo de funciones.  Pruebas felices y productivas!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

QA Head

Este audio es producido en el idioma original de la historia!

Impulsar la productividad: una guía para implementar un nuevo rol de control de calidad para lanzamientos más rápidos

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

El modelo Bitcoin UTXO, impulsando un ecosistema único

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

El modelo Bitcoin UTXO, impulsando un ecosistema único

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps