Descargo de responsabilidad: esta es una traducción de un artículo . Todos los derechos pertenecen al autor del artículo original y a la empresa Miro.
Soy ingeniero de control de calidad en Miro . Permítanme contarles acerca de nuestro experimento de transferir tareas de prueba parciales a los desarrolladores y de transformar el rol de Ingeniero de Pruebas en QA (Garantía de calidad).
Primero brevemente sobre nuestro proceso de desarrollo. Tenemos versiones diarias para el lado del cliente y de 3 a 5 versiones semanales para el lado del servidor. El equipo tiene más de 60 personas repartidas en 10 equipos de Scrum funcional.
Estoy trabajando en el equipo de integración. Nuestras tareas son:
- Integración de nuestro servicio en productos externos.
- Integración de productos externos en nuestro servicio.
Por ejemplo, hemos integrado Jira . Tarjetas Jira: representación visual de las tareas, por lo que es útil trabajar con tareas que no abren Jira en absoluto.
Como comienza el experimento
Todo comienza con un problema trivial. Cuando alguien de Test Engineers tuvo una baja por enfermedad, el rendimiento del equipo se degradó significativamente. El equipo continuó trabajando en tareas. Sin embargo, cuando se alcanzó el código, la tarea de la fase de prueba se mantuvo. Como resultado, la nueva funcionalidad no alcanzó la producción a tiempo.
Ir de vacaciones por Test Engineer es una historia más compleja. Él / ella necesita encontrar otro ingeniero de pruebas que esté listo para tomar tareas adicionales y llevar a cabo el intercambio de conocimientos. Ir de vacaciones por dos ingenieros de prueba al mismo tiempo no es un lujo aplicable.
Hemos comenzado a pensar cómo resolver este problema. Descubrimos que la causa raíz es que la fase de prueba es un cuello de botella. Permítanme compartir algunos ejemplos de estos.
Caso 1: Tarea ping-pong
Soy Yo y Desarrollador. Cada uno tiene sus propias tareas. El desarrollador ha terminado una tarea y me la envía para probarla. En cuanto a que esta nueva tarea tiene mayor prioridad, la estoy activando. Encontré defectos, los levanté en Jira y devolví la tarea al desarrollador para que los arregle.
Vuelvo a las tareas anteriores. El desarrollador vuelve de las tareas actuales a la tarea devuelta. Después de las correcciones, el desarrollador me devuelve la tarea para volver a realizar la prueba. Encontré el defecto nuevamente y devuelvo la tarea nuevamente. Esto podría ser largo y continuo.
Como resultado, el tiempo acumulado en tareas aumenta en poco tiempo y, por lo tanto, en el tiempo de comercialización, lo cual es fundamental para nosotros como empresa de productos. Hay pocas razones para aumentar el esfuerzo:
- Tarea en constante movimiento entre el ingeniero de pruebas y el desarrollador
- Tarea que pasa tiempo esperando al ingeniero de prueba o desarrollador
- El desarrollador y el ingeniero de pruebas tienen que cambiar frecuentemente el contexto entre tareas, lo que causa pérdidas adicionales de tiempo y energía mental.
Caso 2: la cola de tareas está aumentando
Hay algunos desarrolladores en nuestro equipo Scrum. Me envían tareas para que las pruebe regularmente. Eso forma una cola de tareas que procedo según las prioridades.
Así es como hemos trabajado durante aproximadamente un año. Sin embargo, durante este tiempo la compañía crece. Se aumentó el número de proyectos y desarrolladores y, por lo tanto, el número de tareas para realizar pruebas. Al mismo tiempo, todavía era el único ingeniero de pruebas en nuestro equipo Scrum y no pude aumentar mi rendimiento a veces. Como resultado, las tareas cada vez más atascadas en la cola para las pruebas y el proceso de ping-pong también aumentaron el tiempo de espera.
De repente me enfermé. La entrega de nuevas características de nuestro equipo Scrum a la producción se detuvo por completo.
¿Qué equipo debe hacer en esta situación? Es posible solicitar la ayuda de un ingeniero de pruebas para otro equipo. Sin embargo, otro ingeniero de pruebas no está en contexto y no recibió la transferencia de conocimiento por adelantado, lo que afectará negativamente la calidad y el cronograma en ambos equipos.
El resultado de ambos casos en el mismo: los equipos también dependen de los ingenieros de prueba:
- La velocidad del equipo está limitada por la velocidad del ingeniero de pruebas.
- No se puede aumentar la cantidad de desarrolladores sin agregar ingenieros de prueba porque no tiene sentido acelerar el desarrollo si todas las tareas desarrolladas están atascadas en la cola para las pruebas.
- Mientras que el ingeniero de pruebas verifica la tarea después del desarrollador, la responsabilidad del desarrollador por una calidad está disminuyendo.
- Si Test Engineer no está disponible, el proceso de entrega está sufriendo.
¿Vamos a agregar ingenieros de prueba?
La idea obvia: aumentemos la cantidad de ingenieros de prueba. Eso podría funcionar hasta cierto momento: la cantidad de tareas aumentará, pero es imposible aumentar la cantidad de ingenieros de prueba continuamente. Será demasiado costoso e ineficiente.
Más eficiente es mantener la velocidad y la calidad con los recursos actuales. Es por eso que hemos decidido lanzar un experimento que ayudará a los equipos a crear funcionalidades con calidad incorporada asumiendo riesgos y esquinas. Llamamos a este experimento "Transform tester to QA" porque se trata de la transformación de un rol de probadores de monos que buscan errores a QA que influyen conscientemente y proporcionan calidad en todas las fases de SDLC.
Mejoremos los procesos de desarrollo.
Objetivos del experimento:
- Elimine la dependencia del equipo de ingenieros de prueba que no pierden calidad y tiempo.
- Mejore el nivel de garantía de calidad proporcionado por QA y equipos.
El primer paso importante fue cambiar la mentalidad del equipo. Todo se esperaba que los ingenieros de pruebas se preocuparan exclusivamente y fueran responsables de la calidad.
Nuestra idea era que agregar esfuerzo en la preparación y verificación de tareas ayudaría a reducir el número de iteraciones de ping-pong. Por lo tanto, permitirá ofrecer una nueva funcionalidad en la producción manteniendo niveles de velocidad y calidad aceptables o incluso mejorarlos.
Mi equipo Scrum junto con ingenieros de pruebas de otros equipos habían creado un nuevo proceso. Hemos trabajado en consecuencia este nuevo proceso durante medio año y solucionamos algunos problemas que aparecen durante este tiempo y ahora el proceso se ve así:
- Presentación sobre el enunciado de la tarea.
- Solución técnica y escenario de prueba.
- Desarrollo y verificación.
- Lanzamiento
Declaración de tarea
Propietario del producto presente declaración de tarea para un equipo. El equipo analiza la declaración de la tarea para descubrir casos de esquina desde el punto de vista técnico y del producto. Si aparecen preguntas para aclaración o investigación, se realiza un seguimiento como una tarea separada con tiempo dedicado en un sprint.
Solución técnica
Como resultado de Analysis, hay una solución técnica creada por uno o pocos desarrolladores. Todos los compañeros de equipo relevantes junto con el control de calidad deben revisarlo y acordarlo. La solución técnica contiene el propósito de la solución, los bloques funcionales del producto que se verán afectados y la descripción de los cambios de código planificados.
Dicha solución técnica permite descubrir una solución más ligera y más adecuada basada en la experiencia de los participantes relevantes del proceso de desarrollo. Al tener una solución técnica detallada, es más fácil descubrir y evitar problemas de bloqueo, es más fácil realizar una revisión de código.
Aquí hay un ejemplo de algunos bloques en Solución técnica:
Descripción de la tarea
¿Se están introduciendo nuevas entidades o enfoques en el sistema?
En caso afirmativo, estos se describen junto con la explicación de por qué es imposible resolver la tarea con los enfoques actuales.
¿Están cambiando las interacciones de los servidores dentro de un clúster? ¿Se están introduciendo nuevos roles de clúster?
¿Está cambiando el modelo de datos?
Para el servidor se trata de objetos y modelos.
Si el modelo de datos es complejo, podría representarse en un diagrama UML o en una descripción de texto.
¿Está cambiando la interacción cliente-servidor?
Descripción de los cambios. Si es una API, ¿podríamos publicarla? No se olvide del manejo de excepciones, es decir, registre los motivos correctos.
Escenario de prueba
Paralelamente, los desarrolladores o QA están creando escenarios de prueba asumiendo casos de esquina y posibles puntos problemáticos. Si es creado por Developer, entonces QA debe revisarlo en su totalidad. Si QA crea el Escenario de prueba, entonces el Desarrollador debe revisar y confirmar que está claro cómo implementar cada punto. El equipo también evalúa los escenarios de prueba sobre la corrección.
Para crear y mantener escenarios de prueba, estamos utilizando HipTest.
Desarrollo y verificación
El desarrollador crea un código de aplicación basado en una solución técnica y suponiendo casos de esquina y escenarios de prueba. pasar la revisión del código y verificar la característica contra escenarios de prueba. Fusiona rama a maestro.
En esta etapa, QA es compatible con Developer. Por ejemplo, ayuda con la reproducción de casos de prueba complejos, configuración del entorno de prueba, realización de pruebas de carga, consultas sobre la entrega de grandes características en la producción.
Lanzamiento de funcionalidad hecha
Esta es una etapa final. Aquí el equipo puede necesitar proporcionar acciones previas y posteriores al lanzamiento. Por ejemplo, active una nueva funcionalidad para usuarios beta.
El nuevo proceso de desarrollo había requerido de los desarrolladores una participación más profunda en el proceso de prueba.
Por lo tanto, era importante que yo, como QA, les proporcionara todas las herramientas necesarias y las estudiara sobre los fundamentos de las pruebas funcionales. Junto con los QA de otros equipos, hemos compilado una lista de la documentación necesaria, hemos creado instrucciones de prueba faltantes y hemos actualizado las existentes, incluidas las no obvias para los desarrolladores.
Luego, hemos otorgado a los Desarrolladores acceso a todas las herramientas de prueba y entornos de prueba y hemos comenzado a ejecutar las pruebas juntos. Al principio, los desarrolladores no querían hacerse responsables de los resultados de las pruebas porque nadie los verificó después de ellos. Fue inusual. Cada desarrollador solo tenía un escenario de prueba, funcionalidad creada por el desarrollador y el botón Fusionar. Pero se adaptaron rápidamente.
Resultados del experimento
Hace medio año desde el comienzo del Experimento. Hay un gráfico de la cantidad de errores por semana. La cantidad de todos los errores descubiertos está representada por el color rojo. La cantidad de errores corregidos está representada en verde. La línea amarilla es el comienzo del experimento.
Es visible que la línea roja permanece en el mismo nivel, excepto el lucio al comienzo del Experimento.
La cantidad de errores no aumentó y, por lo tanto, hemos mantenido el nivel actual de calidad.
Junto con ese tiempo promedio dedicado a la tarea disminuyó en un 2%: 12 horas y 40 minutos antes del Experimento vs. 12 horas 25 minutos después. Significa que logramos mantener la velocidad.
Como resultado, no hay más dependencia dura del control de calidad en un equipo. Si me enfermo o me voy de vacaciones, el Equipo continuará su desarrollo sin pérdidas de velocidad y calidad.
¿Estamos considerando que el experimento fue exitoso a pesar de que la velocidad y la calidad permanecen igual? Sí, lo hacemos porque al mismo tiempo hemos liberado la capacidad de control de calidad para el trabajo consciente sobre el producto y la estrategia de control de calidad. Por ejemplo, para pruebas exploratorias, aumento de la cobertura de pruebas funcionales y descripción de principios y reglas de creación de documentación de pruebas en todos los equipos.
Tenemos mentalidad de experimento de semillas en otros equipos también. Por ejemplo, en un Equipo, el control de calidad ahora no prueba lo que se describe en la solicitud de extracción del Desarrollador porque el Desarrollador puede verificarlo él mismo. en otro control de calidad del equipo que revisa la solicitud de extracción y prueba solo casos complejos y no obvios
¿Qué se debe tener en cuenta antes de lanzar un experimento?
Es un camino complejo y largo. No se pudo implementar de inmediato. Requiere preparación y paciencia. No promete victorias rápidas.
Prepárate para el equipo resistente. No es una forma de decir que a partir de ahora los desarrolladores verificarán la funcionalidad. Es importante prepararlos para esto, elaborar enfoques, describir las ventajas del experimento para el equipo y el producto.
La pérdida de velocidad al principio es inevitable. Time for Knowledge transfer for Developers, para crear documentación faltante y para cambios en un proceso que es una inversión.
No hay una bala de plata. Se están implementando procesos similares, por ejemplo, en Atlassian, sin embargo, no significa que sea posible implementarlo en su empresa tal como está. Es importante adaptar el experimento a la cultura y los aspectos específicos de la empresa.