Muchos consideran las pruebas en entornos de producci贸n como una pr谩ctica perjudicial: no ayuda a evitar que los problemas lleguen a los usuarios finales, sino que afirma que est谩n presentes. Adem谩s, el probador est谩 separado del flujo de trabajo est谩ndar y de las t茅cnicas utilizadas en el entorno de prueba. Mi nombre es Olya Mikhalchuk, soy ingeniero de control de calidad en la empresa fintech ID Finance. En esta publicaci贸n, explicar茅 por qu茅 las pruebas en el producto pueden ayudar significativamente a su proyecto.
驴Por qu茅 necesita un control de calidad en la producci贸n, si hay un entorno de preproducci贸n
Durante el proceso de desarrollo de software, siempre hay varios entornos en los que se implementa la aplicaci贸n. El entorno que usan los usuarios finales, como ustedes saben, se llama producci贸n. Por lo general, se supone que las pruebas se deben realizar en un entorno separado, con mayor frecuencia en un entorno de control de calidad o en etapas (pre-prod), para evitar que los errores lleguen a los usuarios. Pero existe una t茅cnica como QA en prod, que ayuda perfectamente a resolver problemas que son f铆sicamente imposibles de resolver en un entorno de prueba.
驴Qu茅 tareas ayuda el control de calidad en prod?
1. El problema de las diferencias entre los escenarios y los entornos de producci贸n.
La puesta en escena a menudo se considera una copia del entorno de producci贸n, que es inaccesible para los usuarios finales, pero es m谩s similar al entorno de combate. Cuando la aplicaci贸n es bastante compleja, sincronizar y mantener una copia de este tipo se convierte en una tarea lenta y no siempre racional.
Por ejemplo, en nuestro proyecto, pre-prod se usa m谩s para pruebas funcionales en escenarios de prueba hechos manualmente. No tiene recursos t茅cnicos comparables al entorno de producci贸n. Adem谩s, generalmente no sincronizamos completamente las configuraciones y las bases de datos con el entorno de producci贸n, lo que no interfiere con las pruebas funcionales. 驴Por qu茅 no copiamos el entorno de producci贸n? Imagine cu谩ntos recursos se necesitar铆an para crear una copia de, por ejemplo, Facebook, con los mismos servidores, servicios, bases de datos y configuraciones s煤per potentes que en la producci贸n. Esto es realmente c贸mo implementar otra aplicaci贸n del mismo tipo.
Adem谩s, cuando se integra con servicios de terceros, siempre tiene diferentes configuraciones para los entornos de prueba y combate (la misma API). No estoy diciendo que los entornos de prueba y puesta en escena no tengan sentido. Simplemente no es posible garantizar al 100% que al completar con 茅xito ciertas pruebas en un entorno, los servicios no recaer谩n en otro. Las pruebas adicionales para la producci贸n pueden ayudar a resolver este problema.
2. Niveles reales de multitarea y carga.
Algunos errores solo pueden detectarse bajo un nivel largo y real de multitarea y carga de trabajo. Esto se aplica a p茅rdidas de memoria, estabilidad, velocidad y estabilidad del sistema. Por ejemplo, tuvimos una situaci贸n en la que surgi贸 el problema del rendimiento del sistema debido al hecho de que se realizaron dos tareas intensivas en recursos en el mismo intervalo de tiempo. Los desarrolladores optimizaron el trabajo de las tareas, el equipo realiz贸 pruebas en el entorno previo a la producci贸n, entreg贸 los cambios y luego realiz贸 una verificaci贸n de producci贸n.
3. Errores de implementaci贸n
Desde la definici贸n, la implementaci贸n es la instalaci贸n por un grupo de trabajo de una nueva versi贸n del c贸digo del programa de servicio en la infraestructura de producci贸n. En consecuencia, la mejor manera de ver los errores de implementaci贸n es a trav茅s de pruebas en el proceso de implementaci贸n en s铆.
4. Falta de monitoreo en pre-prod
Una de las mejores e indispensables formas de controlar que la aplicaci贸n funcione como esperamos es monitorear ciertas m茅tricas. Por ejemplo, a partir de ejemplos simples y m谩s cr铆ticos: monitoreo del n煤mero de nuevos registros de usuarios por hora, en la conversi贸n de una acci贸n objetivo a otra, en el n煤mero de pr茅stamos emitidos. Por supuesto, dicho monitoreo solo tiene sentido en un entorno de combate.
5. La capacidad de analizar escenarios de usuario final para usar el sistema
Producci贸n: un almac茅n de casos de prueba para el probador. Si es posible, el probador puede ver y procesar las secuencias de comandos utilizadas por los usuarios finales, el probador puede identificar los escenarios m谩s cr铆ticos, o descubrir la causa del defecto, o prestar atenci贸n a los casos no triviales cuando se realiza la prueba previa.
6. La capacidad de mantener estad铆sticas y m茅tricas m谩s confiables de la calidad del software.
Por ejemplo, la cantidad de errores en los registros de una aplicaci贸n o componente, informes de errores y otros informes que puede hacer un probador, demuestran de manera m谩s realista la calidad del software en comparaci贸n con los mismos informes del entorno de prueba.
7. Siempre es mejor si "su" probador nota el error en el producto que el usuario final.
Por lo general, despu茅s de entregar la tarea, el probador realiza comprobaciones b谩sicas de la funcionalidad nueva o modificada en el producto. Adem谩s, tenemos una persona separada en nuestra empresa: un probador en prod. Quiero se帽alar una vez m谩s que no posiciono el control de calidad en productos como sustituto de las pruebas en preproducci贸n, y, por supuesto, es necesario evitar errores y tomar medidas preventivas. Pero tales pruebas pueden ser una gran t茅cnica adicional en el proceso de garantizar la calidad de su proyecto.
Pr谩cticas 煤tiles de control de calidad en producci贸n que funcionan de manera efectiva en nuestro proyecto1. Verificar las tareas entregadas para asegurarse de que est茅n bien establecidas y que funcionen en el nuevo entorno.
Por ejemplo, cuando presentamos la integraci贸n con un nuevo socio, adem谩s de las pruebas en el pre-prod, definitivamente verificaremos la integraci贸n despu茅s de la entrega, porque hay muchas configuraciones dependiendo del entorno (API, URL, componentes). Tambi茅n hay problemas de terceros: los errores no est谩n de nuestro lado, sino del lado de los servicios integrados.
2. Registro y auditor铆a.
Un buen registro ayuda a los desarrolladores y evaluadores a notar un problema incluso antes de que el usuario final lo adivine, as铆 como tambi茅n a detectar lugares que necesitan optimizaci贸n. Una auditor铆a de acciones y cambios nos permite descubrir siempre las razones de un comportamiento particular sin ning煤n problema. Por ejemplo, si un componente de una pol铆tica de cr茅dito no puede dar una decisi贸n sobre un pr茅stamo, para analizar por qu茅 sucedi贸 esto, primero vamos a los registros. Este art铆culo se aplica a los entornos de producci贸n y preproducci贸n.
3. Sistema de monitoreo y alerta.
Como mencion茅 anteriormente, el monitoreo mediante ciertas m茅tricas es una de las mejores formas de controlar que todo est茅 bien con nuestra aplicaci贸n. Adem谩s, si se produce alg煤n problema, debe enviar una alerta a las partes interesadas (por ejemplo, la cantidad de solicitudes de pr茅stamos es un 20% menor de lo esperado; enviaremos una alerta a los departamentos de TI y de negocios, la carga de la CPU es m谩s alta de lo normal; notifique a los administradores y a las v铆rgenes). Es necesario asegurarse de que las alertas sobre problemas sean oportunas y relevantes, as铆 como tambi茅n indicar realmente el problema.
4. Regresi贸n y control de estabilidad
Una pr谩ctica interesante es pasar peri贸dicamente pruebas de regresi贸n para asegurarse de que nada sali贸 mal en ning煤n lado. Puede ayudar en algunos casos estrechos y espec铆ficos cuando el monitoreo no ve problemas.
5. Informes y estad铆sticas
Como en cualquier prueba, los informes y las estad铆sticas sobre los resultados de las pruebas de productos hacen que el proceso sea m谩s transparente, la calidad del software y las causas de los defectos m谩s visibles.
Todos los errores no se pueden detectar en el pre-prod, por lo que caer谩n en el entorno de combate. Si los usuarios los encuentran, afectar谩 la reputaci贸n de la empresa y, en 煤ltima instancia, la p茅rdida de dinero. Probar en el producto ayudar谩 a prevenir esto.