1. Validacion: ¿se esta contruyendo un producto correcto?
2. Verificacion: ¿Estamos construyendo correctamente?
3. Probar: mostrar error
4. depurar: encontrar error y modificar
5. Técnicas de prueba
5.1. intuicion y experiencia
5.1.1. pruebas ad hoc
5.1.2. pruebas por exploracion
5.2. especificacion
5.2.1. particion de equivalencia
5.2.2. analisis de valores limite
5.2.3. pruebas de robustez
5.2.4. tablas de decision
5.2.5. maquinas de estado finito
5.2.6. especificaciones formales
5.2.7. aleatorias
5.3. codigo
5.3.1. cobertura basadas en flujo de control
5.3.2. cobertura basadas en flujo de datos
5.4. errores
5.4.1. conjetura de errores
5.4.2. mutacion
5.5. estadisticas
5.5.1. sala limpia
5.6. basadas en uso
5.6.1. perfil operativo
5.6.2. fiabilidad del software
6. pruebas segun el objetivo que persiguen
6.1. pruebas de aceptacion
6.1.1. Se dice que un software es aceptable cuando hace aquello que debe hacer y solamente eso.
6.2. pruebas de instalacion
6.2.1. se debe verificar que todos los productos han quedado instalados satisfactoriamente en el entorno final en el que serán utilizados.
6.3. pruebas de alfa y beta
6.3.1. pruebas alfa, realizadas por personas de la organización que desarrolla el software, y pruebas beta, en la que participa un número limitado de usuarios externos.
6.4. pruebas de conformidad
6.4.1. si el comportamiento del software es conforme con ciertas especificaciones a las que debería ajustarse según lo establecido en los requisitos (normas o estándares).
6.5. pruebas de regresion
6.5.1. comprobar que un componente que ya había sido probado no se ha visto afectado por modificaciones en otros componentes
6.6. pruebas de rendimiento
6.6.1. alcanzan los objetivos de rendimiento especificados por el cliente y expresados en el documento de requisitos.
6.7. pruebas de desgaste
6.7.1. sistema más allá de sus límites normales de operación con el objeto de comprobar que no sólo es capaz de soportar los límites de carga marcados sino que también puede funcionar correctamente por encima de los mismos
6.8. pruebas de recuperacion
6.8.1. cuando el sistema sufre algún “desastre”, es necesario poner en marcha mecanismos de recuperación. Las pruebas de recuperación verifican que dichos mecanismos funcionan correctamente.
6.9. pruebas de configuracion (despliegue)
6.9.1. probar que el funcionamiento es igualmente correcto en todas las posibles configuraciones.
6.10. pruebas de usabilidad
6.10.1. a la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el usuario,
6.10.1.1. tiempo de aprendizaje, velocidad de realización de las tareas, porcentaje de errores de los usuarios, retención con el paso del tiempo, satisfacción subjetiva
7. otras pruebas
7.1. continuidad
7.1.1. pruebas a varias versiones del mismo sistema
7.2. compatibilidad
7.2.1. sistema en desarrollo debe comunicarse con otros sistemas
7.3. de humo
7.3.1. . La intención es descubrir errores “paralizantes” que tengan la mayor probabilidad de retrasar el proyecto.
7.4. alfa beta
7.4.1. alfa se lleva a cabo en el sitio del desarrollador por un grupo representativo de usuarios finales. beta se realiza en uno o más sitios del usuario final.
8. Pruebas de Software
8.1. unidades: metodo y clases
8.2. integracion: clases relacionadas
8.3. sistema: sistema como un todo
8.4. validacion o aceptacion: prueba entorno real
9. Pruebas Caja Negra: comportamiento de entrada y salida de datos
9.1. no importa el codigo
9.2. validar requerimientos
9.3. riesgo de dejar codigo sin probar
10. Pruebas caja Blanca: como esta diseñado o programado el software
10.1. necesario conocer el codigo
10.2. no permiten validar requerimientos
10.3. sin redundancia
11. Pruebas caja gris: prueba caja negra pero se necesita conocer el codigo, para probar mejor desde el exterior
12. pruebas segun su objeto (aquello que esta probando)
12.1. pruebas de unidad o unitaria
12.1.1. modulo concreto, verificar el funcionamiento aislado del modulo
12.2. pruebas de integracion
12.2.1. verifica si el modulo trabaja bien cuando trabaja con otros modulos
12.2.1.1. integracion ascendente: integran componentes infraestructura y añaden componentes funcionales progresivamente
12.2.1.2. integracion descendente: desarrolla esqueleto del sistema al que se le va añadiendo componentes progresivamente
12.2.1.3. integracion switch; capa central-->lo que se desea probar, capas exteriores --> superior e inferior
12.3. pruebas del sistema
12.3.1. caja negra, puesto que prueban la funcionalidad del sistema completo (¿hace lo que el cliente desea?)
12.3.1.1. puntos a comprobar; seguridad, velocidad, exactitud, y fiabilidad
12.3.1.2. interconexiones externas con otras apps, utilidades, hadware o S.O.
12.4. pruebas funcionalidad y operativa
12.4.1. pruebas de caja negra sobre funcionalidades del sistema integrado.
12.5. pruebas de rendimiento
12.5.1. se comprueba la complecion de los requerimientos no funcionales, midiendo rendimiento vs valor esperado
12.5.1.1. pruebas desgaste
12.5.1.1.1. evaluan sistema cuando alcanza sus limites de conexiones o usuarios
12.5.1.2. pruebas de volumen
12.5.1.2.1. como se comporta el sistema ante altos volumenes de datos
12.5.1.3. pruebas de configuracion
12.5.1.3.1. comportamiento ante diferentes plataformas, compatibilidad, calidad, recuperacion
12.5.1.4. pruebas de aceptacion
12.5.1.4.1. pruebas en conjunto con el usuario
12.5.1.5. pruebas punto de referencia
12.5.1.5.1. usuario establece puntos de referencia de rendimiento de ciertas funcionalidades
12.5.1.6. pruebas instalacion
12.5.1.6.1. asegurar que todos los componentes necesarios se instalaron bien