Hace un año y medio, destruimos el equipo de pruebas: abandonamos la regresión, transferimos las pruebas automáticas de E2E a Selenium en apoyo de los desarrolladores y nos dispersamos entre los equipos que vieron características para evitar errores de raíz. En sueños optimistas, nos pareció que sería más útil: el control de calidad funciona con la calidad, las pruebas comienzan temprano y los desarrolladores escriben autotest por sí mismos y nadie los molesta.
Pero
¿Cuáles son las consecuencias de primer y segundo orden?
Ray Dalio en Principles tiene el concepto de "consecuencias de segundo orden". Estas son consecuencias no obvias de nuestras decisiones que a menudo no podemos predecir. Por ejemplo, en los años 60 del siglo XX, se inició una guerra con gorriones en China. Los gorriones comían grano y, para dejar de comerlo, China comenzó a cazar pájaros. Durante la caza, los chinos mataron en masa casi dos mil millones de aves.
Como resultado del genocidio de gorriones, la cosecha aumentó después de un año. Estas son consecuencias de primer orden. Pero no había nadie que comiera insectos y se multiplicaron las langostas y las orugas, que comenzaron a destruir aún más grano, lo que provocó una hambruna masiva en China en los años siguientes. Estas son consecuencias de segundo orden.
Las consecuencias de primer orden son consecuencias directas de nuestras decisiones y siempre están en la superficie. Las consecuencias de segundo orden son sutiles y, a menudo, a largo plazo. Para comprenderlos, es necesario pensar y simular la situación. Por ejemplo:
- Si paga a los desarrolladores por la cantidad de líneas de código, habrá más código, pero la calidad será peor. Con el tiempo, la gente comenzará a hacer trampas y producirá más y más código incorrecto para obtener más dinero. Estas son consecuencias de segundo orden.
- Si comienza a hacer ejercicio, al principio le dolerá y le llevará mucho tiempo. Pero después de un tiempo (de una semana a meses), surgirá un hábito y la salud y la apariencia mejorarán. Estas son consecuencias de segundo orden.
- Si te emborrachas como un cerdo todos los viernes, la noche del viernes será buena. Pero el sábado por la mañana será malo, son consecuencias de segundo orden. Y si hace esto con regularidad, durante años, quizás se convierta en alcoholismo y cirrosis hepática. Pero estas ya son consecuencias de tercer orden y "una historia completamente diferente".
Teníamos un equipo de control de calidad y lo "dispersamos"
Ahora les contaré cómo sentimos las consecuencias tanto del primer como del segundo orden. Teníamos un equipo acogedor y dedicado de probadores de 7 personas: 4 de ellos escribieron autotests y 3 los probaron manualmente. En algún momento, decidimos dividirnos y dispersarnos en equipos. ¿Por qué?
Porque los desarrolladores recibieron comentarios demasiado tarde.
Los bugs estaban en la etapa en la que todo el desarrollo estaba "terminado", todo estaba "integrado" y era necesario comprobar que el producto estaba listo para su lanzamiento. No hubo prueba de aceptación , fue realizada por analistas de productos que no tenían habilidades de prueba. Además, los probadores y desarrolladores estaban en mundos diferentes y tenían poca interacción.
La solución obvia (entonces) es dividirse en equipos que trabajen en ciertas características (partes) del sistema para evitar errores de raíz. No queríamos renunciar a nuestro trabajo, así que decidimos transferir nuestras funciones a los desarrolladores. Pensamos en las pruebas automáticas, se las entregaremos a los desarrolladores y se probarán sin problemas.
Al principio, decidieron probar la hipótesis en nosotros mismos con un "experimento": cubriremos los escenarios críticos de regresión con pruebas automáticas y rechazaremos la regresión manual. Si, como resultado de la experiencia, el número de revisiones y reversiones de versiones no aumenta drásticamente, entonces el experimento puede considerarse exitoso. Y así sucedió: no hubo más revisiones. Resuelto - en desacuerdo.
Nota . La empresa tiene un producto llamado Restaurante. Incluye todos los servicios y nuestro monolito. El objetivo del producto es automatizar y optimizar el trabajo de todos los empleados del restaurante tanto como sea posible. Nuestro trabajo ahora se centra más en la prevención de errores. Ahora somos QA en el producto "Restaurante": desarrollamos las cualidades en el producto, participamos en todas las etapas del desarrollo de la tarea.
Consecuencias de primer y segundo orden
Consecuencias directas . Como era de esperar, comenzamos a involucrarnos en el desarrollo de tareas desde el principio, a participar en PBR, planificación, talleres y llevarles la experiencia en pruebas. Nos acercamos más a los equipos de desarrollo, o más bien formamos parte de ellos, y nuestros problemas también eran problemas del equipo. La experiencia en pruebas, aseguramiento de la calidad y un amplio conocimiento del sistema comenzaron a crecer en los equipos. Nosotros, a su vez, comenzamos a sumergirnos en el trabajo de los desarrolladores y a comprender sus dolores.
Ahora, lo que no planeamos son consecuencias de segundo orden .
Nadie impulsa la calidad del producto . Este problema tiene dos caras:
- calidad en términos de procesos;
- calidad de autotest y pipeline.
En nuestro dedicado equipo de control de calidad, hemos impulsado la calidad. Fuimos los últimos en ver el producto frente a los usuarios y entender cómo lo ven. Discutimos los cambios y mejoras en el equipo retro, vinimos con sugerencias a los equipos de desarrollo para decidir juntos si deberían ser introducidos. Monitoreamos los autotest y trabajamos en su estabilidad.
Después de que nos dispersamos en equipos, todo desapareció en alguna parte. En el equipo de desarrollo, somos parte del equipo,
Todas las ideas estaban destinadas únicamente a mejorar el estado del equipo; hicimos todo lo posible para lanzar una característica de calidad, no un producto de calidad. Como resultado, han dejado de aparecer soluciones fundamentalmente sólidas que pueden elevar la calidad del producto a un nuevo nivel.
La competencia para escribir autotests ha desaparecido : los autotests comenzaron a doblarse y, con mayor frecuencia, a caer sin cambiar el código. Para cuando el equipo se disolvió, los probadores manuales estaban empezando a comprender los conceptos básicos de la automatización. Resultó que ni los probadores ni los desarrolladores tenían experiencia. Además, los granos de experiencia se confundieron cuando las personas que escribieron estas pruebas se dedicaron al desarrollo, la gestión de productos y alguien renunció.
No sabíamos con certeza qué pruebas automáticas tenemos, qué cubren, no sabíamos cómo se desarrollan, evolucionan, agregan y quitan; todo quedó a merced de los desarrolladores. Como resultado, cuando fue necesario encontrar información en las pruebas automáticas, fue la misma búsqueda que no se puede resolver sin un desarrollador.
Trabajo extra para desarrolladores . Es difícil ser desarrollador. Si antes solían escribir código de producto, que se verifica "mágicamente" y pasa a producción, ahora necesitan escribir pruebas, editar y estabilizar. En PBR determinamos qué escenarios deben ser cubiertos por las pruebas, y los desarrolladores eligen el nivel de autotest por sí mismos.
Los desarrolladores pasaron por varias etapas para aceptar la
Negación... Todos los lanzamientos de Dodo IS son lanzados por desarrolladores. Organizan el proceso, se comunican con el equipo de pruebas de carga, miran los registros y monitorean durante el lanzamiento. Los desarrolladores que lanzaron el lanzamiento, frente a la prueba roja, no intentaron averiguar la razón, sino que simplemente reiniciaron la tubería hasta que se volvió verde 5-7-10 veces. Esto se debe a que no se confiaba en los autotests.
¡El número máximo de reinicios que he encontrado es 44 veces! Me parece que la regla que adoptamos en uno de los retro "No lanzar con pruebas rojas. Si la prueba es roja, averigüe cuál es el problema. Si el problema está en las pruebas, arréglelo o fírmelo y cree una tarjeta para desbloquear la prueba y agregarla a la lista de trabajos pendientes ".
Ira : los desarrolladores juraron nuestras pruebas, dijeron que
No hubo negociación ni depresión, la aceptación llegó de inmediato : los desarrolladores ahora pueden escribir pruebas de interfaz de usuario y API de E2E, estabilizarlas y mejorarlas.
La cantidad de errores a la venta comenzó a aumentar . Los errores no críticos comenzaron a filtrarse en la producción. Hay varias razones para esto:
- Nuestros autotests no cubren todas las funcionalidades, sino solo las críticas. Y no hay más pruebas de regresión manual.
- No había suficientes ingenieros de control de calidad para todos los equipos. Los equipos no tenían competencias de prueba, por lo que no prestaron la debida atención a las pruebas.
Como resultado, comenzamos a encontrar errores de producción accidentalmente. No son críticos, pero cuántos de ellos en general no fueron imaginados.
¿Cómo resolvemos estos problemas?
Quizás otro equipo podría haber predicho todas las consecuencias no obvias, pero no pudimos. Tomamos una decisión, a los pocos meses vimos las consecuencias, y comenzamos a eliminarlas.
Creó un gremio de control de calidad de restaurantes o una comunidad de práctica, que incluía todos los controles de calidad de restaurantes. El objetivo de la comunidad es impulsar la calidad de todo el producto, para difundir las buenas prácticas de prueba a todos los equipos de productos. Esta es una educación que combina las ventajas de un equipo de control de calidad dedicado y también nos beneficiamos de ser QA en el equipo de desarrollo.
Nos reunimos una vez a la semana: compartimos resultados, descubrimientos y planeamos trabajar juntos en la calidad. También asignamos varios espacios por semana para trabajar en las tareas del gremio. Por ejemplo, estamos terminando nuestro bot asistente para liberadores.
Deber... El gremio cubre parcialmente el problema de la falta de calidad de propietario y autotests. Pero el gremio no tiene competencias sólidas en desarrollo y automatización, por lo que nuestro CTO tomó una decisión decidida y organizó un deber en la tubería.
Ahora los desarrolladores pueden mejorar sistemáticamente el proceso de canalización: estabilizar, encontrar problemas que retrasen las versiones y solucionarlos. Un desarrollador del equipo de desarrollo se convierte en propietario de la tubería durante un mes y la mejora sistemáticamente. No publicar, sino mejorar: hace que el proceso de publicación y soporte de pruebas sea fácil y sin esfuerzo. Ahora que las métricas del producto han mejorado, nos deshicimos de este asistente, pero podemos devolverlo en cualquier momento. (Mientras escribíamos un artículo, lo devolvimos porque el aviso comienza a degradar la estabilidad)
Cursos... Cerramos el problema de la falta de competencias con cursos para testers manuales y trabajo en pareja con desarrolladores con experiencia en automatización.
Trabajo extra para desarrolladores . No hay nada que pueda hacer al respecto, los desarrolladores acaban de llegar a la etapa de aceptar pruebas automáticas. Ahora escriben las pruebas E2E ellos mismos, si los de nivel inferior no pueden cubrir la función, y estabilizan la tubería. Como dicen en los libros inteligentes, es una buena práctica cuando todo el equipo y los desarrolladores y evaluadores pueden escribir pruebas. Nuestra caminata hacia el lado vio los microservicios del monolito. Hay menos pruebas en el monolito y cada vez más en repositorios separados, la canalización se vuelve más estable.
Investigamos el producto... Resolvemos problemas con errores en producción comenzando a investigar el producto en busca de inconsistencias con el comportamiento esperado. Hemos programado sesiones de prueba exploratorias semanales. Y traemos errores a la cartera de pedidos al propietario del producto.
¿Qué haríamos ahora?
No considerar las consecuencias de segundo y tercer orden ha llevado a malas decisiones. Es especialmente peligroso cuando la primera opción, y no la mejor, refuerza un sesgo ya existente. Pero ahora, con toda la experiencia adquirida, habríamos actuado de otra manera.
Por ejemplo, la pérdida de competencias podría resolverse pidiéndoles que compartan la competencia con todos los ingenieros de control de calidad en un producto o desarrolladores de equipos unos meses antes de la transición de personas con competencia en automatización. Y mejor para todos a la vez.
No hay forma de compensar el problema del trabajo adicional para los desarrolladores , pero podría reducir el dolor de escribir pruebas no anteponiéndolo a un hecho, pero:
- mostrar el valor de las pruebas de forma explícita;
- enseñar a los desarrolladores a escribir, mejorar y mantener estas pruebas;
- ( ), .
Cuando tomamos caminos separados, ni siquiera pensamos en estos problemas. “En retrospectiva” parece, bueno, cómo puede ser, pensar en ello es elemental. Pero en retrospectiva, todos somos fuertes: intente predecir el futuro.
Las consecuencias de segundo o tercer orden para mí pueden ser las consecuencias de primer orden para las personas más experimentadas que ya han tomado tales decisiones muchas veces y han visto los resultados de tales decisiones.
Demasiadas incertidumbres y variables que afectan los resultados.
Es importante no predecir las consecuencias, pero, al menos, saber cuáles podrían ser. Antes de tomar cualquier decisión, es importante pensar cuáles serán las posibles consecuencias, leer información sobre casos en otras empresas para al menos tener una idea de la escala de posibles consecuencias no obvias.
Cualquiera que aprenda a predecir las consecuencias de segundo (e incluso tercer) orden de cualquier decisión podrá salvar o destruir a la humanidad. O ganar más dinero que Scrooge McDuck, al menos con las fluctuaciones del precio de las acciones.
¿Cómo voy a intentar predecir las consecuencias ahora?
Leí artículos sobre este tema y deduje por mí mismo varias reglas que, según los autores, ayudarán a predecir tales consecuencias. Intentaré usarlos:
- Antes de tomar una decisión, hágase la pregunta "¿Qué pasará después?" y agregue espacios de tiempo a la pregunta. ¿Qué pasará en 10 minutos, 10 meses o 10 años?
- Entrene su pensamiento hacia tales consecuencias pensando en diferentes situaciones. Por ejemplo, ¿cuáles son las consecuencias del primer segundo o incluso del tercer orden si el mundo entero cambia a los coches eléctricos o, por ejemplo, introduce una renta básica incondicional? No hay respuestas correctas en este ejercicio, pero le permitirá pensar más ampliamente.
- Recuerde que el primer pensamiento en su cabeza es el primer orden. Es siempre.
Si encontró otros problemas al cambiar la organización del equipo de pruebas u otros equipos, escriba en los comentarios, será interesante saber qué problemas enfrentó y cómo los resolvió.
P.S. 2 QA- « » . . : , , SRE- mobile SRE . . , : (@EvgenSkt) HR (@alexpanev).
, , , : « » « » ( «» — ). QA, « ? ».
-, .