1 Proceso de Pruebas El proceso de pruebas consiste en las siguientes actividades: 1.Planeación y Control de pruebas 2.Análisis y Diseño de pruebas 3.Implementación y Ejecución de Pruebas 4.Evaluación de criterios de salida y reportes 5.Actividades de Cierre de Pruebas
2 Planeación y Control de Pruebas a.Planeación: Actividad de definir los objetivos de las pruebas y la especificación de las actividades de pruebas en busca de cumplir con los objetivos propuestos b.Control: es el proceso de comparación de los progresos contra la planeación, reportando los estados, incluyendo las desviaciones contra el plan. Las actividades de prueba deben ser monitoreadas a través del proyecto
3 Análisis y Diseño de pruebas Actividad durante la cual los objetivos generales de las pruebas son transformadas en condiciones de pruebas tangibles y casos de pruebas En esta etapa se destacan las siguientes actividades: a.Revisión de las bases de prueba: requerimientos, niveles de integridad, riesgos, arquitectura, diseño, especificaciones, etc. b.Evaluación de la posibilidad de pruebas de los elementos base y los objetos de prueba c.Identificación y priorización de las condiciones de prueba basada en el análisis de los ítems de prueba, la especificación, el comportamiento y la estructura del software d.Diseño y priorización de los casos de prueba de alto nivel e.Identificación de los datos de prueba necesarios para soportar las condiciones de prueba y los casos de prueba f.Diseño de la configuración de los ambientes de prueba e identificación de cualquier requerimiento de infraestructura y herramientas g.Creación de la trazabilidad bidireccional entre las bases de prueba y los casos de prueba
4 Implementación y Ejecución de Pruebas Actividad donde los procedimientos de prueba y los script son especificados a través de la combinación de los casos de prueba en un orden particular, e incluyendo cualquier otra información necesaria para la ejecución de las pruebas. Se configura el ambiente y se ejecutan las pruebas. Esta fase la componen las siguientes actividades: a.Terminación, implementación y priorización de los casos de prueba (incluyendo los datos de prueba) b.Desarrollo y priorización de los procedimientos de prueba, creación de los datos de prueba, preparación de los elementos de prueba y escritura de los script de pruebas automatizados c.Creación de las suites de prueba desde los procedimientos de prueba para una ejecución eficiente d.Verificar que los ambientes de prueba se hayan configurado correctamente e.Verificar y actualizar la trazabilidad entre las bases de prueba y los casos de prueba f.Ejecutar los procedimientos de prueba tanto de forma manual como automatizada, acorde a la secuencia planeada g.Registrar las salidas de la ejecución de las pruebas, además de las entidades, las versiones de software en prueba y las herramientas usadas h.Comparar los resultados actuales con los resultados esperados i.Reportar las discrepancias y analizarlas para establecer sus causas (un defecto en el código, un dato de prueba especificado, un documento de prueba, un error en la forma de hacer las pruebas, etc.) j.Repetir las actividades de pruebas que generaron discrepancia ( ejecutar las pruebas que fallaron para confirmar los errores, ejecutar las pruebas corregidas y/o pruebas con el fin de verificar si si no se han introducido errores en aéreas de software que no han cambiado o que los defectos cubren otros defectos)
5 Evaluación de Criterios de Salida y Reportes La ejecución es evaluada contra los objetivos definidos, actividad realizada en cada nivel de prueba. Esta fase tiene las siguientes tareas: a.Revisar los registros de pruebas contra los criterios de salida especificados en el plan de pruebas b.Evaluar si son necesarias mas pruebas o si los criterios de salida específicos han cambiado c.Escribir el reporte de pruebas para los interesados
6 Cierre de las Actividades de Prueba Se recolectan los datos de las actividades de prueba completas con el fin de consolidar experiencias, bancos de pruebas,, hechos y números. Este proceso ocurre como cualquier hito del proyecto. Sus tareas principales son: a.Revisar cuales de los entregables del plan han sido entregados b.Cerrar el reporte de incidentes y generar los cambios para cualquier novedad abierta c.Documentar la aceptación del sistema d.Finalizar y archivar los bancos de pruebas, los ambientes de prueba y la infraestructura de pruebas, para su uso posterior e.Mantener los bancos de prueba en la organización f. Analizar las lecciones aprendidas para determinar los cambios a realizar en procesos futuros g.Usar la información generada para mejorar la madurez de las pruebas
7 Modelos de Desarrollo de Software Las pruebas no existen aisladas, las actividades de pruebas se relacionan con las actividades de desarrollo de software. Diferentes modelos de ciclo de vida de desarrollo de software necesitan diferentes características de pruebas.
8 Modelos de Desarrollo Secuencial (Modelo V) Para las diferentes variantes de este modelo, regularmente se usan 4 niveles de pruebas correspondientes a 4 niveles de desarrollo: a. Pruebas de Componentes (Unidad) b.Pruebas de Integración c.Pruebas de Sistema d.Pruebas de Aceptación Este modelo puede tener mas o menos fases dependiendo del proyecto y del producto de software, por lo que pueden haber: 1.Pruebas de integración de componentes, después de las pruebas de Unidad 2.Pruebas de integración de Sistema, después de las pruebas de sistema Productos: casos de uso, especificaciones, diseño, etc. Referentes: CMMI, IEEE/IEC 12207
9 Modelos de Desarrollo Incremental – Iterativo Fases: Requerimientos, diseño, desarrollo y pruebas en ciclos cortos. Ejemplos: Prototipos, RAD, RUP y modelos de desarrollo ágil. Puede ser probado por diferentes niveles de prueba durante cada fase. Un incremento adicionado a otros desarrollos, forma un sistema parcial en crecimiento, el cual también debe ser probado. Pruebas de Regresión: en todas las iteraciones, después de la primera. Verificación y Validación: en cada incremento
10 Pruebas en un Modelo de Ciclo de Vida Se identifican una gran cantidad de posibles buenas pruebas: a.Para cada actividad de desarrollo hay una actividad de prueba correspondiente b.Cada nivel de prueba tiene objetivos de prueba específicos c.El análisis y diseño delas pruebas para un nivel dado podría iniciar durante la correspondiente actividad de desarrollo d.Los testers podrían involucrarse en la revisión de documentos tan pronto como un borrador este disponible en el ciclo de vida de desarrollo de software Los niveles de prueba pueden ser cambiados o reorganizados según la naturaleza del proyecto o la arquitectura del sistema.
11 Niveles de Pruebas Niveles de Pruebas en un Modelo V
12 Niveles de Pruebas PRUEBAS DE COMPONENTES : Bases de las Pruebas: a.Requerimientos b.Diseño Detallado c.Código Objetos típicos de pruebas a.Componentes b.Programas c.Conversión de datos / migración de programas d.Módulos de Bases de Datos
13 Pruebas de Componentes : También llamadas Pruebas de Unidad (módulo o programa), buscan defectos en y verifican la funcionalidad de módulos de software, programas, clases, objetos, etc. Que se prueban por separado. Estas pruebas se pueden realizar de forma aislado con relación al resto del sistema, dependiendo del contexto del ciclo de vida de desarrollo y del sistema. Stubs, drivers y simuladores se pueden usar. Pueden incluir pruebas de funcionalidad y características de No-funcionalidad especificas, tales como: a.Recurso – comportamiento: identificar pérdida de memoria o pruebas de robustez b.Pruebas de Estructura: cubrimiento de decisiones. Los casos de prueba son derivados de los productos de trabajo, tales como la especificación de componentes, el diseño de software o el modelo de datos
14 Pruebas de Componentes: Se ejecutan accediendo al código y al ambiente de desarrollo, tales como: a.Framework de pruebas de unidad b.Herramientas de Debuggin La prueba de Unidad involucra al programador que escribe el código. Los defectos son arreglados tan pronto se encuentran, sin realizar el proceso de gestión de defectos. Se deben preparar y automatizar los casos de prueba antes de codificar. Este proceso es llamado Enfoque de Primera Prueba o Test- Driven Development. Este enfoque es iterativo y basado en el ciclo de desarrollo de casos de prueba, luego se realiza la construcción e integración de pequeñas piezas de código, y la posterior ejecución de los componentes de prueba, corrigiendo cualquier error, hasta que la prueba pase.
15 Niveles de Pruebas Pruebas de Integración : Bases de las Pruebas: a.Diseño de Sistema b.Arquitectura c.Flujos de Trabajo d.Casos de Uso Objetos típicos de pruebas a.Subsistemas b.Implementación de la Base de Datos c.Infraestructura d.Interfaces e.Configuración de Sistema y Configuración de Datos
16 Pruebas de Integración: Este tipo de pruebas se enfoca en probar: a.interfaces entre componentes, b.interacciones con diferentes partes de un sistema, tales como sistema operativo, sistema de archivos y hardware, c.Interfaces entre sistemas Puede haber mas de un nivel de integración y puede llevarse a cabo sobre diferentes objetos de prueba dependiendo su tamaño: a.Las pruebas de interacción de componentes prueba la interacción entre los componentes de software y es hecha después de las pruebas de componentes b.Pruebas de integración de sistema prueba la interacción entre los diferentes sistemas o entre el hardware y el software, y pueden ser hechas después de las pruebas de sistema. En este caso, la empresa desarrolladora puede controlar solo un lado de la interfaz, lo cual podría generar un riesgo a los procesos de negocio, dado que pueden involucrar una seria de flujos de trabajo entre los sistemas.
17 Pruebas de Integración: Una de las mayores dificultades en el alcance de la integración es aislar los defectos de los componentes específicos, lo cual puede incrementar el riesgo y adicionar tiempo al proceso. Las estrategias de integración sistemática se pueden basar en: a.Arquitectura del sistema (top-down y Bottom up) b.Tareas funcionales c.Secuencias de procesamiento de transacciones d.Algún otro aspectos del sistema o de los componentes Para facilitar el aislamiento de los fallos y detectarlos rápidamente debería ser incremental mas que “big bang”. Las pruebas de características especificas No Funcionales (desempeño, por ejemplo), pueden incluir pruebas funcionales y de integración
18 Pruebas de Integración: Para cada estado de la integración, los tester se deben centrar únicamente en la integración. Por ejemplo: Si están integrando el módulo A con el B,, se deben enfocar en probar la comunicación entre los módulos, NO las funcionalidades de los módulos independientes. De igual forma, los testers deben comprender la arquitectura y los planes de integración, si las pruebas de integración son planeadas antes que los componentes y los sistemas sean cargados, estos componentes pueden ser cargados en el orden requerido para efectuar una prueba eficiente.
19 Niveles de Pruebas Pruebas de Sistema : Bases de las Pruebas: a.Especificación de requerimientos de software y sistema b.Caos de Uso c.Especificación Funcional d.Reporte de Análisis de Riesgos Objetos típicos de pruebas a.Manuales de operación, de usuario y de sistema b.Datos de configuración y configuración de sistema
20 Pruebas de Sistema: Se ocupan del comportamiento de todo el producto / sistema. El alcance de las pruebas puede direccionarse en el plan de pruebas del Nivel de Plan Maestro. En este tipo de pruebas, el ambiente de pruebas corresponde al ambiente de producción, tanto como sea posible, en pro de minimizar los riesgos de fallas del ambiente de producción. Pueden incluir pruebas basadas en 1.los riesgos y/o especificación de requerimientos, 2.procesos de negocio, 3.casos de uso u otro documento de alto nivel 4.modelo de comportamiento de sistema, 5.interacción con sistemas operativos y recursos de sistemas
21 Pruebas de Sistema: Permiten explorar requerimientos funcionales y no funcionales del sistema, y las características de calidad de los datos. Los tester se enfrentan con requerimientos no documentados o incompletos Las pruebas de sistema de requerimientos funcionales se inician con pruebas de caja negra para los aspectos del sistema, por ejemplo, crear una tabla para combinar los efectos descritos en las reglas del negocio. Las pruebas de caja blanca se usan para evaluar la rigurosidad de las pruebas con respecto a los elementos estructurales, tales como las estructuras de menú o la navegación en las páginas web. Se recomienda un equipo independiente.
22 Niveles de Pruebas Pruebas de Regresión: RT is another level of testing that is performed throughout the life cycle of a system. Regression testing is performed whenever a component of the system is modified. The key idea in regression testing is to ascertain that the modification has not introduced any new faults in the portion that was not subject to modification. To be precise, regression testing is not a distinct level of testing. Rather, it is considered as a subphase of unit, integration, and system-level testing
23 Niveles de Pruebas Pruebas de Aceptación: Bases de las Pruebas: a.Requerimientos de Usuario b.Requerimientos del Sistema c.Casos de Uso d.Procesos de Negocio e.Reporte de Análisis de Riesgo Objetos típicos de pruebas a.Procesos de negocio integrados completamente b.Procesos de mantenimiento y operación c.Procedimientos de usuario d.Formas (Interfaces) e.Reportes f.Datos de Configuración
24 Pruebas de Aceptación: Son responsabilidad de los usuarios o clientes del sistema, u otros interesados. Su objetivo es establecer la confianza en el sistema, parte del sistema o característica no funcional del sistema. Su enfoque no es encontrar defectos. Evalúa la preparación del sistema para ser descargado y usado, aunque pueden haber pruebas de integración posteriores. Estas pruebas pueden ocurrir en diferentes fases del ciclo de vida de desarrollo: a.Submódulos pueden ser probados por aceptación cuando son instalados o integrados b.Pruebas de aceptación de la usabilidad de un componente, durante la prueba del componente. c.Prueba de aceptación de una funcionalidad ampliada antes de las pruebas de sistema
25 Pruebas de Aceptación Las pruebas de aceptación deben incluir los siguientes estrategias: Pruebas de Aceptación de usuario Verifica la disponibilidad del sistema para ser usado por los usuarios del negocio Pruebas de Aceptación Operacional La aceptación del sistema, por parte de los administradores del sistema: 1.Pruebas de recuperación y copias 2.Recuperación de desastres 3.Administración de usuarios 4.Tareas de mantenimiento 5.Carga de datos y tareas de migración 6. Revisiones periódicas de vulnerabilidades de seguridad
26 Pruebas de Aceptación Las pruebas de aceptación deben incluir los siguientes estrategias: Pruebas de Aceptación de regulaciones y contratos Se realizan contra los criterios de aceptación de contratos estipulados para el desarrollo de software. Los criterios de aceptación podrían ser definidos cuando las partes acuerdan el contrato. Las regulaciones se confrontan con las regulaciones a las cuales se debe adherir, tales como gubernamentales, legales o de seguridad, etc..
27 Pruebas de Aceptación Las pruebas de aceptación deben incluir los siguientes estrategias: Pruebas Alfa y Beta (o de Campo) Los desarrolladores de mercado a menudo quieren feedback de los clientes potenciales, antes de que el producto de software sea comercializado. Pruebas Alfa: se llevan a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y problemas de uso. Pruebas Beta: se llevan a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no está presente normalmente. Así, la prueba beta es una aplicación en vivo del software en un entorno que no puede ser controlado por el desarrollador.