Hola Habr En el último BackendConf, Anton Olievsky, nuestro jefe del departamento de pruebas de software y control de calidad, habló sobre lo más, quizás, lo más importante: una actitud consciente hacia el trabajo.
Aquí está la cosa. La velocidad de implementación de ideas de negocios se ha convertido en un factor clave. Esta velocidad en SJ se estima por el tiempo promedio que se tarda en completar la tarea. En la empresa este tiempo fue igual a 65 días. Sí, 2 meses desde la creación de una tarea hasta su envío al usuario.
Anton dice que pudieron acelerar los procesos 3 veces gracias a las pruebas conscientes. Ahora le diremos qué es y cómo exactamente.
¿Cómo estuvo antes?
El proceso fue así:
- 5 probadores para 40 desarrolladores;
- Cada tarea se prueba por separado;
- Las tareas terminadas se fusionan en la rama de lanzamiento;
- En el lanzamiento, se llevan a cabo pruebas de aceptación;
Entonces integración.
Si el resultado fue exitoso, el lanzamiento se envió a los usuarios, y las tareas de 50-60 en espera de prueba estaban constantemente pendientes del tablero.
¿Cómo trabajó con la tarea?
- Desde el desarrollo, la tarea se puso a prueba y se perdió en la lista sin fondo de otros que esperaban;
- En la lista, podría caer de un par de días a un mes;
- Luego, el probador verificó la tarea, se hicieron errores y se envió de nuevo al desarrollo;
- El programador corrigió errores y devolvió la tarea nuevamente para una prueba.
El ciclo se repitió y la tarea podría congelarse en la etapa de prueba durante varios meses. Desde un punto de vista técnico, todo estaba bien, solo las funciones se lanzaron lentamente y el negocio no estaba contento. Los evaluadores escucharon constantemente el hecho de que el desarrollo avanza muy lentamente, los plazos se están rompiendo y las empresas están perdiendo dinero.
Como cualquier otro probador normal, los chicos leen libros inteligentes sobre pruebas y piensan que lo principal es la calidad del producto. Al igual que, necesita encontrar tantos errores como sea posible y, ciertamente, solucionarlos todos. Pero no
Por que no
Debido a que no necesitamos corregir errores, sino ayudar al negocio, Anton fue al producto Dima para lidiar con la situación. Allí decidieron que lo principal es la velocidad de lanzamiento de las funciones. El hecho es que a las empresas no les gusta perder dinero en el desarrollo y la fijación de proyectos, lo que no está claro si traerá beneficios. Por lo tanto, es mejor lanzar un proyecto imperfecto y, en función de los resultados de su éxito, decidir si llevarlo al ideal o minimizarlo. Los probadores se reunieron e intentaron comprender cómo aumentar la velocidad de lanzamiento. Resultó que todo es obvio.
SJ tiene una aceptación (un conjunto de casos en las principales áreas de funcionalidad para verificar el producto en su conjunto, por ejemplo, autorización del usuario, colocación laboral, etc.), que consta de 150 casos y lleva 1,5 días de prueba. Es muy largo
En serio, se trata de 1,5 días de controles manuales 2 veces por semana. ¿Qué se debe hacer con las verificaciones manuales repetidas? Automatizar
Resultó automatizar 100 casos. Los casos no rentables para compartir en automatización, enviar cartas, recibir SMS no fueron rentables. Los probadores estaban encantados, ya que había menos costos regulares para las versiones de prueba: 3 horas, en lugar de 1,5 días. En segundo lugar, las pruebas automáticas brindan retroalimentación rápida sobre si comenzar a ver una versión o no y detectar errores incluso antes de que una tarea entre en una versión.
Casi todo se decidió, pero luego llegó el CTO.
¿Qué más está mal?
Él vino y dijo que tenemos que ver dónde sigue la sobredosis de horas de trabajo. Los chicos se sentaron y se dieron cuenta de que las acciones repetitivas eran solo en lanzamientos: era aceptación e integración.
¿Qué pasa con la integración? En resumen, hubo una situación en la que enviaron un lanzamiento y el producto de Dim salió indignado de que la tarea que habían prometido no llegó a la batalla. Comenzaron a darse cuenta de dónde se había ido. Resultó que al retener las tareas en la rama de lanzamiento, se perdió parte de la confirmación y la tarea se perdió visualmente para los usuarios.
Devops comenzó a arreglar scripts de compilación, y los probadores verificaron dos veces los casos para cada tarea en el lanzamiento para asegurarse de que todo saliera bien y que todas las tareas estuvieran en su lugar. Parece ser tan difícil verificar las tareas que ya se han visto. Pero resultó que había alrededor de 5 tareas para cada probador en el lanzamiento, y se encontraron casos complejos, como cambiar algo en la base de datos, ejecutar un script, verificar la carta recibida. Toda esta etapa tomó mucho tiempo: de 2 a 10 horas de trabajo de todos los evaluadores.
Los chicos tomaron estadísticas durante varios meses de esta práctica y resultó que no hubo más casos con una versión deficiente del lanzamiento y en esta etapa solo un par de veces hubo errores no críticos que se perdieron al probar las tareas. Sopesó todos los pros y los contras y decidió abandonar esta etapa.
Ahora ok?
No esta bien En el mundo de TI, no se puede disfrutar del éxito por mucho tiempo, porque siempre hay algo que mejorar. En nuestro caso, estos fueron lanzamientos 2 veces a la semana. Por ejemplo, los evaluadores verificaron la tarea el miércoles por la mañana y la enviaron para liberarla, y llega al usuario solo el martes de la próxima semana.
Que mas Demasiadas revisiones de la empresa. El negocio había planeado lanzar una función para alguna fecha, lo anunció y lanzó un anuncio, y los evaluadores dijeron: "Basura, gay, hemos planeado lanzamientos aquí y la tarea se implementará solo la próxima semana". Por lo tanto, para cada una de esas tareas, el producto Dima recurrió a ellas.
Y todos saben que si Dima entra en desarrollo, entonces espera lo urgente. Estas redadas están cansadas de los desarrolladores y probadores. ¿Es esta una razón para ir a la sala de reuniones nuevamente? Todos se encerraron y decidieron que el negocio necesita lanzar más a menudo, por lo que debe automatizar aún más, verificar el lanzamiento en tres horas, automatizar la compilación diaria del lanzamiento y configurar el lanzamiento de pruebas automáticas en el lanzamiento y realizar la aceptación todos los días.
Esta fue una pequeña victoria, porque las características se despliegan después de probar el máximo al día siguiente. Hubo menos problemas con las correcciones urgentes, algunos se enviaron a la versión actual y otros esperaban la versión de mañana. Esto permitió a los evaluadores no distraerse con estos controles y liberar tiempo para probar nuevas tareas. Las estadísticas sobre errores perdidos se han mantenido sin cambios, por cierto.
Luego, el probador Julia se acercó a Anton y le dijo que estaba harta. Como, haz lo que quieras, pero ella ya no puede llevar a cabo una aceptación todos los días, dado el hecho de que, según la funcionalidad principal, rara vez algo cambia y no encuentra errores. Por lo tanto, Julia se ofreció a realizar una aceptación una vez por semana.
Bueno, esta bien gays.
Y como es
Ahorre tiempo: 12 horas a la semana para probar nuevas tareas, menos desmotivación en cheques monótonos. De las desventajas, los errores pueden vivir hasta 5 días desde la fecha de aparición. Se ha hecho mucho con éxito para acelerar, pero al mismo tiempo, los muchachos han tenido poca influencia en lo más importante: el tiempo promedio que se tarda en completar una tarea en la producción.
Avanzaron hacia la meta, pero no la alcanzaron. Sí, los probadores podían dedicar su tiempo a nuevas tareas, pero por la velocidad de paso fue una gota en el cubo.
Anton se fue a pensar qué tareas pasan por las pruebas y se dio cuenta de que casi todo. Y la transmisión es enorme, como la Fosa de las Marianas, por lo que es imposible procesar todo. Por lo tanto, se decidió priorizar. En esta etapa, el producto Dima ayudó, lo que, junto con Anton, verificó todo lo que no era importante para los negocios.
Solo quedaban puntos directamente relacionados con el dinero y cosas críticas para los usuarios.
En resumen, solo quedan 50 de una lista de 300 elementos.
Ya puedes trabajar con esto. Por cierto, ¿qué bonificaciones ofrece el desarrollo web?
- La capacidad de responder rápidamente a los errores encontrados en la batalla;
- Monitoreo en línea de problemas;
- Soporte técnico en contacto con los usuarios.
Ahora lo más importante. Sí, los libros de prueba te enseñan cómo probar todo, pero todas las circunstancias le dijeron a Anton que no todo necesita ser probado. Según Anton, estos tres días de reflexión, se sintió como Hamlet con su pregunta "Ser o no ser".
Reuniendo toda su voluntad en un puño, decidió qué ser. Y se negó a probar la funcionalidad sin importancia. Los probadores comenzaron a verter tareas en esos 250 puntos después del desarrollo inmediatamente en el lanzamiento. En serio
No todas las empresas estarían de acuerdo con ese paso, y casi todos los evaluadores que se niegan a evaluar hieren el rumor. Pero esta decisión permitió centrarse en lo realmente importante.
No realizar la prueba es un paso responsable y peligroso.
Si también quieres hacer esto:- La lista de funcionalidades críticas está disponible públicamente para que los desarrolladores puedan acceder a ella;
- Para evaluar el nuevo enfoque, agregue a Jira la relación "generada en => generado". Para que pueda rastrear cuántos errores pasan en tareas no comprobables;
- Como no es muy tonto probar la mayoría de las tareas, verifique un par de casos principales en ellas, pero en el lanzamiento para no retrasar el vertido;
- Funcionalidad crítica para probar de acuerdo con el esquema anterior.
¿Qué va a cambiar?- La mayoría de las tareas dejarán de patinar durante la fase de prueba;
- Los probadores solo se ocuparán de las tareas críticas del negocio;
- Lo importante se toma en las pruebas más rápido, ya que lo no importante ahora no interfiere en el tablero.
Que es tan malo- Los usuarios reales tienen más probabilidades de encontrar errores menores;
- La carga de soporte técnico está aumentando, porque los errores perdidos comienzan a venir de los usuarios.
¿Estaba herido?
Los chicos completaron todos los pasos descritos en seis meses. Sí, dolió, pero el resultado fue el siguiente:
El tiempo promedio que se tarda en completar una tarea se redujo a 19 días y está disminuyendo constantemente;
El flujo de tareas de prueba se reduce. Los probadores comenzaron a prepararse para probar características importantes en paralelo con el desarrollo;
El producto Dima dejó de ir por completo a Anton.
En lugar de conclusiones
No utilice nuestro enfoque en medicina o construcción de aviones. En situaciones que no están asociadas con un riesgo para la vida, pruebe sus decisiones y enfoques.
No le creas a los libros y deja de probar por el simple hecho de estarlo, simplemente porque está escrito en alguna parte.
Pregúntese si cumple con las expectativas del negocio y si cada elemento de su lista de tareas es realmente útil.
SuperJob estaba contigo. Conciencia a todos!