¿Existe algún método de estimación para estimar las pruebas del usuario final?

¿Existe alguna técnica de estimación que pueda ayudarnos a estimar el número de casos de prueba necesarios en los proyectos de software tradicionales? Por ejemplo, tenemos una especificación de requisitos de software (SRS) con 200 casos de uso; ¿Puedo decir "necesitamos 200 * 10 = 2000 casos de prueba", como una estimación aproximada?

Necesitamos esta estimación para escribir un plan de prueba para el director del proyecto. A veces no comprendemos completamente la aplicación del SRS debido a que dedicamos muy poco tiempo a realizar la planificación de las pruebas.

¿Qué quiere decir con "pruebas de usuario final"? En mi experiencia, esto se refiere a la validación. El usuario final tiene un conjunto de necesidades o expectativas que se han expresado a un equipo de desarrollo y las "pruebas de usuario final" o la validación están totalmente dirigidas por el usuario final para confirmar que lo realmente construido satisfará sus necesidades. ¿Cuánto tiempo necesitan para ejecutar sus pruebas para tener la confianza de que el sistema entregado satisfará sus necesidades?
me refiero a "pruebas de usuario final", que el software está siendo probado por el equipo de prueba para ser confirmado y listo para publicar en la PC del usuario
Eso no es consistente con ninguna definición de "prueba de usuario final" que haya escuchado, especialmente porque su equipo de prueba no es el usuario final del sistema. Lo que estás describiendo es una forma de verificación.

Respuestas (1)

TL;DR

No existe una fórmula única para determinar cuántas pruebas requerirá un conjunto de especificaciones. Sin embargo, puede estimar el nivel de esfuerzo y establecer objetivos de calidad en función de sus planes de prueba, siempre que las personas que realizan las estimaciones sean las que realizarán el trabajo real.

La pirámide de prueba y sus efectos en el "triángulo de hierro"

No existe una fórmula universal para la cantidad de pruebas que necesita para cada especificación. Eso variará según el producto, los marcos que esté utilizando, la complejidad de las especificaciones y la importancia de cada unidad de funcionalidad. Sin embargo, puede obtener estimaciones razonables solicitando a los ejecutores reales de la tarea (por ejemplo, los desarrolladores y evaluadores que realizarán el trabajo) que calculen la cantidad de pruebas que anticipan para cada bloque de trabajo en el plan del proyecto.

En general, debe esperar que un taller ágil tenga muchas pruebas unitarias y muy pocas pruebas manuales. Por ejemplo:

Pruebas tradicionales versus ágiles

Controles deslizantes y compensaciones

Hay muchas variaciones de la pirámide de prueba , y los detalles de lo que pertenece a cada capa pueden variar según su producto, industria y proceso. Sin embargo, los desarrolladores y evaluadores experimentados que están invitados a colaborar con usted en la planificación y la estimación del proyecto a menudo pueden proporcionar estimaciones razonablemente precisas sobre el nivel de esfuerzo involucrado para cada fase o componente de la prueba, y ayudarlo a hacer el intercambio necesario. desviaciones entre:

  1. porcentaje de cobertura de prueba
  2. velocidad de desarrollo de la prueba
  3. velocidad de ejecución de la prueba
  4. velocidad de desarrollo
  5. prueba de velocidad de regresión
  6. velocidad de reproducción/aislamiento de defectos

Estos factores, que a menudo son controles deslizantes complementarios u opuestos, afectarán los costos, el cronograma y la calidad de su proyecto. También tendrá un gran impacto en su deuda técnica y en las tasas de defectos, según lo que acuerden el equipo y la organización.

Incorporar métricas de prueba en la definición de hecho

Su definición de hecho siempre debe incluir objetivos acordados para la cobertura de la prueba. Es probable que el resto de los detalles de las pruebas sean más una negociación y un conjunto de pautas que un porcentaje fijo.

Ver también