Mire el video, lea la transcripción y escriba su opinión sobre las preguntas expresadas en los comentarios. Vamos a resolverlo juntos: ¿ser o no ser?
Discusión número uno
Códigos de tiempo 0:56 - ¿Las pruebas siempre son necesarias?
2:00 - ¿Por qué realizar pruebas cuando necesita lanzar funciones al mercado lo antes posible?
3:24 - ¿Es posible probar solo la funcionalidad básica o una parte de la aplicación?
5:29 - Criterios para probar la funcionalidad
7:28 - ¿En qué momento una empresa emergente o de subcontratación debe dejar de lanzar funciones y comenzar a perder tiempo en pruebas?
La reunión comenzó de inmediato con una caliente, con discusiones. Por lo tanto, presentaremos a los participantes en nuestra discusión en línea:
- Dmitry Voronin, ingeniero jefe del equipo Speed (Avito).
- Yuri Chechetkin, desarrollador móvil (Revolut)
- Dmitry Manko, desarrollador de Android (Citymobil)
- Nina Semkina, programadora sénior (Yandex.Money)
- Vladimir Genovich, programador principal (Yandex.Money)
- Dmitry Zhakov, probador (Yandex.Money)
Nina Semkina: Mucha gente dice que las pruebas deben introducirse en los proyectos ... Pero todo el mundo entiende que es muy caro. Es muy costoso dedicar tiempo a los desarrolladores y un montón de recursos cubriendo todo el código con pruebas. ¿Las pruebas siempre deben realizarse?
Dmitry Manko: ¿Qué vas a probar?
Nina Semkina: aplicación para Android. ¿Cuándo debo comprender que es necesario probar el 100%?
Dmitry Manko:Si el mercado no espera la aparición de ninguna funcionalidad, entonces, desde el punto de vista del desarrollo o desde el punto de vista de la cobertura, las pruebas se pueden simplificar o descuidar por completo. Todo depende del producto. Si estamos haciendo una calculadora con 2 funciones, lo más probable es que pasamos por una serie de casos de prueba más de una vez. Por lo tanto, se pueden omitir las pruebas, la aplicación se puede comercializar más rápidamente y se puede reducir el tiempo de comercialización.
Nina Semkina:Siempre tenemos una carrera por el tiempo de comercialización, el mercado siempre requiere un montón de funciones y no podemos frenarlas. Especialmente cuando se trata de un proyecto que recién comienza y necesita ser lanzado al mercado ahora mismo, no tenemos nombre, competimos con otras empresas. ¿Qué nos importa probar en este momento? Necesitamos proporcionar funciones a nuestra aplicación y desecharlas más rápido, de lo contrario se volverán obsoletas en 3 semanas. ¿Por qué probarlos?
Dmitry Voronin:De hecho, la velocidad de desarrollo en algún momento comienza a depender de la cobertura de la prueba. Si, por ejemplo, una empresa está vinculada arquitectónicamente a una pantalla principal, donde se encuentran todas las funciones principales, y se realizan cambios allí muchas, muchas veces, entonces, sin pruebas, puede comenzar a moverse allí más lentamente, incluso con un gran "flujo de funciones". Tan pronto como hay señales, parece que a menudo regresa a la regresión, es decir, una razón para pensar en el hecho de que algo anda mal con el recubrimiento y no está tomando acciones reactivas. Por ejemplo, algo se rompe a menudo, lo que significa que este lugar no se está probando como debería.
Nina Semkina:¿Puedo llegar a la conclusión de que solo la funcionalidad básica debe probarse constantemente y las características deben estar conectadas "en un punto"? Dejemos que estas características individuales estén con errores, pero tal vez existan hoy y mañana no. ¿Puedo probar solo una parte de la aplicación?
Dmitry Manko: Prefiero decir que vale la pena probar las partes clave. Lo que es importante desde el punto de vista comercial para este producto. Y si hay funciones con errores, están ubicadas en algún lugar separado y no afectan algo en común, entonces idealmente ciérrelas con un interruptor remoto. Y si, según los análisis, ve que realmente hay errores y los usuarios se quejan, desactive esta función.
Dmitry Voronin:Dima tocó un buen tema, que las pruebas no son la única herramienta de control de calidad que tiene un desarrollador. Siempre debe recordar que además de las pruebas unitarias y de integración, las pruebas manuales, hay y debe haber monitoreo. Y hay formas de implementar y revertir sus cambios. Si tiene todas estas prácticas de ingeniería, entonces, en principio, puede descuidar algunas herramientas en favor de otras, si la velocidad se beneficia de esto. Pero, en general, siempre se considera de buena forma si el desarrollador tiene una cultura de prueba, que es más cómodo y más confiable para él entregar cambios para que haya probado la funcionalidad que debe realizar. En nuestra empresa, es costumbre dejar un código de este tipo, en el que luego puede realizar cambios fácilmente y ejecutar pruebas rápidamente para comprender que no ha estropeado lo que ya sucedió.
Nina Semkina: En el chat escriben que necesitas probar qué genera ingresos. Y cuando los costos de prueba son menores que las posibles pérdidas por funcionalidad que no funciona. En principio, este es un buen criterio para comprender qué es exactamente lo que se debe probar. ¿Podría nombrar algún otro criterio para probar una funcionalidad específica?
Dmitry Manko: Los criterios se pueden identificar mediante análisis. Por ejemplo, si corrige las funciones que se utilizan con más frecuencia, también es aconsejable probarlas para que los usuarios encuentren errores lo menos posible. Si los errores están en lugares raros, entonces este es un pequeño problema. Y si la prohibición está en la pantalla de autorización, puede que no sea crítico, pero sigue siendo un error que todos verán. Y esto ya es un riesgo para la reputación.
Dmitry Zhakov:Generalmente, se necesitan pruebas. No debemos olvidar que las pruebas son una prueba de los requisitos que imponemos a un producto. Si algo no cumple con los requisitos, entonces esto es un problema, error, problema. Todos los casos de prueba y las pruebas se pueden automatizar, y si no hay suficiente tiempo, primero vale la pena verificar los momentos críticos y luego todo lo demás. Por ejemplo, si tiene un lanzamiento mañana y su empresa quiere una función mañana, entonces verifica la funcionalidad más crítica. Y si tiene suficiente tiempo, puede permitirse el lujo de comprobar los casos medios y bajos. Es más una cuestión de si sus pruebas serán manuales o automatizadas. Ya sean métricas o pruebas de IU, completamente verificables por un robot.
Nina Semkina:Ahora todos hablamos en nombre de grandes empresas con muchos recursos y oportunidades. Y si tenemos en cuenta el punto de vista de las pequeñas empresas, las startups, que cuentan con tiempo y recursos limitados. Creo que al principio todo el mundo sacrificará las pruebas allí. ¿En qué momento podemos entender que este es el hito crítico en el que debemos detener y dejar de implementar funciones y gastar recursos en pruebas?
Dmitry Manko:Puedo compartir mi opinión, ya que vengo de una empresa de outsourcing. La subcontratación se trata principalmente de dónde se venden las horas de trabajo, y las pruebas son realmente caras allí. A veces cuesta más que desarrollar la propia funcionalidad. Estas empresas de subcontratación, cuando el cliente está esperando la aplicación y "la deja a un lado", no son famosas por realizar pruebas. En nuestro equipo, nos enfrentamos a la siguiente situación. El producto es un menú para bares, donde las promociones se utilizaron para un gran número de casos (cumpleaños, 2 por 1, estudiante, etc.). Y notamos que esta funcionalidad de stock se rompía todos los meses durante un año. Y luego, las pruebas unitarias describieron todos los casos, idealmente. Entendimos cómo funciona todo (había alrededor de 70 casos de prueba). Le ganamos a este producto, pero, por supuesto, no sería posible hacer esto en todas partes.
Yuri Chechetkin:Mi experiencia de trabajo en grandes empresas (Yandex, Alfa-Bank, Revolut) en fintech, donde la criticidad de cualquier error simplemente se sale de escala. Dicho esto, tengo experiencia en una startup, e incluso allí, las pruebas eran absolutamente necesarias. Creo que no importa si es una startup o no, porque el desarrollador debe ser responsable de su código, y las pruebas son una garantía de que este código funciona. Un desarrollador es principalmente un ingeniero que es responsable del producto que se está desarrollando. Por lo tanto, debe escribir pruebas no porque sea necesario, sino porque deberían ayudarlo. Si se trata de pruebas escritas para mostrar, esto puede ralentizar el desarrollo. Y si necesita pruebas y las comprende usted mismo, debe escribirlas. Si un desarrollador escribe código y está seguro de que funciona sin pruebas, entonces esto es un riesgo y es su elección. Pero sigo pensandoque el desarrollador no debe correr ese riesgo y debe cubrirse y cubrir todo con pruebas.
Nina Semkina: Entonces, decidimos que teníamos que probar nuestro código de alguna manera, analizaremos este tema con más detalle. Doy ahora la palabra a Vladimir Genovich con su informe .
Discusión número dos
Códigos de tiempo 0:09 - ¿Cómo eliminar la carga de regresión del control de calidad antes de los lanzamientos? ¿Tienen las empresas una estrategia para mejorar la estabilidad de las aplicaciones?
4:25 - ¿Tiene sentido usar simulacros u objetos falsos en las pruebas de IU?
8:05 - Pruebas en usuarios: ¿es aceptable o no?
Nina Semkina: Durante el informe, recibimos una pregunta en el chat, y es de él que me gustaría continuar nuestra discusión. ¿Cómo eliminar la carga de regresión del control de calidad antes de los lanzamientos? ¿Qué prácticas utilizan nuestros oradores al elegir los lugares para las pruebas? ¿Tienen las empresas una estrategia para mejorar la estabilidad de las aplicaciones y descargar a los especialistas en control de calidad?
Dmitry Zhakov:Nuestra estrategia es que probamos todo. Porque somos la última frontera, como empleados antes que como usuarios. Por lo tanto, solo damos una aplicación de este tipo al cliente, que funciona de manera estable siempre y en todas partes. La única cuestión es la velocidad. Inicialmente, la ejecución manual nos llevó mucho tiempo, hasta una semana. Pero gracias a la automatización, hemos conseguido que el lanzamiento dure una media de un día. Por lo tanto, si está desarrollando alguna funcionalidad, debe aceptar que usted o los evaluadores escribirán automáticamente pruebas automáticas. Y algunos casos específicos de dispositivos móviles que no puede automatizar solo tendrán que verificarse en regresión, y el robot verificará el resto. Por lo tanto, descargará probadores, se dedicarán a trabajos de investigación más interesantes y le dará al robot toda la rutina: hacer clic en los scripts.
Yuri Chechetkin: La mayoría de las grandes empresas rechazan el control de calidad y las pruebas manuales. Este no es exactamente un camino revolucionario, sino una pequeña reliquia del pasado. Y, por ejemplo, en mi empresa, donde ahora trabajo, ni siquiera se pronuncia una palabra como regresión. No tenemos un departamento de control de calidad en absoluto.
Vladimir Genovich: ¿Probablemente lo automatizaste?
Yuri Chechetkin: No exactamente, solo estaba en las etapas iniciales del proyecto, y luego se fue.
Vladimir Genovich: Ejecutas pruebas de interfaz de usuario, ¿verdad?
Yuri Chechetkin: Hay pruebas de IU, por supuesto.
Vladimir Genovich: ¿ Y las pruebas unitarias? Entonces, ¿ejecutar estas pruebas en el lanzamiento no es una regresión?
Yuri Chechetkin:Sí, esto es una regresión, pero no hay pruebas manuales de las que estamos acostumbrados a hablar. Y ese es un enfoque bastante interesante. Se pone serio y transforma al desarrollador de un "niño" que escribe código y se lo da a los probadores, en un ingeniero más maduro e independiente que es responsable de su propio código. En cuanto a las cosas visuales, la revisión puede realizarla un diseñador o un PO. Y hay cosas como pruebas de captura de pantalla, como Facebook. Así que parece que ahora las empresas alimentarias pueden prescindir del control de calidad. Y los probadores mismos pueden hacer un trabajo más interesante. Por supuesto, hay una historia ligeramente diferente en la subcontratación: venden horas de trabajo y el control de calidad se puede vender como un servicio adicional.
Dmitry Zhakov:Resulta que tiene regresión, simplemente se entrega a la automatización y tiene personas que se dedican al trabajo de investigación de su aplicación. Las pruebas pueden ser no solo UI, sino también diferentes.
Yuri Chechetkin: Sí, por ejemplo, probando en usuarios.
Nina Semkina: Antes de tocar este tema tan peligroso, me gustaría leer la siguiente pregunta de nuestros oyentes. ¿Tiene sentido usar simulacros u objetos falsos en las pruebas de IU?
Dmitry Voronin:Tiene sentido, y sin ellos en ninguna parte. Porque las pruebas de IU completamente integradas son algo muy poco confiable. Y nunca puede confiar en una prueba que tiene 30 sistemas, cada uno con un montón de puntos de falla al ejecutar una solicitud de extracción. Tales pruebas no son viables. Y nadie en ninguna empresa podría hacer que esas cosas funcionen. Por lo tanto, las pruebas de IU son la pesadilla del desarrollo móvil. Si es posible, es mejor probar sin IU. Pero debido a que nos vemos obligados a vivir con un framework, y la única alternativa es algún tipo de robótica, y en iOS, ni siquiera esto. Y para verificar la interacción con al menos uno de los sistemas importantes para nosotros, ejecutamos todo en el dispositivo. La interfaz de usuario está aquí en la medida en que, debido a nuestra inmadurez de desarrollo, queremos capturar tanto como sea posible para verificar cómo hace clic el usuario, estamos más tranquilos. Me parece,que después de un tiempo esto se convertirá en cosa del pasado y ya no tendremos miedo a las burlas, clics y no lucharemos con el sistema para que revise todo como debe, porque de todos modos no lo revisaremos todo. Puede haber errores visuales que no se comprobarán en ninguna prueba de IU. Por lo tanto, creo que se puede y se debe hacer burla en las pruebas de UI, y el principal objetivo de esto es aumentar la estabilidad de esta herramienta, para llevarla a tal estado que sea útil. Y el beneficio real en este caso es asegurarse de que no haya regresiones. Y cualquier instrumento que se enrojezca se convierte en la segunda "D" del informe anterior de Vladimir Genovich, cuando dejamos de confiar. Esto sucede cuando una gran cantidad de valores aleatorios comienzan a llegar a nuestra prueba. Y tal prueba no da ninguna confianza en uno mismo, sino que solo da falsas esperanzas de que algo ha sido probado.
Dmitry Zhakov: Aproximadamente el 70% de nuestros casos están automatizados y no usan una sola simulación en la aplicación. Podría ser más fácil migrarlos al backend. Por ejemplo, si se refiere al número de tarjeta, esperaría que no se le solicite 3DS. Es decir, la aplicación no sabe que está bloqueada. Creo que este es un problema de infraestructura.
Nina Semkina: Antes de pasar al siguiente informe, me gustaría que mencionáramos un tema escurridizo: las pruebas de usuario. Muchos pecan esto: siempre quieren e inyectan ... ¿Qué piensas de esto? ¿Es posible darse el lujo de implementar a los usuarios a escondidas, recopilar los bloqueos de ellos y solucionarlo usted mismo? Y después de probarlos, lanza buenas versiones completas. ¿O es generalmente inadmisible? ¿O existen límites razonables?
Yuri Chechetkin:En Revolut practicamos esto un poco en el sentido de que no va directamente a la batalla, sino a usuarios reales. La demostración también es una prueba en los usuarios, y durante la demostración surgen preguntas sobre el flujo y así sucesivamente. En esta etapa, puede haber preguntas sobre el diseño y la mecánica general. Entre otras cosas, hay una renovación interna: la empresa es grande, tiene más de 1000 personas y podemos implementarla entre colegas. Esta es una prueba de usuario, pero no externa, y parece segura. Y luego se puede implementar para un pequeño porcentaje de usuarios reales fuera, pero con la capacidad de cerrar esta función con un interruptor. ¿Qué crees que podría salir mal durante estas etapas?
Dmitry Manko:En nuestra realidad, las cosas pueden salir mal. No importa cuánto intentemos llevar a cabo bien estas etapas, en cualquier caso, los casos saltan cuando necesitamos monitorear el análisis de fallas. El lanzamiento no termina con el hecho de que lo enviamos a la tienda, han pasado todas las etapas, todo está bien con nosotros. Debes seguir observando cómo se comporta la aplicación.
Yuri Chechetkin: Definitivamente sí. En nuestro caso, tenemos una demostración, implementación interna y pruebas para el 5% de los usuarios en lugar de pruebas manuales. Por supuesto, después del lanzamiento de la función, debe buscar. El balanceo no debe ser 100% inmediato, este es el principal mecanismo de defensa.
Dmitry Voronin:Google se encarga de la cuestión ética de las pruebas de usuario. Apple no parece tener esto. Hay canales de distribución especiales, como sabes (alfa, beta ... producción). Cualquiera puede ingresar a la prueba beta y está de acuerdo con un formulario comprensible, que dice que está de acuerdo en que puede recibir una versión inestable del producto. Por eso quiere ser voluntario y ayudar a la empresa a mejorar el producto. Tan pronto como le digamos abiertamente a una persona sobre esto, creo que este problema debería eliminarse y no deberíamos tener miedo de lanzar una versión en la que no estamos 100% seguros. Y es aún mejor cuando tenemos comentarios desde allí, y con cada lanzamiento tan inestable, mejoramos este proceso. Si una empresa tiene procesos que rastrean las tendencias de calidad en beta, las cosas solo deberían mejorar.Y esto también es una ventaja para los usuarios: serán los primeros en recibir funciones. Estos son en su mayoría usuarios motivados y leales a su producto, y ellos mismos querrán probar las cosas nuevas que aparecen en la aplicación. E incluso estarán dispuestos a sacrificar algo por ello.
Nina Semkina: Entendemos que cuando hablamos de una audiencia fiel, es leal siempre que no afecte sus intereses personales. Así es como podemos implementar funciones con pequeños bollos adicionales, que incluso si se caen, estos usuarios no estarán muy molestos. Pero incluso si esta persona confirmó que está lista para tomar la versión de prueba, pero algo grave le sale mal (por ejemplo, se cancelará el dinero extra), entonces ya no será leal. Y cuanto más grande sea la empresa, más duramente responderá el usuario sobre el producto.
Vladimir Genovich:Pero, ¿qué pasa con el adoptante temprano, que te ama, sin importar cómo se equivoque la empresa? Y, lo más probable, esta empresa podrá recuperar las pérdidas. De acuerdo, si desplegamos algo, le decimos al usuario: “Escucha, tenemos mucho miedo. Y puedes perder 1000 rublos. Pero te lo reembolsaremos ". Lo más probable es que dicho usuario lo haga bajo su propio riesgo y riesgo, y si pierde el dinero, no le diremos más adelante: "Bueno, usted mismo tiene la culpa". Por tanto, creo que, incluso en el caso de una aplicación bancaria, podemos ayudar a los usuarios.
Dmitry Zhakov:Y si tiene muy pocos probadores beta, puede usar las pruebas A / B con la ayuda de archivos de configuración para habilitar / deshabilitar alguna función, de modo que, en caso de falla, pueda deshabilitar algo inmediatamente y probarlo según sea necesario. Como recordamos, es muy difícil hacer retroceder en el móvil, por lo que es mejor revisar todo al máximo antes del lanzamiento.
Vladimir Genovich: O escribe en React Native))
Nina Semkina: Interrumpiré nuestra conversación, ya que ha llegado el momento del próximo informe. Dima, te doy la palabra.
Discusión número tres
Códigos de tiempo 0:05 - ¿Cómo mejorar las pruebas de regresión? ¿Cómo y cuándo se introducen las pruebas en el desarrollo de funciones (experiencia de Avito)?
10:43 - ¿Dónde persiguen las pruebas unitarias: en CI o localmente antes de impulsar?
Nina Semkina: Me gustaría comunicarme con Dima Voronin para conocer su opinión y su experiencia sobre cómo mejoraron las pruebas de regresión en la empresa y cuándo introducen las pruebas al desarrollar funciones.
Dmitry Voronin:Realmente tengo algo que compartir. Esta es una historia de cinco años sobre cómo lidiar con la regresión manual. Y esto es en parte una continuación de la respuesta a la pregunta que teníamos entre los 2 primeros informes. Esta pregunta trata sobre qué hacer si tiene regresión manual. Porque no todo el mundo podrá repetir la experiencia Revolut. Los muchachos son buenos tipos que cortaron del hombro y lograron hacerlo de manera confiable. Se necesita mucho coraje, una buena cultura de desarrollo y, lo que es más importante, comprender a los líderes del desarrollo que no se sienten locos por este enfoque. Esto sucede porque hay inercia en nuestro trabajo y puede resultar difícil cambiar los cimientos, especialmente en las grandes empresas. El ejemplo de Revolut demuestra que si funciona, entonces es al menos más rápido que la regresión manual, y cada desarrollador comienza a hacerse las preguntas correctas.Es decir, comienza a ser responsable de la mayor parte del ciclo de lanzamiento, es decir, no hasta el momento en que comete los cambios, pero como cualquier ingeniero adulto, también lidera el producto en la etapa de lanzamiento.
Que paso con nosotros Estábamos en el punto en el que tuvimos una regresión manual realizada por 5 personas durante 12 días hábiles, y sin eso, la aplicación móvil no funcionaría. Era 2015. Y en ese momento no teníamos una sola prueba de IU automatizada. Escribimos pruebas unitarias casi desde el principio y escribimos de forma bastante activa. Vladimir en su informe habló de 10 segundos y 1000 pruebas; me da miedo imaginar cuando pasamos un momento así en 2014. Ahora tenemos 12.000 unidades de pruebas, y no toman 10 segundos, esto tampoco es una pieza gratuita. Aunque todos los ingenieros comprenden y escriben pruebas, hubo un momento complicado. Todas estas pruebas unitarias no prueban ni un solo gramo sobre errores en producción y cómo se comporta la aplicación. Es decir, las pruebas capturan el comportamiento, facilitan la realización de cambios y brindan retroalimentación,lo estás haciendo bien. El problema es que existe un departamento de control de calidad. Por supuesto, este no es el problema. El problema es que tienen la tarea de proporcionar un cierto nivel de calidad. Y están acostumbrados a llegar a este nivel, asumen esta responsabilidad. Y es difícil dar vuelta este momento si no viene desde el principio de su producto. ¿Qué recetas hay? Lo más correcto es no activar el modo difícil cuando despedimos a todos y todo se hace cargo de la automatización. Este es probablemente el enfoque más aterrador e inmaduro que he visto. ¿Qué está mal con eso? Primero, la calidad de las pruebas se perderá durante algún tiempo. En segundo lugar, todos los procesos se destruyen y los nuevos no se crean rápidamente.Y están acostumbrados a llegar a este nivel, asumen esta responsabilidad. Y es difícil convertir este momento si no viene desde el principio de su producto. ¿Qué recetas hay? Lo más correcto es no activar el modo difícil cuando despedimos a todos y todo se hace cargo de la automatización. Este es probablemente el enfoque más aterrador e inmaduro que he visto. ¿Qué está mal con eso? Primero, la calidad de las pruebas se perderá durante algún tiempo. En segundo lugar, todos los procesos se destruyen y los nuevos no se crean rápidamente.Y están acostumbrados a llegar a este nivel, asumen esta responsabilidad. Y es difícil convertir este momento si no viene desde el principio de su producto. ¿Qué recetas hay? Lo más correcto es no activar el modo difícil cuando despedimos a todos y todo se hace cargo de la automatización. Este es probablemente el enfoque más aterrador e inmaduro que he visto. ¿Qué está mal con eso? Primero, la calidad de las pruebas se perderá durante algún tiempo. En segundo lugar, todos los procesos se destruyen y los nuevos no se crean rápidamente.la calidad de las pruebas se perderá durante algún tiempo. En segundo lugar, todos los procesos se destruyen y los nuevos no se crean rápidamente.la calidad de las pruebas se perderá durante algún tiempo. En segundo lugar, todos los procesos se destruyen y los nuevos no se crean rápidamente.
¿Qué hemos hecho? Comenzamos nuestra optimización escribiendo pruebas de IU que reemplazan la regresión. Es decir, estas son pruebas de infraestructura completas que tocan el backend con los usuarios de prueba. Y, de hecho, el resultado de este trabajo fue, como saben, todo tipo de marcos populares, por ejemplo, Kaspresso. Esto es exactamente lo que pusimos cuando comenzamos. Dejamos atrás un montón de artefactos que pueden ayudar a los desarrolladores. Y es por eso que ahora es más fácil comenzar a probar. También colocamos varios corredores en el código abierto, y todos pueden ver cómo trabajamos con ellos. Pero no nos olvidamos de las pruebas manuales, de su optimización y de cómo estos dos departamentos comienzan a fusionarse en un proceso efectivo. Probablemente el punto B sea el estado Revolut. Pero nuestro camino del punto A al punto B, como muchas otras empresas,toma mucho tiempo. Ahora estamos en la etapa en la que QA desempeña el papel de investigadores, se sumergen más en el producto, trabajan en requisitos funcionales, escriben autotest.
Lo más interesante de la práctica de mejorar la regresión manual es el análisis de impacto. Es decir, un intento de responder a la pregunta: "¿Qué ha cambiado en esta versión?" Y qué podemos probar y qué podemos implementar con tranquilidad en las siguientes etapas. El análisis de impacto es una pregunta difícil, porque cuando tienes un ciclo de lanzamiento grande, es decir, te liberan por 2-3 meses, entonces el análisis de impacto siempre te responderá igual, porque durante ese tiempo, casi ninguna parte de la aplicación no ha sido tocada. Pero si acorta este ciclo de lanzamiento a una semana, o incluso mejor a un día, entonces el análisis de impacto muestra cosas bastante adecuadas, deja marcas que ayudarán a optimizar la regresión manual. Hemos aplicado esta práctica con bastante éxito. Al principio hubo errores, pero redujimos la cantidad de pruebas manuales una sola vez.
La siguiente práctica es optimizar el modelo de prueba. Curiosamente, pero en las pruebas también hay legado: las pruebas se escriben, pero pueden no ser muy óptimas, luego se agregó algo más allí y los casos de prueba no se procesaron para esto ... Con un análisis detallado, resultó que se puede acortar varias veces número de escenarios de prueba.
Estas tres direcciones nos permitieron llegar al punto en que lo lanzamos a beta una vez al día, una vez a la semana llega al 100% de los usuarios, no hay regresión manual. Espero que esta historia motive a las empresas, que no están contentas con su estado de lanzamiento, a actuar, para que solo presionen el botón de lanzamiento en el futuro, todo va a los usuarios y todos miran solo las listas.
Yuri Chechetkin:Estas son, por supuesto, no solo las prácticas de Revolut, sino también en todo el mundo, son utilizadas por Google, Facebook, etc. Estoy de acuerdo en que esta debería ser una transición sin problemas. Y cuando muchos se convierten en PO o pasan al control de calidad automatizado, todo se vuelve un poco borroso, evoluciona y se convierte en algo dicho. Y en Rusia, sin embargo, esta tendencia apenas está comenzando. Y como bien dijo, debería estar lo más sano posible.
Nina Semkina: Había tal pregunta. ¿Quién ha realizado las pruebas unitarias y dónde? ¿En CI o localmente antes de presionar?
Yuri Chechetkin: Parece que conducir localmente es tarea del desarrollador, es decir, no debes hacerlo a la fuerza. Para mí es obvio que debería haber un 100% en IC.
Nina Semkina: ¡ Gracias a todos los participantes por la discusión! Doy la palabra a nuestro oradorDima Manko con su informe.