1

2 Principios de las pruebas 1 Principios2 Ciclo de Vida 4 Técnicas Dinamicas 3 Pruebas estáticas 5 Manejo6 Herramientas Software Testing ISTQB / ISEB Foundation Exam Practice Chapter 1

3 Contenidos ¿Por qué es necesario realizar pruebas? Psicología de las pruebas Resultados Esperados Priorización de las pruebas Principles 123 456 ISTQB / ISEB Foundation Exam Practice

4 Terminologia de Pruebas n No se aceptó en general un conjunto de definiciones de pruebas utilizados en todo el mundo. n El estandar nuevo BS 7925-1 -Glosario de términos de prueba (con énfasis en las pruebas de componentes) -Mas reciente. -Desarrollado por un grupo de trabajo del SIGIST BCS -Adoptada por la ISEB / ISTQB

5 Que es un “bug”? n Error: una acción humana que produce un resultado incorrecto. n Defecto: una manifestación de un error en el software. -también conocido como un defecto o fallo. -si se ejecuta, un defecto puede provocar un fallo. n Fallo: desviación del software desde su entrega prevista o servicio. -(defecto encontrado) Si no es un evento; fallo es un estado de el software, causada por un error

6 Error - Defecto - Fallo Una persona que hace un error...... Que crea un defecto, En el software... Que puede causar... ¿una falla? En funcionamiento

7 Fiabilidad frente a fallos n Fiabilidad: la probabilidad de que el software no provocará el fallo del sistema durante un tiempo especificado en condiciones especificadas -Puede ser un sistema libre de errores? (cero defectos, la primera vez a la derecha) -¿Puede un sistema de software fiable, pero todavía tiene defectos? -Es un aplicación de software "sin fallos" siempre es fiable?

8 ¿Por qué se producen fallos en el software? n El software esta escrito por personas. -Que saben algo, pero no todo. -Que tienen habilidades, pero no son perfectos. -Que comenten errores (errors). n Bajo una creciente presión para entregar a plazos estrictos -no hay tiempo para comprobar las hipótesis, pero puede estar equivocado. -Los sistemas pueden estar incompletos. n Si alguna vez ha escrito software...

9 ¿Qué costo ocacionan las falla en el software ? n Grandes sumas de dinero -Accidente Ariane 5 ($7billion) exception de software. -Mariner sonda espacial a Venus($250m). instrucciones del programa. -American Airlines ($50m). n muy poco o nada en absoluto -inconveniente menor. -efecto perjudicial visible o físico. n El software no es "lineal":  Una entrada pequeña puede tener un efecto muy grande.

10 Sistemas de seguridad críticos n Las fallas de software pueden causar la muerte o lesiones. -El tratamiento de radiación mata pacientes (Therac- 25) -maquinista muerto. -impactos de los aviones (Airbus y coreano Airlines) -Sistema de emision de cartas bancarias de sobregiro causan suicidio.

11 ¿Por qué es necesario probar? -porque es probable que el software que tengan defectos -para aprender acerca de la fiabilidad del software -para llenar el tiempo entre la entrega del software y la fecha de lanzamiento -para demostrar que el software no tiene faltas -porque la prueba está incluida en el plan del proyecto -porque las fallas pueden ser muy caros -para evitar ser demandado por los clientes -para mantenerse en el negocio

12 ¿Por qué no simplemente "probar todo"? El sistema tiene 20 pantallas Promedio: 10 campos / pantalla 2 tipos de entrada / campo (fecha como Enero 3 or 3/1) (numeros integeros o decimales) Redondeo de 100 posibles valores Total para prueba 'exhaustive' : 20 x 4 x 3 x 10 x 2 x 100 = 480.000 pruebas Si 1 segundo por prueba, 8000 minutos, 133 horas, 17.7 dias (sin contar los problemas dedo, fallas o retest) Prom. 4 menus 3 options / menu 10 secs = 34 wks, 1 min = 4 años, 10 min = 40 años

13 Las pruebas exhaustivas? n ¿Qué es la prueba exhaustiva? -cuando todos los probadores se han agotado -cuando todas las pruebas previstas se han ejecutado -el ejercicio de todas las combinaciones de insumos y las condiciones previas n ¿Cuánto tiempo va a tomar hacer pruebas exhaustivas? -Una cantidad de tiempo poco práctica -Un tiempo infinito -No mucho tiempo

14 ¿Cuántas pruebas son suficientes? -nunca es suficiente -cuando hayáis hecho lo que planeaste -cuando el cliente / usuario es feliz -cuando se ha demostrado que el sistema funciona correctamente -cuando se tiene la certeza de que el sistema funciona correctamente -que depende de los riesgos detectados para su sistema

15 ¿Cuántas pruebas? n Esto depende del RIESGO -riesgo de fallas importantes que faltan. -riesgo de incurrir en los costos de fallas. -riesgo de liberación de software no probado o bajo prueba. -riesgo de perder credibilidad y cuota de mercado -riesgo de perder una ventana de mercado -riesgo de un exceso de pruebas, pruebas ineficaces

16 -qué no probar (esta vez) n Usas el RIESGO -asignar el tiempo disponible para la prueba, dando prioridad a las pruebas... Tan poco tiempo, tanto para poner a prueba.. n El tiempo de prueba siempre será limitado n El uso del RIESGO determina: -Lo que debe probar primero -Lo que mas debe probar -Como probar afondo cada elemento } i.e. Donde hacer enfasis

17 El principio más importante Priorizar las pruebas de modo que, siempre que se detenga la prueba, que ha hecho la mejor prueba en el tiempo disponible. Priorizar las pruebas de modo que, siempre que se detenga la prueba, que ha hecho la mejor prueba en el tiempo disponible.

18 Pruebas y calidad n Pruebas para determinar la calidad del software n Las pruebas pueden encontrar fallos, y cuando se retiran, la calidad del software (y posiblemente fiabilidad) se mejora. n Que probar? -la función del sistema, corrección de la operación -Cualidades no funcionales : fiabilidad, facilidad de uso, mantenibilidad, reusabilidad, capacidad de prueba, etc

19 Otros factores que influyen en las pruebas n Requerimientos contractuales. n Requerimientos Legales. n Requerimeintos Industriales Especificos. -por ejemplo industria farmacéutica (FDA), pruebas compilador estándar, de seguridad crítico o relacionado con la seguridad, tales como ferrocarril de conmutación, control de tráfico aéreo. Es difícil determinar la cantidad de pruebas que son suficientes pero no es imposible Es difícil determinar la cantidad de pruebas que son suficientes pero no es imposible

20 Contenidos ¿Por qué es necesario realizar pruebas? Proceso de prueba Fundamental Psicología de las pruebas Resultados Esperados Priorización de las pruebas Principles 123 456 ISTQB / ISEB Foundation Exam Practice

21 Planificación de prueba - los diferentes niveles Politica de Prueba Estrategia de prueba Nivel Compañía High Level Test Plan Plan de Prueba de alto nivel Nivel de Proyecto (IEEE 829) (uno por cada proyecto) Detailed Test Plan Plan de Prueba Detallado Nivel de Estado de Pruebas (IEEE 829) (uno para cada etapa dentro de un proyecto,por ejemplo Componente, sistema, etc)

22 El Proceso de Prueba especificacionejecucionregistro Chequeo Completacion Planificacion (Nivel Detallado)

23 Planificando Pruebas n Como la estrategia de pruebas y el plan de proyecto de prueba aplican al software bajo prueba. n documentar cualquier excepción a la estrategia de prueba -por ejemplo Sólo en un caso de prueba de diseño técnica necesaria para esta área funcional, ya que es menos crítico -otro software necesario para las pruebas, tales como talones y conductores, y los detalles del entorno n establecer criterios de prueba de finalización

24 El Proceso de Prueba especificacionejecucionregistro Chequeo Completacion Identificar Condiciones Diseñar Casos de Prueba Construir Pruebas Planificacion (Nivel Detallado)

25 Un buen caso de prueba n Eficaz n Ejemplar n Evolucionable n Económico Encuentra las fallas Representa los demás Fácil de mantener Barato de implementar

26 Especificacion de Pruebas n La especificación de la prueba se puede dividir en tres tareas distintas: 1. Identifique:determinar "qué" se va a probar (identificar condiciones de prueba) y priorizar. 2. Diseñe:determinar "cómo" el "qué" se va a probar? (es decir, los casos de prueba de diseño) 3. Construya: implementar las pruebas (datos, scripts, etc)

27 Tarea 1: Identifique Condiciones n una lista de las condiciones que nos gustaría probar: -utilizar las técnicas de diseño de ensayo especificados en el plan de pruebas -puede haber muchas condiciones para cada función del sistema o atributo -e.g. "Seguro de vida para un deportista de invierno“ "Seguro de vida para un deportista de invierno“ "Número de elementos ordenada> 99“ "Número de elementos ordenada> 99“ “fecha = 29-Feb-2004” “fecha = 29-Feb-2004” n priorizar las condiciones de ensayo -deben garantizar las condiciones más importantes están cubiertas (determinar "qué" se va a probar y priorizar)

28 Selección de las condiciones de Prueba Importancia Tiempo Mejor Conjunto 4 8 Primer Conjunto

29 Tarea 2: Diseño de Casos de Prueba n Diseño entrada de prueba y datos de prueba. -cada prueba ejerce una o más condiciones de prueba. n Determinar los resultados esperados. -predecir el resultado de cada caso de prueba, lo que es la producción, lo que ha cambiado y lo que no se cambia. n Diseño de conjuntos de pruebas -prueba diferentes conjuntos de objetivos diferentes, tales como la regresión, la construcción de la confianza, y la búsqueda de fallos (determinar "cómo" el "qué" se va a probar)

30 Diseñando casos de prueba Importancia Tiempo Condiciones de prueba mas importantes Condiciones de Prueba menos importantes Casos de Prueba

31 Tarea 3: Construir casos de prueba n Preparara scripts de prueba -En el caso que el probador tenga menos conocimiento del sistema los scripts deben ser más detallados. -Los scripts de herramientas deben especificar todos los detalles. n Preparar data de prueba -Los datos que deben existir en los archivos y bases de datos en el inicio de las pruebas -preparar a los resultados esperados -deben ser definidos antes que la prueba se ejecute (Implementar casos de prueba)

32 Prueba de ejecución especificacionejecucionregistro Chequeo Completacion Planificacion (Nivel Detallado)

33 Ejecucion n Ejecutar casos de prueba prescritos -Los más importantes primero -no se ejecutaría todos los casos de prueba el if pruebas sólo las correcciones de fallas pruebas sólo las correcciones de fallas demasiados fallos encontrados por los primeros casos de prueba demasiados fallos encontrados por los primeros casos de prueba La presión del tiempo La presión del tiempo -se puede realizar manualmente o automatizado

34 Prueba de ejecución especificacionejecucionregistro Chequeo Completacion Planificacion (Nivel Detallado)

35 Registrando Prueba 1 n El registro de prueba contiene: -identificacion y versiones (sin ambigüedades) Del software bajo prueba Del software bajo prueba Especificaciones de Prueba Especificaciones de Prueba n Siga el plan de prueba -marcan el progreso del script de prueba -documentos reales de los resultados de la prueba -capturar cualquier otra idea que tengas para nuevos casos de prueba -Ten en cuenta que estos registros se utilizan para establecer que todas las actividades de prueba se han llevado a cabo tal como se especifica.

36 Registrando Prueba 2 n Comparar los resultados reales con el resultado esperado. Entrar discrepancias en consecuencia: -Fallas en el software. -de prueba de fallos (por ejemplo, los resultados esperados mal) -El medio ambiente o la versión falla -prueba de funcionamiento incorrecto n Entrar en niveles de cobertura alcanzados (para las medidas especificadas como criterios de terminación de prueba) n Después de la falla se ha solucionado, repita las actividades de prueba requeridos (ejecutar, diseño, plan)

37 Chequeo de Completacion de prueba especificacionejecucionregistro Chequeo Completacion Planificacion (Nivel Detallado)

38 Chequeo de Completacion de prueba n Los criterios de prueba de finalización se especifica en el plan de pruebas n Si no se cumplen, la necesidad de repetir las actividades de prueba, por ejemplo, Especificación de prueba para diseñar más pruebas especificacionejecucionregistro chequeo completacion Cobertura insuficiente Cobertura Aceptar

39 Criterios de prueba de completacion n Los criterios de completacion o de salida se aplica a todos los niveles de la prueba - para determinar cuándo parar. -cobertura, utilizando una técnica de medición, por ejemplo: rama de cobertura para las pruebas unitarias. rama de cobertura para las pruebas unitarias. Usar requerimientos. Usar requerimientos. transacciones de uso más frecuente transacciones de uso más frecuente -fallas encontradas (por ejemplo, frente a lo esperado) -Tiempo o Costos

40 Comparación de las tareas habitual Intelectual una sola vez la actividad repetida muchas veces Gobierna la calidad de las pruebas Es Bueno automatizar Ejecucion Registro Planificando Especficaciones

41 Contenidos ¿Por qué es necesario realizar pruebas? Proceso de prueba Fundamental Psicología de las pruebas Resultados Esperados Priorización de las pruebas Principles 123 456 ISTQB / ISEB Foundation Exam Practice

42 Por que Probar? n fomentar la confianza n demostrar que el software es correcto n demostrar la conformidad con los requisitos n encontrar fallos n Reducir costos n Los sistema de demostración cumple las necesidades del usuario n evaluar la calidad del software

43 Fault found Fallas Encontradas Confianza Tiempo Confianza No encontrarar fallas = confianza?

44 Few Faults Muchos Fallos Pocos Fallos Pocos Fallos Pocos Fallos Usted puede estar aquí Crees que estás aquí Prueba de Calidad Bajo Alto Calidad del Software BajoAlto La evaluación de la calidad del software

45 Un enfoque de las pruebas tradicionales n Demuestre que el sistema: -hace lo que debe -no hace lo que no debe Más rápido logro: fáciles casos de prueba Objetivo: Mostrar el trabajo Éxito: funciona el sistema Objetivo: Mostrar el trabajo Éxito: funciona el sistema Resultado: Las fallas que quedan

46 Una prueba mejor enfoque n Demuestre que el sistema : -hace lo que no debe -no hace lo que debe Más rápido logro: los casos difíciles pruebas objetivo : encontrar fallos éxito: sistema falla objetivo : encontrar fallos éxito: sistema falla Resultado: menos fallos que quedan

47 La paradoja de las pruebas Propósito de la prueba: encontrar fallos La mejor manera de construir confianza es tratar de destruirlo La mejor manera de construir confianza es tratar de destruirlo Propósito de la prueba: construir confianza Encontrar fallas destruye la confianza Propósito de la prueba: destruir la confianza

48 ¿Quién quiere ser un probador? n Un destructor de procesos n Trae malas noticias (“su bebé es feo”) n Bajo la presión peor momento (al final) n Necesidad de tener una visión diferente, una mentalidad diferente ("¿Y si no lo es?", "¿Qué podría salir mal?") n ¿Cómo debe ser comunicada la información de fallos (para autores y administradores?)

49 El probador tienen el derecho a: -Tener información precisa sobre el progreso y los cambios -visión de los desarrolladores acerca de las áreas del software -código entregado certificado con el estándar acordado -considerarse como un profesional (no abuso!) -encontrar defectos! -Cambio de Especificaciones y planes de prueba -han reportado fallas tomado en serio (no reproducible) -hacer predicciones sobre los futuros niveles de fallo -mejorar su proceso de pruebas propio

50 El probador tienen la responsabilidad de: -seguir los planes de pruebas, scripts.etc. como se documenta -Informar fallas objetivamente y de hecho (sin abuso!) -comprobar que las pruebas son correctas antes de informar s / w fallas -recuerda que es el software, no el programador, que se está probando -evaluar el riesgo objetivamente -prioridad a lo que informan -comunicar la verdad

51 Independencia n Pon a prueba tu propio trabajo? -encontrar un 30% - 50% de sus propias faltas -mismos supuestos y procesos de pensamiento -ver lo que quieres decir o quieren ver, no lo que hay -apego emocional no quieren encontrar fallos no quieren encontrar fallos NO quiero activarme para encontrar las fallas NO quiero activarme para encontrar las fallas

52 Los niveles de independencia n Ninguno: las pruebas diseñadas por la persona que escribió el software n Las pruebas diseñadas por una persona diferente n Las pruebas diseñadas por alguien de otro departamento o equipo (por ejemplo, equipo de prueba) n Las pruebas diseñadas por alguien de otra organización (por ejemplo, la agencia) n Pruebas generadas por una herramienta (pruebas de baja calidad?)

53 Contenidos ¿Por qué es necesario realizar pruebas? Proceso de prueba Fundamental Psicología de las pruebas Re-testing y pruebas de regresión Resultados Esperados Priorización de las pruebas Principles 123 456 ISTQB / ISEB Foundation Exam Practice

54 Después un fallo se fijan el Re-testing n Ejecutar una prueba, esta falla, reportar falla n Nueva versión de software con fallos "fijo“ n Vuelva a ejecutar la misma prueba (es decir, re-test) -debe ser exactamente repetible -mismo entorno, versiones (excepto por el software que ha sido intencionalmente cambiado!) -mismos insumos y las condiciones previas n Si la prueba pasa ahora, el fallo se ha corregido correctamente - o lo tiene?

55 Re-testing (re-ejecución de pruebas fallidas) x x x x Las fallas Nuevas introducidas por el primero La falla arreglada no fue localizada durante el re-testing Re-test para chequeo Fallo ha sido arreglado

56 Prueba de Regresion n para ver si hay efectos secundarios inesperados x x x x No se puede garantizar para encontrar a todos

57 Pruebas de regresión1 n nombre equivocado: "anti-retroceso" o "progreso“ n conjunto estándar de pruebas - paquete de pruebas de regresión n en cualquier nivel (unidad, integración, sistema, aceptación) n bien vale la pena la automatización n un activo de desarrollo, pero es necesario mantener

58 Pruebas de regresión2 n Pruebas de regresión se realizó -después de los cambios de software, incluidos los fallos corregidos -cuando el entorno cambia, aunque la funcionalidad de la aplicación se mantiene igual -para los arreglos de emergencia (posiblemente un subconjunto) n Suites de pruebas de regresión -evolucionar en el tiempo -se ejecutan a menudo -puede llegar a ser bastante grande

59 Pruebas de regresión3 n Mantenimiento del paquete de ensayo de regresión -eliminar las pruebas repetitivas (pruebas que ponen a prueba la condición misma prueba) -combinar casos de prueba (por ejemplo, si se ejecutan siempre juntos) -seleccionar un subconjunto diferente de la suite de regresión completa se ejecute cada vez que se necesita una prueba de regresión -eliminar las pruebas que no han encontrado un fallo durante un tiempo largo (por ejemplo, pruebas de edad fijos de fallo)

60 Pruebas de regresión y automatización n Los instrumentos de ensayo de ejecución (por ejemplo, repetición de captura) son herramientas de pruebas de regresión - que volver a ejecutar las pruebas que ya se han ejecutado n Una vez automatizado, las pruebas de regresión se puede ejecutar tantas veces como se desee (por ejemplo, todas las noches) n Automatización de pruebas no es trivial (por lo general tarda de 2 a 10 veces más tiempo para automatizar una prueba de que ejecutarlo manualmente) n No automatizar todo - Plan para automatizar lo primero, sólo si vale la pena automatizar.

61 Contenidos ¿Por qué es necesario realizar pruebas? Proceso de prueba Fundamental Psicología de las pruebas Re-testing y pruebas de regresión Resultados Esperados Priorización de las pruebas Principles 123 456 ISTQB / ISEB Foundation Exam Practice

62 Resultados esperados n Debería preverse con antelación como parte del proceso de diseño de la prueba -"Asunción de Oracle” asume que el resultado correcto se puede predecir. n ¿Por qué no basta con ver lo que hace el software y lo valora en el momento? -subconsciente deseo de realizar la prueba correctamente - menos trabajo que hacer, no informe de incidente para escribir -parece plausible, por lo que debe estar bien - menos riguroso que calcular de antemano y comparar

63 Una prueba Un Programa: Source: Carsten Jorgensen, Delta, Denmark entradas Salidas esperadas 3 8 6? 10? Read A IF (A = 8) THEN PRINT (“10”) ELSE PRINT (2*A)

64 Contenidos ¿Por qué es necesario realizar pruebas? Proceso de prueba Fundamental Psicología de las pruebas Re-testing y pruebas de regresión Resultados Esperados Priorización de las pruebas Principles 123 456 ISTQB / ISEB Foundation Exam Practice

65 Priorización de las pruebas n No podemos probar todo n Nunca hay tiempo suficiente para hacer todas las pruebas que le gustaría n Entonces, ¿qué pruebas debe hacer?

66 El principio más importante Priorizar las pruebas de modo que, siempre que se detenga la prueba, que ha hecho la mejor prueba en el tiempo disponible. Priorizar las pruebas de modo que, siempre que se detenga la prueba, que ha hecho la mejor prueba en el tiempo disponible.

67 ¿Cómo priorizar? n Posibles criterios de clasificación (todo basado en el riesgo) -probar que un fracaso sería más grave -comprobar que las deficiencias sería más visible -comprobar que las deficiencias son más propensos -preguntar al cliente para priorizar los requisitos -lo que es más importante para el negocio del cliente -Las áreas cambian más a menudo -las zonas con más problemas en el pasado -Las áreas más complejas o técnicamente crítico

68 Resumen: Puntos claves Las pruebas son necesarias porque la gente comete errores El proceso de prueba: planificación, especificación, ejecución, registro, comprobación de finalización Independencia y las relaciones son importantes en las pruebas Re-soluciones de prueba, prueba de regresión para lo inesperado Resultados esperados de una especificación por adelantado Dar prioridad a hacer la mejor prueba en el tiempo que tiene Principles 123 456 ISTQB / ISEB Foundation Exam Practice