Get best of the week

Lo que aprendimos al probar el sistema de información del estado

¡Hola a todos! 

Lidero el sector de pruebas en el departamento de análisis y pruebas de sistemas del departamento de sistemas corporativos de LANIT. He estado en este campo durante 14 años. En 2009, por primera vez tuve que probar el sistema de información del estado. Y para LANIT y para el cliente, fue un proyecto enorme y significativo. Ha estado en operación comercial por más de nueve años.

Fuente

Este texto le presentará el enfoque para probar SIG, que se utiliza en nuestra empresa. En particular, lo descubrirá (el enlace lo lleva al fragmento del artículo mencionado en un párrafo específico):


Antes de LANIT, trabajé en un grupo de prueba de cinco personas, donde las tareas fueron asignadas al líder del equipo. Cuando llegué a LANIT, me asignaron administrar un equipo de prueba distribuido geográficamente de cuatro evaluadores, que estuvieron involucrados al comienzo del proyecto para probar el sistema de información del estado. A medida que se desarrolló el proyecto, el número de evaluadores en el grupo aumentó en proporción al aumento de la funcionalidad.

Capítulo 1. Inicio del primer proyecto de prueba SIG


Cuando comenzamos a trabajar con SIG, en primer lugar, tuvimos que lidiar con grandes volúmenes de funcionalidad (varias docenas de subsistemas, cada uno con hasta cientos de funciones) que debían probarse en poco tiempo. El equipo tenía la tarea de no confundirse en el alcance de las funciones y minimizar los riesgos de defectos perdidos.

La documentación normativa, sobre la base de la cual se desarrollaron las especificaciones técnicas, estaba cambiando constantemente, y todo el equipo tuvo que adaptarse a las innovaciones: revisamos las especificaciones técnicas para el desarrollo y las prioridades del proyecto (como resultado, el plan de prueba cambió). 

Fue difícil para los analistas adaptarse al cambio frecuente de la documentación reglamentaria, lo que llevó a una falta de comprensión de cómo mantener actualizadas las especificaciones técnicas, cómo tener siempre un conjunto de especificaciones relevantes para cada versión del sistema, cómo y dónde mostrar el grado de influencia de un cambio en una especificación en muchos otros documentos relacionados . 

Dado que el resultado del trabajo de los analistas fue utilizado por los desarrolladores y evaluadores, las preguntas sobre la relevancia de las especificaciones técnicas, la comprensión del historial de especificaciones, la conformidad del conjunto de especificaciones técnicas de la próxima versión de lanzamiento, fueron agudas para todos los participantes en el equipo del proyecto. Las consecuencias de la confusión con la documentación, el control de versiones de las especificaciones técnicas afectaron el costo del proyecto.

A veces la situación cambió 180 grados. De acuerdo, cuando un tren se apresura a alta velocidad, es imposible cambiar de dirección bruscamente sin consecuencias.

Asistía regularmente a reuniones y entendía la razón de los cambios en el proyecto. La parte más difícil es explicar a los evaluadores remotos por qué probamos el nuevo registro durante un mes, y ahora tenemos que olvidar todo y prepararnos para probar la funcionalidad completamente rediseñada de este registro. La gente comenzó a sentirse como dientes en una máquina gigante, y su trabajo se consideró completamente inútil.

Al principio, tales cambios molestaron al equipo y lo desmotivaron fuertemente. Pero el equipo aceptó el hecho de que es imposible influir en el cambio en las especificaciones técnicas, pero puede aprender a trabajar con él. En ese período difícil para el proyecto, el equipo de prueba tenía una nueva tarea, que generalmente estaba ausente en proyectos más pequeños: requisitos de prueba. 

Como resultado, las desventajas de cambiar los requisitos se convirtieron en ventajas para los evaluadores en forma de una nueva tarea de prueba y la capacidad de influir en el resultado final del proyecto. 

Además de interactuar con los analistas, el equipo de evaluación resultó ser dependiente de las comunicaciones con sistemas externos con los que debían integrarse. No todos estaban listos para proporcionar su circuito de prueba e informar a los sistemas de terceros sobre sus fechas de lanzamiento e intercambiar información sobre cambios en los servicios. Tal desincronización en las comunicaciones o una actitud descuidada hacia la notificación de la composición de los cambios a los servicios web por parte de sistemas externos condujo a errores del producto y dificultades para realizar pruebas de integración. Los probadores tuvieron que establecer comunicaciones con sistemas externos, desarrollar la habilidad de probar la integración y atraer desarrolladores para implementar stubs.

Todo el equipo de prueba que participó en el proyecto se enfrentó a la necesidad de sumergir al equipo de desarrollo en el proceso de producción. Al comienzo del proyecto, el equipo de desarrollo comenzó a buscar nuevos enfoques para la organización del trabajo, introdujo los modelos de ramificación Feature Branch Workflow y el modelo Gitflow. El desarrollo de pequeños proyectos anteriormente no tenía un montón de sucursales, todos estaban cómodos. Pero ante el problema de la incapacidad de estabilizar la versión durante un par de meses para la próxima demostración de la etapa intermedia del proyecto al cliente, después de analizar las razones, el gerente de desarrollo y el arquitecto llegaron a la conclusión de que el proceso de creación de software necesita ser cambiado. Luego comenzaron a utilizar activamente Flow Branch Workflow y Gitflow en el proyecto. Apareció otra nueva tarea de prueba: estudiar los principios de funcionamiento de los modelos de desarrollo para adaptarse al proceso de creación de software.

Los SIG implican dividir un proyecto en bloques funcionales, cada uno de los cuales incluye un conjunto de componentes estrechamente relacionados entre sí por parte de las empresas y / o realizar una función técnica independiente. Si al comienzo del proyecto todos los evaluadores verificaron los bloques funcionales recién llegados, y todos en el equipo eran intercambiables, tenían el mismo grado de conocimiento de todos los bloques, entonces a medida que el proyecto se expandió, el número de evaluadores también tuvo que aumentarse y dividirse en grupos. El crecimiento del equipo condujo al proceso de separación en grupos de prueba, la asignación de roles de proyecto dentro de cada grupo.

A medida que se desarrolló el proyecto, comenzaron a aparecer características de los sistemas de información estatales. 

Capítulo 2. Características de los SIG. Cómo los probadores viven y trabajan con ellos


En primer lugar, los SIG grandes están sujetos a mayores requisitos de confiabilidad y carga, operación del sistema - 24/7, el mal funcionamiento del sistema no debe conducir a la pérdida de datos, tiempo de recuperación del sistema - no más de 1 hora, tiempo de respuesta - no más de 2 segundos y mucho más. 

Como se trataba de un portal web, los evaluadores tuvieron que sumergirse en el proceso de prueba de los portales web multiusuario y desarrollar un enfoque para el diseño y el proceso de prueba, teniendo en cuenta las peculiaridades de la interfaz web.

Una gran cantidad de usuarios puede usar una aplicación web al mismo tiempo. Se requería proporcionar pruebas de carga de la parte abierta del SIG utilizada por todos los usuarios, para predecir el modelo de carga y realizar pruebas de carga.

El usuario puede tener sus propios niveles de acceso. Se requirió probar la matriz de roles de usuario en el subsistema de administración de aplicaciones usando técnicas de diseño de prueba.

Los usuarios pueden acceder a una entidad, lo que conduce a un acceso competitivo. Para que los datos de entrada de un usuario no sobrescriban los datos de otro, tuvimos que realizar un análisis de prueba de situaciones en las que es posible cambiar simultáneamente los datos en los paneles personales de los usuarios, para incluir en las pruebas las comprobaciones de las pruebas correctas con mensajes de diagnóstico.

Una de las características del sistema fue el uso del motor de búsqueda SphinxSearch.con lo cual el equipo de prueba no sabía cómo trabajar. Para comprender las complejidades de las pruebas, Sphinx tuvo que consultar con los desarrolladores y comprender cómo ocurre la indexación de datos.

Los probadores dominaron las características de las búsquedas de prueba por formas de palabras, fragmentos de palabras, sinónimos, al buscar dentro de los documentos adjuntos, comenzaron a comprender por qué los datos de búsqueda recién creados no aparecían en el resultado de la búsqueda y si esto era un error. 

El proyecto tenía un subsistema de administración aplicada, que incluía no solo el registro de usuarios, sino que se complicaba por la presencia de una matriz de roles de usuarios. Se configuró en las cuentas personales de administradores de organizaciones. El número de combinaciones de controles de la matriz de roles fue enorme y el número de tipos de organizaciones tampoco fue pequeño, es decir, el número de combinaciones de controles creció exponencialmente. Era necesario cambiar el enfoque familiar para diseñar pruebas utilizadas anteriormente en proyectos pequeños. 

Dado que el sistema asumía una interfaz web, era necesario proporcionar pruebas de navegador cruzado, lo cual no se planeó originalmente. Cuando el proyecto recién comenzaba, Internet Explorer 7.0 era el único navegador que soportaba criptografía doméstica, y la mayoría de los usuarios usaban este navegador. Por lo tanto, al comienzo del proyecto, para probar la lógica y la funcionalidad del trabajo de las cuentas personales, solo se utilizó IE de esta versión, pero para la parte abierta del portal, se requería soporte para todos los navegadores existentes en ese momento. Sin embargo, en ese momento no pensaron en las pruebas entre navegadores.

Cuando me preguntaron: "¿Cómo se comporta el sistema en todas las versiones conocidas de los navegadores?" - Estaba en pánico, por decirlo suavemente, ya que el volumen del modelo de prueba era enorme (alrededor de 4,000 casos de prueba), el conjunto de prueba de regresión era de aproximadamente 1,500 casos de prueba, y el equipo de prueba verificó a toda la multitud exclusivamente en un navegador seleccionado por defecto. Este caso tuvo que resolverse muy rápidamente y utilizó el ingenio para cumplir con los plazos para el primer lanzamiento y cubrir las versiones principales del navegador con pruebas.

En Internet, entonces, había pocos artículos sobre pruebas, desarrollo de modelos de prueba. Para nuestro equipo, en ese momento, una tarea incomprensible era cómo crear, dónde almacenar y cómo mantener actualizado un modelo de prueba grande. No estaba claro cómo alejarse de las pruebas de investigación, que podrían volverse infinitas, y no había recursos para la prueba interminable: ni humana ni temporal.

Después de que el SIG se puso en operación de prueba, y luego en la industrial, apareció una nueva tarea: manejar los incidentes de los usuarios. 

Antes de que se creara un servicio completo de soporte al usuario de SIG, el equipo de prueba atendió el primer golpe de las solicitudes de los usuarios, como el más inmerso en los detalles del sistema, tratando de combinar las tareas principales de probar nuevas mejoras, así como procesar los incidentes entrantes de proceso que fueron superpuestos por SLA.

El equipo de prueba no ha encontrado una tarea así antes. El flujo de incidentes necesitaba ser procesado, sistematizado, localizado, corregido, verificado e incorporado al nuevo ciclo de lanzamiento. 

El nivel de comprensión y madurez del proceso de operación creció y mejoró a medida que el sistema mismo creció. 

He enumerado solo una parte de las características que el equipo de pruebas encontró al trabajar con SIG.

Capítulo 3. Problemas de prueba de SIG y métodos para resolverlos. Recomendaciones para evaluar gerentes de equipos.


En el proceso del equipo de pruebas trabajando en varios SIG grandes, se nos ocurrieron recomendaciones para los gerentes de pruebas. Posteriormente se transformaron en la metodología del proceso de prueba de dichos sistemas en nuestro departamento y continúan mejorando al resolver nuevos problemas en proyectos de una escala similar.

¿Qué hacer cuando hay mucha funcionalidad?


No entre en pánico y divida lo funcional en bloques / módulos / funciones, conecte al analista a la auditoría del resultado, asegúrese de que la visión de los bloques funcionales sea correcta. 

Recomendamos hacer:

  1. .

    , , , , production. , .
  2. //.

    , , — ,   ///. , , , - , , , / // , , « » , .

¿Qué hacer con las matrices de conocimiento y la cobertura de los requisitos funcionales?


La funcionalidad no se vuelve más pequeña. Ahora todavía hay mucho, pero está en una nueva representación (en forma de matriz). Es necesario determinar qué funciones son las más importantes desde el punto de vista comercial y qué no se puede proporcionar a los usuarios en forma cruda. Entonces comienza la priorización de la funcionalidad. Idealmente, si el analista ayuda al probador en esto. Como mínimo, apreciará la exactitud de las prioridades colocadas por las pruebas.

A las funciones / bloques / módulos más importantes se les asignará una alta prioridad para la prueba, las menos importantes serán cubiertas por las pruebas de segunda prioridad, el resto será la tercera, o si los "plazos están en marcha", puede posponer su prueba para un momento más tranquilo. 

Por lo tanto, tenemos la oportunidad de probar la funcionalidad que es realmente importante para el cliente. Ponemos las cosas en orden en una gran cantidad de funciones, entendemos lo que está cubierto por las pruebas y lo que queda por cubrir, sabemos que en el interior es necesario fortalecer las pruebas, en caso de enfermedad / despido de probadores responsables, entendemos a cuál de los probadores los equipos deben pasar las mejoras a la prueba (en correspondencia con la matriz de conocimiento), qué nuevas funciones / módulos / subsistemas interesantes puedo ofrecerle a Vasya, Pete, Lisa condicional, cuando están cansados ​​de probar lo mismo. Es decir, obtuve una herramienta visual para motivar a los evaluadores que desean aprender algo nuevo sobre el proyecto.

¿Qué hacer cuando los requisitos no son compatibles con la historicidad, están confundidos, duplicados, cómo trabajan los probadores con esto?


Recomendamos implementar el proceso de prueba de requisitos en el proyecto. Cuanto antes se descubra un defecto, menor será su costo.

Los probadores distribuidos por la matriz de conocimiento, sobre la disponibilidad de especificaciones técnicas para el desarrollo, inmediatamente comienzan a estudiarlos y verificarlos. Con el fin de dejar en claro a todos qué errores hay en los requisitos, se desarrolló un conjunto de reglas para los analistas "Receta para los requisitos de calidad", según la cual trataron de escribir los requisitos, y se crearon plantillas para especificaciones técnicas para describirlos en un solo estilo. Se emitieron reglas para el formato de especificaciones técnicas y recomendaciones para la descripción de los requisitos a los evaluadores para comprender qué errores buscar en los requisitos.

Por supuesto, la tarea principal del probador fue encontrar inconsistencias lógicas o momentos de influencia no contabilizados en funciones / subsistemas / módulos relacionados que el analista podría perderse. Después de detectar defectos, se repararon en el rastreador de errores, se asignaron al autor del requisito, el analista detuvo el desarrollo y / o conversó con el probador y el desarrollador informó que la condición se modificaría de acuerdo con el defecto (para no ralentizar el desarrollo), hacer correcciones y publicar la versión corregida requisitos El probador verificó y cerró el trabajo sobre el defecto a los requisitos. Este procedimiento le dio al equipo la confianza de que después de un par de semanas de desarrollo, el problema detectado definitivamente no saldría en la prueba.

Además de la detección temprana de defectos, recibimos una herramienta poderosa para recopilar métricas sobre la calidad del trabajo de los analistas. Teniendo estadísticas sobre el número de errores en los requisitos, el analista principal del proyecto podría tomar medidas para mejorar la calidad del trabajo en su grupo. 

¿Qué hacer cuando es necesario realizar pruebas de carga?


Es necesario estudiar los requisitos para la carga, elaborar su modelo, desarrollar casos de prueba, coordinar el modelo de prueba de la carga con el analista y desarrollar scripts de carga con la participación de especialistas competentes en las pruebas de carga. 

Por supuesto, no puede adivinar la carga con el modelo de prueba, pero para un golpe más preciso, además del analista, puede atraer a un arquitecto o especialista en DevOps que, después de analizar la información, estadísticas, métricas, puede decir qué otros casos se necesitan en el modelo de carga propuesto.

También vale la pena implementar el proceso de ejecutar pruebas de carga, tomar los resultados de la carga y pasarlos a los desarrolladores para eliminar los cuellos de botella.

El proceso de carga debe llevarse a cabo regularmente antes del lanzamiento de cada lanzamiento, cambie periódicamente el modelo de carga para identificar nuevos cuellos de botella.

¿Qué hacer cuando es necesario realizar pruebas de integración en las que no hay experiencia?


Hay formas básicas: por ejemplo, puede tomar cursos de capacitación avanzada sobre el tema de las pruebas de Rest API, leer artículos en Internet, intercambiar experiencias con colegas a través de Skype, con una demostración del proceso, contratar a un especialista que esté bien versado en las pruebas de Rest API para el grupo de prueba. 

Hay muchas formas de sumergirse en este tipo de pruebas. Se contrató a un especialista experimentado en mi equipo, que en el futuro nos capacitó a mí y a todo el equipo de pruebas, desarrolló manuales: qué buscar al probar la API Rest, cómo elaborar un diseño de prueba para verificar la integración, realizó seminarios web con una demostración del proceso de prueba para todo el equipo. 

Se nos ocurrieron tareas de prueba en las que todos tuvieron la oportunidad de practicar y sumergirse en este proceso. Ahora, el material que ya se ha desarrollado a lo largo de los años solo está mejorando, y el proceso de aprender y sumergirse en las pruebas de Rest API tarda 1-2 semanas, mientras que antes tardaba un mes o más en bucear, dependiendo de la complejidad del proyecto y el volumen del modelo de prueba. 

Fuente

¿Cómo no confundirse en ramas de código, stands, implementaciones y probar el código necesario?


Si bien el SIG se encuentra en la etapa inicial de desarrollo, solo hay dos ramas de código: maestro y lanzamiento. El segundo se separa en la etapa de estabilización para realizar pruebas de regresión final y corregir defectos de punto de la regresión.

Cuando la rama de lanzamiento se envió a producción y comenzó la siguiente iteración de desarrollo, en algún momento decidimos paralelizar el desarrollo de nuevas tareas para que la tarea más grande planificada a través del lanzamiento pudiera completarse a tiempo. En algún momento, había 3-4 o más de tales ramas. Hay más de tres bancos de pruebas implementados con el objetivo de comenzar a probar las pruebas de versiones futuras tan pronto como sea posible.

Los probadores están seguros de que el especialista en infraestructura instaló, por ejemplo, la revisión No. 10001 en uno de los bancos de pruebas, realizó todo correctamente y puede comenzar la prueba. El especialista en infraestructura realizó la implementación desde la rama de código, informó que el soporte se implementó, el código se instaló y se pudo probar.

Comenzamos la prueba y entendemos que:

  • hay errores que ya se han corregido;
  • la funcionalidad del bloque existente difiere significativamente de la funcionalidad similar que se encuentra en otro banco de pruebas y se está preparando para la próxima versión planificada, aunque no debería haber ninguna modificación dentro de la rama del código transferido;
  • comenzamos a registrar defectos, los desarrolladores los devuelven, el holivar comienza en los chats de diseño y descubre lo que realmente instalamos y por qué no lo que esperábamos.

Llevamos a cabo un análisis y descubrimos que los desarrolladores no dieron instrucciones al especialista en infraestructura sobre qué rama implementar, el empleado recolectó de la rama de desarrollo y el desarrollador logró fusionar solo una parte del código de la rama de características en la rama de desarrollo. 

El probador, que no entendía en absoluto la gestión de la sucursal, obtuvo la tarea y un enlace al stand, corrió a probar, pasó tiempo, tuvo muchos defectos, la mayoría de ellos eran irrelevantes debido a toda esta confusión.

Lo que hicimos para evitar situaciones similares en el futuro:

  • el desarrollador prepara instrucciones para el especialista en infraestructura que indica desde dónde desplegar la implementación, la instrucción se pasa a través de la tarea a jira;
  • el especialista en infraestructura no está confundido y hace lo que se le dio;
  • GIT, , jira ;
  • jira : 

  • Gitflow , , hotfixes develop,  .


, ,   ?


Le recomendamos que elabore una estrategia de prueba por adelantado, pero como se perdió este punto, mi experiencia probablemente le sea útil.

Primero, debe comprender qué navegadores se especifican en los requisitos. Si ha decidido esto, pero no hay absolutamente ningún tiempo, miraremos las estadísticas de los navegadores más utilizados, por ejemplo, aquí . Luego intentamos llegar a tres o cinco de los navegadores más populares.

Como el proyecto es grande y el equipo de prueba era grande, era físicamente posible asignar un navegador popular de acuerdo con las estadísticas a cada probador. Lleva a cabo sus casos de regresión en una versión de navegador dedicada, se debe prestar especial atención al diseño, la posibilidad de hacer clic en los botones y enlaces. Este proceso se ve así: por ejemplo, hay 100 scripts para una prueba de regresión, el equipo tiene 5 probadores, cada uno puede tomar 20 scripts para trabajar, cada uno tiene asignado un navegador. Para una ejecución de regresión, cada probador verificó sus casos en uno de los navegadores. Al final, la cobertura no está completa, pero dado que muchos escenarios todavía se repiten en un grado u otro, el porcentaje de cobertura aumentó debido al paso de parte de los guiones de regresión por parte de diferentes navegadores. 

Por supuesto, esto no proporcionó una cobertura de prueba del 100% de toda la funcionalidad, pero permitió reducir significativamente los riesgos de que los defectos entre navegadores entren en producción de acuerdo con los principales escenarios comerciales del sistema.

Además, no solo en la regresión, sino también en la prueba de mejoras y validación de defectos, realizamos controles en diferentes navegadores, ampliando la cobertura de compatibilidad entre navegadores.

En el futuro, comenzaron a aplicar el enfoque distribuyendo probadores por navegadores en la prueba de refinamiento, sin esperar la etapa de prueba de regresión, aumentando así el porcentaje de pruebas que cubren diferentes versiones de navegadores.

Lo que tenemos

  • costos de prueba optimizados, tanto financieros como de tiempo, durante un intervalo de tiempo verificamos tanto la prueba de regresión como el navegador cruzado;
  • , Severity;
  • , , .

?


Muy rápido, teníamos una pregunta sobre cómo ejecutar pruebas en un único repositorio, mantenerlas actualizadas y sobre la capacidad de ejecutar ejecuciones de prueba con marcas en el resultado de la ejecución.

El equipo incluía empleados con experiencia en el sistema de gestión de pruebas TestLink . Este es el único sistema de gestión de casos de prueba de código abierto, por lo que se eligió para funcionar. En este sistema, una interfaz gráfica muy simple y un diseño sin lujos innecesarios. Rápidamente llenamos el programa con pruebas, surgió la pregunta de cómo mantenerlo. Al principio, se gastaron muchos recursos en actualizar los casos para cada revisión; esta opción resultó inoperante.

Después de consultar con el analista y el equipo de prueba, decidimos que no era necesario mantener siempre actualizado un modelo de prueba tan grande debido a los costos de su soporte. 

Todos los casos se dividieron de acuerdo con la matriz de requisitos funcionales en carpetas, cada módulo / subsistema funcional almacenó un conjunto de casos en una carpeta separada. Esto nos permitió estructurar visualmente los casos de prueba. Las palabras clave se crearon en TestLink, con la ayuda de la cual el caso pertenece a un grupo en particular, por ejemplo:

  • humo: utilizado para casos de prueba incluidos en la prueba de humo ( realizando un conjunto mínimo de pruebas para detectar defectos obvios de funcionalidad crítica );
  • prueba automática: se utiliza para casos de prueba mediante los cuales se desarrollan pruebas automáticas;
  • Prioridad 1: se utiliza para casos de prueba relacionados con funciones comerciales etiquetadas como Prioridad 1.

Como resultado, un diseño de prueba siempre está diseñado para nuevas mejoras, como resultado de lo cual aparece un documento de lista de verificación. En él, las verificaciones tienen prioridad, y solo una parte de las verificaciones cae dentro de la "Prioridad 1" o ya se han creado casos de prueba de humo y regresión en el sistema TestLink.

¿Cómo tener siempre un modelo de caso de regresión real para un lanzamiento planificado y un HotFix repentino en producción?


Antes del comienzo de la prueba de regresión, se completó todo el trabajo preparatorio, incluida la actualización o la adición de nuevos casos a la regresión. Y esto significa que si ejecuta un caso de prueba ejecutado relevante para la nueva versión, pueden provocar defectos al verificar HotFix en tales casos de prueba. 

Las correcciones de HotFix se realizaron en la rama del código anterior (última versión) y se realizaron cambios en el código mediante correcciones de defectos, mientras que los casos de prueba actuales podrían haberse modificado a partir de las mejoras de la versión futura. Es decir, ejecutar casos de prueba relevantes para una versión futura podría conducir al registro de defectos falsos y retrasar la publicación de HotFix.

Para evitar el registro de defectos falsos y la interrupción de los plazos de prueba de HotFix, decidimos utilizar un mecanismo similar al mantenimiento de las ramas de código. Los probadores llevaron a cabo manualmente la fusión y actualización de casos entre ramas (léase "carpetas") de TestLink de acuerdo con un cierto algoritmo, mientras que en el modelo de Gitflow Git lo hace automáticamente.

Aquí hay un conjunto de casos de prueba en TestLink:


Se inventó el proceso de actualización de casos en TestLink

  • El administrador de pruebas copia la carpeta con los casos "Test Project 1.0.0" y crea un nuevo conjunto de pruebas, que se llama el número de la próxima versión planificada. Resulta que la carpeta con casos "Proyecto de prueba 2.0.0".
  • Después de estudiar las mejoras para una versión futura, se analizan los casos de prueba de la carpeta "Test Project 2.0.0" para determinar la necesidad de actualizarlos para nuevas mejoras.

Si es necesario, actualice los casos:

  • el probador responsable de la revisión realiza cambios en el caso de prueba en el conjunto "Proyecto de prueba 2.0.0";
  • si necesita eliminar un caso de prueba, primero debe moverlo a la carpeta "Eliminar", esto se hace para poder recuperar un caso de prueba eliminado accidentalmente o si los requisitos se devuelven y el caso de prueba vuelve a estar en demanda (la prueba casos solo de la carpeta correspondiente al conjunto de pruebas de la futura versión planificada, en la que este caso de prueba no será relevante);
  • si agregamos un caso de prueba, esto solo debe hacerse en la carpeta correspondiente al conjunto de pruebas de la futura versión planificada;
  • los casos de prueba que cambian están marcados con la palabra clave "Modificado" (necesario para evaluar la métrica del grado de influencia de las mejoras en la regresión funcional);
  • los casos que se agregan están marcados con la palabra clave "Agregado" (necesario para evaluar la métrica por el efecto de las mejoras en la regresión funcional).

Por lo tanto, siempre tenemos un conjunto de casos de prueba real correspondiente a la versión de lanzamiento anterior del sistema y lo usamos para la prueba HotFix, así como también trabajamos para actualizar el nuevo conjunto de pruebas, prepararnos para las pruebas de regresión y el proceso de estabilizar la nueva versión planeada. En algún momento, al mismo tiempo, se pueden obtener de 3 a 4 ramas de prueba (leer "carpetas") de TestLink, correspondientes a diferentes versiones del sistema, lo cual es especialmente importante cuando se prueban mejoras en las ramas de características.

Después de cada lanzamiento, podemos estimar cuánto ha cambiado nuestro modelo de regresión, en función de las etiquetas "agregado" / "cambiado". 

Si el modelo de regresión aumenta mucho, mientras que el volumen de mejoras en la versión no ha cambiado significativamente en comparación con la versión anterior, entonces esta es una ocasión para pensar en la corrección de establecer prioridades en la lista de verificación de las revisiones de revisión. Tal vez el evaluador hizo una elección incorrecta de casos para recurrir y es necesario tomar medidas: por ejemplo, explique al evaluador el principio de priorización, involucre al analista en la priorización, cambie el modelo de regresión resultante eliminando casos de prueba redundantes.

¿Cómo se puede optimizar el modelo de prueba de regresión?


Comenzamos a trabajar con un modelo de prueba de regresión, optimizamos el proceso de desarrollo de casos de prueba de regresión resaltando las prioridades e incluyendo solo los casos de "Prioridad 1" en la regresión. Ante el hecho de que el modelo de prueba, después de un tiempo, se hizo grande, los costos de ejecutar sus casos aumentaron y dejamos de caer en el intervalo de tiempo aceptable para realizar una prueba de regresión en el proyecto.

Ha llegado el momento de implementar la automatización de pruebas, cuyo propósito fue:

  • reducir el tiempo para completar casos de prueba de regresión;
  • utilice las pruebas automáticas para crear condiciones previas para realizar verificaciones posteriores, optimizando así el tiempo y los costos humanos de la creación de datos de prueba;
  • mejorar la calidad de las pruebas de regresión eliminando la influencia del factor humano en los resultados de una prueba manual;
  • , .

Se desarrolló un marco para automatizar las pruebas de GUI en Java (GIT se utilizó como un sistema de versión de control de origen).

Un equipo separado de pruebas automatizadas participó en el desarrollo de las pruebas automáticas, que se enfrentaron con éxito a la tarea. Para futuros proyectos de una escala similar, en el futuro se planea aplicar los desarrollos existentes y lanzar pruebas automatizadas al comienzo del proyecto para beneficiarse de su uso lo antes posible. Puede leer más sobre la automatización de probar SIG grandes en un artículo de mis colegas que estuvieron directamente involucrados en la organización y realización de pruebas automatizadas.

Por parte de las pruebas manuales funcionales, el modelo de regresión también fue optimizado. 

Utilizando dos SIG grandes como ejemplo, el equipo y yo ideamos e implementamos sesiones de prueba o recorridos de prueba, cuya esencia era la siguiente: era necesario analizar el proceso comercial en cada subsistema y pensar en la sesión (recorrido) de los controles que pasan por este proceso comercial, simulando la mayoría Acciones de usuario realizadas con frecuencia en el proceso. 

En un proyecto SIG esto se llamaba "sesión de prueba", en otro se llamaba "recorrido de prueba". Pero la esencia siguió siendo la misma: pensamos en el escenario comercial clave de extremo a extremo (a través de toda la revisión) que cubre completamente la idea comercial de la revisión implementada (puede haber varios escenarios de este tipo). 

El escenario del recorrido de prueba se acordó con el analista, se desarrollaron casos detallados de prueba de regresión y, en los casos en que no lograron realizar la prueba de regresión en todo el modelo de prueba, podrían limitarse a realizar una "sesión de regresión" o "recorrido de prueba de regresión", que, por regla general, Tomó menos tiempo e hizo posible comprender claramente si hay problemas con los procesos comerciales clave en el sistema.

En el futuro, los recorridos de prueba fueron cubiertos por pruebas automáticas, y los evaluadores liberados de las comprobaciones de rutina cambiaron a las mejoras de prueba de las próximas versiones planificadas. 
Un ejemplo de un recorrido de prueba: "creación, edición, publicación y anulación de una entidad". 

Un recorrido de prueba puede ser complicado, por ejemplo:

  • dar derechos para crear, editar y anular,
  • crear una entidad en la "Cuenta personal" del usuario con el rol de "Especialista",
  • ,
  • ,
  • ,
  • « » «»,
  • , .

SLA?


Recomiendo no tratar el proceso de localización de incidentes de los usuarios como una tarea de bajo nivel. Debe tomar esto como parte del proceso de prueba. Además, este es un proceso mucho más creativo que, por ejemplo, verificar casos de prueba. Es necesario aplicar la lógica, la experiencia de las técnicas de diseño de pruebas, para llegar al fondo del error, detectarlo y pasarlo al desarrollo.

Por supuesto, es deseable organizar el proceso de operación SIG con tres niveles de soporte (idealmente) y, como resultado, los incidentes más obvios que a menudo solo los probadores pueden localizar fallarán en el equipo de prueba, que ya está filtrado en las dos primeras líneas.

Para cumplir con SLA, recomendamoshaga que el proceso de localización de incidentes sea un deber en el equipo de prueba con la máxima prioridad e intente introducir métodos de optimización para que la velocidad de reproducción del incidente sea lo más alta posible. 

Para optimizar el tiempo que pasan los evaluadores, puede:

  • mantener una base de conocimiento del proyecto con consultas SQL típicas o frecuentes;
  • organice el proceso de clasificar las tareas entrantes en el rastreador de errores para que en el panel indicador el probador vea inmediatamente un incidente caído y lo lleve a trabajar en la primera prioridad;
  • agregar contadores de tiempo de cuenta regresiva en JIRA para tareas que tienen SLA;
  • establecer un sistema de alerta para incidentes;
  • production ( — ), , , , , , production;
  • « » « ». . 

Sobre la "matriz de conocimiento" se escribió anteriormente. En cuanto a la "matriz de responsabilidad", esta es una tabla en la que, por analogía con la "matriz de conocimiento", se escriben bloques / módulos / subsistemas funcionales y cuál del grupo de prueba es responsable de probar lo funcional, por regla general, este es el líder del equipo o el probador principal / principal en un grupo.

¿Qué sucede si el probador de un bloque / módulo / subsistema funcional no comprende la imagen completa del proceso comercial en el proyecto?


Este es un tema delicado que hemos encontrado en varios grandes proyectos SIG. El equipo realizó una "matriz de conocimiento", los evaluadores realizaron una autoevaluación del grado de inmersión en lo funcional y se asignaron a su pieza de funcionalidad. Pero en algún momento, los evaluadores experimentados que participaron desde el inicio del proyecto abandonaron el grupo, y los nuevos especialistas aún no estaban inmersos en todos los procesos comerciales y no vieron la imagen completa. Esto condujo al hecho de que al probar casos en un módulo, los resultados de este caso deberían haberse utilizado en el siguiente módulo y, como resultado, si se proporcionaron resultados incorrectos a la entrada del segundo módulo (las condiciones previas no eran ideales para ejecutar casos desde el módulo anterior), entonces era necesario analizar la situación y registrar errores.

Pero los evaluadores no pensaron por qué esos números llegaron a su aporte y simplemente resolvieron sus casos. Formalmente, la prueba se llevó a cabo, todo está bien, no se encontraron defectos, y cuando el analista acepta lo funcional o cuando se prepara para las pruebas de aceptación, se aclaran problemas significativos en el trabajo de la lógica empresarial que se perdieron en la prueba. La razón fue la falta de comprensión del proceso comercial de extremo a extremo realizado por el sistema.

En esta situación, se realizó lo siguiente:

  • inmerso en lo funcional con la participación del analista;
  • la capacitación se realizó en el grupo de prueba, el intercambio de experiencias, las historias en las reuniones sobre su subsistema y lo que está sucediendo en él, la discusión de las nuevas mejoras que se planean para el subsistema en el próximo lanzamiento planificado;
  • atraer analistas e introducir plantillas informativas en las especificaciones de las especificaciones sobre el grado de impacto de las mejoras en los módulos / subsistemas de terceros;
  • la implementación del proceso de prueba para sesiones de prueba (recorridos), que son probadores y los coordina con analistas (ayuda a reducir los riesgos de malentendidos del proceso comercial por parte del equipo y la cantidad de errores comerciales en el sistema).

Fuh! Traté de recopilar los principales problemas y recomendaciones para su eliminación, pero esto está lejos de toda la información útil que quiero compartir.

Capítulo 4. Métricas para determinar la calidad del proyecto y la metodología para evaluar los costos laborales para las pruebas


Antes de presentar la colección de métricas en el proyecto, nos preguntamos: "¿Por qué deberíamos hacer esto?" Los objetivos principales eran monitorear la calidad del equipo de prueba, la calidad del lanzamiento producido en la producción y monitorear los indicadores de desempeño de los participantes del grupo de prueba para comprender cómo desarrollar el equipo.

Se realizó un análisis de las métricas necesarias para alcanzar los objetivos. Luego se dividieron en grupos. Luego pensaron en lo que se puede medir sin cambios adicionales en el proceso y dónde se necesitará la ayuda de otros miembros del equipo del proyecto.

Cuando se completaron todas las etapas preparatorias, comenzó el ensamblaje regular de métricas: una vez al mes / lanzamiento / sprint / trimestre, dependiendo del proyecto y las características del proceso de producción.

Una vez recopiladas las primeras métricas, fue necesario determinar los indicadores objetivo por los que queremos luchar en esta etapa del desarrollo del proyecto. Luego quedaba tomar regularmente métricas y analizar las razones de su desviación de los indicadores objetivo, tomar medidas destinadas a mejorar los indicadores, es decir, optimizar no solo el proceso de prueba, sino también todo el proceso de producción del proyecto.

Por supuesto, no solo los evaluadores participaron en la mejora de la calidad, los analistas y el gerente de desarrollo y lanzamiento también participaron en la optimización del proceso, los ingenieros de DevOps fueron todos los participantes clave en el proceso, ya que todos querían mejorar la calidad del lanzamiento y mejorar su trabajo. 

Un ejemplo de cómo se ve la colección de métricas y objetivos en uno de los proyectos completados:


Metodología para evaluar los costos laborales para las pruebas


Con el fin de informar al gerente del proyecto sobre los plazos más precisos para completar la prueba, basado en la recopilación de métricas de proyectos similares, se desarrolló una metodología para evaluar el esfuerzo de prueba, que permite el informe más preciso del tiempo de finalización de la prueba y notifica los riesgos de la prueba.

Esta técnica se utiliza en todos los proyectos de implementación de SIG, las diferencias solo pueden estar en algunos valores métricos, pero el principio de cálculo es el mismo.

Las métricas utilizadas para realizar una evaluación detallada de los costos de prueba


Las métricas de tiempo se obtienen mediante mediciones repetidas de los costos reales de los evaluadores de diferentes niveles de competencia en diferentes proyectos, se toma la media aritmética.

El tiempo para registrar un error es de 10 minutos (el tiempo para registrar 1 error en el rastreador de errores).
El tiempo para validar el error / refinamiento es de 15 minutos (el tiempo para verificar la corrección de 1 error / refinamiento).
Tiempo para escribir 1 TC (caso de prueba) : 20 minutos (tiempo para desarrollar un caso de prueba en el sistema TestLink).
Tiempo para completar 1 TC - 15 minutos (tiempo para completar verificaciones en un caso de prueba en el sistema TestLink).
Tiempo para una prueba. El tiempo total obtenido al agregar los costos en la Lista de verificación para la columna "Tiempo de entrega, min".
Tiempo de informe de prueba - 20 minutos (tiempo para escribir un informe de acuerdo con la plantilla).
Tiempo de errores . Tiempo planificado para el registro de todos los errores / aclaraciones (tiempo para el registro de 1 error / aclaración * número posible de errores / aclaraciones (10 errores para la revisión - el número estimado de errores por revisión)).
Tiempo total en DV (validación de defectos) . Tiempo planificado para la validación de todos los errores / refinamientos encontrados y corregidos (tiempo para la validación de 1 error / refinamiento * número estimado de errores / refinamientos).
Preparación de datos de prueba. El tiempo para preparar los datos de prueba se calcula subjetivamente en función de la experiencia de probar tareas similares en el proyecto actual dependiendo de diferentes parámetros (el alcance de la tarea desde el punto de vista del analista de prueba, las competencias del equipo de desarrollo de código (nuevo equipo desconocido o equipo probado para el cual hay estadísticas sobre la calidad del trabajo) , integración entre diferentes módulos, etc.).

Al medir los costos reales de uno de los proyectos, se calculó lo siguiente: 

  • no más de 1 hora por tarea hasta 60 horas de desarrollo,
  • no más de 3 horas por tarea hasta 150 horas de desarrollo,
  • no más de 4 horas por tarea hasta 300 horas de desarrollo.

En casos especiales, los costos planificados para la preparación de los datos de prueba podrían cambiar de acuerdo con el gerente de prueba.
 
Hora de escribir TC . El tiempo para escribir el TC, que se estima después de que la lista de verificación esté lista para inspección y priorización para la prueba. Para la prueba de regresión, los TC se marcaron con Prioridad 0 (el número de verificaciones de Prioridad 0 * 20 minutos (tiempo de escritura para 1 TC)).
Tiempo de retroceso según TC. Tiempo para completar una iteración de la prueba de regresión de acuerdo con TC en el sistema TestLink (número de TC * tiempo de ejecución promedio de 1 TC (15 minutos)). 
Riesgos Se establece el 15% del tiempo para la prueba (los riesgos significan todas las operaciones manuales, caídas de pie, problemas de bloqueo, etc.). 
Tiempo total para la prueba.El costo total de la prueba para un HL (preparación de los datos de la prueba + ejecución de la prueba + tiempo para registrar errores / aclaraciones + validación de errores / refinamientos + tiempo para retroceder según la prioridad TC 0 + riesgos) en h / h.
Tiempo total para la tarea. Costos totales para toda la tarea de prueba, figura en h / h (Tiempo total para prueba + tiempo para informe + tiempo para escribir TC).

Todas estas métricas se utilizan en el proyecto para resolver diversas tareas relacionadas con la planificación, evaluaciones de trabajo, tanto temporales como financieras. Como ha demostrado la práctica, dicha estimación da un error mínimo (no más del 10%), que es un indicador bastante alto de la fiabilidad de la estimación.

Por supuesto, no puede usar ninguna métrica o sus métricas según las estadísticas pueden diferir mucho, pero el principio de estimar el costo del trabajo de prueba se puede aplicar a cualquier proyecto y elegir la fórmula de cálculo más óptima para su proyecto y equipo.

Capítulo 5. Receta para un proceso de prueba de SIG exitoso


Es importante mostrar a los gerentes de pruebas y evaluadores que cuando se enfrentan con dificultades y nuevas tareas, pueden encontrar soluciones, optimizar el proceso de prueba y tratar de aplicar la experiencia acumulada a proyectos futuros. 

Preparé sorpresas para todos los lectores: una receta para un proceso de prueba SIG exitoso y plantillas de documentos que puede descargar y usar en sus proyectos.
Entonces, la receta sobre cómo hacer que el proceso de probar un gran sistema de información sea exitoso, y lo que recomendamos incluir en este proceso, trataré de decirlo breve y concisamente.

Del proceso analítico:

  • Implementar plantillas de requisitos técnicos
  • implementar las reglas para el desarrollo de requisitos técnicos en un grupo de analistas;
  • desarrollar un reglamento sobre notificación de disponibilidad de los requisitos técnicos del equipo del proyecto.

:

  • - ;
  • ;
  • ;
  • :

    ○ - ;
    ○ -;
    ○ ;
  • , , , , , ;
  • , , , , ;
  • ;
  • ;
  • ;
  • ;
  • (, , ..);
  • , , ;
  • use las recomendaciones de colegas más experimentados, desarrollos de otros proyectos, hojas de trucos listas para usar , realice sesiones de lluvia de ideas con el equipo y busque nuevos métodos para optimizar y mejorar el proceso.

Ahora me estoy preparando para probar el nuevo SIG. Así es como se ve mi Wiki de trabajo, que ya tiene en cuenta muchos puntos que recomendamos hacer:


Sorpresa para lectores pacientes.


Si lees el artículo hasta el final, mereces un regalo. Quiero compartir con ustedes plantillas útiles que pueden usar en su trabajo:


Espero que nuestras recomendaciones, ejemplos, ideas, enlaces y mis plantillas ayuden a muchos equipos a desarrollar de manera competente el proceso de prueba, optimizar sus costos y enfrentar con éxito las tareas en un proyecto responsable y complejo. 

Si desea unirse al equipo de pruebas de LANIT y participar en las pruebas de SIG, le aconsejo que vea las vacantes de nuestra empresa.

¡Ven a nuestras escuelas de evaluación!
, , .


¡Les deseo a todos proyectos interesantes y buena suerte!

PD: Realmente se ruega realizar una pequeña encuesta. 

More articles:


All Articles