Algunas personas pueden ver las pruebas en producción de forma negativa, equiparándolas con el lanzamiento de funciones no probadas o productos defectuosos con bajo rendimiento y tasas de retención.
Sin embargo, las pruebas en producción son una etapa crucial del proceso de desarrollo de software. Permite a los ingenieros de control de calidad (QA) examinar el comportamiento real del usuario en la fase posterior al lanzamiento. Además, ejecutar pruebas en un entorno de producción agrega otra capa de seguridad contra errores en tiempo real.
En este artículo, cubriremos los tipos y beneficios de las pruebas en producción. También aprenderá sobre seis prácticas para realizar los exámenes y métricas que indican pruebas de producción exitosas.
Descargar glosario para principiantes web
Por qué probar en producción
La creación de un entorno de prueba lleva mucho tiempo y es posible que el resultado no coincida con el producto real. Por lo tanto, muchos desarrolladores web incluyen pruebas en producción como una fase complementaria después de los exámenes previos a la implementación.
En esta sección, repasaremos cinco razones por las que debe ejecutar pruebas en un entorno de producción.
Mejora la precisión de la prueba
El principal beneficio de las pruebas en producción es obtener resultados más precisos, ya que lo hace en el mismo entorno. Saber que los usuarios experimentarán la misma funcionalidad verificada en las pruebas aumentará la confianza del equipo.
Sin embargo, esto puede no suceder en entornos de ensayo. Incluso si replica la producción, ciertos elementos pueden tener datos no exactos o diferentes opciones de configuración. Esto puede afectar los resultados de la prueba.
Mejora la frecuencia de implementación
El lanzamiento frecuente de código o funciones nuevas durante las pruebas en producción también mejora la agilidad. Puede responder a las solicitudes de los clientes de manera más flexible, liberando cambios según sea necesario.
Además, las pruebas en producción permiten desarrollos basados en banderas con una funcionalidad de bandera de función automática en mente. Esto significa que puede implementar y revertir de manera segura cualquier modificación negativa de inmediato.
Garantiza una transición suave durante las pruebas
Las pruebas en producción lo ayudan a aprender y experimentar cómo reaccionan los usuarios a una característica o código específico.
Por ejemplo, cuando se lanzan nuevas funciones, los ingenieros de control de calidad realizan pruebas en producción para verificar si la funcionalidad del software funciona correctamente. Luego, utilizan varias herramientas analíticas para ejecutar las pruebas A/B y recopilar los comentarios de los clientes.
Además, las pruebas en producción le permiten administrar el indicador de funciones y las herramientas analíticas de forma independiente. También puede integrar ambos para obtener los mejores resultados.
Límites Daños
La forma más eficiente de limitar los daños es mediante pruebas en producción. Con él, puede detectar defectos en tiempo real e implementar directamente medidas de seguridad y parches.
La liberación gradual de código o características nuevas puede evitar que las implementaciones deficientes dañen los sistemas de producción y afecten negativamente la experiencia del usuario.
Detectar errores y fallas al principio del desarrollo requiere tiempo y esfuerzo. Los ingenieros de control de calidad deben crear pruebas unitarias, verificar el sistema de automatización y verificar manualmente los flujos de usuarios utilizando datos simulados.
Permite recopilar comentarios
Las pruebas en producción le permiten observar y monitorear el sistema a través de comentarios de usuarios reales. Además, determina la tasa de falla o éxito de las nuevas funciones o código.
Para realizar con éxito las pruebas en producción, asegúrese de que el rendimiento de la aplicación se mantenga igual desde la línea de base esperada.
Tipos de Pruebas en Producción
En esta sección, repasaremos las seis pruebas más comunes en los métodos de producción:
Monitoreo y Diagnóstico
El objetivo principal de la supervisión y el diagnóstico en un entorno de producción es garantizar que el software funcione según lo previsto. Para lograr esto, puede realizar las siguientes pruebas:
Monitoreo continuo. Esto incluye pruebas de rendimiento, como examinar la estabilidad, el tiempo de respuesta, la escalabilidad y la confiabilidad del producto, así como realizar pruebas de velocidad del sitio web. El monitoreo continuo ayuda a encontrar problemas que pueden disminuir la funcionalidad del software. Además de hacerlo manualmente, los desarrolladores también pueden usar herramientas de automatización que brindan información y diagnósticos adicionales.
Seguimiento de aplicaciones. Consta de dos tipos: monitoreo de usuario real (RUM) y monitoreo sintético (prueba de simulación). El primero comprueba cómo interactúan los usuarios reales con el servidor de aplicaciones. Mientras que el segundo examina cómo las API de la aplicación responden a las solicitudes continuas enviadas por visitantes automatizados.
Seguimiento en tiempo real. Esto significa verificar cada transacción sobre cada capa dentro de una aplicación. Permite a los ingenieros de control de calidad ver el código base y detectar errores, fallas y rendimiento lento. Además, el seguimiento en tiempo real también proporciona un análisis específico, como el comportamiento de la pila de ejecución y los hilos problemáticos.
Pruebas A/B
Solo puede ejecutar este tipo en un entorno de producción real para proporcionar valiosos comentarios de los usuarios.
La prueba A/B implica lanzar dos versiones de una aplicación web o una nueva función con contrastes sutiles, por ejemplo, diferentes interfaces de menú o esquemas de color. Esto dividirá la base de usuarios en varios grupos.
Luego, asigne a cada lote una variante diferente para encontrar cuál es preferible. Esta prueba estadística le ayuda a decidir qué versión incluir en versiones futuras.
De esta manera, los desarrolladores también pueden aprender más sobre las necesidades de los clientes y crear productos que cumplan con sus expectativas.
Liberación incremental
Esta prueba en el tipo de producción divide los requisitos del producto en varios módulos independientes. Cada parte se trata como un subproyecto y pasará por las etapas del ciclo de vida de desarrollo de software (SDLC).
Además, un módulo presentará una nueva función o infraestructura de producción en cada versión. Continúa hasta que el sistema se desarrolla por completo e implementa todas las partes previstas.
Aquí hay cuatro fases incrementales:
-
Análisis de requisitos. Identificar los requisitos funcionales del software y del sistema.
Diseño y desarrollo. Creando funcionalidad.
Pruebas. Examinar todas las funciones existentes utilizando varios métodos.
Implementación. Terminando el diseño de codificación del software.
También conocido como el modelo de mejora iterativa, esta prueba del entorno de producción ayuda a lograr los objetivos a través de varios pasos prácticos.
El modelo de versiones incrementales ofrece dos tipos para elegir:
Modelo de entrega por etapas. Construya una parte del proyecto a la vez en fases sucesivas.
Modelo de desarrollo paralelo. Desarrollar el producto simultáneamente siempre que los recursos estén disponibles. Este tipo puede ayudar a acortar el proceso de desarrollo.
Prueba de picos
Las pruebas de picos en un entorno de producción ayudan a evaluar el rendimiento del software en situaciones extremas, como un aumento o disminución repentino de la carga. Su propósito es determinar cuánto tráfico de usuarios puede manejar el producto antes de colapsar.
Además, las pruebas de picos definen cuánto tiempo lleva recuperarse de circunstancias difíciles. La mayoría de los desarrolladores también usan este método para averiguar si el software emplea buenos sistemas de manejo de errores.
Pruebas de integración
También conocido como integración y prueba (I&T), este tipo combina lógicamente todos los diferentes componentes, unidades y módulos de software y los prueba como una sola entidad.
Por lo general, la producción consta de varios módulos codificados por varios programadores. Las pruebas de integración tienen como objetivo encontrar errores en su interacción cuando se fusionan. Además, comprueba la comunicación de datos entre estos módulos.
Un ejemplo común de pruebas de integración es el enfoque big bang. Sin embargo, funciona principalmente para examinar sistemas pequeños.
Seguimiento de comentarios
Una vez que los desarrolladores lanzan el software, comienzan a observar cómo los usuarios finales interactúan con el producto. Por lo general, utilizan herramientas de comentarios de los clientes como Mopinion para recopilar datos de manera eficiente. Esto ayuda a determinar los cambios necesarios en iteraciones futuras.
Además, el seguimiento de comentarios en un entorno de producción permite a los desarrolladores acelerar el proceso de prueba e integración de código. Esto crea un equilibrio entre el tiempo de lanzamiento y la calidad.
Al adoptar este método, recuerde especificar a qué elementos los usuarios deben dar su opinión para que sea más fácil categorizar los datos.
Mejores prácticas para pruebas en producción
Después de analizar los beneficios y los tipos de pruebas en producción, es hora de aprender algunos consejos y trucos para mejorar aún más su trabajo.
Crear datos de prueba
Al realizar pruebas en producción, la información utilizada debe representar la condición real del software. Por lo tanto, es posible que deba crear datos de muestra o usar un reemplazo adecuado para los casos de prueba.
Hay varias formas de generar datos de prueba:
Cree los datos manualmente. Copie los datos de la producción al entorno de prueba. Obtenga los datos de los sistemas cliente. Utilice herramientas de generación de datos de prueba automatizadas.
Antes de crear datos de prueba, los desarrolladores deben realizar varios pasos previos o establecer opciones de configuración. Como es un proceso que requiere mucho tiempo, le recomendamos que lo atienda con anticipación.
Nombra los datos de prueba de manera realista
Escribir un buen nombre de datos de prueba ayuda a crear un proceso de prueba de producción atractivo y organizado. Además, puede informar a los ingenieros de control de calidad qué acciones tomar y qué tipo de comentarios esperan los desarrolladores.
Aquí hay tres consejos para crear un buen nombre de datos de prueba:
Representar con precisión escenarios de la vida real. Describe la situación de forma concisa. Cree nombres de datos de prueba reutilizables para examinar múltiples contextos.
Evite el uso de datos de usuarios reales
El uso de datos reales puede ser un enfoque eficaz al realizar pruebas en producción y solucionar problemas de la funcionalidad del software. Además, ayuda a imitar los tipos de aplicaciones de datos que se ven en el entorno de producción.
Sin embargo, exponer información de identificación personal (PII) puede generar varios riesgos graves, como violaciones de seguridad. Esto también significa que está violando las leyes de privacidad de datos, incluido el Reglamento General de Protección de Datos (GDPR) y la Ley de Privacidad del Consumidor de California (CCPA).
Otras desventajas incluyen:
Tener datos de prueba y producción mezclados. Exponer lagunas en procesos críticos para el negocio. Posible pérdida de datos. Consecuencias no deseadas en otros sistemas de software. Ruido en los registros del sistema de producción debido a la actividad de bots y scripts. Confiar en los usuarios finales para proporcionar comentarios sobre las fallas del sistema.
Por lo tanto, para evitar infracciones y problemas legales, emplee estas técnicas de seguridad en los entornos de prueba de producción:
Usa fichas. Reemplace los datos confidenciales de producción con un valor de marcador de posición genérico que no imite el formato original.
Manténgalo en el anonimato. Utilice el valor generado de forma realista mediante la aleatorización y la generalización.
Aplique el cifrado que conserva el formato. Asegure la información confidencial mientras mantiene el formato original. Esto mantiene los datos relevantes.
Pseudo-anonimización. Inserte el PII real junto a los datos de producción aleatorios y cámbielo en la tabla de mapeo. Esto le permite restaurar la información original cuando sea necesario. Sin embargo, asegúrese de que la tabla de asignación esté cifrada.
Generar datos sintéticos. Use información simulada que tenga un formato similar y vínculos de datos válidos. Hay muchos generadores de datos sintéticos, como Avo Automation, MOSTLY AI y Mockaroo.
Crear credenciales para probar la aplicación
Para mantener la protección de datos y garantizar la funcionalidad del software, cree credenciales de prueba y póngalas a disposición del equipo en el entorno de prueba.
Con credenciales de muestra, puede probar las partes de software o las API REST sin aplicar cambios directamente desde la cuenta existente. Le permite actuar como usuario y explorar el software para encontrar posibles inconvenientes.
Sin embargo, las cuentas de prueba suelen tener algunas restricciones. Por ejemplo, es posible que no permitan interactuar con los datos dentro de las credenciales reales o acceder a ciertas partes de administración de la aplicación.
Antes de crearlos, revise la política de seguridad de la empresa y consulte con el equipo de seguridad.
Hay algunos aspectos a considerar al configurar las credenciales de prueba:
Acuerde con el equipo el rol y los permisos de la cuenta de prueba. Asegúrese de que contiene datos representativos. Considere los problemas de tenencia cruzada y cree conjuntos para dos entornos de producción separados. Proporcione una matriz de permisos para garantizar que las funciones y los privilegios sean claros. Esto también ayuda a prevenir informes de falsos positivos.
Prueba cuando el proyecto está bajo carga baja
Realizar pruebas en producción, especialmente durante el horario comercial, puede aumentar las posibilidades de falla del sistema. Además, puede resultar en una mala experiencia de usuario. Por lo tanto, recomendamos realizar las pruebas del entorno de producción durante las horas de menor actividad, por ejemplo, durante la noche.
Sin embargo, realizar exámenes en software avanzado puede llevar horas. Por lo tanto, programe un plan de mantenimiento en consecuencia y envíe correos electrónicos para notificar a los usuarios que se realizarán pruebas de producción.
Además, es mejor habilitar la opción de indicador de función para mitigar los errores de software.
Métricas que indican una prueba de producción exitosa
Las métricas de pruebas de producción ayudan a monitorear y calificar las pruebas que ha realizado. Transmiten un resultado o una predicción basada en la combinación de datos utilizada.
Además, las métricas de prueba de producción muestran el progreso del examen del equipo, analizan la calidad del software, monitorean la productividad, miden cambios, identifican áreas de mejora y prueban el último procedimiento o tecnología para determinar si el producto necesita más modificaciones.
Las métricas de prueba de producción constan de tres tipos:
Métricas de proceso. Definir la ejecución y características del producto. Se utilizan para mejorar y mantener el proceso SDLC.
Métricas de productos. Determine el diseño, la calidad, el tamaño, la complejidad y el rendimiento del producto. Los desarrolladores utilizan estas métricas para mejorar la calidad del software.
Métricas del proyecto. Mida la eficiencia y la eficacia del equipo del proyecto o las herramientas de prueba utilizadas.
Hay cinco factores esenciales para recordar antes de crear las métricas de prueba de producción:
Elija el público objetivo con cuidado. Determine el objetivo de cada métrica. Planifique las medidas de acuerdo con las especificaciones del producto. Evaluar los ingresos de cada estadística. Haga coincidir los cálculos con el ciclo de vida del proyecto.
Métricas de prueba manuales
Las pruebas manuales requieren mucho tiempo, ya que los ingenieros de control de calidad deben realizarlas paso a paso. Sin embargo, les ayuda a comprobar minuciosamente y examinar las configuraciones del sistema en circunstancias más complejas.
Esta técnica consta de dos métricas:
Métricas base. Contener análisis de datos recopilados del desarrollo y ejecución de los casos de prueba. Al generar los informes de estado del proyecto, los gerentes de proyecto recibirán y revisarán el uso de estas métricas. Esta técnica realiza un seguimiento de los datos en todo el SDLC, desde la recopilación del número total de casos de prueba hasta cuántos de ellos se completaron, fallaron o bloquearon.
Métricas calculadas. Contener datos recopilados en las métricas base, como el número de cobertura de prueba. Los gerentes o líderes de proyectos los usan para fines de informes de prueba.
Las pruebas manuales incluyen muchas métricas importantes, que incluyen calificación absoluta, derivada, de resultados y predictiva. Hemos enumerado algunos de los más utilizados a continuación.
números absolutos
Estos contienen valores unidimensionales que los ingenieros de control de calidad utilizan para derivar métricas de prueba de producción. Para usarlos, registre estos valores durante el desarrollo y la ejecución de los casos de prueba a lo largo del ciclo de vida de las pruebas de software.
Las métricas absolutas contienen 12 cálculos:
Total de casos de prueba Casos de prueba aprobados Casos de prueba fallidos Casos de prueba bloqueados Defectos encontrados Defectos rechazados Defectos aceptados Defectos diferidos Defectos críticos Horas de prueba planificadas Horas de prueba reales Errores encontrados después del envío
Métricas derivadas
El uso de números absolutos como métricas independientes no es suficiente para evaluar la calidad de las pruebas. Por lo tanto, debes complementarlo con las métricas derivadas. De esta manera, sabrá cómo solucionar problemas durante los procesos de prueba del producto..
El seguimiento de pruebas y eficiencia Las fórmulas ayudan a los ingenieros de control de calidad a comprender la eficiencia de las pruebas y realizar un seguimiento de sus logros. También muestran cualquier defecto relevante del producto.
Por lo general, los desarrolladores y los ingenieros de control de calidad aplican las siguientes fórmulas:
% de casos de prueba aprobados = (número de casos de prueba aprobados/total de pruebas ejecutadas) x 100
% de casos de prueba fallidos = (número de casos de prueba fallidos/total de pruebas ejecutadas) x 100
Casos de prueba bloqueados % = (número de casos de prueba bloqueados/total de pruebas ejecutadas) x 100
Defectos corregidos % = (número de defectos reparados/defectos notificados) x 100
Defectos aceptados % = (número de defectos válidos confirmados por los desarrolladores/total de defectos informados) x 100
Defectos rechazados % = (número de defectos no válidos rechazados por los desarrolladores/total de defectos informados) x 100
Defectos diferidos % = (número de defectos diferidos para versiones futuras/total de defectos informados) x 100
Defectos críticos % = (número de defectos críticos/total de defectos notificados) x 100
Tiempo promedio para que los desarrolladores corrijan defectos % = (tiempo necesario para la corrección de errores/número de errores) x 100
Tenga en cuenta que estas fórmulas solo brindan información sobre la cobertura y la calidad de la prueba.
Mientras tanto, esfuerzo de prueba Las métricas establecen las líneas de base para la futura planificación de pruebas. Sin embargo, los resultados producidos son promedios: la mitad está por encima del valor, mientras que otros están por debajo.
Las siguientes son las fórmulas más importantes para mostrar el esfuerzo de prueba:
Número de pruebas ejecutadas por un período % = número de pruebas ejecutadas/tiempo total
Eficiencia del diseño de prueba % = número de pruebas diseñadas/tiempo total
% de eficiencia de revisión de prueba = número de pruebas revisadas/tiempo total
Cantidad de errores o defectos por hora de prueba % = número de errores o defectos/total de horas de prueba
Cantidad de errores por prueba % = número de errores/número total de pruebas
Tiempo promedio para que los desarrolladores prueben la corrección de un error % = tiempo total entre la corrección de errores para volver a probar todos los defectos/defectos totales
El tefectividad est las métricas miden la capacidad de detección de errores y la calidad del conjunto de pruebas. Muestran una proporción de los defectos totales identificados antes de la implementación a las fallas encontradas antes y después del lanzamiento del producto.
Hay dos formas de calcular la efectividad de la prueba:
% de eficiencia de contención de defectos basado en métricas = (errores encontrados en la prueba/total de errores encontrados (errores encontrados en la prueba + después del envío)) x 100 Basado en el contexto significa usar la evaluación del equipo para calificar la efectividad de la tasa de prueba.
En comparación, el cobertura de prueba Las métricas miden los esfuerzos de prueba. Muestran cuántas de las partes del software se probaron.
Para calcular la cobertura de la prueba, aquí hay tres fórmulas clave para ejecutar:
% de cobertura de ejecución de prueba = (número de pruebas ejecutadas/total de pruebas a ejecutar) x 100
Cobertura de requisitos % = (número de requisitos cubiertos/requisitos totales) x 100
% de cobertura de prueba de automatización = (cobertura automatizada/cobertura total) x 100
También conocida como distribución de defectos, la métricas de defectos dividir el software defectuoso en función de varios aspectos, como la causa, la gravedad y el tipo. Esta técnica ayuda a identificar qué áreas son más susceptibles de error.
Para calcularlo, usa estas fórmulas:
Densidad de defectos % = número de defectos/módulos totales
Índice de gravedad del defecto % = ∑ (defecto x nivel de gravedad)/defecto total
Métricas de prueba automatizadas
Como sugiere el nombre, le permite realizar pruebas automatizadas utilizando herramientas. Además de reducir el costo y el tiempo, esta técnica puede aumentar la cobertura de las pruebas. Además, el enfoque automatizado utiliza principalmente las mismas métricas que el manual.
Hay muchas herramientas de automatización disponibles, incluidas TESTIFI, LambdaTest y Katalon.
Conclusión
La prueba en producción es un complemento crucial para una estrategia de prueba de software. Hacerlo ayuda al equipo a aprender cómo funciona el sistema con usuarios, datos y solicitudes reales.
La realización de pruebas en un entorno de producción brinda una mejor comprensión del software, mejora su calidad durante la fase de lanzamiento posterior a la producción y aumenta el valor comercial.
Las pruebas en producción tienen muchas ventajas, como mejorar la precisión de las pruebas, publicar actualizaciones con frecuencia y evitar fallas en el sistema. Comúnmente consta de seis categorías:
Monitorización y diagnóstico. Realice pruebas de rendimiento, supervisión de aplicaciones y seguimiento en tiempo real.
Pruebas A/B. Pruebe dos versiones de una nueva función o software en el entorno de producción.
Liberación incremental. Separe los requisitos del producto en módulos de software hasta que se complete el SDLC.
Prueba de picos. Pruebe el software en múltiples eventos, como aumentos o disminuciones repentinos en el tráfico de producción.
Pruebas de integración. Combine múltiples unidades, componentes y módulos y pruébelos como una entidad.
Prueba de retroalimentación. Utilice herramientas de comentarios de los clientes durante el entorno de producción.
Para producir los mejores resultados, recuerde crear siempre los datos de muestra, asígnele un nombre útil, evite usar información personal, cree credenciales de prueba y ejecute las comprobaciones durante la carga baja.
Esperamos que este artículo le haya ayudado a comprender cómo realizar pruebas en producción. Si tiene alguna pregunta o sugerencia, déjela en la sección de comentarios a continuación.
Preguntas frecuentes sobre pruebas en producción
Ahora, responderemos las preguntas más frecuentes sobre las pruebas en producción.
¿Cuál es la diferencia entre las pruebas en producción y puesta en escena?
La principal diferencia entre las pruebas en producción y las pruebas es el entorno de prueba. Con el primero, el examen ocurre en un servidor web de producción. Esto significa que el producto ha sido lanzado oficialmente para usuarios reales.
Mientras que el entorno de ensayo significa que los desarrolladores utilizan una réplica del entorno de producción original. Su objetivo es probar un software de nivel cercano a la producción para garantizar que la aplicación funcione correctamente después de la implementación.
¿Qué tipo de pruebas se pueden automatizar?
Hay siete pruebas automatizadas que puede realizar en un entorno de producción: API, humo, regresión, integración, rendimiento, seguridad y aceptación.
