Testing - Ing. Gabriela Muñoz

16,063 views
15,871 views

Published on

Proyecto presentado por la Ing. Gabriela Muñoz en su Tesis de Grado

Published in: Technology
3 Comments
10 Likes
Statistics
Notes
No Downloads
Views
Total views
16,063
On SlideShare
0
From Embeds
0
Number of Embeds
2,050
Actions
Shares
0
Downloads
792
Comments
3
Likes
10
Embeds 0
No embeds

No notes for slide
  • Mi nombre es Gabriela MuñozEste es mi trabajo final para la materia Proyecto.El tema que elegí y sobre el cual investigué es Testing de Software (porque además trabajo en una empresa de rosario en Testing).Tenemos 2 días en lo cuales armé la presentación para que el primer dia veamos temas teoricos y si podemos terminar hoy con ellos. Y el segundo día mostrarles como se implementa el testing en la empresa donde yo trabajo.Algunos conceptos teóricos que vamos a estar viendo son:
  • Edsger Wybe Dijkstra - Fue un científico de la computación de los Países Bajos.
  • RUP – (Rational Unified Process) Proceso Unificado de Rational.Es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.Ejemplo Caso de PruebaCampo cantidad tiene que ser mayor que 100.Ej. CP1: ingresar una cantidad mayor que 100. CP2: Ingresar una cantidad menor que 100, ingresar una cantidad igual a 100.
  • Caso de prueba: PreCondicion -Objetivo – Descripción – Resultado esperado. Puede haber otros campos a utilizar.Ejemplo Objetivo: Verificar que el sistema solicita confirmación para la eliminación
  • Inception:La meta de esta fase es lograr una clara descripción de los requerimientos con la participación del cliente en la definición de los objetivos del proyecto. Elaboration:La meta de esta fase es definir la arquitectura del sistema estableciendo la base del diseño para la construcción del mismo.Construction:La meta de esta fase es completar el desarrollo del sistema soportado en una arquitectura definida. Transition:La meta de esta fase es asegurar que el software se libere adecuadamente a los usuarios. En este punto del ciclo de vida, la retroalimentación del cliente es básica para culminar con la aceptación del producto.
  • Planificar TestingEstimación de Testing (por experiencia, basada en Hs de desarrollo).Plan de Pruebas: Ambientes, schedule, requerimientos, etc.Diseño de CP: escritura en herramienta, PR escritura.
  • Testing - Ing. Gabriela Muñoz

    1. 1. Testing de Software Cátedra: Proyecto Profesor: Mario Bressano Universidad Tecnológica Nacional - FRROAbril 2012
    2. 2. Agenda Lunes 9 de Abril Testing Fundamentos del Testing Proceso Fundamental de Testing Modelo de Desarrollo de Software: Modelo V Niveles de Prueba Tipos de Prueba Martes 10 de Abril Conceptos Teóricos finalización En la PracticaConfidential // Neoris 2
    3. 3. ¿Testing?Confidential // Neoris 3
    4. 4. Pruebas de Software - Testing Definición Las pruebas de software, en inglés “Testing” son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de ordenador o videojuego. Básicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas. “El testing puede probar la presencia de errores pero no la ausencia de ellos”. Edsger Wybe DijkstraConfidential // Neoris 4
    5. 5. ¿Por qué es necesario el Testing?Confidential // Neoris 5
    6. 6. Fundamentos del Testing La importancia económica del software El funcionamiento de maquinaria y equipamiento depende en gran medida del software. No es posible imaginar grandes sistemas, en el ámbito de las finanzas ni el control del tráfico automotor, entre otros, funcionando sin software. Calidad del Software Cada vez más, la calidad software se ha convertido en un factor determinante del éxito de sistemas y productos técnicos o comerciales. Pruebas para la mejora de la calidad Las pruebas y revisiones aseguran la mejora de la calidad de productos de software así como de la calidad del proceso de desarrollo en sí.Confidential // Neoris 6
    7. 7. TerminologíaConfidential // Neoris 7
    8. 8. Error Defecto FallaConfidential // Neoris 8
    9. 9. Definición Error Acción humana que produce un resultado incorrecto. Ej. Un error de programación. Defecto Desperfecto en un componente o sistema que puede causar que el componente o sistema falle en desempeñar las funciones requeridas. Ej: una sentencia o una definición de datos incorrecta. Falla Manifestación física o funcional de un defecto. Si un defecto es encontrado durante la ejecución de una aplicación puede producir un fallo. Desvío de un componente o sistema respecto del resultado esperado.Confidential // Neoris 9
    10. 10. Fundamentos del Testing Calidad Grado en el cual un componente, sistema o proceso satisface requisitos especificados y/o necesidades y expectativas del usuario/cliente.Confidential // Neoris 10
    11. 11. Calidad de Software  Atributos funcionales de calidad: Funcionalidad: correctitud y completitud de los requisitos del usuario.  Atributos NO funcionales de calidad: Fiabilidad: el sistema mantendrá su capacidad y funcionalidad a lo largo de un período de tiempo. Usabilidad: fácil de usar, fácil de aprender, conforme a normas y uso intuitivo. Portabilidad: fácil de instalar y desinstalar, y configurar parámetros.Confidential // Neoris 11
    12. 12. ¿Cuánto Testing es necesario?Confidential // Neoris 12
    13. 13. Fundamentos del Testing El testing exhaustivo es imposible. Testear todas las combinaciones de entradas y precondiciones no es factible. Para enfocar el testing nos debemos basar en Riesgos y Prioridades.Confidential // Neoris 13
    14. 14. ¿Qué es testing?Confidential // Neoris 14
    15. 15. Percepción común Consiste solamente en realizar pruebas. Es ejecutar la aplicación. Es fácil y cualquiera lo puede hacer.Confidential // Neoris 15
    16. 16. Realidad Las actividades de la prueba existen antes y después de la ejecución de la prueba. Puede haber diferentes objetivos de prueba: Encontrar defectos. Ganar confianza sobre el nivel de calidad y proporcionar información. Prevenir defectosConfidential // Neoris 16
    17. 17. Proceso Fundamental de Testing El proceso de prueba fundamental consiste de las siguientes actividades principales: El proceso fundamental del Testing Planificación Aplicación y Actividades Análisis y Ejecución y Control de cierre de Diseño Pruebas Evaluación de los criterios de salida y ReportesConfidential // Neoris 17
    18. 18. Planificación y Control Nos aseguramos de haber entendido las metas y objetivos del cliente, el proyecto y los riesgos de las tareas de testing. Planificación y Control Determinar el alcance y los riesgos, e identificar los objetivos de la prueba. Implementar la estrategia de prueba. Programar los análisis de prueba y las tareas de diseño.Confidential // Neoris 18
    19. 19. Análisis y Diseño Actividad donde los objetivos generales de las pruebas se transforman en condiciones de prueba tangibles y casos de prueba. Análisis y Revisión de los elementos básicos para las Diseño pruebas (tales como los requerimientos, arquitectura de la aplicación, diseño, interfaces). Identificar y priorizar las condiciones de las pruebas y datos de pruebas basado en el análisis anterior. Puesta a punto del entorno de pruebas y se determinan las herramientas necesariasConfidential // Neoris 19
    20. 20. Ejecución Aplicación y Ejecutar las pruebas. Ejecución Registrar resultados, Comparar e Informar. Evaluación de los Repetir las pruebas. criterios de salida y ReportesConfidential // Neoris 20
    21. 21. Implementación y ejecución de prueba La implementación y ejecución de prueba tienen las siguientes tareas principales: Ejecutar los casos de prueba ya sea manualmente o mediante el uso de herramientas de ejecución de prueba, de acuerdo con la secuencia planeada. Registrar el resultado de la ejecución de prueba y la versión del software bajo prueba, en una herramientas de prueba. Comparar los resultados reales con los resultados esperados. Informar discrepancias como incidentes. Repetir las actividades de prueba después de las correcciones. Por ejemplo, la re- ejecución de una prueba que falló previamente para confirmar un arreglo (pruebas de confirmación), ejecución de pruebas para asegurarse que los defectos no han sido introducidos en áreas no cambiadas del software o que el arreglo del defecto no reveló otros defectos (pruebas de regresión).Confidential // Neoris 21
    22. 22. Evaluación de los criterios de salida y Reportes Evaluar los criterios de salida es la actividad donde la ejecución de prueba es evaluada contra los objetivos definidos. Esto debe hacerse para cada nivel de prueba. Evaluar los criterios de prueba tiene las siguientes tareas principales: Comparar los registros de prueba contra los criterios de salida especificados en la planificación de prueba. Evaluar si se necesitan más pruebas. Escribir un reporte de resumen de prueba para las partes interesadas.Confidential // Neoris 22
    23. 23. Actividades de cierre de Pruebas Se recolecta la información de las actividades de prueba Actividades completadas para consolidar. de cierre de Pruebas Verificar el entregable y que los defectos hayan sido corregidos. Archivar todo el material generado en las pruebas para un futuro uso. Evaluar como resultaron las actividades de testing y analizar las lecciones aprendidas.Confidential // Neoris 23
    24. 24. Psicología de Prueba El modo de pensar a ser usado mientras se prueba y revisa es diferente al usado mientras se analiza o desarrolla. La separación de esta responsabilidad hacia un probador es realizada típicamente para ayudar a enfocar el esfuerzo y para proporcionar beneficios adicionales, tales como una visión independiente. Varios niveles de independencia pueden ser definidos: Pruebas diseñadas por la(s) persona(s) que escribió (escribieron) el software bajo prueba. Pruebas diseñadas por otra(s) persona(s) del equipo de desarrollo. (bajo nivel de independencia). Pruebas diseñadas por una(s) persona(s) de un grupo organizacional diferente (por ejemplo, un grupo de prueba independiente. Pruebas diseñadas por una(s) persona(s) de una organización o compañía diferente (es decir subcontratación o certificación por un organismo externo).Confidential // Neoris 24
    25. 25. Psicología de Prueba – continuación Identificar fallas durante la prueba puede ser percibido como una crítica contra el producto y contra el autor. La prueba es, por lo tanto, a menudo vista como una actividad destructiva, aunque es muy constructiva en la gestión de riesgos del producto. Buscar fallas en un sistema requiere curiosidad, pesimismo profesional, un ojo crítico, atención al detalle, buena comunicación con los pares de desarrollo y experiencia en que basar la conjetura de error. Si los errores, defectos o fallas son comunicados en una forma constructiva, malos sentimientos entre los probadores y los analistas, diseñadores y desarrolladores pueden ser evitados.Confidential // Neoris 25
    26. 26. Modelos de desarrollo de SoftwareConfidential // Neoris 26
    27. 27. Testing a través del ciclo de desarrollo del software La prueba no existe en forma aislada; las actividades de prueba están relacionadas con las actividades de desarrollo de software. Los diferentes modelos de ciclo de vida de desarrollo necesitan diferentes enfoques hacia la prueba. Modelo-V Aunque existen variantes del Modelo-V, un tipo común de Modelo-V usa 4 niveles de prueba, correspondientes a 4 niveles de desarrollo. Los cuatro niveles usados en este programa son: Prueba de componente (unidad). Prueba de integración. Prueba de sistema. Prueba de aceptación. En la práctica, un Modelo-V puede tener diferentes niveles de desarrollo y prueba, dependiendo del proyecto y del producto de software. Por ejemplo, puede existir prueba de integración de componentes después de las pruebas de componente y prueba de integración del sistema después de la prueba del sistema.Confidential // Neoris 27
    28. 28. Modelo V Definición de Requisitos Pruebas de Aceptación Diseño Funcional del Sistema Pruebas de Sistema Diseño Técnico del Sistema Pruebas de Integración Especif. de Componentes Pruebas de Componentes ProgramaciónConfidential // Neoris 28
    29. 29. Testing a través del ciclo de desarrollo del software Testing de Niveles de Pruebas Aceptación Testing del Sistema Testing de Integración Testing de ComponentesConfidential // Neoris 29
    30. 30. Testing de Componentes Definición Prueba de cada componente tras su realización/construcción Los componentes son referidos como módulos, clases o unidades También denominadas pruebas de Desarrollador (developer’s test) Alcance Testing de Cada componente es probado de forma independiente Componentes Descubrir fallos producidos por defectos internos Los casos de prueba tienen 3 fuentes: especificaciones de componente, diseño, modelo de datos.Confidential // Neoris 30
    31. 31. Testing de Integración Definición Testing de Integración Comprueba la interacción entre elementos de software (componentes) tras la integración del sistema. Comprueban las funciones externas. Testing de Componentes Pueden ser ejecutadas por desarrolladores, testers o ambos.Confidential // Neoris 31
    32. 32. Testing de Integración Estrategias Testing de Integración Incremental Ascendente Testing de Descendente Componentes No Incremental Ad-HocConfidential // Neoris 32
    33. 33. Estrategias – Tipos fundamentales de Integración Integración incremental. Se combina el siguiente módulo que se debe probar con el conjunto de módulos que ya han sido probados. Ascendente. Se combinan los módulos de bajo nivel en grupos que realicen una función o subfunción específica (o quizás si no es necesario, individualmente) -> de este modo reducimos el número de pasos de integración. Se escribe para cada grupo un módulo impulsor o conductor -> de este modo permitimos simular la llamada a los módulos, introducir datos de prueba y recolectamos resultados. Se prueba cada grupo mediante su impulsor. Se eliminan los módulos impulsores y se sustituyen por los módulos de nivel superior en la jerarquía.Confidential // Neoris 33
    34. 34. Estrategias – Tipos fundamentales de Integración Integración incremental. Descendente. Se comienza por el módulo raíz. Comienza por el módulo de control principal y va incorporando módulos subordinados progresivamente. No hay un orden adecuado de integración, pero se recomienda lo siguiente: Si hay secciones críticas (especialmente complejas) se deben integrar lo antes posible. El orden de integración debe incorporar cuanto antes los módulos de entrada/salida para facilitar la ejecución de pruebas. Integración NO incremental. Se prueba cada módulo por separado y luego se integran todos de una vez y se prueba el programa completo. Ad-hoc: Los componentes serán probados, si fuera posible, inmediatamente después de haber sido finalizada su construcción y se hayan finalizado las pruebas de componente.Confidential // Neoris 34
    35. 35. COMPARACION DE LOS DISTINTOS TIPOS DE INTEGRACION PRUEBAS DEL SOFTWARE Ventajas de la No incremental: Requiere menos tiempo de máquina para las pruebas, ya que se prueba de una sola vez la combinación de los módulos. Existen más oportunidades de probar módulos en paralelo. Ventajas de la incremental: Los defectos y errores en las interfaces se detectan antes, ya que se empieza antes a probar las uniones entre los módulos. La depuración es mucho más fácil, ya que si se detectan los síntomas de un defecto en un paso de la integración hay que atribuirlo muy probablemente al último módulo incorporado. Se examina con mayor detalle el programa, al ir comprobando cada interfaz poco a poco.Confidential // Neoris 35
    36. 36. INCREMENTAL ASCENDENTES DESCENDENTES VENTAJAS VENTAJAS Es un método ventajoso si aparecen grandes Es ventajosa si aparecen grandes defectos fallos en la parte inferior del programa, ya en los niveles superiores del programa, ya que se prueba antes. que se prueban antes. La entradas para las pruebas son más Permite ver antes una estructura previa del módulos inferiores. programa, lo que facilita el hacer Es más fácil observar los resultados de la demostraciones. prueba, ya que es en los módulos inferiores donde se elaboran los datos (los superiores suelen ser módulos de control). DESVENTAJAS DESVENTAJAS Se requieren módulos impulsores, que Las entradas para las pruebas pueden ser deben codificarse. difíciles o imposibles de crear, puesto que, a El programa, como entidad, sólo menudo, se carece de los módulos inferiores aparece cuando se agrega el último que proporcionan los detalles de operación. módulo. Es más difícil observar la salida, ya que los resultados surgen de los módulos inferiores.Confidential // Neoris 36
    37. 37. Testing de Sistema Definición Tiene que ver con el comportamiento de todo un sistema/producto, definida por el alcance de un proyecto de desarrollo o programa. Enfoques para las pruebas funcionales: Testing de Sistema Basadas en Requisitos. Los casos de prueba se derivan de la especificación de requisitos. El número de casos de prueba variará en función del tipo/profundidad Testing de de las pruebas basadas en la especificación de requisitos. Integración Basadas en Procesos de Negocio. Cada proceso de negocio sirve como fuente para derivar/generar pruebas. El orden de relevancia de los procesos de negocio puede ser aplicado para asignar prioridades a los casos de prueba. Testing de Componentes Basadas en Casos de Uso. Los casos de prueba se derivan/generan a partir de las secuencias de usos esperados o razonables. Las secuencias utilizadas con mayor frecuencia reciben una prioridad más alta.Confidential // Neoris 37
    38. 38. Testing de Aceptación Testing de Definición Aceptación Pruebas formales llevadas a cabo con el Testing del objeto de verificar la conformidad del Sistema sistema con los requisitos. Testing de El Objetivo de las pruebas de aceptación es Integración validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su Testing de funcionalidad y rendimiento. ComponentesConfidential // Neoris 38
    39. 39. Tipos de Pruebas Tipos de pruebas: Objetivos del proceso de Pruebas Testing Funcional Testing No Funcional Testing Estructural Testing relacionado a cambiosConfidential // Neoris 39
    40. 40. Tipos de Pruebas – Testing Funcional Testing Funcional Objetivo: La función del objeto de prueba. Las funciones, que un sistema, un subsistema o un componente realizará, pueden estar descritas en productos de trabajo tales como una especificación de requisitos, casos de uso o una especificación funcional, o podrían estar no documentados. Las funciones son “lo que” el sistema hace. Las pruebas funcionales consideran el comportamiento externo del software (pruebas de caja negra). Se pueden llevar a cabo en todos los niveles de pruebasConfidential // Neoris 40
    41. 41. Tipos de Pruebas – Testing No Funcional Testing No Funcional Objetivo: La finalidad de la prueba es saber “como” funciona el sistema. El termino pruebas no funcionales describe las pruebas necesarias para medir las características de los sistemas y software que se puede cuantificar en una escala variable, tales como tiempos de respuesta para las pruebas de rendimiento. Pruebas de Performance Pruebas de Volumen Pruebas de ConcurrenciaConfidential // Neoris 41
    42. 42. Tipos de Pruebas – Testing Estructural Testing Estructural Objetivo: La finalidad de las pruebas es medir el grado en el cual la estructura del objeto de prueba ha sido cubierto por los casos de prueba. Las pruebas estructurales (de caja blanca) pueden ser realizadas en todos los niveles de prueba, pero sobre todo en las pruebas de componentes (unit testing) y las pruebas de integración de componentes. Las técnicas estructuradas son las mejores usadas después de las técnicas basadas en especificaciones.Confidential // Neoris 42
    43. 43. Tipos de Pruebas – Testing relacionado a cambios Testing de confirmación/regresión Objetivo: Repetir una prueba de funcionalidad que ha sido verificada previamente. Confirmación: Cuando un defecto es detectado y arreglado, entonces el software debe ser probado de nuevo para confirmar que el defecto original ha sido retirado exitosamente. Regresión: son las pruebas repetidas de un programa ya testeado, después de una modificación, para descubrir cualquier error introducido o no descubierto como resultado del cambio(s). Estos errores pueden ser ya sea en el software que se está testeando, o en otro componente del software relacionado o no. Se lleva a cabo cuando el software, o su entorno, sufren cambios. El alcance de las pruebas de regresión esta basado en el riesgo de no encontrar errores en el software que estaba funcionando anteriormente.Confidential // Neoris 43
    44. 44. Pruebas de Mantenimiento Testing durante el mantenimiento Las pruebas de mantenimiento se realizan en un sistema operativo existente, y es provocada por modificaciones, migración de datos, o la jubilación del software o sistema. Las modificaciones incluyen cambios planificados, correctivos y cambios de emergencia, y cambios de ambiente, como el sistema operativo o base de datos prevista, actualizaciones o parches. Además de verificar lo que se ha cambiado, las pruebas de mantenimiento incluyen extensivas pruebas de regresión a las partes del sistema que no han sido cambiadas. La determinación de cómo el sistema actual puede verse afectado por los cambios se llama análisis de impacto, y es utilizado para ayudar a decidir la cantidad de pruebas de regresión a hacer.Confidential // Neoris 44
    45. 45. Recapitulación Error, defecto y falla. Proceso fundamental de testing. Ciclo de desarrollo de software: modelo V. Niveles de pruebas: •Componente. •Integración. •Incremental (asc o desc), No Incremental, Ad hoc. •Sistema. •Aceptación. Tipos de Pruebas (a través de los distintos niveles) Testing Funcional Testing No Funcional: carga, stress, volumen, etc. Testing Estructural: caja blanca Testing Relacionado a Cambios: confirmacion/regresión. Pruebas en el Mantenimiento.Confidential // Neoris 45
    46. 46. Preguntas?Confidential // Neoris 46
    47. 47. Agenda Martes 10 de Abril  Diseño de Pruebas  Técnicas  Caja Negra  Caja Blanca  En la Práctica  Ciclo de Vida y Testing  Niveles de Prueba  Servicios de Testing  Consultoría de pruebas  Automatización  HerramientasConfidential // Neoris 47
    48. 48. Diseño de PruebasConfidential // Neoris 48
    49. 49. TerminologíaConfidential // Neoris 49
    50. 50. Caso de Prueba Definición Son un conjunto de condiciones o variables bajo las cuáles el analista determinará si el requisito de una aplicación es parcial o completamente satisfactorio. Se pueden realizar muchos casos de prueba para determinar que un requisito es completamente satisfactorio. Debe haber al menos un caso de prueba para cada requisito. Algunas metodologías como RUP recomiendan el crear por lo menos dos casos de prueba para cada requisito. Uno de ellos debe realizar la prueba positiva de los requisitos y el otro debe realizar la prueba negativa. Lo que caracteriza un escrito formal de caso de prueba es que hay una entrada conocida y una salida esperada. La entrada conocida debe probar una precondición y la salida esperada debe probar una postcondición.Confidential // Neoris 50
    51. 51. Casos de Prueba - continuación Información general acerca de los Casos de Prueba: Identificador Objetivo Descripción Resultado Esperado Creador VersiónConfidential // Neoris 51
    52. 52. Caso de Prueba - continuación Objetivo: Es el fin que se quiere alcanzar y al cual se dirige la acción. El objetivo debe estar alineado con el resultado esperado. Ejemplo: • Verificar que el sistema solicita confirmación para la eliminación. Descripción: los pasos que debe seguir el tester para realizar la prueba y alcanzar el objetivo expuesto. Ejemplo: • Realizar una búsqueda que arroje resultados, seleccionar un elemento de la lista y seleccionar la opción “Eliminar”. Resultado Esperado: Es la respuesta que esperamos de la aplicación testeada luego de ejecutar los pasos detallados en la descripción con el fin de alcanzar el objetivo. Ejemplo: • El sistema muestra un mensaje de confirmación.Confidential // Neoris 52
    53. 53. Técnicas de diseño de pruebasConfidential // Neoris 53
    54. 54. Representación Gráfica CAJA BLANCA Se realiza sobre las funciones internas de un módulo. Los casos de prueba son seleccionados en base a la estructura interna del programa/código. La estructura del programa es el foco de la atención. CAJA NEGRA El tester observa el objeto de pruebas como una caja negra. Los casos de prueba se obtienen a partir del análisis de la especificación de un componente o sistema. La funcionalidad es el foco de la atención.Confidential // Neoris 54
    55. 55. Técnicas de Caja BlancaConfidential // Neoris 55
    56. 56. Caja Blanca Utiliza la estructura de control de diseño procedural para derivar casos de pruebas que:  Garanticen que todos los caminos independientes dentro de un módulo han sido ejercitados por lo menos una vez.  Ejerciten todas las decisiones lógicas en sus lados verdaderos y falsos.  Ejerciten estructuras de datos internas para asegurar su validez. Distintos Métodos: Cobertura de Camino Básico Cobertura de Condición Cobertura de BuclesConfidential // Neoris 56
    57. 57. Técnicas de caja negraConfidential // Neoris 57
    58. 58. Técnicas de diseño de pruebas Los métodos más utilizados son: Particiones de equivalencias Es un proceso sistemático que identifica un conjunto de clases de prueba representativas de un conjunto de pruebas posibles, la idea es que el producto se comportará de la misma manera para todos los miembros de una clase. Consta de los siguientes pasos: 1. Identificar las clases de equivalencias: Por ejemplo: (si un contador puede ir de 1 a 999). Entonces tendríamos: Clases Válidas: (1 <= contador <= 999). Clases Inválidas: (contador < 1), (contador > 999) 2. Identificar los casos de pruebas: asignar un nro. único a cada clase, diseñar casos de pruebas hasta cubrir todas las clases válidas y clases inválidas. Análisis de valores fronteras Es una variante del particiones de equivalencias, se seleccionan los bordes de una clase. Por cada clase válida hay que definir pruebas para las fronteras. Por ejemplo: número entre 3 y 8, probar para 2, 3, 8 y 9.Confidential // Neoris 58
    59. 59. Resumen Caso de Prueba: identificador, objetivo, descripción, resultado esperado, etc. Técnicas Caja Negra: Particiones de Equivalencias, Análisis de valores frontera. Caja Blanca: Cobertura de camino Básico, de condición, de bucle. Los métodos de caja negra y caja blanca son métodos dinámicos. Solo se puede probar código existente. Detecta el código muerto, pero no funciones faltantes. Los métodos de caja blanca son utilizados en pruebas de bajo nivel como prueba de componente o pruebas de integración de componentes.Confidential // Neoris 59
    60. 60. EN LA PRACTICAConfidential // Neoris 60
    61. 61. Servicios de Testing Permite evaluar y conocer los procesos y Asegurar que el usuario final obtiene la actividades de testing que se realizan y funcionalidad requerida a través de un proponer una solución metodológica y software bien construido operativa de acuerdo a las oportunidades identificadas. Testing Methodology Garantizar la máxima productividad del Ahorrar tiempo y costo en las pruebas, usuario final, evitando retrasos y otros mediante el diseño, construcción y impactos negativos en los negocios, a ejecución de pruebas automatizadas través de un buen tiempo de respuesta de las aplicaciones, validando su infraestructura y arquitecturaConfidential // Neoris 61
    62. 62. En la Practica - Ciclo de Vida Desarrollo Implementación Propuesta Análisis Diseño y TestingConfidential // Neoris 62
    63. 63. Testing a través del ciclo de desarrollo del software Nivel de Testing Tipo de Testing Breve Descripción Testing de Unidad Verifica que el código de cada componente trabaja de acuerdo a sus especificaciones y Testing de Unidad valida la lógica del programa. Se utiliza la estrategia de caja blanca Ejecutados por el Desarrollador Verifica que las interfaces entre las componentes, entidades externas y la aplicación Testing de Testing de Integración funcionan correctamente. Integración de primer nivel Se pueden aplicar diferentes estrategias. Testing de Integración de segundo nivel Verifica la integración funcional entre los diferentes casos de usos del sistema. Consiste en probar la funcionalidad del sistema, a partir de cumplir con los requerimientos, sin tener en cuenta la forma en cómo éste resuelve internamente las Testing Funcional especificaciones. Se utiliza la estrategia de caja negra. Ejecutados por el Testing de Tester Consiste en verificar el cumplimiento de los requerimientos no funcionales, por Sistema Testing No Funcional ejemplo: capacidad de instalación, usabilidad. Valida, ante un cambio en el sistema, que las partes del mismo, que no hayan cambiado continúen funcionando correctamente, luego de implementada la modificación. Se ejecutan casos de prueba seleccionados de entre los que se definieron para Testing Testing de Regresión Funcional y Testing No Funcional. Ejecutado por el Testing de Valida el cumplimiento de los requerimientos a partir del punto de vista del usuario. Se Cliente Aceptación ejecutan casos de prueba seleccionados de entre los que se definieron para Testing de Testing de Aceptación Sistema. (opcional junto al tester)Confidential // Neoris 63
    64. 64. Preparación del Testing – ActividadesConfidential // Neoris 64
    65. 65. Estimación del Testing Consideraciones Generales Tarea % tiempo insumido Detalle de Operaciones Lectura y análisis de documentación. Definición de casos 35% Escritura de casos de Prueba. Ejecución de Casos de Prueba. Ejecución: 1er pasada 40% Reporte de Errores. Reejecución de Casos. Retesting 15% Actualización de Estados. Generación de Informes. Otras tareas 10% Problemas con entornos. Otros tiempos a tener en cuenta Una vez que se tienen definidos los tiempos para los módulos, entran otras variables en juego, las cuales aumentan el volumen de horas: •Distintos Navegadores y/o resoluciones de pantalla. •Cantidad de Idiomas. •Lugar donde se testea (Staging, Producción)Confidential // Neoris 65
    66. 66. Comunicación durante las pruebas Documentación de Entrada Salida Generada Aviso Formal de la liberación de un Ejecución de los Casos de Prueba y Módulo al entorno de Testing. Registración de Incidencias en la Herramienta. Aviso Formal de Fin de Testing del Módulo. Ejecución del Re-testing, y pruebas de Regresión. Elaboración de Informe Final. BD Tareas a Realizar Asignación de Incidencias en la Herramienta. Corrección de Incidencias y Registro en la Herramienta. Actualización del Entorno de Testing. Aviso Formal de la Liberación del Módulo para el Re-testing. BD Consideraciones a Tener en Cuenta El testing se realizará en base a la documentación recibida y cualquier diferencia entre la Aplicación y la documentación será considerada una falla y reportado como tal.Confidential // Neoris 66
    67. 67. Consultoría de Testing La consultoría consiste en conocer los procesos y actividades de testing que realiza la compañía internamente y/o a través de sus proveedores. Y así poder detectar fortalezas y debilidades de dichos procesos y actividades. Luego, en función de este trabajo, proponer una solución metodológica y operativa para mejorar las actividades de testing aplicables a los proyectos de software que lleve adelante la compañía. Permite mejorar: • Gestión y mitigación de riesgos • Aplican mejores prácticas en la gestión de procesos de testing • Diseño y Mejoras en el proceso de Testing • Soporte de expertos de testing durante el período necesario • Trasferencia de conocimientos de testing a la organizaciónConfidential // Neoris 67
    68. 68. Automatización de Pruebas Proceso El proceso general de automatización comienza por la evaluación de factibilidad de automatizar los casos de prueba, posterior confección del plan de automatización, desarrollo de los scripts y validaciones, y por último, la ejecución de los mismos y generación de reportes. Dado que no todos los casos de prueba definidos para una solución pueden automatizarse, este proceso transcurre como un subproceso de testing dentro del ciclo de proyecto. Qué debería ser automatizado primero? Test core del negocio / Test del mismo caso con diferentes datos Test ejecutados con mucha frecuencia Repetitividad Como Optimización de muchos proyectos:  Tareas repetitivas Complejidad  Generación de datos Impacto en el negocio  Múltiples regresiones  Errores que se repiten demasiado  Workflows largos necesarios para llegar a la funcionalidad a testearConfidential // Neoris 68
    69. 69. Herramientas utilizadas QA Process Management permite a un usuario final realizar un procedimient o de Test sobre un Sistema Team Foundation Server (TFS). Es un producto de Microsoft de control de versión, recolección de datos, informes y seguimiento de proyectos. V2008 y Beta 2010.Confidential // Neoris 69
    70. 70. Herramientas UtilizadasConfidential // Neoris 70
    71. 71. Comparación Herramientas Automatización Selenium 2 (Webdriver) QTP 11(última versión) Open Source y gratuito. Herramienta paga, cada licencia cuesta 9000 mil dólares más 25% del costo por año en mantenimiento. Funciona en todos los Sistemas Operativos. Funciona sólo en Windows. Sólo para pruebas en aplicaciones Web. Pruebas en aplicaciones Web y Escritorio (Windows). Funciona en todos los browsers. Funciona sólo con Firefox 3.5 e Internet Explorer (gran limitación para el testing Web). Se codifica en cualquier lenguaje (C#, Java, Ruby, Python, Sólo Visual Basic. PHP, Pearl, etc). Record and Play no es 100% confiable, pero es útil (sólo se Record and Play tiende a ser más sólido que en Selenium. utiliza para quienes no sepan codificar y quieren automatizar). Selenium no se integra nativamente con QC, necesita QTP se integra muy bien con Quality Center y TD. algunas configuraciones, pero no de forma nativa. Existen múltiples formatos y herramientas de reporte que puede generar Selenium. Selenium tiene una gran comunidad online de soporte, pero QTP tiene soporte telefónico, mail, y Web. no oficial. Hay empresas que cobran por dar soporte.Confidential // Neoris 71
    72. 72. Preguntas?Confidential // Neoris 72
    73. 73. MUCHAS GRACIAS! A.U.S Gabriela MuñozConfidential // Neoris 73

    ×