Calidad de Software Conferencia # 7 Calidad de software.

Presentación del tema: "Calidad de Software Conferencia # 7 Calidad de software."— Transcripción de la presentación:

1 Calidad de Software Conferencia # 7 Calidad de software

2 Objetivos Entender el concepto de calidad
Conocer la importancia de la calidad del producto y la calidad del proceso. Conocer los niveles y métodos de prueba. Conocer cómo diseñar un caso de prueba. Conocer el proceso de prueba definido en el laboratorio de pruebas del CITI.

3 Bibliografía Pressman, R. Ingeniería de Software. Un enfoque práctico.
Mary Beth Chrissis, Mike Konrad and Sandy Shrum CMMI® Guía para la integración de procesos y la mejora de productos. Segunda edición. Área de proceso: Aseguramiento de la calidad del proceso y el producto. PMBOK. Edición Capítulo 8: Gestión de la Calidad del proyecto

4 ¿Qué es Calidad? Diccionario de la Real Academia Española:
Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor, Condición o requisito que se pone en un contrato.

5 ¿Qué es Calidad? Grado en que un conjunto de características inherentes satisfacen los requerimientos (necesidades o expectativas). (ISO 9000:2000)

6 ¿Qué es Calidad? Habilidad de un conjunto de características inherentes de un producto, componente de un producto o proceso, para satisfacer los requerimientos de los clientes. (CMMI-DEV v1.2)

7 ¿Qué es Calidad? Grado en que un sistema, componente o proceso cumple las necesidades o expectativas de clientes y usuarios. (IEEE 1991)

8 ¿Qué es Calidad de software?
Cumplimiento de los requerimientos de funcionalidad y de desempeño establecidos explícitamente; normas de desarrollo documentadas explícitamente y características implícitas que son esperadas en todos los programas desarrollados profesionalmente. (Pressman)

9 Inversión en la Calidad
Menos defectos. Mejor situación económica. Mejores productos. Aumento del bienestar. Clientes satisfechos y mejor imagen. 9 9

10 Cuando no hay un proceso para asegurar la calidad
No se sabe qué procesos se siguen en la organización. No se sabe si se respetan los estándares definidos. Los mismos productos se entregan con niveles diferentes de calidad. Se paga un alto costo financiero y de posicionamiento en el mercado por la falta de calidad. 10

11 Costo de la Calidad Prevenir el incumplimiento de los requisitos
Evaluar la conformidad del producto o servicios con los requisitos Constatados por el equipo de proyecto Constatados por el cliente 11 11

12 Área del conocimiento de Gestión de la Calidad
de PMBOK Planificar la Calidad: Es el proceso por el cual se identifican los requisitos de calidad y/o normas para el proyecto y el producto, documentando la manera en que el proyecto demostrará el cumplimiento con los mismos. Realizar el Aseguramiento de Calidad: Es el proceso que consiste en auditar los requisitos de calidad y los resultados de las medidas de control de calidad, para asegurar que se utilicen las normas de calidad apropiadas y las definiciones operacionales. Realizar el Control de Calidad: Es el proceso por el que se monitorean y registran los resultados de la ejecución de actividades de control de calidad, a fin de evaluar el desempeño y recomendar cambios necesarios.

13 Elementos que dan relevancia a la Gestión de la Calidad dentro de la Gestión del proyecto
• La satisfacción del cliente. Entender, evaluar, definir y gestionar las expectativas, de modo que se cumplan los requisitos del cliente. • La prevención antes que la inspección. Uno de los preceptos fundamentales de la gestión moderna de la calidad establece que la calidad se planifica, se diseña y se integra (y no se inspecciona). Por lo general, el costo de prevenir errores es mucho menor que el de corregirlos cuando son detectados por una inspección. • La mejora continua. El ciclo planificar-hacer-revisar-actuar es la base para la mejora de la calidad. • La responsabilidad de la dirección. El éxito requiere la participación de todos los miembros del equipo del proyecto, pero proporcionar los recursos necesarios para lograr dicho éxito sigue siendo responsabilidad de la dirección.

14 Pruebas La prueba es un proceso de ejecución de un programa con la intención de descubrir errores. Una buena prueba es aquella que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene éxito si descubre un error no detectado hasta entonces.

15 Elementos de éxito en pruebas
Existe una dependencia jerárquica entre estos conceptos, por lo que vamos a comenzar a estudiar primero los métodos hasta la estrategia. Estrategia de Prueba Niveles de Prueba Método de Prueba Tipo de Prueba Caso de Prueba

16 Niveles de Prueba La Prueba es aplicada para diferentes tipos de objetivos, en diferentes escenarios o niveles de trabajo. Se distinguen los siguientes niveles de pruebas: Prueba modular: Consiste en la prueba de cada módulo aislado del resto del sistema. Prueba de Integración: Se realiza a medida que los diferentes módulos se integran en el mismo. Prueba de sistema: Su objetivo es comprobar que el sistema satisface los requisitos (funcionales y no funcionales) del usuario. Prueba de aceptación: Se realiza cuando el sistema es implantado en el entorno real de funcionamiento. Su objetivo es demostrar al usuario que el sistema satisface sus necesidades. Duda Cuando se hable de pru eba de unidad no se puede olvidar que para los sistemas orientados a objetos lo primero a probar es la clase 16

17 Métodos de Prueba Pruebas de caja negra: Pruebas que se llevan a cabo sobre la interfaz del software. El objetivo es demostrar que las funciones del software son operativas, que las entradas se aceptan de forma adecuada y se produce un resultado correcto, y que la integridad de la información externa se mantiene (no se ve el código). Pruebas de caja blanca: Se comprueban los caminos lógicos del software. Se puede examinar el estado del programa en varios puntos para determinar si el estado real coincide con el esperado.(sobre el código)

18 Pruebas de caja negra Prueba de caja negra se refiere a las pruebas que se llevan a cabo sobre la interfaz del software. O sea, los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce un resultado correcto, así como que la integridad de la información externa (por ejemplo, archivos de datos) se mantiene. Una prueba de caja negra examina algunos aspectos del modelo fundamental del sistema sin tener mucho en cuenta la estructura lógica interna del software.

19 Pruebas de caja negra Se centran principalmente en los requisitos funcionales del software. Permiten encontrar: Funciones incorrectas o ausentes. Errores de interfaz. Errores en estructuras de datos o en accesos a las Bases de Datos externas. Errores de rendimiento. Errores de inicialización y terminación.

20 Pruebas de caja blanca La prueba de caja blanca del software se basa en el minucioso examen de los detalles procedimentales. Se comprueban los caminos lógicos del software proponiendo casos de prueba que ejerciten conjuntos específicos de condiciones y/o bucles. Se puede examinar el «estado del programa» en varios puntos para determinar si el estado real coincide con el esperado o mencionado. Las pruebas de caja blanca son diseñadas después de que exista un diseño de componente (o código fuente). El detalle de la lógica del programa debe estar disponible.

21 Tipos de Prueba Cada tipo de prueba tiene un objetivo específico y una técnica que lo soporte. Dimensión Tipo de Prueba Funcionalidad Función, Seguridad, Volumen Usabilidad Fiabilidad Integridad, Estructura, Stress Rendimiento Contención, Carga, Profile Soportabilidad Configuración, Instalación 21

22 Requisitos y Caso de Uso como base para el Caso de Prueba
Un caso de uso "describe completamente una secuencia de las acciones realizadas por un sistema para proporcionar un resultado observable del valor a una persona o a otro sistema usando el producto bajo desarrollo." Crear software de alta calidad en una manera sistemático, controlada y eficiente. Enfatizando análisis y evaluación, especificación, diseño y evolución de software. Además administración y callidad novedad y creatividad, standard, habilidades individuales y en equipo y practica profesional etc. Los casos del uso dicen al cliente qué esperar, al programador cuál es el código, al escritor técnico qué es el documento, y al probador qué es la prueba. 22

23 Caso de prueba Conjunto de entradas de pruebas, condiciones de ejecución y resultados esperados desarrollados para cumplir un objetivo en particular o una función esperada. Siempre es ejecutada como una unidad, desde el comienzo hasta el final. Debe verificar: Si el producto satisface los requerimientos del usuario, tal y como se describe en las especificación de los requerimientos. Si el producto se comporta como se desea, tal y como se describe en las especificaciones funcionales del diseño.

24 Descripción de CU La parte más importante de un caso del uso para generar los casos de prueba es: El flujo de eventos. Las dos partes principales del flujo de eventos son el flujo básico de eventos y los flujos alternativos de eventos. El flujo básico de eventos debe cubrir lo que sucede "normalmente" cuando se realiza el caso de uso. Los flujos alternativos de eventos cubren el comportamiento de una opción o excepción relativa al comportamiento normal, además de variaciones de este. Se puede pensar en los flujos alternativos como "desvíos" del flujo básico de eventos.

25 Ejemplo

26 Ejemplo

27 Ejemplo

28 Escenarios en un CU Un escenario de un caso de uso es un "camino" completo a través del caso de uso. Los usuarios finales del sistema pueden seguir muchos caminos cuando ejecutan la funcionalidad especificada en el caso de uso. Siguiendo el flujo básico serían un escenario. Siguiendo el flujo básico más el alternante flujo 1A sería otro. El flujo básico más el alternante flujo 2A sería un tercero, y así sucesivamente.

29 Escenarios Sección “Registrar Libro”

30 Matriz de Casos de prueba
La tabla q hay q hacer 30

31 Identificar Valores de Datos
Una vez que todos los casos de prueba se han identificado, todos ellos deben repasarse y validarse para asegurar exactitud e identificar los casos de prueba redundantes o que faltan. Entonces, una vez que sean aprobados, el paso final es sustituir los valores reales de los datos para las I’s y V’s. La tabla 31

32 Matriz de CP

33 Proceso de prueba definido en el CITI

34 Rol: Jefe Laboratorio de Prueba
Descripción: Es el encargado de velar porque todas las tareas que se ejecuten en el Laboratorio de pruebas, se lleven a cabo de la manera más eficiente posible, aprovechando el tiempo y los recursos disponibles. Todo el tiempo debe velar porque el proceso de pruebas en el laboratorio se realice basado en las políticas de calidad, definidas en la organización. Responsabilidades: Revisar las solicitudes de prueba. Revisar el Plan de Pruebas. Asignar el especialista encargado de la prueba. Supervisar el montaje del entorno para la ejecución de las pruebas. Supervisar la realización de las pruebas exploratorias. Comunicar los resultados de todas las pruebas a la Alta Gerencia.

35 Rol: Especialista de calidad
Descripción: Es el máximo responsable de la prueba que le ha sido asignada. Debe garantizar la gestión de los recursos necesarios para llevar a cabo la misma y resolver los problemas que puedan presentarse durante su ejecución. Responsabilidades: Elaborar el Plan de Pruebas. Revisar los Casos de Prueba definidos en el proyecto. Revisar y unificar las NC detectadas durante la realización de la prueba (si existe más de un probador). Montar el entorno para la ejecución de las pruebas. Realizar las pruebas exploratorias. Supervisar el registro y gestión de las NC detectadas. Comunicar los resultados de las pruebas al equipo de proyecto.

36 Rol: Representante del proyecto
Descripción: Es el encargado de mediar entre el equipo de proyecto y el equipo de pruebas. Responsabilidades: Realizar la solicitud de prueba. Proveer toda la documentación del proyecto que sea necesaria para la realización de la prueba. Garantizar que se dé respuesta a las NC detectadas. Montar el entorno para la ejecución de las pruebas.

37 Ejecutar los Casos de Prueba definidos en el equipo de proyecto.
Rol: Probador Descripción: Es el encargado de probar la aplicación y de realizar un levantamiento de NC de la manera más clara, concisa e íntegra posible. Responsabilidades: Ejecutar los Casos de Prueba definidos en el equipo de proyecto. Registrar las NC detectadas durante la prueba en el formato definido para ello. Montar el entorno para la ejecución de las pruebas.

38

39 Documento de arquitectura
Manual de instalación Manual de usuario Rol: Jefe de proyecto

40 Rol: Jefe Laboratorio de Prueba

41 Rol: Jefe Laboratorio de Prueba, Especialista de calidad

42 Rol: Especialista de calidad, Probador, representante del proyecto

43 Rol: Probador

44 Rol: Probador

45 Rol: Especialista de Calidad

46 Rol: Jefe Laboratorio de Prueba, Especialista de calidad, Probador,
Representante del proyecto

47 Conclusiones El objetivo de las pruebas de software es descubrir errores. Es necesario planificar las pruebas, definiendo la estrategia a seguir en cada una de ellas.

48 Conclusiones Un buen diseño de un caso de prueba de caja negra depende de la información que brinde el caso de uso o requisito. Apenas se cuente con la descripción de un caso de uso se puede comenzar a diseñar los casos de pruebas que lo validan.