Comencemos con lo dulce y demos ejemplos de las prácticas de prueba.
Imagine una tienda en línea lista para su lanzamiento. Nada presagia problemas. Los especialistas en marketing desarrollaron una estrategia de promoción, se escribieron artículos en recursos especializados de Internet y se pagó publicidad. La gerencia esperaba hasta 300 compras semanales. La primera semana pasa, los gerentes registran 53 pagos. La gerencia de la tienda está furiosa ...
El gerente del proyecto se ejecuta en busca de razones: la falta de pensamiento de usabilidad? tráfico inapropiado? algo mas? Comenzamos a entender, estudiamos el sistema de análisis de datos. Resultó que 247 personas llegaron a la caja y solo 53 pagaron.
¡El análisis mostró que el resto no pudo hacer una compra debido a la dirección de correo electrónico!
Las pruebas del formulario de pedido se entregaron a un especialista novato. Hizo su mejor esfuerzo, ingresó en los campos "Nombre", "Correo electrónico", "Teléfono" todas las opciones posibles e imposibles que le dieron generadores en línea. Una semana después, todos los errores fueron encontrados y reparados. El lanzamiento ha tenido lugar. Pero entre las opciones consideradas no había una sola dirección de correo electrónico que contuviera menos de 8 caracteres después de @.
Entonces, los felices propietarios de mails @ mail.ru, @ ya.ru (y otros similares) no pudieron ingresar su correo y dejaron el sitio sin comprar. Los propietarios recibieron menos de 600 mil rublos, el presupuesto publicitario completo fue vaciado y la tienda en línea recibió un montón de críticas negativas.
¿Crees que este es un caso aislado? Entonces aquí hay otra historia de terror para el cliente.
A raíz del interés general en los pagos sin efectivo, la compañía de préstamos decidió introducir una nueva forma de transferir fondos: a la tarjeta bancaria del prestatario. Implementamos el formulario apropiado en la cuenta personal del administrador, probamos varias opciones de error en los campos para ingresar datos de la tarjeta, lo arreglamos y comenzamos a trabajar. Un mes después, la gerencia llegó a la información de que el 24% de los prestatarios potenciales que ya habían recibido la aprobación no solicitaron un préstamo hasta el final. Por qué Proporcionaron una tarjeta bancaria, cuyo número contenía 18 dígitos, en lugar de los prometidos y probados 16. Ni el sistema ni los gerentes podían registrar tales tarjetas, y los clientes se quedaron sin nada.
El proyecto piloto se implementó en 3 oficinas de la ciudad. El número promedio de préstamos mensuales en tres oficinas fue de 340. Resultado: la organización perdió al menos 612 mil rublos. ingresos
Estos son solo un par de ejemplos en los que los datos sintéticos pueden causar serias pérdidas en un proyecto. Muchos probadores ingresan datos sintéticos para probar varios proyectos, desde aplicaciones móviles hasta software. En este caso, los probadores mismos proponen situaciones de prueba, tratando de predecir el comportamiento del usuario.
Sin embargo, la mayoría de las veces ven al usuario no multidimensional, como en un cine con gafas 3D, sino incompleto, como si el niño pintara a un hombre pequeño en la hoja de un álbum.
Esto lleva al hecho de que el probador no cubre todas las situaciones de prueba posibles y no puede trabajar con una gran cantidad de datos. Y, aunque las pruebas se pueden llevar a cabo bien, no hay garantías de que el sistema no se caiga cuando un usuario real (a menudo ilógico e incluso impredecible) comienza a interactuar con el producto.
Hoy hablaremos sobre qué datos dar preferencia en el proceso de prueba: sintético o real.
Entenderemos en términos
Cada vez que realizamos una prueba, decidimos qué datos de prueba usaremos. Sus fuentes pueden ser:
- Copias de la base de datos de producción en el banco de pruebas.
- Base de datos de sistemas de clientes de terceros que se pueden usar en el actual.
- Prueba de generadores de datos.
- Creación manual de datos de prueba.
Las primeras 2 fuentes nos proporcionan datos de prueba reales. Son creados por procesos existentes por los usuarios o el sistema.
Por ejemplo, cuando nos unimos a un proyecto para desarrollar un producto web para una empresa de fabricación, podemos usar una copia de la base de datos 1C existente para las pruebas, que durante varios años ha recopilado y procesado todos los datos sobre operaciones y clientes. Al utilizar el módulo para generar y mostrar informes sobre pedidos completados, obtenemos información de 1C en el formato requerido y trabajamos con datos de prueba reales.
Llamamos a las fuentes de los puntos 3 y 4 "datos de prueba sintéticos" (dicho término se puede encontrar en pruebas extranjeras, pero rara vez se usa en el segmento de idioma ruso). Creamos dichos datos nosotros mismos para fines de desarrollo y pruebas.
Por ejemplo, recibimos una orden de una nueva plataforma de comercio electrónico para adquisiciones por parte de organizaciones estatales y municipales bajo 44 Leyes Federales. Aquí, se siguen reglas muy estrictas de protección de la información, por lo que el equipo no tiene acceso a datos reales. La única salida para las pruebas es crear un conjunto completo de datos de prueba desde cero. Incluso firmas digitales físicas que están destinadas únicamente a pruebas.
En nuestra práctica, rara vez se usa un tipo de datos, generalmente trabajamos con una combinación de ellos dependiendo de la tarea.
Para verificar las limitaciones y excepciones en el mismo sistema para la empresa fabricante, también utilizamos datos sintéticos. Con su ayuda, verificamos cómo se comporta el informe si no hay productos en uno de los pedidos. En una plataforma de comercio electrónico, combinamos datos sintéticos con libros de referencia reales OKPD2 y OKVED2.
Capacidades de datos sintéticos
¡En algunas situaciones, los datos sintéticos simplemente no se pueden prescindir! Veamos qué tareas se pueden usar del arsenal del probador:
1. Simplificación y estandarización.
A menudo, los datos reales son conjuntos de datos homogéneos: imagine que miles de personas con un conjunto de atributos, entidades legales de diferentes tipos, operaciones estándar y muchos otros tipos de entidades están registradas en el sistema. Entonces, ¿por qué pasar horas probando la misma entrada, si puede combinarlos en grupos y designar un "representante" para cada grupo?
En uno de los proyectos del año pasado, el cliente decidió fortalecer el equipo de evaluadores antes del próximo lanzamiento, para lo cual participó un equipo de nuestros especialistas. El producto contenía un formulario de registro modificado con muchos campos. Presentamos los formularios de prueba durante 30 minutos y pasamos aproximadamente la misma cantidad de tiempo. Paralelamente, se reveló que otro probador ya había probado este formulario, después de haber pasado 7 horas en él. Por qué Simplemente decidió ejecutar la prueba de acuerdo con los datos reales de 12 empleados de la lista de personal y no tuvo en cuenta que la prueba para un empleado cubre todos los atributos que son los mismos para cada perfil registrado.
Beneficio: 6 horas 30 minutos y esto es solo en una prueba.
2. Combinatoria y cobertura de prueba
A pesar de la gran cantidad de datos reales, es posible que no contengan varios casos posibles. Para garantizar la operatividad del sistema con varias combinaciones de datos de entrada, debemos generarlos nosotros mismos.
Volvamos al ejemplo anterior. El formulario de registro en la nueva versión se finalizó por una razón. El equipo del cliente, basado en las normas de la cultura corporativa, decidió hacer obligatorio el segundo nombre. Como resultado, todos los especialistas extranjeros en el estado de repente tuvieron un padre: Ivan (alguien dijo que escribiera Ivanovich hasta que lo arreglaran). El caso es divertido, pero si no tiene en cuenta alguna Lista de deseos o los parámetros de sus clientes en las pruebas, no se ofenda si estas personas no lo tienen en cuenta en sus costos / revisiones.
3. Automatización
En las pruebas automatizadas, los datos sintéticos son indispensables. Incluso los cambios aparentemente insignificantes en los datos pueden afectar el funcionamiento de un conjunto completo de ejecuciones de prueba.
Un ejemplo del sector bancario será ilustrativo aquí. Para verificar si la aplicación anota correctamente los números de cuenta bancaria en los documentos generados por ella, pasamos 120 personas / horas escribiendo autotests. No había acceso a la base de datos porque el número de cuenta se indicaba en la prueba automática. Las pruebas mostraron excelentes resultados y estábamos listos para extraer 180% + ROI de la automatización en el informe. Pero una semana después, la base de datos se actualizó con un cambio en el número de cuenta. Todas las pruebas automáticas, así como nuestros esfuerzos de automatización, terminaron de manera segura. Después de revisar las pruebas automáticas, el ROI final cayó al 106%. Con el mismo éxito, podríamos comenzar inmediatamente a probar con nuestras manos.
4. Mejora de la manejabilidad
Usando datos sintéticos, sabemos (en el peor de los casos, suponemos) qué tipo de respuesta esperar del sistema. Si se realizan cambios en la funcionalidad, entendemos cómo cambiará la respuesta a los mismos datos. O podemos ajustar los datos para obtener el resultado deseado.
En uno de los proyectos, nuestro equipo comenzó a realizar pruebas utilizando datos reales de la base de datos de contraparte del cliente. La base de datos fue refinada activamente, pero en ese momento fue compilada extremadamente descuidadamente. Perdimos el tiempo tratando de entender dónde está el error, en la funcionalidad o en la base de datos. La solución fue simple, componer una base de datos sintética, que se ha vuelto más corta, pero más adecuada y más informativa. La prueba de esta funcionalidad se completó en 12 personas / horas.
¿Cuáles son las desventajas?
Los datos sintéticos pueden parecer omnipotentes. Así es, hasta que te encuentres con el factor humano. Los datos sintéticos son creados intencionalmente por personas y este es su principal inconveniente. Físicamente, no podemos pensar en todos los posibles escenarios y combinaciones de factores de entrada (y nadie canceló la fuerza mayor). Y aquí la ventaja sigue siendo para los datos reales.
Los beneficios de trabajar con datos reales
¿Qué ventajas vemos al trabajar con datos reales? 4 pruebas de nuestra experiencia:
1. Trabajar con grandes cantidades de información.
La operación real del sistema nos proporciona millones de operaciones. Repetir el trabajo simultáneo de miles de usuarios o la generación automática de datos no será capaz de ningún equipo de especialistas.
Prueba: creamos una mini base de datos sintética que, como nos parecía, cumplía con todos los criterios de la base existente del cliente. Con una base sintética, todo funcionó muy bien, pero tan pronto como ejecuta pruebas con una base real, todo cayó. En pocas palabras: si no puede tener en cuenta todos los matices de una muestra de datos reales, no pierda el tiempo generando datos sintéticos.
2. Usando una variedad de formatos de datos
Texto, sonido, video, imágenes, archivos ejecutables, archivos: es imposible predecir lo que el usuario decide cargar en el campo del formulario. Se pueden ignorar los consejos sobre formatos aceptados, y el equipo de desarrollo no puede implementar la prohibición de descargar. Como resultado, se prueban los escenarios deseados. Por ejemplo, que en el campo de descarga de sonido, es posible descargar un archivo mp3 y que descargar un archivo ejecutable no dañará el sistema. Los datos reales nos ayudan a rastrear excepciones.
Prueba: probamos el campo de carga de fotos en el perfil del usuario. Probamos los formatos gráficos más comunes de la base de datos, además de varios archivos de video y texto. Compilación sintética cargada perfectamente. En el uso real, resultó que cualquier intento de descargar un archivo de sonido causa un error. El formulario de registro completo se bloqueó sin la capacidad de reemplazar el archivo. Incluso una actualización de página no se guardó.
3. Imprevisibilidad del comportamiento del usuario.
Aunque muchos especialistas en control de calidad han logrado crear y analizar situaciones excepcionales, seamos honestos: nunca podremos predecir con precisión cómo se comportará una persona y los factores que la rodean. Y puede comenzar apagando Internet en el momento de la operación y terminar con operaciones con el código del programa y los archivos internos.
Prueba: en nuestra empresa cada año los empleados se someten a una certificación, donde, entre otras cosas, evalúan sus habilidades en un cuestionario especial. Las estimaciones se acuerdan con el jefe y, en función de ellas, se calcula el grado (nivel) del especialista. Antes del lanzamiento, el módulo fue probado completamente, todo funcionaba como un reloj. Pero una vez, al momento de guardar los resultados, se realizó un ataque ddos en el sistema, como resultado de lo cual solo se guardó parte de los datos, y los intentos posteriores de guardar solo duplicaron los errores. Sin una situación real, no habríamos rastreado un error tan grave.
4. Actualizaciones del sistema
Es muy importante comprender cómo se comportará el sistema durante la actualización, cuáles son los posibles riesgos, qué puede "no despegar". En programas como 1C, donde hay una gran cantidad de directorios y enlaces, el tema de las actualizaciones es especialmente grave. Y aquí la mejor opción sería tener una copia nueva de la versión de producción, probar la actualización y solo luego ser lanzada.
Prueba: el caso es bastante común. Proyecto en el campo de los servicios de factoring. La criticidad de la pérdida y distorsión de datos es abrumadora, y cualquier sospecha de la relevancia de los datos reproducidos por el sistema puede detener a toda la oficina. Y aquí nuestro especial torcidamente lanza la próxima actualización inmediatamente al producto, sin capturar las últimas 10 versiones de las compilaciones.
Llegaron a las 18-00 fijadas en la mañana, a las 11 en punto. Debido a la finalización fallida y la incomprensión con las versiones, el trabajo de las divisiones de la compañía se congeló por completo durante 2 horas. Los gerentes no podían procesar los contratos actuales y registrar otros nuevos.
Desde entonces, hemos estado trabajando con tres stands sin falta:- Desarrollar Aquí se presentan mejoras, se están desarrollando la anarquía y la anarquía, llamadas pruebas de excepción. Los ingenieros de control de calidad trabajan principalmente con datos sintéticos, los reales se infunden con poca frecuencia.
- Prelanzamiento. Cuando se implementen y prueben todas las mejoras, se dirigirán a esta rama. Una versión con una venta también se lanza preliminarmente aquí. Por lo tanto, probamos la actualización y el funcionamiento de nuevas funciones en condiciones de combate condicional.
- Producción. Esta es una versión funcional y de combate del sistema con el que trabajan los usuarios finales.
Entonces, ¿qué datos y cuándo trabajar?
Compartimos 3 ideas de nuestro trabajo con datos reales y sintéticos:
1. Recuerde que la elección del tipo de datos depende de los objetivos y la etapa de prueba. Entonces, al desarrollar un nuevo sistema, solo podemos operar con datos sintéticos. Para cubrir varias combinaciones de condiciones de entrada, también, con mayor frecuencia, recurrimos a ellas. Pero la reproducción de alguna excepción complicada relacionada con el comportamiento del usuario requerirá registros reales. Lo mismo se aplica al trabajo con directorios y registros generalmente aceptados.
2. No olvide optimizar su trabajo con datos de prueba. Siempre que sea posible, use generadores, cree registros comunes de las entidades principales, guarde y use las copias de seguridad del sistema a tiempo, implementándolas en el momento adecuado. Entonces, la preparación para el próximo proyecto no será una fuente de melancolía y tristeza para usted, sino una de las etapas del trabajo.
3. No vaya al lado de los sintéticos sólidos, pero no se centre en datos reales. Use un enfoque combinado para probar datos para no perder errores, ahorrar tiempo y mostrar los máximos resultados en su trabajo.
A pesar del hecho de que los sintéticos están profetizando un gran futuro, y los científicos han visto en los datos sintéticos una nueva esperanza para la inteligencia artificial, los sintéticos no son una panacea para las pruebas. Este es solo otro enfoque para generar datos de prueba que puede ayudarlo a resolver sus problemas y puede generar otros nuevos. Conocer las fortalezas y debilidades de los datos reales / sintéticos, así como la capacidad de aplicarlos en el momento adecuado, es lo que lo protege de pérdidas, tiempo de inactividad o acciones legales. Espero que hoy te hayamos ayudado a ser un poco más seguro. O no?
Hablemos Cuéntanos en los comentarios sobre tus casos de trabajo con datos de prueba sintéticos y reales. Veamos quién de nosotros es más: ¿realistas o sintéticos? ;)
Victoria Sokovikova.
Analista de Pruebas en Laboratorio de Calidad