Get best of the week

Evaluación de prueba: cómo calcular el tiempo exacto para probar el sistema o "¿Cuándo estarán listas las pruebas?"

imagen

¡Buen día a todos! Mi nombre es Denis, soy el jefe del servicio de pruebas en BARS Group. Esta es mi primera publicación en Habré.

Después de leer muchos artículos interesantes y obtener mucha información útil de allí, quería dar algo a cambio. Luego comencé a analizar los temas: algunos ya estaban expresados, otros eran demasiado simples ("¿cómo ingresar a TI?"). PD: no quería herir los sentimientos de nadie :)

Cómo calcular el tiempo para las pruebas: problema y solución


Como jefe del servicio, constantemente me encuentro con una pregunta de los gerentes: "¿Cuándo estará lista?" o "¿Cuánto tiempo lleva la prueba?" Parecería que esto es complicado, tome una evaluación del proyecto anterior y más o menos lo mismo ... pero no. Me di cuenta de que la tarea no es trivial y requiere un estudio detallado. Y quiero compartir su decisión.

Nuestra empresa tiene muchos centros de negocios y cada uno tiene su propio enfoque de desarrollo, principalmente Kanban y Scrum. Por lo tanto, se han seleccionado equipos de evaluadores automáticos, que están sincronizados con el equipo de desarrollo con su metodología.

Debido a los diferentes enfoques para la gestión del desarrollo, surgen dificultades en la uniformidad de la formación y planificación de tareas. El uso de Kanban y Scrum en su forma pura no dio una respuesta de cuánto tiempo tomaría la prueba. En las decisiones de diseño, cada vez es necesario evaluar la nueva funcionalidad y cubrirla con pruebas. Me tomó mucho tiempo calcular. Por lo tanto, decidí tomar los métodos para estimar los costos de tiempo para el desarrollo de software (para probar la automatización) como base y modificarlos para adaptarlos a mis realidades. El principio de la evaluación promedio ponderada y el cálculo basado en la tipificación formaron la base. Las estimaciones serán indicadores temporales para la automatización de elementos típicos del sistema, y ​​el nivel de capacitación de especialistas se utilizará como pesos. Al formar los valores de los pesos, elegí la precisión de la evaluación al realizar la tarea, es decir, cuanto más experimentado sea el especialista,cuanto menor es el error de estimación. Se obtuvieron los siguientes valores:

  • "Senior" - 95% de precisión, factor 1.05
  • "Medio +" - 80% de precisión, factor 1.2
  • "Medio" - 70% de precisión, coeficiente 1.3
  • "Junior +" - 60% de precisión, coeficiente 1.4
  • Junior - 50% de precisión, factor 1.5

A continuación, tendremos que multiplicar el tiempo estimado t n por el coeficiente correspondiente W n . Nuestro método de cálculo se realiza de acuerdo con la fórmula, donde la suma de los pesos no es igual a 1 (100%).

imagen

W avg = (w 1 * t 1 + w 2 * t 2 ... + w n * t n ) / (w 1 + w 2 + ... + w n )

Para el cálculo, tomé dos pruebas: pruebas funcionales y de IU, porque suman alrededor del 85%.

Para obtener el resultado final, necesitamos recopilar un puntaje promedio ponderado para cada elemento en un objeto más grande para los cálculos: una categoría.

Prueba de IU


Al probar la interfaz de usuario, debe emular el trabajo del usuario a través del marco Selenium.Webdriver. Cuando se usa este enfoque, hay elementos difíciles de construir en formularios: pestañas, documentos con edición en línea, grandes cuadrículas con líneas, una estructura de árbol, etc. Además de estos elementos, también hay factores que afectan el tiempo de desarrollo de la prueba:

  • Estructura de formas (constructor típico o personalizado)
  • Solicitudes AJAX (su número)

En base a esto, 3 categorías de formularios de UI se distinguieron por su dificultad en la implementación de pruebas:

1 categoría



2 categoría



3 categoría



Como resultado, recibí los siguientes resultados, que se presentan en la tabla:



Prueba funcional


Para las pruebas funcionales, la situación es similar a la de la IU: se destacan las categorías para la sistematización de casos. Además de los servicios REST, vale la pena mencionar sobre SOAP, será similar a las 3 categorías de REST.

La prueba de integración implica probar varios métodos en un servicio, para una evaluación aproximada tomamos la presencia de 5 métodos por 1 servicio.

1 categoría



2 categoría



3 categoría



Similar a la tabla de la interfaz de usuario: las



pruebas de integración verifican el funcionamiento de los servicios creados tanto en REST como en SOAP. Al diseñar un servicio, la cantidad de métodos utilizados en el interior puede variar. Para los cálculos, tomamos un promedio de 5 métodos.



Con este cálculo del tiempo dedicado al proyecto, el porcentaje de entrar en esta estimación fue de 81.

En lugar de una conclusión


Tomó una semana de arduo trabajo contar la primera vez. Por lo tanto, hice la evaluación después de las pruebas y luego comparé los resultados con los costos en tiempo real.

Es suficiente hacer el trabajo principal una vez y luego considerarlo de acuerdo con la "fórmula" preparada. Pero debe tener en cuenta el hecho de que el nivel de empleados está creciendo, por lo que debe comprender el peso de cada empleado para saber si debe volver a calcular los indicadores.
Todo lo anterior es mi experiencia y no pretende ser cierto.

More articles:


All Articles