3. Deben realizarse pruebas de todos los artefactos generados durante la construcción de un producto software, lo que incluye las especificaciones de requisitos, casos de uso, diagramas de diversos tipos y, por supuesto, el código fuente y el resto de elementos que forman parte de la aplicación

5. Calidad

10. El empleado marca los productos que le interesan y al terminar oprime el botón “Cotizar”;

11. El sistema le muestra la lista de productos seleccionados y los precios de cada uno, así como la disponibilidad; también deja un espacio a la derecha de cada producto para anotar la cantidad deseada;

13. El empleado marca “Tarjeta” y escribe el número y la compañía y oprime “Termina”;

14. el sistema verifica los datos con el banco y, si está de acuerdo, envía mensaje y un muestra un botón “Imprimir factura”;

16. Diseño de casos de pruebas El diseño de casos de prueba se puede realizar basándose en los enfoques y en sus técnicas y las estrategias de prueba. Objetivo: Conseguir confianza aceptable en que se encontraran todos defectos existentes, sin consumir una cantidad excesiva de recursos.

18. Diseño de casos de pruebas III PRUEBAS DE CAJA BLANCA Consiste en realizar pruebas para verificar que líneas específicas del código funcionan tal como esta definido. También usa la estructura de control del diseño procedimental para obtener los casos de prueba .

19. Diseño de casos de pruebas III PRUEBAS DE CAJA NEGRA La prueba verifica que el ítem que se esta probando, cuando se dan las entradas apropiadas produce los resultados esperados. Los datos de prueba se escogerán atendiendo a las especificaciones al problema, sin importar los detalles internos del programa, al fin de verificar que el programa corra bien.

21. Una buena prueba no debe ser redundante.Uno de los objetivos de las pruebas es «encontrar el mayor número de errores con la menor cantidad de tiempo y esfuerzo posibles».

22. Una buena prueba debería ser la mejor de la cosecha. La limitación en tiempo y recursos puede impedir que se ejecuten todos los casos de prueba.

24. Caso de prueba dueño/creador es el nombre del analista o diseñador de pruebas, quien ha desarrollado pruebas o es responsable de su desarrollo.

25. Versiónla actual definición del caso de prueba.

26. Nombre el caso de prueba debe ser un título entendible por personas, para la fácil comprensión del propósito del caso de prueba y su campo de aplicación.

27. Identificador de requerimientos el cuál está incluido por el caso de prueba. También aquí puede ser identificador de casos de uso o especificación funcional.

28. Propósito contiene una breve descripción del propósito de la prueba, y la funcionalidad que chequea.

30. Inicialización describe acciones, que deben ser ejecutadas antes de que los casos de prueba se hayan inicializado. Por ejemplo, debemos abrir algún archivo.

31. Finalización describe acciones, que deben ser ejecutadas después de realizado el caso de prueba. Por ejemplo si el caso de prueba estropea la base de datos, el analista debe restaurarla antes de que otro caso de prueba sea ejecutado.

32. Acciones pasos a realizar para completar la prueba.

34. Resultados reales contienen una breve descripción de lo que el analista encuentra después de que los pasos de prueba se hayan completado. Esto se sustituye a menudo con un Correcto/Fallido. Si un caso de prueba falla, frecuentemente la referencia al defecto implicado se debe enumerar en esta columna.