Nociones básicas de pruebas.

1. Diseño de casos de prueba * ERP (“Enterprise Resource Planning”)

2. 1 2 Conceptosgenerales de pruebas Diseño de casos de prueba Agenda

3. 2 Diseño de casos de prueba Agenda 1 Conceptosgenerales de pruebas

4. Importancia de las pruebas Los sistemas de software son una parte creciente en nuestra vida, desde aplicaciones de negocio (bancos) hasta productos de consumo (autos) Muchas personas han tenido experiencias con software que no trabaja como es esperado. El software que no hace su trabajo correctamente puede acarrear muchos problemas, desde pérdida de dinero, tiempo o una mala reputación, y pueden incluso causar lesiones o muerte. Toyota anunció que llamará a revisión 133,000 vehículos del modelo Prius 2010 y 14,500 Lexus HS 250h 2010 "para actualizar el software en el sistema de antibloqueo de frenos (ABS) de los vehículos".

5. Causas de los defectos de software Un humano puede cometer un error que a su vez produce un defecto en el código, software, sistema o documento. Si un defecto en el código es ejecutado, el sistema fallará en hacer lo que tenía que hacer (o hará algo que no debía), causando una falla. Los defectos en el software, sistemas o documentos pueden resultar en fallas, pero no todos. Los defectos ocurren porque los principios humanos son falibles y por la existencia de presión, código complejo, infraestructura compleja, cambio en las tecnologías y/o muchas interacciones del sistema. Los defectos pueden ser causados por condiciones ambientales como: radiación, magnetismo, campos electrónicos y contaminación y pueden causar fallas en el firmware o influir en la ejecución de software al cambiar las condiciones del hardware

6. Defectos causados por condiciones ambientales…

7. Niveles de Pruebas Para cada uno de los niveles de pruebas, puede identificarse lo siguiente: Objetivos genéricos Los productos que será referenciado de la derivación de los casos de prueba El objetivo de la prueba (lo que será probado) Defectos típicos y fallas a ser encontradas Herramientas a utilizar

8. Pruebas de componentes Busca defectos Verifica la funcionalidad Módulos, programas, objetos, clases Puede ser realizado aislado del resto del sistema según el contexto del desarrollo del ciclo de vida Puede probar requerimientos funcionales o no funcionales Los casos de prueba derivan de Especificación de componentes Arquitectura Modelo de datos

9. Pruebas de componentes Se realiza accediendo al código a ser probado en el ambiente de desarrollo Compilador Involucrando al programador Los defectos se corrigen tan pronto como son encontrados No es necesario el registro formal de incidentes Preparar y automatizar casos de prueba antes de la codificación

10. Pruebas de integración Prueba la interfase entre componentes Interacciones con diferentes partes del sistema S.O. Sistema de archivo Hardware Interfases entre sistemas En cada escenario de la integración, los probadores se concentran en al integración misma. Si se prueba el módulo A contra el módulo B, están interesados en probar la comunicación entre los módulos, no la funcionalidad de cada uno de ellos.

11. Pruebas de Sistema Son concernientes al comportamiento del sistema/producto entero definido por el ámbito del proyecto de desarrollo o programa. El ambiente del sistema debe corresponder al objetivo final de producción Minimiza el riesgo de fallas de ambiente Incluye pruebas basadas en: El riesgo o especificación de requerimientos Procesos de negocio Comportamiento del sistema Interacciones con el sistema operativo Recursos del sistema Debe probar los requerimientos funcionales y no funcionales

12. Pruebas Enfoques de las pruebas Pruebas de desarrollo: causar tantas fallas como sea posible para que los defectos de software puedan ser detectados y corregidos Pruebas de aceptación: confirmar que el sistema funciona en base a lo esperado, para asegurarse que cumple los requisitos. Pruebas de mantenimiento: probar que no han sido introducidos nuevos defectos al código durante el desarrollo de cambios. Pruebas operacionales: asegurar las características del sistema como disponibilidad y confiabilidad.

13. Pruebas de aceptación Comúnmente es responsabilidad de los usuario del sistema Establece la confiabilidad del sistema Encontrar defectos no es el principal enfoque Debe asegurarse de que el sistema esta preparado para la implementación y uso Pruebas de aceptación del usuario Verifica comúnmente las condiciones de uso del sistema por los usuarios del negocio

14. Pruebas de aceptación Pruebas de aceptación operacional Pruebas de restauración/respaldo Recuperación de fallas Administración de usuarios Tareas de mantenimiento Pruebas de aceptación contractual Prueba el desempeño de cualquier regulación que dba ser incluida: legal, gobierno, seguridad

15. 7 principios de las pruebas Principio 1: Las pruebas muestran la presencia de defectos. Las pruebas pueden mostrar que los defectos están presentes, pero no pueden probar que no son defectos. Las pruebas reducen la probabilidad de mantener defectos ocultos en el software pero, si no se encuentran defectos, no es una prueba de que este correcto.

16. 7 principios de las pruebas Principio 2: las pruebas exhaustivas son imposibles. Probar todo (todas las combinaciones de entradas y precondiciones) no es viable excepto para casos excepcionales. En lugar de pruebas exhaustivas, el análisis de riesgo y prioridades debería ser usado para enfocar las pruebas.

17. 7 principios de las pruebas Principio 3: Pruebas tempranas. Las actividades relacionadas a las pruebas, deben iniciar tan temprano como sea posible en el ciclo de vida de desarrollo de software, y debe enfocarse en objetivos definidos. Principio 4: Agrupación de defectos. Un pequeño número de módulos contienen la mayor parte de los defectos encontrados durante la preliberación de pruebas, o es responsable de la mayor parte de las fallas operacionales.

18. 7 principios de las pruebas Principio 5: Paradoja del pesticida. Si las mismas pruebas son repetidas una y otra vez, ese conjunto de casos de prueba no encontrará más defectos. Para evitar la paradoja del pesticida, los casos de prueba necesitan ser revisados regularmente, deben escribirse nuevos casos de prueba para probar diferentes partes del software o sistema para potenciar el hallazgo de nuevos errores.

19. 7 principios de las pruebas Principio 6: Las pruebas son dependientes del contexto. Las pruebas son diferentes en diferentes conceptos. Po ejemplo, el software crítico para un banco es probado diferente a un sitio de comercio electrónico. Principio 7: La falacia de la ausencia de errores. Encontrar y reparar defectos no ayuda si la construcción del sistema es inoperable y no satisface las necesidades y expectativas del cliente.

20. Psicología de las pruebas Con el modo de pensar correcto los desarrolladores son capaces de probar su propio código, pero la separación de esta tarea a un probador enfoca el esfuerzo y provee beneficios adicionales.

21. Psicología de las pruebas Un cierto grado de independencia es más efectivo al encontrar defectos y fallas: Pruebas diseñadas por la persona que escribió el código bajo prueba (bajo nivel de independencia) Pruebas diseñadas por otras personas Pruebas diseñadas por personas ajenas a la organización Pruebas diseñadas por personas de diferente compañía u organización.

22. Psicología de las pruebas La búsqueda de fallas en un sistema requiere curiosidad, pesimismo profesional, ojo crítico, atención a los detalles, buena comunicación con los desarrolladores. Si los errores, defectos o fallas son comunicados de una manera constructiva, los malos entendidos entre probadores y analistas, diseñadores y desarrolladores pueden ser reducidos.

23. 1 Conceptosgenerales de pruebas Agenda 2 Diseño de casos de prueba

24. ¿Qué es un caso de Prueba? El estándar IEEE 610 (1990) define un caso de prueba como: Un conjunto de entradas de prueba, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular. El (IEEE Std 829-1983) especifica que es Documento que especifica entradas, resultados previstos y un conjunto de condiciones de ejecución para un elemento de prueba Un caso de prueba es un conjunto de pasos específicos que tiene resultados junto con varias piezas de información adicionales 1 de 1

25. ¿Qué es un caso de Prueba? Un caso de prueba es un documento que describe una entrada, acción o evento y tiene una respuesta esperada para determinar si una característica de una aplicación funciona correctamente Un caso de prueba debe contener algunos datos: Identificador Nombre del caso de prueba Objetivo Precondiciones Datos de entrada del requerimiento Pasos a seguir Resultados esperados 1 de 1

26. ¿Qué es un caso de Prueba? Hay que notar que el proceso de desarrollo de casos de prueba puede ayudar a encontrar problemas en los requerimientos o diseño de una aplicación ya que requiere por completo el pensar a través de la operación de la aplicación Por esta razón es muy útil preparar los casos de prueba lo más temprano posible en el ciclo de vida del software en caso de ser posible 1 de 1

27. ¿Qué es un caso de prueba? Los casos de prueba pueden ser de dos tipos: Casos de prueba positivos Casos de prueba negativos

28. Objetivos del diseño de Casos de Prueba Detectar la mayor cantidad de defectos posible Buena cobertura (no quede algo sin probar) Minimizar los costos del desarrollo de pruebas Minimizar los costos de la ejecución de pruebas Minimizar los costos del mantenimiento de pruebas

29. Desarrollo de pruebas Una buena prueba debe tener una alta probabilidad de encontrar un defecto El responsable de la prueba debe entender el software e intentar desarrollar una imagen mental de cómo podría fallar Una buena prueba se centra en: Probar si el software no hace lo que debe hacer Probar si el software hace lo que no debe hacer

30. Desarrollo de pruebas Una buen prueba debe ser la mejor de todas Se debería emplear la prueba que tenga la más alta probabilidad de descubrir una clase entera de errores. Una buena prueba no debe ser ni muy sencilla ni muy compleja Combinar varias pruebas a la vez puede enmascarar errores. Cada prueba debe hacerse por separado.

31. Orígenes

32. Casos de prueba de requerimientos Pasos para seleccionar casos de prueba Identificar los casos básicos que indiquen la funcionalidad del programa Crear un conjunto básico de pruebas que cubran las entradas y salidas Separar los casos complejos en casos más simples Remover casos duplicados o innecesarios Revisar sistemática y profundamente

33. Casos de prueba en los extremos Buscan condiciones excepcionales, límites, fronteras y anormalidades Se necesita: Experiencia Creatividad del ingeniero de pruebas

34. Casos de prueba aleatorios y extraídos Los casos de prueba extraídos involucran ejemplos extraídos de datos reales para el proceso de pruebas Los casos de prueba aleatorios involucran el uso de herramientas para generar datos potenciales para el proceso de pruebas

35. Métodos para el diseño de casos de prueba Partición de equivalencia Análisis de valores límite Adivinación de errores Diagrama de causa-efecto

36. Partición de equivalencia Dominio de la entrada Una clase de equivalencia es un subconjunto de datos que es representativo de una clase más grande Se divide el dominio de la entrada dentro clases de equivalencia Se intenta cubrir clases de errores Un caso de prueba por cada clase de equivalencia para reducir el número total de casos de prueba necesarios

37. Ejemplo Un programa que autoriza créditos limita en base a u rango dado: $10,000 a $15,000 Existen tres clases de equivalencia: Menor a $10,000 (Inválido) Entre $10,000 y $15,000 (Válido) Mayor a $15,000 (Inválido)

38. Partición de equivalencia $9,800 $18,000 $12,500

39. Ejercicio El módulo de captura de contrarecibo tiene establecido que para subir un archivo adjunto, el tamaño de dicho archivo no debe ser mayor a 4Mb. Encuentre la partición de equivalencia para esta función El módulo de Factura Electrónica obtiene el R.F.C. de un cliente. Para personas físicas es de 13 posiciones mientras que para una persona moral es de 12. realice la partición de equivalencia para ambos casos.

40. Análisis de valores límite Esta técnica consiste en desarrollar casos de prueba y datos enfocados en las entradas y salidas límite de una función dada Complementan la partición de equivalencia seleccionando los casos de prueba en el filo de las clases de equivalencia En la práctica, la mayor parte de los errores se encuentran en los límites de las clases de equivalencia que en la misma clase Se divide el dominio de entrada dentro de clases de equivalencia

41. Análisis de valores límite Valores válidos Valores válidos

42. Ejemplo En el mismo ejemplo del límite de crédito el análisis de límites sería: Límite inferior más ó menos 1 $9,999 y 10,001 En el límite $10,000 y $15,000 Por encima del límite más ó menos 1 $14,999 y %15,001

43. Rango de valores límite Un valor inmediatamente por debajo del rango Primer valor del rango Segundo valor del rango Valor inmediatamente por debajo del último valor del rango Último valor del rango Valor inmediatamente por encima del rango

44. Adivinación de errores En base a la teoría de que los casos de prueba pueden ser desarrollados basados en la intuición y experiencia del ingeniero de pruebas

45. Ejemplo. En un sistema donde en una de sus funciones debe ingresar una fecha: El ingeniero de prueba puede introducir 29/02/2000 09/09/9999

46. Diagrama de causa efecto Ofrece una descripción de condiciones lógicas y acciones asociadas 4 etapas Las causas (condiciones de entrada) y efectos (acciones) son listadas para un módulo y un identificador es asociado a cada una Se crea una gráfica de causa-efecto La gráfica se convierte en una tabla de decisión La tabla de decisión se convierte en casos de prueba

47. Diagrama de causa efecto Ofrece una descripción de condiciones lógicas y acciones asociadas 4 etapas Las causas (condiciones de entrada) y efectos (acciones) son listadas para un módulo y un identificador es asociado a cada una Se crea una gráfica de causa-efecto La gráfica se convierte en una tabla de decisión La tabla de decisión se convierte en casos de prueba

48. Ejemplo Se tiene un requerimiento donde se prueba la condición siguiente: If A or B then C Las siguientes reglas cumplen este requerimiento: Si A esverdadero y B esverdadero , entonces C esverdadero . If A esverdadero y B esfalso, entonces C esverdadero . If A esfalso y B esverdadero , entonces C esverdadero . If A esfalso y B esfalso, entonces C esfalso.

49. Ejemplo A,B y C son llamados nodos A y B son las causas y C el efecto. Las líneas son llamadas vectores Todos los requerimientos se trasladan a nodos y relaciones Solo hay 4 posibles relaciones A ----- C A ____VC A ____ ^C A_____~C

50. Ejemplo La gráfica de causa y efecto se convierte en una tabla de verdad que representa cada relación lógica entre las causas y lso efectos Cada columna representa un caso de prueba y cada caso de prueba corresponde a una única posible combinación

51. Ejemplo Solo hay 3 casos de prueba, sin embargo cubren el 100% de la funcionalidad. Colocar A y B T redundaría.

52. Buenas prácticas del diseño de casos de prueba Desarrollar al menos dos casos de prueba por cada requerimiento a probar. Un caso de prueba para demostrar que un requerimiento ha sido implementado, se conoce como Caso de Prueba Positivo Otro caso que refleje una anormalidad, condición o datos faltantes para demostrar que el requerimiento se cumple solo bajo las condiciones deseadas, se llama Caso de Prueba Negativo

53. Formato del caso de Prueba

54. Formato del caso de Prueba (casos aprobados *100)/CP a evaluar

55. Perfeccionando las pruebas - Conceptos Testability Fácil de probar Escribir en modo activo: Hacer esto, hacer lo otro El sistema muestra esto, hace esto otro Usar lenguaje simple y conversacional Exactitud, nombres de campos consistentes y no genéricos No explicar las funciones básicas de Windows Ir al menú inicio… Ir al menú archivo/Seleccionar… Abrir en con el botón inicio/todos los programas/Internet explorer De 10 a 15 pasos o menos para describir casos de prueba Siempre actualizar los casos de uso