🎇 🗑️ 🐧 Por qué y cómo estamos probando la actualización 🍇 ✋ 😖

En este artículo explicaré por qué es tan importante no olvidarse de probar actualizaciones de productos y cómo funciona este proceso en nuestra empresa. La estabilidad de las actualizaciones depende de la reputación del producto y la confianza del usuario en sus innovaciones. Desde mi propia experiencia, puedo decir que a veces antes de comenzar una actualización, por ejemplo, por teléfono, prefiero esperar al menos un día y leer los comentarios (siempre son relevantes solo para la última versión). Si los comentarios son abusivos, entonces la probabilidad de que decida actualizar, tiende a cero. La calificación de la aplicación debido a comentarios negativos disminuye, y no es tan fácil restaurarla, ya que debe poder interesar al usuario en la instalación de una nueva actualización, que ahora temerá.

¿Con qué suelen estar descontentos los usuarios?

la aplicación no funciona en absoluto después de la actualización. Por ejemplo, simplemente no sabe qué hacer con los datos en el formato anterior;
se perdieron bonos, descuentos, salvaciones de usuarios (juegos, tiendas, cafeterías);
la nueva característica para la que se anuncia la actualización no funciona;
una nueva característica funciona, pero algunas de las antiguas se cayeron;

Todos estos problemas son relevantes tanto para la aplicación móvil como para el sistema DLP que estamos probando en casa. Más sobre lo que estamos tratando.

Lo que lanzamos y lo que necesita ser actualizado

Nuestra compañía ofrece a los clientes una solución para proteger contra la filtración de información corporativa con la capacidad de configurar por separado para cada organización, según sus necesidades. Los elementos principales del sistema son su configuración (según qué criterios se buscarán los intrusos) y los eventos (incidentes registrados).

El producto consta de varias partes, en este artículo consideraremos el servidor de análisis y almacenamiento de incidentes de InfoWatch Traffic Monitor. El producto se ejecuta en el sistema operativo de la familia Linux, tiene su propia base de datos. El oficial de seguridad usa la consola web para el trabajo. Actualmente se admiten dos distribuciones de Linux diferentes y dos bases de datos. El sistema se puede instalar de varias maneras: todo en uno, cuando todos los componentes de una máquina; e instalación distribuida cuando existen componentes del sistema en diferentes máquinas físicas.

Además de la funcionalidad declarada del sistema, debemos garantizar una actualización de las versiones principales N-1 y N-2 a N, así como la actualización de todas las versiones menores: parches y revisiones de cada versión. Esto se debe al hecho de que nuestros clientes a menudo tienen una infraestructura de TI bastante complicada, la actualización puede llevar mucho tiempo, por lo que es importante limitar el número de actualizaciones, no hacerlas con demasiada frecuencia, evitando el tiempo de inactividad.

Todas estas condiciones dan un conjunto suficientemente grande de configuraciones de nuestro producto, para cada una de las cuales debemos garantizar una actualización exitosa. Por esto se entiende una actualización, como resultado de lo cual:

los datos del usuario no se pierden
las características antiguas no están rotas
nuevas funciones están disponibles para su uso

En este caso, la prioridad de los requisitos de la lista anterior está en orden descendente de importancia. Por ejemplo, si transfiere prioridades desde el plano de trabajar con sistemas DLP al plano de aplicaciones de usuario mencionadas anteriormente, entonces salvar al usuario del juego probablemente sea más importante que la capacidad de comenzar un nuevo juego. Y al usuario de las aplicaciones de pedidos de alimentos no le importa lo lindo que sea el nuevo menú si el botón "Enviar pedido" ha dejado de funcionar.

Considere el ejemplo con nuestra tabla de actualización cuando se lance la versión principal 3. Para la versión 1.0.0, se lanzaron dos parches y tres revisiones, y para la versión 2.0.0 hubo dos revisiones.

1.0.0	2.0.0	3.0.0
1.0.1	2.0.1
1.0.2	2.0.2
1.1.0
1.1.1
1.2.0

En total, en el ejemplo tenemos nueve versiones, de las cuales debemos actualizar a la nueva versión 3.0.0. Hay dos sistemas operativos y dos bases de datos para cada versión de nuestro producto. Aquellos. Se liberan un total de 27 configuraciones actualizadas. Y si tomamos también diferentes métodos de instalación, este número puede multiplicarse fácilmente por dos, como resultado obtenemos 54.

Cada uno de nuestros lanzamientos contiene una serie de características serias (desde el punto de vista del impacto del producto). Los métodos de ajuste del sistema pueden cambiar, los sistemas de análisis se refinan, los incidentes se complementan con nuevos datos, la versión del entorno cambia, por ejemplo, la versión del sistema operativo o la base de datos, etc.

Históricamente...

En tiempos inmemoriales, hemos desarrollado un enfoque de investigación al probar actualizaciones de productos. Se demostró a sí mismo en las condiciones de un buen conocimiento del producto y un pequeño número de entornos y configuraciones probadas. Pero pasó el tiempo, el equipo creció y cambió su composición: tanto los probadores como los desarrolladores iban y venían, y algunas características indocumentadas se olvidaron con seguridad.

La planificación de pruebas de investigación sin un buen conocimiento del producto es una tarea ingrata, estuvo cargada de consecuencias como:

Probar actualizaciones cada vez tomó un tiempo diferente. Más a menudo, el tiempo se asignó de acuerdo con el principio residual, ya que la actualización se probó cuando el producto ya está estabilizado y los toques finales permanecen antes del lanzamiento.
A veces se olvidaron algunos ambientes.
, , . , , , «» - .

La preparación preliminar también se llevó a cabo principalmente a discreción del probador, quien consiguió la tarea y, a veces, sin tener en cuenta todos los cambios en la versión.

Además de las características internas del proceso de prueba, el hecho de que la documentación no describiera los cambios que ocurren con la funcionalidad del producto agregó combustible al fuego. Por lo tanto, podríamos probar no lo que estaba cambiando, sino lo que no se vio afectado en absoluto por la versión actual.

Como resultado, era imposible comprender claramente a partir del informe de prueba de actualización qué controles se llevaron a cabo, a qué valores, etc.

Sin embargo, durante algún tiempo estuvimos satisfechos con los resultados de las pruebas de investigación: no hubo tantos defectos militares para la actualización y no hubo recursos para los cambios para la ventaja teórica.

Algo salió mal

Sin embargo, la situación cambió cuando los defectos críticos de actualización para nuestros clientes se arrastraron. Con mayor frecuencia, se encontraron en algún lugar alejado de los escenarios de actualización principales y se asociaron con situaciones en las que, por ejemplo, un elemento de tecnología de análisis creado y funcionando en la versión anterior bloqueó la actualización, o se perdieron algunos de los eventos en la base de datos del cliente, o el escenario más crítico cuando, después de la actualización, algunos de los servicios no se iniciaron y recibimos un producto inoperativo. Los defectos relacionados con la base también han comenzado a aparecer en nuestros clientes.

En esta situación, el proceso actual ya no nos satisface. Algo tuvo que ser cambiado.
Comenzamos formulando problemas que, en nuestra opinión, nos impedían probar mejor la actualización. Después de la discusión, se formó la siguiente lista de problemas:

;
, ;
, , , , ;
, ;
;
. ? ? ? ?

Además, para cada problema identificado, tratamos de encontrar una solución digna. Además de resolver problemas específicos que hemos formulado para nosotros mismos, decidimos en el curso de las discusiones presentar requisitos para el proceso de prueba en sí, en el que nos gustaría trabajar más.

El proceso debe hacerse más abierto y transparente, por esto abandonamos completamente las pruebas de investigación a favor de los casos de prueba.

Para crear los casos de prueba necesarios, necesitamos información sobre los cambios entre versiones. Esta información debe solicitarse a los desarrolladores y analistas de productos.

En el nuevo enfoque, utilizamos una combinación de comprobaciones en los objetos del sistema (sin cambios y cambios durante la actualización) + comprobaciones de humo de la funcionalidad (antiguas, nuevas o modificadas).

Para la actualización, se seleccionará la opción más difícil para instalar el sistema: instalación distribuida. Para todos los SO y DB. Las opciones más simples se omiten como casos especiales.

Esta combinación de controles nos dará la oportunidad de probar los siguientes componentes del sistema:

DB
Web (frontend, backend);
Componentes de Linux

Como resultado, la solución para cada uno de nuestros problemas se presentó de la siguiente manera:
no hay suficiente información sobre los cambios en la versión actual. Insuficiente conocimiento del sistema, no hay suficiente información sobre el sistema. Junto con analistas y desarrolladores, determinamos las áreas cambiantes del producto entre las versiones actualizadas y actualizadas.

Probar actualizaciones se convierte en regresión. Se realizan pruebas funcionales, no objetos del sistema y operaciones en ellas. Probaremos la actualización de los casos de prueba en forma de pruebas de humo de la verificación funcional + de datos.

imagen

Incomprensible presentación de informes. La cobertura y los resultados se pueden tomar de los casos de prueba.

El proceso es opaco. Después de resolver cada problema individual, se formó un nuevo proceso que se justificó por nuestras necesidades y también se solucionó de tal manera que cada miembro del equipo ahora podía familiarizarse con sus principios.

Nuevo proceso

Como resultado, construimos un proceso bastante efectivo.

Dividimos las pruebas en varias etapas, que dieron aún más bonificaciones no planificadas, que se describen a continuación:

Formación.
- Analizamos los cambios en el sistema, preparados conjuntamente con analistas y desarrolladores para áreas cambiantes.
- De acuerdo con los resultados del análisis, compilamos una lista de objetos del sistema preparados para probar actualizaciones.
- Para cada objeto del sistema, se determina el conjunto necesario de estados, estados y parámetros.
- Creamos stands con la versión necesaria (actualizada) del producto.
- , .
- ( ).
- smoke- , .
:
- ;
- (, , , );
- , .
- .
- -, .
- .
- , .
- Comprobaciones de operaciones en objetos (creación, edición, eliminación).
- Comprobación de la interacción de objetos con otros objetos (detección).

Pros y contras de enfoque

Hemos logrado nuestro objetivo, a saber:

El proceso se ha vuelto transparente. Sabemos que estamos probando cómo, cuánto tiempo llevará y qué artefactos se generarán. Recibimos criterios objetivos por los cuales fue posible dar nuestro veredicto sobre una actualización de producto que funciona o no funciona.
Los informes se hicieron claros. La presencia de casos de prueba y un informe sobre los resultados de su aprobación permitieron informar rápidamente al gerente del proyecto y al director técnico sobre la calidad del ensamblaje creado.
Mayor cobertura y más comprensible que con un enfoque de investigación.
Ahora estamos probando un cambio en los datos y la funcionalidad. Gracias a la capacidad de respuesta de analistas y desarrolladores, podemos decir con un alto grado de precisión qué ha cambiado en el sistema y dónde existe el riesgo de contraer un defecto.

Pero siguiendo una nueva estrategia de prueba, no podríamos dejar de encontrar el inconveniente obvio del nuevo enfoque: un aumento significativo en el tiempo de prueba.

Comenzamos a pasar tiempo no solo en pruebas directas, como fue el caso de las pruebas de investigación. Los nuevos costos de tiempo se asociaron principalmente con la preparación para las pruebas, a saber:

análisis de cambio;
creación, llenado, mantenimiento de stands para actualización;
actualizar kits de prueba antiguos y crear nuevos.

Este punto negativo podría convertirse en decisivo para tomar la decisión de abandonar la nueva metodología, si no fuera por un "pero".

Toda la preparación, y esta es la etapa que requiere más tiempo, podría llevarse a cabo tan pronto como se formara la composición final de la liberación, incluso sin un producto terminado. Por lo tanto, "distribuimos" la preparación de acuerdo con el plan de prueba, sin sobrecargar el período de pre-liberación demasiado saturado. Todavía solo tenía que pasar las pruebas en el producto estabilizado terminado.

En total, de acuerdo con los resultados de la primera etapa de mejoras, recibimos lo siguiente: comenzamos a pasar más tiempo probando, pero al mismo tiempo tenemos un proceso transparente, una visualización clara de los resultados y más cobertura, lo que nos permite:

detectar más defectos como resultado de verificar las actualizaciones de productos en su departamento;
reducir el número de defectos cuando los ingenieros de implementación actualizan a nuestros clientes;
reducir la cantidad de defectos recibidos del soporte técnico.

¿Que sigue? - acerca de la optimización

Bien podría haberse resuelto en esto, pero el tiempo siempre es dinero. Además, de acuerdo con los resultados del primer avance de la nueva metodología, las formas de optimizar los costos de tiempo se hicieron más claramente visibles.

Fuimos de dos maneras:

optimización basada en análisis de ejecuciones de pruebas: aquí nos dedicamos a identificar dependencias obvias e implícitas de los resultados de las pruebas en los entornos utilizados. Esta es la forma en que han ido las pruebas funcionales.
prueba de automatización. Entonces nuestro equipo de automatización vino al rescate.

Hablaré un poco más sobre cada camino.

Primera forma: optimización basada en el análisis de las ejecuciones de prueba. De

esta manera elegimos optimizar las pruebas de actualización entre las versiones principales, es decir entre aquellos donde hubo un cambio significativo en la funcionalidad.

Lo primero que notamos fueron las pruebas que dependen de la base de datos y solo de la base de datos. Pudimos comprender qué controles son suficientes para realizar una vez en cada base, y luego excluirlos de nuestra combinatoria con el sistema operativo por completo.

El segundo paso fue el "colapso" de las verificaciones volumétricas de la funcionalidad anterior en una lista de verificación. En las primeras iteraciones, la funcionalidad, independientemente de si aparecía en la versión actual, en la anterior o siempre, se basaba en su propia prueba completa. Ahora, las pruebas completas se basan solo en nuevas características, mientras que la funcionalidad anterior se verifica en la lista de verificación.

Además, la misma lista de verificación fue muy útil para nosotros cuando lanzamos parches y revisiones, donde además de las actualizaciones entre las versiones principales, también es importante buscar actualizaciones dentro de la versión.

La segunda forma: prueba de automatización En

primer lugar, quiero hacer una reserva de que no planeamos automatizar las actualizaciones de prueba porque fue aceptado y en general un buen tono, pero porque la actualización es el tipo de prueba que no puede excluirse con ninguna versión, ya sea importante lanzamiento, parche o revisión. Elegimos este camino para reducir el tiempo de prueba de actualizaciones para versiones menores, es decir, parches y revisiones, es decir versiones entre las cuales la composición de lo funcional no cambia. En este caso, la automatización de prueba parecía muy eficiente.

En esta etapa, las actualizaciones de prueba al lanzar parches y revisiones están casi completamente automatizadas.

Las actualizaciones de prueba cuando se lanzan versiones principales se divide entre pruebas manuales y automatizadas. Comprueba manualmente las áreas cambiables afectadas por las características. Las pruebas de áreas invariables se persiguen automáticamente, la mayoría de las veces es la reutilización de las pruebas automáticas ya escritas para versiones anteriores con poca actualización para una nueva.

Para comenzar el proceso de automatización de casos de prueba, tuvimos que refinarlos aún más, ya que el lenguaje de las pruebas de un probador manual permite muchas más dificultades de las que puede permitirse un autotest. Es decir, también asignamos tiempo para la preparación de pruebas para la automatización, que realmente valió la pena casi la primera ejecución.

Resumen

Tuvimos un proceso de investigación para probar actualizaciones. En algún momento, dejó de satisfacernos debido a una caída notable en la calidad de la actualización. No elegimos un reemplazo para las pruebas de investigación como una técnica preparada, sino que la formamos en función de los problemas que identificamos. La formación de una nueva metodología, que usamos y seguimos mejorando, estuvo influenciada por soluciones preparadas a los problemas, así como por los deseos generales del proceso de prueba.

No creo que en esta situación inventamos una bicicleta cuando tomamos el camino de crear nuestro propio proceso diseñado específicamente para nuestro proyecto y las características de nuestro producto. Si desarmamos el proceso en sus partes constituyentes, obtenemos, en general, técnicas generalmente aceptadas y ampliamente utilizadas.

A pesar del hecho de que los resultados del trabajo que hemos recopilado en un artículo no demasiado voluminoso, todo el proceso desde la comprensión del problema hasta la introducción de nuevas soluciones y la optimización de las pruebas nos llevó casi dos años.

Tratamos de describir honestamente aquí todos los pros y los contras, así como las trampas de nuestras decisiones, para que la historia no se vea exclusivamente como una historia de éxito "fue malo, se volvió bueno".

Esperamos que nuestra experiencia le sea útil.

Autor del material:tryzhova (Ryzhova Tatyana).

Por qué y cómo estamos probando la actualización