Estimación y pruebas en la gestión de proyectos

Actualmente estoy escribiendo un artículo sobre la gestión de proyectos y me preguntaba si alguien con experiencia podría responder las siguientes preguntas.

  1. ¿Cuáles son los pasos involucrados en la creación de un proceso de prueba? (¿Hay un conjunto estándar de pasos, ya que después de buscar en Internet no pude encontrar ninguno?)

  2. ¿Cómo se puede refinar la estimación de costos cuando se está en la etapa de diseño de un proyecto?

Para la primera pregunta, ¿sería la siguiente una explicación válida o no se trata de un proceso de prueba?

  • Diseñar casos de prueba

  • Preparar datos de prueba

  • Ejecutar programa con datos de prueba

  • Comparar resultados con datos de prueba

No creo que sea prudente dividir el proceso de prueba en estas etapas. No puede estimar el diseño de nada en el campo del software por sí mismo: el diseño cambia a medida que lo implementa. Específicamente, mientras se escriben las pruebas y se recopilan los datos, el diseño cambiará. La recopilación de datos puede provocar la reescritura de la prueba. La única vez que se pueden dividir las etapas es si está volviendo a ejecutar pruebas existentes y no necesita agregar otras nuevas. En general, las estimaciones se dividen mejor por característica y no por etapas (por ejemplo, para diseño de código, implementación, prueba unitaria).
No cruce la publicación: programmers.stackexchange.com/questions/133438/… . ¿En qué sitio quieres hacer la pregunta? Si desea diferentes perspectivas, asegúrese de adaptar la pregunta a la audiencia de cada sitio.
Hola Gerente, bienvenido a PMSE, el sitio de preguntas y respuestas para gerentes de proyectos expertos y entusiastas. Esta pregunta en su totalidad posiblemente esté fuera de tema. Considere dividir la pregunta para que la pregunta de preguntas y respuestas/pruebas se haga en el sitio de control de calidad y la pregunta de PM se haga en el sitio de PM. Como dice ChrisF, es mejor adaptar su pregunta al tema y la audiencia del sitio para obtener mejores resultados. De nuevo, ¡bienvenido a nuestro sitio! Espero que sigas participando. :)
Para el n. ° 2, sugiero mirar el 'Cono de incertidumbre', que responde a esa pregunta

Respuestas (4)

1.) ¿Cuáles son los pasos involucrados en la creación de un proceso de prueba? (¿Hay un conjunto estándar de pasos, ya que después de buscar en Internet no pude encontrar ninguno?)

Para la primera pregunta, ¿sería la siguiente una explicación válida o no se trata de un proceso de prueba?

-Diseño de casos de prueba

-Preparar datos de prueba.

-Ejecutar programa con datos de prueba

-Comparar resultados con datos de prueba

Tengo la sensación de que en realidad está preguntando cómo implementar un proceso de prueba adecuado en una organización. En cuanto a su pregunta inicial: para crear un proceso de prueba, es necesario acordar un flujo de trabajo determinado y los requisitos con respecto a la forma en que se debe probar el producto en una empresa determinada. Ya sea un taller de software o, por ejemplo, una fábrica que crea paraguas. Aquí es medianoche, así que permítanme exagerar un poco.

Deténgase aquí por un segundo e intente investigar qué significaría realmente el control de calidad para la empresa.

Así que aquí está, gestionando el proceso de producción para el ejemplo de Umbrellas Incorporated . Tiene un conjunto de requisitos que describen cómo debe funcionar el producto final y también, posiblemente, deba acordar qué tan bueno debe ser un producto, antes de lanzarlo a los clientes finales. Por lo tanto, necesita algunos estándares. Además, le gustaría saber qué sucede durante la producción y qué sucede en el sitio. ¿Cómo debe abordar cualquier tarea su departamento de control de calidad? ¿Cuándo deben comenzar el procedimiento de prueba y cómo deben informar? Además, ¿qué sucede si un cliente final lo llama y le dice que el paraguas tiene una fuga de agua, que no funciona correctamente o que necesita arreglos ahora mismo para un cliente enojado que está parado frente a un hotel de lujo en París y exige cambios inmediatos en el paraguas, porque ¿Su producto no funciona correctamente dadas las condiciones de lluvia en el lugar? Por lo tanto, necesita un flujo de trabajo organizacional adecuado .

Además, piense en lo que sucede cuando la línea de producción no funciona correctamente. ¿Qué debe hacer el departamento de Garantía de Calidad? ¿Se les permite influir fuertemente en el proceso de producción? ¿Se les permite detener el proceso de producción? Por lo tanto, junto con el flujo de trabajo , necesitará pautas para situaciones excepcionales.

Ahora siguiendo la pregunta, ahora sabemos lo que se necesita para implementar efectivamente un proceso de prueba. La ejecución real de las pruebas es solo una parte. ¿Lo que hacemos ahora es asegurarnos de que el proceso de prueba pueda funcionar de manera efectiva para nuestra empresa Umbrella Incorporated ? Vamos a crear un documento que describa nuestros acuerdos.

  • Estándares

    • Describa las áreas del producto que se requiere verificar.
    • Describir los artefactos utilizados durante un proceso de prueba (documentos, errores en algún sistema de seguimiento, datos de prueba)
    • Acordar una posible lista de prioridades/valores de gravedad para los problemas encontrados durante las pruebas; por ejemplo: los problemas de gravedad pequeña con la interfaz de usuario (mal color del material utilizado durante la producción de un paraguas de ejemplo), los de gravedad media son algunas molestias en la forma en que funciona el producto (problemas con los resortes utilizados en el paraguas) y los de gravedad alta. problemas graves que impiden que los usuarios accedan a las funcionalidades del producto (el dosel no se puede abrir en absoluto)
    • Describir la lista de informes que se proporcionarán después de la ejecución de las pruebas.
  • flujo de trabajo

    • Acuerde un flujo de trabajo, incluya una descripción adecuada de las responsabilidades en un proyecto o cartera de proyectos. Incorporar el Proceso de Prueba al Proceso de Producción actual. Determinar los posibles puntos de intercambio de información entre el equipo de producción y Garantía de Calidad. Sea una lista de problemas o alguna herramienta informática para manejar la información del proyecto. Acordar políticas adecuadas para la introducción de nuevas funciones. Determine cuándo se escriben los casos de prueba y de quién es la responsabilidad de administrar los casos de prueba de acuerdo con los requisitos del usuario. Determine qué diferentes escenarios de prueba se están utilizando. Ya sean pruebas de regresión o pruebas de nuevas funcionalidades. De acuerdo en lo que se probó y verificó por completomedios del producto. Incluya la información sobre las pruebas utilizadas durante la vida útil del producto: determine los procesos de ejemplo que describió (Ejemplo: después de crear un nuevo requisito, prepare una lista de casos de prueba, prepare los datos de prueba y agregue dicho caso de prueba a las listas de pruebas/ escenarios de prueba que se realizarán durante el ciclo de producción, después de los lanzamientos internos y después de los lanzamientos finales listos para el cliente )
    • Determine los roles de los miembros del equipo: describa quién es responsable de iniciar el proceso de prueba, quién puede informar problemas y problemas. Quién es responsable de la creación y aceptación de escenarios de prueba.
    • Asegúrese de que toda la información esté fácilmente disponible y que el equipo entienda lo que está involucrado durante el proceso de prueba.
    • Describa las posibles situaciones, que pueden implicar una reacción inmediata del Aseguramiento de la Calidad. Debe quedar claro si el proceso de prueba puede bloquear la liberación o no.
    • Acordar el nivel de servicio necesario que se entregará. Describa cómo se seleccionan los problemas para solucionarlos. Cuándo deben introducirse las correcciones en el producto.
  • Ejecución de pruebas: como notó inicialmente en su pregunta, también debe crear una descripción detallada de los pasos necesarios en el proceso. Los puntos que enumeró son solo subtareas utilizadas en todo el proceso, pero obviamente, uno las necesita para realizar las pruebas eventualmente.

Nota: este no es un manual o una definición teórica, solo mi opinión y mi sentimiento sobre cómo se puede responder esta pregunta. Además, no estoy asociado de ninguna manera con ninguna empresa posiblemente involucrada en la producción de paraguas, y yo mismo rara vez los uso, simplemente no pude resistirme después de leer la descripción adecuada de the_reluctant_tester de lo que es un proceso de prueba ;-)


2.) ¿Cómo se puede refinar la estimación de costos cuando se está en la etapa de diseño de un proyecto?

Obtener la estimación de costos de manera adecuada está muy relacionado con el cronograma y la estimación de tareas del proyecto dado. Cuando el proyecto está en una fase de diseño, la forma más efectiva de superar cualquier complicación es describir mejor el resultado deseado. Uno puede evaluar las tareas de manera más efectiva si se le dan detalles más específicos sobre el producto que se va a crear. Una forma de lograr esto es extender la fase responsable de recopilar los requisitos y luego programar el trabajo del equipo para estimar los requisitos de nivel inferior. No siempre es posible introducir dicha solución, dado el desarrollo del software; depende de la estrategia del cliente, qué tan avanzada es la visión del producto, etc. En mi opinión, no hay una manera realmente fácil de mejorar las estimaciones.

También se pueden usar algunas técnicas de estimación para mejorar la evaluación, como usar FPE (Estimación de puntos de función) o estimación basada en WBS (Estimación basada en la estructura de desglose del trabajo). Si es posible, el equipo de desarrollo deseado también debería ayudar durante la estimación, pero tenga en cuenta que los desarrolladores tienden a subestimar o sobrestimar las tareas en las que trabajarán. En mi humilde opinión, la pericia y la experiencia son los factores clave durante el proceso de estimación.

Mirando su respuesta a la pregunta 1, creo que está confundiendo el proceso de prueba con la ejecución de la prueba.

El proceso de prueba es una actividad general más grande que generalmente sirve para los siguientes dos propósitos:

  1. Guía/explica al equipo de pruebas sobre cómo - diseñar, ejecutar, informar, defender - pruebas, resultados de pruebas, riesgos

  2. Proporciona a la gestión empresarial o de proyectos los resultados que necesitan para tomar decisiones empresariales basadas en la información de las pruebas.

Tenga en cuenta que las pruebas de software son una actividad tan compleja que implica la exploración, el aprendizaje y la improvisación continuos (de acuerdo con la dinámica del proyecto), es difícil (y más bien desaconsejable) que un proceso de prueba sea más que un montón de documentos fáciles de entender y concisos. , brindando orientación en lugar de instrucciones talladas en piedra

Intentaré responder a la pregunta n. ° 1.
Para mí, básicamente respondió su pregunta, pero agregaría (con una perspectiva de gerente de proyecto):

1/ La prueba es verificar la conformidad con los requisitos (esta es la definición de calidad en ISO 9001: conformidad con los requisitos). Como resultado, antes de ir a diseñar el caso de prueba, debe planificar el trabajo a partir de la lista de requisitos y organizar las pruebas para que coincidan con esta lista (de una forma u otra). Esto será útil para (por ejemplo) calificar la calidad del producto que prueba: % de requisitos cumplidos.

2/ Debe asegurarse de que el producto sea comprobable. Esto tiene un impacto en el diseño y desarrollo del producto.
Intentaré ilustrar con un ejemplo simple: si prueba una aplicación web con Selenium, será útil si los elementos DOM se identifican con #id específicos para que pueda afirmar (o reutilizar) valores.
Lección: el diseño de prueba puede tener impacto en el diseño/desarrollo y debe abordarse al principio del proyecto (al menos en su estrategia de prueba).
(un paso más allá: podría considerar que sus scripts de prueba deben estar disponibles antes del desarrollo, para que se usen como la "especificación viva". Esto se remonta a TDD).

Una precisión en la estimación de costes: una estimación de costes es muy difícil de acertar con exactitud. Puede consultar los informes de proyectos similares ya completados con las mismas tareas más o menos, para ver sus propias estimaciones. Eso puede darle una buena idea de hacia dónde se dirige. Cuando termines tus estimaciones, agrega una cuenta que no se vincule con ninguna tarea: una cantidad para los eventos inesperados o no planificados. Puedo ser el 5% (por ejemplo) del presupuesto total de tu proyecto. Por lo tanto, si surge un problema, tendrá una manera de adaptarse a él sin que su proyecto de agujero pase por encima del presupuesto.