¿Cómo definir un criterio de salida de prueba?

El problema de trabajar a precio fijo para este tipo de trabajo es establecer dónde se detendrá el contratista: no se puede escribir "hasta que todas las pruebas hayan pasado" ya que la calidad del sistema está fuera de su responsabilidad.

Una declaración de trabajo generalmente contiene el enfoque en el trabajo a realizar, en este caso deberá especificar

* Test Planning
* Test Development
* Test Execution
* Follow-Up

y cosas más generales como la planificación, la entrega, el lugar para estar, los recursos por nombre, el calendario de pagos, etc.

Planificación de pruebas. ¿Puede el contratista partir de una lista de requisitos funcionales y no funcionales? ¿O tendrá que crear un conjunto de requisitos de prueba? 'Qué probar' debe ser lo más claro posible, por ejemplo, corrección funcional, seguridad, facilidad de uso, rendimiento, portabilidad, documentación... También es importante aquí la Cobertura del diseño de prueba : puede parecer trivial que esto es 100%, pero tal vez el núcleo los procesos/características de su sistema necesitan más atención (lea el número de pruebas escritas contra ellos) que las simples funciones de administración para, no sé, crear parámetros o algo así. Si es de menor importancia, podría indicar que estas funciones están fuera del alcance de esta tarea de prueba.

Desarrollo de pruebas. ¿Cómo se documentará el escenario de prueba? ¿Tiene una herramienta disponible o estará en una hoja de cálculo o en un programa de procesamiento de texto? Si ya tiene una plantilla disponible (o el contratista), agréguela a la SOW. Si el contratista necesita crear uno, se debe describir un proceso de revisión y aceptación. Lo mismo vale para todas las pruebas: quién las revisará y cómo serán aceptadas. Decida el nivel de detalle: ¿las pruebas serán de alto nivel, de modo que una persona con conocimientos deba ejecutarlas, o requerirá procedimientos de prueba detallados, de modo que cualquier persona sin conocimientos previos pueda realizar estas pruebas?

Si se requieren pruebas automatizadas, también aquí se deben describir y acordar los detalles de la técnica y el proceso de revisión de los guiones de prueba.

Finalmente, para la recopilación de datos de prueba, su gente deberá proporcionarlos de alguna forma, para que el contratista pueda crear casos de prueba específicos: quién estará disponible a su lado: analistas de negocios, funcionales ...

Ejecución de pruebas. ¿Cuántas pruebas se deben realizar? Una ejecución es hacer cada prueba una vez, independientemente del resultado. ¿Qué sucede cuando hay errores de bloqueo que impiden realizar las pruebas? Qué puede esperar el contratista en cuanto a la resolución para que pueda continuar con la ejecución de la prueba (no debe quedarse de brazos cruzados). Cómo se informarán los errores (una herramienta, un registro de errores en una hoja de cálculo, ...), qué información debe proporcionarse en un ticket de error y cómo se comunicará con el personal técnico. Si está haciendo scrum, las pruebas generalmente se desarrollan y (re) ejecutan como parte del sprint. En ese caso habrá que determinar el número de sprints.

Seguimiento. Informes como cobertura de ejecución de pruebas, producto aprobado, etc. Tal vez también informes de estado de errores, # errores por área de aplicación, ... Asistencia a reuniones de estado semanales o stand-up diarios.

Finalmente algunas otras cosas:

Planificación. Enumere los hitos relevantes del proyecto y cómo este contratista debe alinear su trabajo con él. O agregue los hitos específicos para el aseguramiento de la calidad.

Entrega _ Transferencia de conocimiento entre consultor y cliente, para que pueda continuar cuando el contratista se haya ido.

Personas. Quién es el(los) recurso(s) del contratista que hará el trabajo. A veces, los consultores de pruebas especializados envían un perfil senior para la planificación y el desarrollo de pruebas, pero perfiles junior (= a menudo más baratos) para la ejecución de pruebas.

Espero que esto haya sido útil

Escríbalo exactamente como comenzó a deletrear la pregunta con más detalle en su segundo párrafo. Asegúrese de incluir las iteraciones que toma la prueba desde que se informa un error por primera vez, hasta que alguien lo corrige, se vuelve a probar, etc., así como especificar cómo se deben informar los errores y qué información debe contener el informe de error.

Muy buenos comentarios de los demás.

2 puntos para agregar:

1) Hay que estar atento cuando la misma persona está planificando y ejecutando la prueba. Si se trata de tiempo y materiales, es posible que planifiquen demasiadas pruebas. Costo fijo muy bajo.

2) los evaluadores no pueden controlar la calidad del código, por lo que es posible que necesite un cargo por ciclo o por caja. De lo contrario, puede llegar a la cantidad de pruebas acordadas, pero aún tiene más trabajo por hacer.

2.5) A mediano plazo, debe considerar poseer la definición de la prueba, si no la ejecución. Esto puede no ser factible a corto plazo.