Hola a todos, mi nombre es Sergey. Estoy probando la interfaz de Yandex.Market. Sé que entre los lectores de Habr hay muchos especialistas en TI que de alguna manera están conectados con el proceso de lanzamiento y las pruebas. Tengo una pregunta para ti ¿Alguna vez ha sucedido en su práctica que las funciones no funcionan durante mucho tiempo en la producción? ¿Conoce las versiones infladas y sus comprobaciones volumétricas?
Creo que todos tenían esto. Vine a Yandex hace 3 años, nuestro equipo era muy joven, los procesos no estaban completamente establecidos. Y me encontré con estos problemas cara a cara.
Como era
En ese momento, nuestros equipos de productos no tenían un área específica de responsabilidad y solo estaban involucrados en el proyecto para el que fueron creados. Luego se desmoronaron. Las pruebas tampoco estaban vinculadas a los equipos de desarrollo. Existía como un servicio y se conectaba al proyecto según fuera necesario.
Las tareas se verificaron solo a mano, las pruebas de integración fueron inestables, el porcentaje de cobertura con autotest fue pequeño. El cheque duró mucho tiempo. El conjunto de tareas listas para el cálculo crecía constantemente y podía alcanzar tamaños enormes.
En cuanto a los lanzamientos, uno de los gerentes se dedicaba al montaje y al cálculo. Mantuvimos reuniones con todos los gerentes y decidimos qué incluiría en el próximo lanzamiento y qué podría posponerse.
Verificaron los comunicados al azar: quien tuvo tiempo de revisarlos, él verificó. Se hizo hincapié en las pruebas de regresión manual, que podrían durar varios días. Y esto a pesar del hecho de que el lanzamiento ejecutó un paquete de pruebas automáticas y hubo un departamento que las escribió y las apoyó.
Entonces, el problema resuelto cayó en la prueba y pudo probarse hasta 2 días. Luego se metió en la liberación, fue revisada por otros 4 días. En producción, la tarea resultó mejor en una semana. A pocas personas les gustó, era necesario cambiar algo. Y lo más importante para cambiar son los procesos.
Contorno
Lo primero que hicimos fue introducir una división en contornos: equipos de especialistas de diversos campos. A diferencia de los equipos anteriores, los contornos no se rompen después del final del proyecto. Continúan generando nuevos proyectos e ideas dentro de su área de responsabilidad.
De 1 a 3 probadores son responsables de las pruebas en cada circuito. Cada probador de circuito responsable está presente en todas las etapas del desarrollo del producto, desde una idea hasta un informe.
De turno
Para estructurar el trabajo de las versiones, presentamos dos roles en nuestro equipo de pruebas: un asistente de versiones y un probador de versiones. Como maestro de lanzamiento, tenemos 4 probadores en servicio a la vez, todos están involucrados en el deber de lanzamiento. Para cada uno de estos roles, organizamos un horario de servicio.
Las tareas que surgen durante el servicio tienen prioridad sobre la prueba de las características del producto dentro de los circuitos. Para que los evaluadores no tengan que esperar mucho sin interrupción, el servicio de liberación se organiza de la siguiente manera: un turno está en servicio de lunes a miércoles, el segundo, de miércoles a fin de viernes. En cada turno: 4 personas, 2 personas por plataforma.
La documentación
¿Y qué hay de la documentación? No tenemos mucho, pero lo es. Por ejemplo, cuando implementamos funciones, nosotros, junto con los desarrolladores y el administrador, determinamos el número óptimo de pruebas automáticas. Si no podemos automatizar algo, o si una función requiere publicación inmediata sin pruebas automáticas, escribimos un caso en el conjunto de pruebas de todos los casos de verificación de Mercado y, si es necesario, lo incluimos en el conjunto de pruebas de lanzamiento de pruebas de regresión.
Si verificamos las correcciones de errores y vemos que el autotest no estaba escrito en el error, también establecemos la tarea para desarrollarlo, y la edición comienza de inmediato con la prueba escrita en él.
Al diseñar cada experimento, tenemos una lista de verificación, ya que no sabemos de antemano si el experimento será exitoso.
Una lista de verificación es un conjunto de verificaciones positivas sobre las características de un experimento. El probador de versiones lo utiliza con cada versión mientras el experimento está funcionando. Esta lista de verificación también puede quedar en blanco para futuras tareas de automatización si el experimento es exitoso y lo implementamos al 100% de los usuarios.
Al verificar las versiones, utilizamos varios kits de prueba dependiendo de la complejidad y la plenitud de la versión. Tenemos tanto suites de pruebas pequeñas como suites con el número máximo de casos de prueba. Qué conjunto de pruebas usar, decide el probador de versiones.
En algunas áreas, también utilizamos la lista de verificación de verificaciones positivas para desarrolladores. Con él, el desarrollador puede verificar la tarea él mismo y prever cuellos de botella en el desarrollo de características. Si el probador ha cambiado en el proyecto, esto ayudará al nuevo especialista a unirse rápidamente al proyecto. Las listas de verificación se escriben antes del inicio del desarrollo, inmediatamente después de programar la tarea.
Eso es todo por los muelles.
Cómo probamos las tareas
Utilizamos varias técnicas de diseño de pruebas: clases de equivalencia, valores límite, pruebas por pares, escenarios de usuario. La experiencia del probador también es muy importante. El mercado es una gran máquina, y usted necesita saber cómo funcionan todas sus partes para reparar o mejorar algo. Por ejemplo, tenemos 4 tipos de tarjetas de productos y 6 tipos de problemas de productos. Sin saber esto, es simplemente imposible probar cualitativamente la tarea de cambiar estas páginas.
Las pruebas automáticas desempeñan un papel importante en la comprobación de tareas. Realizamos pruebas automáticas funcionales para cada tarea que implementamos, analizamos bloqueos e informamos de errores.
En casos especiales, cuando la tarea afecta a muchos componentes del mercado, también ejecutamos pruebas de pantalla, que nos ayudan a detectar errores.
Cuando se completa la verificación de la tarea, dejamos un comentario de que todo está bien y que la tarea se puede liberar. En el comentario, indicamos cuántas pruebas se han escrito, o decimos que las pruebas no son necesarias, y traducimos la tarea al estado "pendiente de publicación".
A continuación, la tarea es recogida por el asistente de lanzamiento, y se envía al lanzamiento junto con otras tareas comprobadas. Intentamos rellenar lanzamientos con tareas para verificarlos en 8 horas con las manos de 4 probadores: 2 para la versión táctil de Market y 2 para la versión de escritorio. Nuestro objetivo es implementar al menos 5 lanzamientos. Es decir, la velocidad de entrega de la tarea al producto en comparación con lo que era, aumentó 5 veces.
Cómo verificamos los lanzamientos
Comenzamos a verificar el lanzamiento verificando las pruebas automáticas y las pruebas de pantalla. Después de mirar los informes, podemos detectar de inmediato hasta el 90% de los problemas. Analizamos el bloqueo de las pruebas: si están relacionadas con un error o están dañadas por un ticket en el lanzamiento, buscamos la tarea en la que se reproduce este bloqueo y solicitamos su reparación. Si esto no se hace, la tarea no se incluye en la versión.
Las pruebas también pueden morir por sí mismas. En este caso, apagamos la prueba de la ejecución de la prueba automática y comenzamos la tarea de solucionarlo y crear el mox si es necesario.
Dependiendo de las tareas en el lanzamiento, podemos usar el kit de prueba de lanzamiento completo, o podemos rechazar completamente la regresión manual. La decisión la toman los probadores de lanzamiento.
Si la versión tiene varias ediciones pequeñas, la verificación de tareas se realiza localmente y la regresión manual se reemplaza por la verificación de los informes de prueba automática.
Independientemente de la integridad de la versión y las tareas, el equipo de evaluadores de versión verifica los experimentos que actualmente se muestran a diferentes porcentajes de usuarios en producción. Se utiliza una lista de verificación escrita por un probador de experimentos.
Cuando se completan todas las comprobaciones, el probador de la versión deja un comentario en el que enumera todas las actividades de la versión y, si es necesario, escribe tareas para corregir las pruebas rotas.
El maestro de lanzamiento analiza los informes de disparo (prueba de carga) y, si ve un aumento en los errores, los reinicia. Si esto no ayuda, busca al culpable o busca ayuda del desarrollador de turno.
Si todo está bien con los resultados de la filmación, el asistente de lanzamiento abre los gráficos del mercado y comienza a implementar el lanzamiento en producción. Los gráficos deben ser monitoreados para no perderse el crecimiento de errores.
Si el lanzamiento tiene la culpa del aumento de errores, el maestro de lanzamiento lo revierte y comprende las razones. Si los horarios son normales, completa el lanzamiento y comienza a recopilar uno nuevo de las tareas preparadas.
Luchando por lo mejor
A pesar de que todo funciona bien, siempre debes esforzarte por lo mejor. Estamos al borde de una entrega continua futura más brillante, donde las tareas se comprobarán y se implementarán en producción paralelamente, sin una etapa intermedia en forma de lanzamiento. Esto le permitirá no ser distraído por el reloj en los lanzamientos y acelerar significativamente la entrega de funcionalidad a los usuarios.
Decidimos cambiar a CD por etapas. El primer paso fue la introducción de un monorepository, que combina la implementación de la funcionalidad en ambas plataformas, la táctil y la de escritorio, en una versión. Este enfoque tiene ventajas tanto para el desarrollo como para las pruebas. Pasamos mucho menos tiempo probando el componente. Las tareas ahora están en un solo lugar, lo que facilita la navegación. Es más fácil para el gerente navegar, ya que conoce el momento exacto de implementación de la tarea de lanzamiento en el producto, y no existe una reacción violenta entre el lanzamiento de las plataformas.
El siguiente paso para el CD será la introducción de la "herida verde". Para cada boleto verificado por el probador, se lanzarán 2 tipos de pruebas para ambas plataformas: pruebas funcionales y pruebas de pantalla. Todas las pruebas deberán tener moki. Si las pruebas para una de las plataformas fallan, la tarea no se considerará verificada. Si la prueba falla, deberá comprender por qué sucedió esto. Solo en ausencia de pruebas de caída y la finalización exitosa de todos los controles, la tarea se enviará al producto.
Gracias por su atencion Espero que nuestra experiencia te haya sido útil, te espero en los comentarios.