Hola queridos lectores. Hoy nos gustaría coincidir con el lanzamiento del curso "Python QA Engineer" . Anticipando posibles preguntas, advertimos que no hay una palabra sobre Python en el artículo, pero sin embargo encontramos este material útil para los evaluadores, por lo que decidimos compartirlo con usted.
No es factible probar hasta el más mínimo detalle del código, por lo tanto, las pruebas de regresión deben llevar a cabo una verificación exhaustiva y centrarse en un área específica en su totalidad. El objetivo principal es garantizar que ni un solo error de regresión dañará un proceso comercial crítico. Es este esfuerzo el que hace posible capitalizar la automatización. Un enfoque de prueba automatizado destinado a reducir los errores de regresión ayudará a recorrer un largo camino hacia la construcción de buenas relaciones con los clientes y aumentar el valor de la marca.
Mi equipo es responsable de probar una aplicación de contabilidad que utiliza cálculos sofisticados y anota entradas en el libro en el sistema de contabilidad. Todo esto es un flujo de trabajo, y cerrar libros todos los meses es lo más importante.
Con cada lanzamiento, hay algunos cambios en los cálculos, por ejemplo, para la cuenta puede ser necesario aumentar el débito o crédito, o el valor existente puede dividirse entre las dos cuentas. Tales cambios en una aplicación compleja, que tiene muchas dependencias internas y externas, a menudo conducen a un comportamiento impredecible, incluidos errores de regresión, en lugares inesperados y aparentemente no relacionados.
Tratemos con un error de regresión, a veces se le llama incidente crítico o problema de producción. Después de trabajar durante varios años en la industria del software, se da cuenta de que el error de regresión que se filtró a la producción es mucho más importante que la nueva función que funciona incorrectamente. El hecho es que la nueva función aún está oculta, por lo tanto, cuando se rompe, el impacto en el componente comercial es mínimo, mientras que con un error de regresión, el usuario confía en la función de trabajo y lo más probable es que no tenga una versión de respaldo del sistema de trabajo.
Los errores de regresión son causados por cambios que el gerente del proyecto o el propietario del producto no tuvieron en cuenta durante las pruebas de aceptación; arquitecto, desarrollador durante la revisión del código en la etapa de diseño o implementación; o por un analista y probador de control de calidad en casos de prueba. Todas las redes de seguridad perdieron un error y el usuario lo encontró. Si se detectó un error en una actualización reciente en cualquiera de las etapas anteriores, es decir equipos, partes interesadas o cualquier otro enlace que esté presente en su organización, luego se revisó antes del lanzamiento, o al menos se evaluó su importancia.
Los errores de regresión implican varios costos: corrección urgente, multas por posible violación del acuerdo de nivel de servicio y, lo más importante, dañan la confianza de sus usuarios en su producto. Pueden decidir que un nuevo lanzamiento romperá algo que ya funciona.
Se volvió importante para mi equipo verificar absolutamente todo.
Sin embargo, es bien sabido que esto no es posible, o al menos demasiado costoso y lento. Por lo tanto, "probar todo" se centró en las dos cosas siguientes: procesos comerciales críticos y la creencia de que el comportamiento en los principales procesos comerciales críticos será el mismo que en la última versión, antes del cambio. En general, queríamos asegurarnos de que en la última versión, no apareciera un error de regresión en el proceso comercial crítico.
Evaluamos nuestros enfoques típicos de las pruebas automatizadas para verificar los cálculos y verificar que toda la lógica se describe en el código para la automatización de las pruebas. Este enfoque planteó una pregunta clásica: "¿Quién está probando el código del probador?" Si el caso de prueba no tuvo éxito, existía la misma posibilidad de que el problema estuviera en el código del probador. Además, con cada cambio en la aplicación, el código de prueba también debe actualizarse, y dichos cambios se han producido con frecuencia.
Además, gracias a las pruebas automatizadas, nos aseguramos de tener un conjunto fijo de entradas y un conjunto conocido de salidas. Debido a la complejidad de la aplicación, fue imposible enviar todos los conjuntos posibles de datos de entrada a la vez. También se necesitaron varios conjuntos de datos para el final del mes, trimestre y año. El cronograma fue un problema grave, ya que toma mucho tiempo generar un gran conjunto de datos de entrada y los scripts correspondientes.
Había otra variable: los datos del usuario. Teníamos un privilegio especial: recibíamos copias de seguridad de los datos de los usuarios cada mes. La calidad de la prueba depende directamente de los datos utilizados para la prueba, y los datos de la producción siempre son mejores que los datos generados, por lo que nuestro privilegio fue una gran ventaja que no queríamos perder.
Identificación e implementación de pruebas de regresión.
Nuestra idea era utilizar pruebas automatizadas, que requieren el mantenimiento mínimo necesario y fortalecen la confianza de las partes interesadas en que la versión será de calidad adecuada.
Por lo tanto, necesitábamos una estrategia de prueba para casos comerciales críticos, lo que garantizaría la ausencia de errores de regresión y, por supuesto, que podríamos poner rápidamente en práctica.
Nuestro proceso de preparación se veía así:
- Copia de seguridad de la base de datos de producción, restaurada dos veces;
- Se instalan dos sistemas de prueba que funcionan en paralelo:
- Uno con un código de producción;
- Otro con la versión actual de la aplicación bajo prueba.
Este enfoque proporciona dos sistemas idénticos con diferencias de código en una sola versión:
Tener dos sistemas es bastante importante, ya que ayuda a comprender que cualquier problema surge solo debido a los últimos cambios en el código.
Las pruebas están separadas, por lo que del proceso estándar "realizar una acción y obtener una reacción", procedemos al hecho de que las acciones se realizan de un punto a otro mientras se mantiene el flujo de trabajo, después de lo cual se comparan los informes de errores. Esta es la clave para detectar errores inesperados.
Cuando el probador se enfoca en una nueva función o algún tipo de cambio, la prueba se enfoca específicamente en ella, es decir. Se verifica la relevancia de un cambio particular. La prueba de regresión es diferente, ya que debe verificar que nada más ha cambiado. Esta diferencia se refleja en los escenarios de automatización. Hace que los scripts de prueba de funciones específicas no sean adecuados para buscar errores de regresión, por lo que aquí se necesita un enfoque diferente.
Por ejemplo, si está trabajando con un sistema de gestión de pedidos, necesitará un script para realizar pedidos con una gran cantidad de datos de entrada para realizar pedidos de dos sistemas de prueba instalados (preferiblemente trabajando en paralelo), luego obtendrá un informe sobre los pedidos del último día y comparará cada uno valor Luego, todos los pedidos se confirman o aprueban (esta acción) e informes, tales como pedidos diarios confirmados, pedidos en existencia, informes de almacén, pedidos de cada transportista, tipo de envío, tipo de pago, etc. será comparado en dos sistemas. Esto continúa durante todo el flujo de trabajo. Puede combinar acciones, como realizar y confirmar pedidos, y luego comparar informes en etapas separadas.
Otro ejemplo es el sistema de gestión hotelera, en el que las acciones individuales se definen como procesos comerciales críticos, como el check-in, la facturación en un restaurante y la recepción de inventario. A todos estos procesos se les asignarán sus propias acciones e informes. La diferencia en este sistema en comparación con el ejemplo anterior es que los conjuntos de pruebas pueden ejecutarse en paralelo, y no hay necesidad de completar el paso antes de comenzar el siguiente.
Una comparación de los dos informes es un momento de verdad, y debería ser impecable, en el sentido de que ninguna de las partes interesadas debería tener dudas sobre su corrección. La diferencia en los informes es la verdadera diferencia.
Para esta operación, utilizamos la interfaz del servicio web. Todos los informes se envían en paralelo en dos sistemas, como resultado, se compara la respuesta recibida en formato JSON.
La comparación tiene lugar en tres frentes:
- Fuente (producción) menos objetivo (aplicación bajo prueba);
- Objetivo menos fuente;
- Comparación de valores para obtener la intersección.
Este método funcionará para XML, XLS, CSV de ancho fijo o cualquier otro formato. Debemos asegurarnos de que no haya registros innecesarios, que no falten registros y que todos los valores de los registros sean iguales.
Esta es la esencia del enfoque del que estamos hablando. Todo esto es información legible en la aplicación, que se emite como un informe o, en algunos casos, funciona como una interfaz para otras aplicaciones.
El éxito de este enfoque radica en una herramienta de comparación o utilidad que procesa casos relacionados con su aplicación. Puede considerarse afortunado si encuentra algo adecuado "listo para usar", de lo contrario, es importante comprender que vale la pena invertir en un instrumento de este tipo, ya que traerá buenos resultados.
Después de todo lo que se habla sobre automatización, debe insertar un comentario. Dado que se esperan algunas diferencias en los informes, ya que deben estar allí según sea necesario, todos los resultados también deben analizarse manualmente. Debe haber claros resultados exitosos de pasar los casos de prueba, sin embargo, los resultados no exitosos también deben ser analizados y su validez debe ser confirmada. Como estamos hablando de errores de prueba de regresión, deben corregirse antes del lanzamiento. Por supuesto, hay algunas excepciones que se manejan de acuerdo con la aplicación.
Ajuste del programa
Todas las aplicaciones son diferentes, y su instalación y configuración también ocurre de diferentes maneras. Para preparar la aplicación para la prueba, se pueden requerir algunos pasos adicionales, por lo tanto, deben tenerse en cuenta en el momento correcto y en el lugar correcto para ejecutar las pruebas. Aquí hay un conjunto de pasos típicos:
"Confunde" los datos de producción eliminando identificadores de correo electrónico u otra información confidencial, o reemplácelos con datos ficticios;
Obtenga los datos en la forma adecuada para ejecutar la prueba;
Adapte la configuración para el entorno de control de calidad, por ejemplo, cambiando las relaciones de integración.
Lo único que vale la pena recordar es que los pasos anteriores deben realizarse para ambas instalaciones. Recuerde que antes de iniciar el conjunto de pruebas, la configuración debe ser idéntica.
A menudo, las acciones que no sean solicitar un informe pueden devolver un objeto, por ejemplo, una acción, como crear o modificar un pedido, puede devolver un nuevo objeto de pedido. En este caso, debe comparar dos objetos y no esperar la comparación de los informes. Esto puede ayudar a identificar el error en las primeras etapas en la raíz.
También se recomienda dividir todo el conjunto en conjuntos más pequeños, por ejemplo, agrupando las transacciones y los informes relacionados. Los conjuntos se pueden ejecutar en paralelo para ahorrar tiempo de ejecución. Sin embargo, para una aplicación con un flujo de trabajo típico, esto solo funciona si puede dividir los casos vertical y horizontalmente, o viceversa.
Las variaciones pueden comenzar con tecnologías: JSON, XML o escaladores (int / string / float), y expandirse hasta que la aplicación bajo prueba y producción reaccione con diferentes estructuras, pero aún así cumpla con la arquitectura. Por ejemplo, la versión de producción puede usar el antiguo archivo JAR, que opera en un formato específico, y en la nueva versión el archivo JAR se ha actualizado y ahora el formato de respuesta ha cambiado, por lo que su comparación mostrará inconsistencias. Para compararlos correctamente, necesita un complemento temporal.
Probablemente habrá pocas situaciones de este tipo. En tales casos, a veces es más fácil modificar el diseño o considerarlos en el contexto de una solución alternativa.
Hay varias opciones para manejar tales comparaciones:
Ignora algunos campos, como identificadores y fechas;
Ignorar las diferencias numéricas inferiores a 0,0001;
Ignorar mayúsculas y minúsculas;
Cambios de estructura en dos respuestas.
Mejorando las pruebas de regresión
Las pruebas de regresión deben ser holísticas y centrarse en un área completa. Este equilibrio ayudará a capitalizar la automatización. Un enfoque de prueba automatizado ayudará a reducir el número de errores de regresión y ayudará en el camino hacia buenas relaciones con los clientes y aumentará el valor de la marca.
Ahora, en un ritmo constante de avance, nuestro equipo quiere tratar de abandonar las dos instalaciones de sistema idénticas que usamos ahora e implementar la misma estrategia en una instalación. Queremos mantener las respuestas de los logros pasados y usarlos para comparar. El enfoque de prueba siempre se puede mejorar. ¡Deséanos la mejor de las suertes!
La traducción fue preparada especialmente para los estudiantes del curso "Python QA Engineer" .