Trabajo como ingeniero de control de calidad en
Miro . Le contaré sobre nuestro experimento de transferir a los desarrolladores parte de las tareas de probar y transformar el rol del probador en el rol de QA (Garantía de calidad).
Primero, brevemente sobre nuestro proceso de desarrollo. Tenemos versiones diarias de clientes y de 3 a 5 versiones de servidores por semana. El equipo de desarrollo tiene más de 60 personas que se dividen en 10 equipos scrum funcionales.
Trabajo en el equipo de integración, cuya tarea es integrar nuestro servicio en productos externos e integrar productos externos en nuestro servicio. Por ejemplo,
integramos el rastreador de tareas Jira . Jira Cards: una pantalla visual de tareas que puede trabajar cómodamente en el tablero sin tener que ingresar a Jira.
¿Cómo comenzó el experimento?
Todo comenzó con un problema común. Cuando uno de los evaluadores fue a la lista de enfermos, el rendimiento del equipo se redujo considerablemente. El equipo continuó trabajando en las tareas, pero el código llegó a la etapa de prueba y la tarea se detuvo. Como resultado, la nueva funcionalidad no alcanzó la producción a tiempo.
La salida del probador de vacaciones es otra historia. Necesita encontrar de antemano a uno de los evaluadores que esté listo para asumir sus tareas además de las suyas, para estar de acuerdo, sumergirse en las tareas. Al mismo tiempo, dos probadores se van de vacaciones es un lujo inadmisible.
Comenzamos a pensar en cómo resolver el problema, y nos dimos cuenta de que el verdadero problema era que el cuello estrecho de los procesos de desarrollo estaba probando. Te mostraré un ejemplo de varias historias.
La primera historia: reversión de tareas sin fin
También hay un desarrollador. Cada uno tiene sus propias tareas. El desarrollador completó una de las tareas y me la dio para que la probara. Como esta tarea tiene una prioridad más alta que las actuales, me cambio a ella. Encuentro errores, obtengo todo en Jira y se lo devuelvo al desarrollador para su revisión.
Vuelvo a las tareas que tuvieron que posponerse. El desarrollador cambia de nuevas tareas a la tarea que devolví. Corrige errores y me devuelve para probar. Encuentro errores nuevamente y devuelvo la tarea nuevamente. Este proceso puede continuar por mucho tiempo.
Como resultado, el tiempo total de trabajo en la tarea aumenta varias veces, seguido por el aumento del tiempo de comercialización, y esto es fundamental para nosotros como empresa de alimentos. Existen varias razones para aumentar el tiempo dedicado a la tarea:
- La tarea cambia constantemente entre desarrollo y pruebas.
- La tarea está inactiva esperando a un probador o desarrollador.
- El desarrollador y el probador tienen que cambiar regularmente entre tareas, lo que requiere tiempo y energía adicionales.
La segunda historia: una línea creciente de tareas
Nuestro equipo scrum tiene varios desarrolladores. Regularmente me envían sus tareas para que las pruebe. Una cola de formularios de tareas para las que me comprometo, en función de las prioridades.
Así que trabajamos durante aproximadamente un año, pero durante este tiempo la compañía ha crecido significativamente: la cantidad de proyectos y desarrolladores ha aumentado y, por lo tanto, la cantidad de tareas en las pruebas. Al mismo tiempo, seguía siendo el único probador en nuestro equipo y no podía multiplicar mi velocidad. Como resultado, se estaban acumulando más y más tareas en la cola de prueba, y el proceso de transferencia de tareas entre el desarrollador y el probador aumentó el tiempo de espera.
De repente me enfermé. La entrega de nuevas características de nuestro equipo de producción se ha detenido por completo. ¿Qué debe hacer un equipo en tal situación? Puede pedirle ayuda al probador de otro equipo. Pero, con un alto grado de probabilidad, no estará inmerso en nuestros detalles, lo que afectará negativamente la calidad y el tiempo de ambos equipos.
La conclusión de ambas historias es la misma: los equipos dependen demasiado del probador:
- El rendimiento de todo el equipo está limitado por el rendimiento del probador.
- El número de desarrolladores no se puede aumentar sin aumentar el personal de los probadores.
- Un aumento en la velocidad de desarrollo no tiene sentido si todas las tareas caen en la cola para la prueba.
- Si bien el probador verifica el trabajo del desarrollador, se reduce el sentido de responsabilidad del desarrollador por la calidad.
- Si no hay un probador, el proceso de generar nuevas funciones se ve afectado.
Vamos a aumentar el personal de los probadores?
El pensamiento más obvio es aumentar el personal de los probadores. Esto funcionará, pero solo hasta cierto punto: el número de tareas crecerá constantemente y es imposible aumentar infinitamente el número de probadores; en algún momento se volverá costoso e ineficiente.
Fedor Ovchinnikov , CEO de Dodo Pizza,
escribió bien sobre el tema de los problemas de "pensamiento de recursos" (¿no puede resolver el problema? Contratar a otro empleado).
Es mucho más eficiente mantener la velocidad y la calidad del desarrollo dentro de los recursos actuales. Por lo tanto, decidimos lanzar un experimento que ayudará a los equipos a crear funcionalidad de inmediato, teniendo en cuenta todos los riesgos y situaciones fronterizas. Lo llamaron Transform tester to QA, porque se trata de la transformación de uno de los roles en el equipo: desde un probador de mono, identificando errores por el desarrollador, hasta un ingeniero de QA que conscientemente garantiza la calidad en todas las etapas del proceso de desarrollo.
Mejoremos los procesos de desarrollo.
Objetivos del experimento:
- Para eliminar la dependencia del equipo de los probadores, pero sin pérdida de calidad y tiempo.
- Mejore la garantía de calidad de los ingenieros de control de calidad en equipos.
El primer paso fue cambiar el pensamiento del equipo. Todos están acostumbrados al hecho de que el probador es responsable de la calidad del equipo.
Nuestra hipótesis era que aumentar el tiempo de preparación y prueba de las tareas ayudaría a reducir el número de iteraciones al trabajar en una tarea. Esto, a su vez, permitirá traer nuevas funcionalidades a la producción sin pérdida de velocidad y nivel de calidad, y quizás más rápido y con mejor calidad.
Junto con el equipo y con probadores de otros equipos, desarrollamos un nuevo esquema de trabajo. Durante medio año, mientras el equipo trabaja en ello, tomamos en cuenta las dificultades y los problemas que surgieron en el camino, y hoy se ve así:
- Presentación de la producción.
- Solución técnica y escenario de prueba.
- Desarrollo y verificación.
- Lanzamiento
Declaración del problema.
El propietario del producto presenta la declaración del problema al equipo. El equipo analiza la formulación para identificar situaciones límite desde el punto de vista técnico y del producto. Si hay preguntas que deben investigarse más a fondo, se establece una tarea separada, para la cual se asigna tiempo en el sprint.
Solución técnica
El resultado del análisis de la formulación del problema es una solución técnica, que es uno o más desarrolladores. Todos los empleados relevantes de la compañía, incluido el control de calidad, deben estar familiarizados con la solución técnica y estar de acuerdo con ella. La solución técnica describe el problema que estamos resolviendo, los bloques funcionales del producto que se verán afectados y el plan propuesto para realizar cambios en el código.
Esta solución le permite identificar una solución mejor y más simple basada en la experiencia de los participantes relevantes en el proceso de desarrollo. Tener una descripción técnica detallada a mano: es más fácil ver y evitar problemas de bloqueo, es más fácil realizar una revisión del código.
Aquí hay un ejemplo de algunos bloques de una solución técnica:
Descripción de la tarea
¿Se agregan nuevas entidades o enfoques al sistema?
Si es así, se describen y explican por qué es imposible resolver el problema en el marco de los enfoques existentes.
¿Está cambiando la interacción del servidor dentro del clúster? ¿Se están agregando nuevos roles de clúster?
¿Está cambiando el modelo de datos?
Para el servidor estamos hablando de objetos y modelos.
Si el modelo de datos es complejo, puede presentarlo en forma de diagrama UML o como una descripción de texto.
¿Está cambiando la interacción entre el cliente y el servidor?
Descripción de los cambios. Si se trata de una API, ¿se puede dar a usuarios externos? No te olvides del manejo de errores, es decir Indique la razón correcta.
Escenario de prueba
Paralelamente, el desarrollador o QA elabora un escenario de prueba que tiene en cuenta todos los lugares posibles donde se han producido problemas. Si el desarrollador hace esto, necesariamente entregará el script a QA, que lo verifica para verificar que esté completo y sea suficiente. Si el script es QA, el desarrollador debe confirmar que comprende cómo se puede completar cada uno de sus elementos. El equipo también evalúa la corrección del guión.
Para la compilación y el almacenamiento de scripts utilizamos HipTest.
Desarrollo y Validación
El desarrollador comienza a escribir código basado en una solución técnica y teniendo en cuenta todas las situaciones posibles descritas en la documentación de prueba. Pasa una revisión de código y verifica el código contra escenarios de prueba. Produce fusión en el maestro.
En esta etapa, QA proporciona el soporte necesario para el desarrollador. Por ejemplo, ayuda a reproducir casos complejos, configurar un entorno de prueba, realizar pruebas de carga y sugiere los posibles matices de generar grandes características para la producción.
Lanzamiento de funcionalidad lista
Esta es la etapa final. Aquí, el equipo puede estar obligado a realizar acciones previas o posteriores al lanzamiento, por ejemplo, la inclusión de nuevas funciones para usuarios beta.
Documentación y herramientas
El nuevo esquema de trabajo requirió que los desarrolladores se sumergieran más en el proceso de prueba. Por lo tanto, como QA, era importante para mí proporcionarles todas las herramientas necesarias y enseñarles los conceptos básicos de las pruebas funcionales. Junto con el control de calidad de otros equipos, hicimos una lista de la documentación necesaria, creamos las instrucciones de prueba que faltaban y finalizamos las existentes teniendo en cuenta cosas que no eran obvias para los desarrolladores.
Luego les dimos acceso a los desarrolladores a todas las herramientas de prueba y entornos de prueba y comenzamos a realizar pruebas conjuntas. Al principio, los desarrolladores no querían hacerse responsables de los resultados de la prueba, porque nadie más los revisó, era inusual para ellos. Cada desarrollador tenía solo un script de prueba, la funcionalidad que desarrolló y el botón Combinar. Pero poco a poco se fueron acostumbrando.
Resultados del experimento
Han pasado seis meses desde el inicio del experimento. El gráfico muestra las estadísticas de la cantidad de errores por semana en nuestro equipo. El color rojo muestra el número de todos los errores encontrados por el equipo, verde: el número de errores corregidos.
Se puede ver que el nivel de la línea roja se mantuvo en el mismo nivel, excepto por el estallido al comienzo del experimento. No hay más errores, lo que significa que hemos mantenido el nivel actual de calidad.
Al mismo tiempo, el tiempo promedio para trabajar en tareas disminuyó solo un 2%: antes del inicio del experimento, eran 12 horas y 40 minutos, después de 12 horas y 25 minutos. Así pudimos mantener la velocidad actual de trabajo en las tareas.
Como resultado, nuestro equipo ya no tiene una fuerte dependencia del control de calidad. Si me enfermo o me voy de vacaciones, el equipo continuará trabajando sin perder velocidad y calidad.
¿Consideramos que el experimento fue exitoso, a pesar de que los indicadores de tiempo y calidad siguieron siendo los mismos? Sí, creemos, porque mantuvimos la velocidad y la calidad del trabajo y liberamos tiempo de control de calidad para un trabajo más consciente sobre la calidad del producto y los procesos de desarrollo. Por ejemplo, para realizar pruebas de investigación, aumente la cobertura de las pruebas funcionales y describa los principios y las reglas para el desarrollo de la documentación de las pruebas en todos los equipos.
En otros equipos, sembramos la semilla del experimento. Por ejemplo, en uno de los comandos, QA ahora no prueba lo que describe el desarrollador en la solicitud de extracción, porque el desarrollador puede verlo por sí mismo. En otro equipo, el control de calidad analiza los cambios de solicitud y verifica solo casos complejos y no obvios.
Cosas para recordar antes de comenzar un experimento
Este es un experimento complejo y largo. No se implementa con el clic de un dedo, debe prepararse cuidadosamente y no esperar resultados rápidos.
Prepárate para la negatividad del equipo. No puede simplemente tomarlo y decir que ahora los desarrolladores están probando la funcionalidad. Es necesario prepararlos para esto, desarrollar enfoques, explicar el valor del experimento para el equipo y el producto.
La pérdida de velocidad al comienzo es inevitable. El tiempo para capacitar a los desarrolladores, escribir la documentación que falta y reconstruir los procesos lleva tiempo, que deberá donarse al experimento.
No hay una solución preparada. Procesos similares se implementan, por ejemplo,
en Atlassian , pero esto no significa que también podrá implementarlos como está. La adaptación a la cultura de la empresa y las características específicas de los equipos es importante.