¿Necesito pruebas automáticas? Cuando se necesita ¿Qué valor aporta?
El artículo analiza cuándo y por qué se necesitan pruebas como tales y en qué casos se necesita su automatización.
Durante la discusión sobre este tema celebrada en el club para ellos. Francis Bacon ("KifB Web-Meetings" en teleram), sus colegas intercambiaron experiencias y escribieron sus pensamientos.
La automatización de pruebas es necesaria si aporta valor. ¿Cuándo las pruebas mismas aportan valor? Se han identificado dos casos.
Si el proceso detecta errores en el software antes de iniciar la batalla
Si la prueba de la nueva versión revela errores que posteriormente se corrigieron, entonces esta prueba no fue en vano.
Pero, ¿y si la situación se invierte? Si las pruebas no encontraron un error, pero aparecieron en la batalla? Si se detectaron errores en el banco de pruebas (incluido el banco de pruebas configurado más cerca de la batalla).
Se alega que en este caso la prueba se realizó mal.
¿Cómo medir la calidad de las pruebas? Para este caso, la métrica es adecuada = el número de errores en el entorno de prueba / (el número de errores en el entorno de prueba + combate). En este caso, el número de errores se toma ponderado por el nivel de criticidad.
Pero, ¿qué pasa si las pruebas no encontraron errores y no se encontraron en el servidor de batalla?
Se alega que en este caso, las pruebas, como tales, no aportaron valor y estos trabajos se realizaron en vano (con la excepción del siguiente caso, que discutiremos más adelante). Desde el punto de vista de Lean, esto es una pérdida.
¿Cuándo es esto posible? Cuando el módulo bajo prueba no cambió. ¿Qué puede cambiar un módulo?
- Modificación del código del módulo.
- Cambiar la versión de las bibliotecas utilizadas (incluido el sistema operativo, la base de datos, etc.). El cambio puede deberse a los requisitos de los reguladores, por lo que la biblioteca debe actualizarse en un plazo fijo.
- Cambiar la configuración o los datos que afectan seriamente el comportamiento de un funcional universal, cuyas pruebas exhaustivas son innecesariamente difíciles de realizar y, como resultado, se abandonaron las pruebas. Ejemplos:
- Establecer promociones en soluciones como Siebel CRM u Oracle ATG puede conducir a la degradación del rendimiento de las funciones de cálculo de la promoción, y la posibilidad de una verificación exhaustiva no es posible en un tiempo razonable debido a la excesiva flexibilidad y versatilidad de estas soluciones.
- La descripción html de la tarjeta del producto puede contener una estructura de documento rota o errores en la descripción del código js escrita en su interior, lo que rompe la página de la tarjeta del producto
- El uso de la funcionalidad no está destinado para este propósito (clavos de martillo con un microscopio). Por ejemplo, un cambio en el tipo de carga que no es inherente a los requisitos y, como resultado, no se tiene en cuenta durante la prueba. Por ejemplo, antes del Black Friday, vale la pena realizar una prueba de carga por separado para la página de destino, a dónde irá el tráfico si no existieran tales requisitos de carga para este tipo de página.
- Cambiar el comportamiento de la API de otros módulos que utiliza el módulo desarrollado. Especialmente si la funcionalidad de la API no está cubierta por las pruebas de regresión.
Dado que las opciones para los cambios pueden ser diferentes, y realizar una prueba de regresión completa cuesta dinero, no vale la pena todas las pruebas. Una opción de control es etiquetar las pruebas con etiquetas y antes de las pruebas. El administrador de pruebas determina qué conjunto de pruebas debe enviarse para su ejecución para una parte determinada de los cambios.
¿Cuándo necesito escribir autotests en este caso?
Para empezar, las pruebas automatizadas no cancelan las pruebas de configuración, las pruebas de diseño y la escritura de casos de configuración de prueba. Y no los reemplaza. Si este no es el caso, entonces la automatización no debería ser tratada. Al mismo tiempo, las pruebas automáticas deben entenderse no solo como el script en sí, sino también como preparación para su ejecución y uso de los resultados.
Si escribe pruebas automáticas después de crear el código, esto conducirá a un aumento en time2market (que automáticamente conducirá a un aumento en el capital conectado). Por lo tanto, si se decide cubrir el código con pruebas automáticas, debe escribir estas pruebas automáticas paralelas al código principal, en el paradigma de desarrollo de "TestFirst" o "TDD".
El principal valor creado por la automatización de pruebas es la reducción de time2market debido a la carga más rápida de la nueva versión.
Se necesitan pruebas para garantizar el rendimiento de los procesos críticos.
A pesar de que el automóvil nunca se incendió, la presencia de un extintor de incendios no es inútil.
Un error en un sitio con mucho tráfico que no permite agregar un artículo a la canasta puede generar pérdidas más significativas que el costo de desarrollar y probar esta función durante el año.
Por lo tanto, es necesario resaltar los procesos críticos que pasarán a controles regulares (que vale la pena hacer si se produce algún tipo de cambio). Compara:
- pérdida del tiempo de inactividad de la función desde el momento de la detección hasta su corrección,
- prueba manual de gastos o su automatización y su posterior implementación durante el período de recuperación.
Pero, ¿qué pasa si las pruebas regulares no encuentran errores durante mucho tiempo y no ocurren en la batalla? Entonces las pruebas no aportan valor y, por lo tanto, no son necesarias. ¿Cuándo es esto posible?
- El módulo en desarrollo no es muy grande.
- Equipo estable y altamente competente.
- Las integraciones se cierran mediante pruebas o, por otro lado, no hay cambios.
¿Es posible no hacer pruebas en absoluto?
Esto es posible mediante el lanzamiento de varias instalaciones de la solución y la prueba de nuevas versiones beta en gatos, si esto es técnicamente posible y si se encuentran dichos voluntarios. Después de diseñar la nueva versión, se monitorea la telemetría y se realiza una reversión en caso de degradación de los indicadores. (Recuerde que la telemetría en la batalla debe ser independiente de la disponibilidad de pruebas).
Otro caso de la utilidad de la prueba automática de regresión es la prueba de API (prueba de contrato de API), si esta API es necesaria para soportar un proceso crítico. Esto es especialmente importante si los desarrolladores de otro módulo cambian algo y no hacen pruebas de calidad de los cambios de su lado.
Cuando no se necesita automatización de prueba
Si obtuvo una gran cantidad de código heredado de muy baja calidad. Cubrir las protestas automáticas con tal caos está aumentando el caos.
En este caso, vale la pena resaltar el módulo lógico de esta solución. Después de seleccionar la capa de interacción de este módulo con el resto del código, debe cubrir la interacción con pruebas automáticas. Esto proporcionará garantías de la integridad del comportamiento y la integridad del módulo después de su recodificación.
Las pruebas automáticas no reemplazan las pruebas manuales. Las pruebas manuales se llevan a cabo con mayor frecuencia y de manera más económica que la escritura y, posteriormente, las pruebas automáticas que las acompañan. En particular, si las pruebas se llevan a cabo después del desarrollo del código, entonces, a partir de estas pruebas, solo se debe automatizar la pieza que entrará en las pruebas regulares de funcionalidad crítica.
Y, por último, una lista de verificación de la preparación de la compañía para las pruebas automáticas
Hagamos una reserva de inmediato, esta lista de verificación no es para todos, está escrita para evaluadores de empresas para las cuales el desarrollo de software es la principal fuente de ingresos.
Lista de verificación
- La compañía dibuja el proceso principal de entrega de negocios y comprende dónde se encuentra.
- La compañía ha elaborado el proceso de entregar valor a los clientes.
- Se ha configurado la gestión de tareas, lo que significa que todos los involucrados llevan las tareas al estado deseado. Y las tareas están tipificadas.
- La compañía ha formulado objetivos de prueba.
- Los títulos de las tareas en el rastreador están "peinados", en otras palabras, por el título puede entender qué tipo de tarea es.
- El registro de tareas es manejable, en cualquier momento refleja el estado actual y la política del proyecto / producto.
- Hay un registro de requisitos y es manejable.
- Hay trazabilidad de los requisitos de la tarea.
- Hay trazabilidad de los requisitos de prueba. Se sabe qué requisitos están cubiertos por qué pruebas.
- Hay trazabilidad de las pruebas de tareas. Se sabe que ya se ha probado dónde y cómo.
- Hay una matriz de la influencia de los componentes entre sí.
- Las tareas se remontan a los componentes.
- Todo está en control de versiones.
- Hay una política versionada de quién, cómo y por qué. Se entiende por qué git flow es un mal modelo.
- Estándares existentes: codificación y otros
- Hay un ci
- Existe una política de lanzamiento, donde en particular se prescriben métodos de control de versiones, todo lo que se necesita.
- Hay un repositorio de artefactos desde donde puede sacar un producto listo para la instalación.
- Existe una política para marcar artefactos de acuerdo con diferentes criterios. El análisis de código estático no se olvida.
- El medio de barrido del producto se eleva con el clic de un dedo. El entorno también está en control de versiones.
- El entorno está totalmente automatizado para verificar su corrección. Puertos, versión Java, ...
- El producto se despliega al hacer clic con cheque
- El producto se configura de forma totalmente automática para la tarea requerida. Por cierto, esto también se aplica a las configuraciones de negocios. Y esto también se registra automáticamente.
- Tiene una manera de generar repetida y automáticamente todos los datos de prueba necesarios. Los scripts de generación también están en el control de versiones y están asociados con artefactos del producto.
- Todo lo anterior funciona para cualquier versión del producto.
- Tiene una tubería de entrega registrada dentro de la política de lanzamiento.
Finalmente, gracias a los miembros del grupo por la discusión y ayuda en la preparación del artículo.