Temario VI Gestión de Testing

Documentos relacionados
Capítulo 3. Áreas de Proceso

CMM - Capability Maturity Model. Estructura de CMM... Componentes de CMM. Estructura de CMM

CMMI (Capability Maturity Model Integrated)

SW-CMM Capability Maturity Model for Software

Planeación del Proyecto de Software:

Elementos requeridos para crearlos (ejemplo: el compilador)

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE

El Modelo CMMI (for Development) Monterrey, N.L. México Noviembre 2008

Calidad de Software - CMM

CMMI : mejora del proceso en Fábricas de Software

Gestión y Desarrollo de Requisitos en Proyectos Software

Resumen General del Manual de Organización y Funciones

Prof. Juan José Díaz Nerio. Foro de Tecnología : Gestión de la Calidad del Software. Domingo 16 Noviembre 2014

Capítulo 2 Ideas generales de CMMI-SW. 2.1 Introducción. 2.2 Procesos. 2.3 Modelo de procesos

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008

Gestión del Servicio de Tecnología de la información

UN RECORRIDO POR LA FAMILIA ISO

Diferencias entre nivel 2 y nivel 3 y una estrategia de implantación

Empresa Financiera Herramientas de SW Servicios

ISO 9000 Escuela de Ingeniería de Sistemas y Computación Desarrol o de Software II Agosto Diciembre 2007

Plan de estudios ISTQB: Nivel Fundamentos

Ingeniería de Software. Pruebas

COMITÉ TECNICO DE NORMALIZACION DE GESTION Y ASEGURAMIENTO DE LA CALIDAD

CMMI SERVICIOS. María Smith Gutiérrez Rueda - Quality Assurance Officer y Líder del Grupo de Ingeniería de Procesos (EPG) de Aranda Software

1.1 Aseguramiento de la calidad del software

CALIDAD DEL SOFTWARE TESTS DE EXAMEN ACTUALIZADO SEP TEMA 3 NORMALIZACIÓN Y CERTIFICACIÓN: NORMA ISO 9001:2000

GUIA SOBRE LOS REQUISITOS DE LA DOCUMENTACION DE ISO 9000:2000

CAPÍTULO 4. FORMA DE EVALUACIÓN CMM. 4.1 Evolución de los métodos de valoración del SEI

RUP: Disciplina de Manejo de Cambios y Configuraciones

ARQUITECTURA TÉCNICA ASIGNATURA: MATERIALES DE CONSTRUCCIÓN II CURSO: APUNTES TEMA 1: CONTROL DE CALIDAD

Modelo de Proceso de Desarrollo de Software

Temario. Calidad de software y Procesos. Éxito de un proyecto de software. 1- Calidad de software. Evolución de la calidad

Capability Maturity Model Integration CMMI - Overview I

Curso TURGALICIA SISTEMA DE GESTIÓN DE SEGURIDAD Y SALUD EN EL TRABAJO OHSAS 18001:2.007

COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a

LISTA DE CHEQUEO NORMA NTC ISO 9001:2000 No. REQUISITOS EXISTE ESTADO OBSERVACIONES D: Documentado I: Implementado M: Mejorar SI NO D I M

Qué es el Modelo CMMI?

CAPÍTULO 2. MODELOS Y ESTÁNDARES DE CALIDAD DE SOFTWARE

Alcanzando la gestión cuantitativa en la gestión de proyectos en el ámbito de las PYMEs

Procesos Críticos en el Desarrollo de Software

Los procesos de software. Un proceso de software se define como un:

Norma ISO Francisco D Angelo Douglas García Claudia Herrera Luis Laviosa

Administración de Centros de Computo. ITIL. MSG.ING. DARWIN CERCADO B dcercado@primma.com.ec

ASIS Technology Partners. 1

Metodología básica de gestión de proyectos. Octubre de 2003

-OPS/CEPIS/01.61(AIRE) Original: español Página Estructura del programa de evaluación con personal externo

Procedimiento de gestión de auditorias internas de calidad

Recursos HELP DESK Biblioteca 2012

Enginyeria del Software III

LEY QUE NORMA EL USO, ADQUISICIÓN Y ADECUACIÓN DEL SOFTWARE EN LA ADMINISTRACIÓN PUBLICA

CALIDAD DEL SOFTWARE TESTS DE EXAMEN ACTUALIZADO SEP TEMA 4 MODELOS, METODOLOGÍAS Y ESTÁNDARES: ESTRATEGIAS PARA ALCANZAR LA CALIDAD

Términos definiciones

Mantenimiento de Sistemas de Información

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Mantenimiento del Software

TECNOLOGICO DE ESTUDIOS SUPERIORES DE ECATEPEC CALIDAD DE SOFTWARE Guía para Examen Segundo Parcial Grupo 6501

Sistemas de Gestión de Calidad. Control documental

Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización.

Plan de Gestión de Configuración. Universidad Nacional de la Patagonia Austral

ITIL FOUNDATION V3 2011

Curso. Introducción a la Administracion de Proyectos

Gestión de la configuración en el software (SCM) Ingeniería de software Eduardo Ferreira, Martín Solari

Programa de Desarrollo Profesional en Mejora del Proceso de Software

SISTEMAS Y MANUALES DE LA CALIDAD

Relación de ITIL con los procesos de aseguramiento de la Calidad del Software.

Sistema de Gestión de la Seguridad de la Información, UNE-ISO/IEC 27001

SOLICITUD DE DESARROLLO Y ACTUALIZACIÓN DE APLICACIONES G OBIERNO D E L A CIUDAD DE BUENOS AIRES

RICARDO REYES TAVARA. Avance de los Cambios de la Norma ISO 9001:2015 Apuntes de clase : Fuente LRQA

Capítulo 4. GESTIÓN DE LA INTEGRACIÓN DEL PROYECTO

P.S.P. Programa Educativo. Tecnologías de la Información y Comunicación. Alumno. José Alfredo Ramírez Jaguey

Dirección General de Educación Superior Tecnológica

2. EL MODELO CMMI. En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de

CMMI Capability Maturity Model Integration Modelo integrado de madurez de la capacidad

Gestión de la Configuración

Actualización de la Norma ISO 9001:2008

Gestión de Configuración del Software

Ejemplo Manual de la Calidad

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

Propuesta Matriz de Actividades para un Ciclo de Vida de Explotación de Datos

Mejora de procesos desde el ámbito de la innovación. Santiago, 20 de agosto 2014

Operación 8 Claves para la ISO

GLOSARIO DE TERMINOLOGIA SOBRE SISTEMAS DE GESTIÓN DE LA CALIDAD

ISO 9000:2000. Roberto Aprili Justiniano Rodrigo Ramírez Pérez. Roberto Aprili, Rodrigo Ramírez

Hospital Nacional de Maternidad UNIDAD DE INFORMATICA

CUESTIONARIO AUDITORIAS ISO

FÁBRICA DE SOFTWARE. Presentado por: Ing. Juan José Montero Román Gerente de Fábrica de Software USMP

Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A.

Actividades para mejoras. Actividades donde se evalúa constantemente todo el proceso del proyecto para evitar errores y eficientar los procesos.

cumple y hay evidencias objetivas

CONTROL DE CAMBIOS. FICHA CONTROL DE CAMBIOS Versión Fecha Descripción de la Modificación

Sistemas de gestión de la calidad Requisitos

Marco Normativo de IT

ISO 9001:2015 Comprender los cambios clave. Lorri Hunt

La tabla muestra de manera resumida los requerimientos esperados en un proceso de capacitación. Somos su Relevo a la Calidad

ISO 9001 Auditing Practices Group Guidance on:

Introducción. Por lo que existe una creciente preocupación por lograr que los productos software cumplan con ciertos criterios de calidad.

Modelos y Normas Disponibles de Implementar

Examen de Fundamentos de ITIL

Transcripción:

Temario VI Gestión de Testing Topicos Avanzados en Pruebas de Software UNS 1 Gestión de Testing Lectura Sommerville I., 2000. Software Engineering, 7th Edition. Addison Wesley. Patton. Software Testing. SAMS. July 2005. Craig and Jaskiel. Systematic Software Testing. Artech House Publishers.March, 2005. Kaner, Kalk and Nguyen. Testing Computer Software. Wiley Computer Publishing.1999. Reportes Técnicos ISO/IEC JTC1/SC7: ISO 9126 http://www.sei.cmu.edu Reportes Técnicos: CMU/SEI 93 TR 024, CMU/SEI 93 TR 025 Jenner Software Quality Management and ISO 9001 John Wiley & Sons, 1995 Topicos Avanzados en Pruebas de Software UNS 2

Planificación del Test (Test Planning) (1) Determinar el alcance, enfoque, y programación de las actividades de testing Identificar las características a ser verificadas Las tareas de testing que serán realizadas El personal responsable para cada tarea Los riesgos asociados con el plan Topicos Avanzados en Pruebas de Software UNS 3 Planificación del Test (2) Debe iniciarse al comienzo y seguir en paralelo al desarrollo del software Información del Proyecto Información del Software Desarrollar Plan de Pruebas Maestro Desarrollar Planes de Pruebas Detallados Plan Maestro Recursos Planes Detallados Recursos específicos Topicos Avanzados en Pruebas de Software UNS 4

Planificación del Test (3) Desarrollo Testing Requerimientos Aceptación Diseño Preliminar Sistema Diseño Detallado Integración Codificación Unidad El test del sistema debe ser construido en base al Diseño Arquitectónico y Requerimientos Topicos Avanzados en Pruebas de Software UNS 5 Planificación del Test (4) El objetivo principal es comunicar al equipo encargado del testing: Sus intenciones Sus expectativas Su entendimiento del testing que será realizado El resultado final será un documento de alguna clase Topicos Avanzados en Pruebas de Software UNS 6

Planificación del Test (5) Nada se puede dejar como asumido Aspectos a tener en cuenta para realizar el plan: Expectativas de Alto Nivel Determinar el propósito del proceso de planificación del test y del plan del test Programadores Técnicos Gerentes Topicos Avanzados en Pruebas de Software UNS 7 Planificación del Test (6) Aspectos a tener en cuenta para realizar el plan: Expectativas de Alto Nivel Qué producto se esta verificando? Debe haber un entendimiento de qué es el producto, su magnitud y su alcance Empezamos con la especificación Topicos Avanzados en Pruebas de Software UNS 8

Planificación del Test (7) Aspectos a tener en cuenta para realizar el plan: Expectativas de Alto Nivel Cuáles son las metas de calidad y confiabilidad del producto? No debe tener ningún bug Necesita la última tecnología Debe ser lo más rápido posible Topicos Avanzados en Pruebas de Software UNS 9 Planificación del Test (8) Aspectos a tener en cuenta para realizar el plan: Personas, Lugares y Cosas, Lugares y Cosas Se debe incluir toda la información necesaria para cada miembro del equipo (nombre,te, mail, dirección, título, responsabilidad) Dónde están almacenados los documentos, de dónde se puede bajar el software, dónde están las herramientas de test, etc. Qué hardware utiliza el sistema y de dónde lo puedo obtener. Si hay laboratorios para realizar testing de configuración, dónde están? Topicos Avanzados en Pruebas de Software UNS 10

Planificación del Test (9) Aspectos a tener en cuenta para realizar el plan: Definiciones Qué es un bug? El software no hace algo que la especificación del producto dice que debería El software hace algo que la especificación del producto dice que no debería El software hace algo que la especificación del producto no menciona El software no hace algo que la especificación del producto no menciona pero debería Topicos Avanzados en Pruebas de Software UNS 11 Planificación del Test (10) Aspectos a tener en cuenta para realizar el plan: Definiciones Todas las palabras y términos se deben definir Si existen diferentes definiciones, se debe llegar a un consenso Por ejemplo, se define bug, alpha release, beta release, etc Dependerá del tipo del proyecto, el modelo de desarrollo, el nivel de experiencia Deberán ser específico y precisas Topicos Avanzados en Pruebas de Software UNS 12

Planificación del Test (11) Aspectos a tener en cuenta para realizar el plan: Responsabilidades Inter Grupo Obviamente el programador programa, el testeador realiza las pruebas Se deben definir las actividades en forma detallada Indicar tarea y quiénes la realizarán Así las responsabilidades están bien separadas y cada sabe lo que debe hacer Topicos Avanzados en Pruebas de Software UNS 13 Planificación del Test (12) Tareas Programadores Testers Gerentes Esc. Técnicos Marketing Soporte de Prod Crear una lista de componentes del producto X Planificación del Proyecto X Diseñar y codificar el producto X Realizar el testing de unidad X Realizar el plan de test X Revisar el material impreso X Definir version demo X Definir el programa beta X Topicos Avanzados en Pruebas de Software UNS 14

Planificación del Test (13) Aspectos a tener en cuenta para realizar el plan: Qué deber verificarse y qué no Aquellos componentes ya testeados en previas entregas (releases) Se deben identificar componentes a ser testeados y componentes no testeados Si el componente no será verificado, indicar razones por las cuales no se hará (no porque no lo entiendan) Topicos Avanzados en Pruebas de Software UNS 15 Planificación del Test (14) Aspectos a tener en cuenta para realizar el plan: Fases del Test y Estrategias Según el modelo de desarrollo (code and fix, espiral) Indicar cada una de las fases junto con la estrategia a utilizar en cada una de ellas. Por ejemplo, caja negra, caja blanca, integración bottom up, etc. Se requieren testeadores experimentados Topicos Avanzados en Pruebas de Software UNS 16

Planificación del Test (15) Aspectos a tener en cuenta para realizar el plan: Requerimientos de Recursos Personal: full time, part time, experiencia, cantidad Equipamiento: computadoras, hardware, etc. Espacio de oficinas y laboratorios Software: BD s, procesadores de texto, qué debe comprarse? Accesorios: teléfonos, discos, libros, etc. Topicos Avanzados en Pruebas de Software UNS 17 Planificación del Test (16) Aspectos a tener en cuenta para realizar el plan: Planificación n del Test Testers Meses Topicos Avanzados en Pruebas de Software UNS 18

Planificación del Test (17) Aspectos a tener en cuenta para realizar el plan: Planificación del Test En vez de indicar fechas exactas... Tarea de Testing Plan de Test Completo Casos de Test Completos Fase de Test 1 Fase de Test 2 Fase de Test 3 Fecha de Comienzo 7 días después de la especificación Plan de test completo Código completo Beta Release Release Duración 4 semanas 12 semanas 6 semanas 6 semanas 4 semanas Topicos Avanzados en Pruebas de Software UNS 19 Planificación del Test (18) Aspectos a tener en cuenta para realizar el plan: Casos de Test Reportar bugs Métricas y Estadísticas Total de fallas encontradas diariamente Lista de fallas que necesitan todavía ser arregladas Total de fallas encontradas por testador Topicos Avanzados en Pruebas de Software UNS 20

Planificación del Test (19) Aspectos a tener en cuenta para realizar el plan: Riesgos Identificar los riesgos tempranamente Testeadores experimentados sabrán dimensionarlos mejor El impacto sobre el esfuerzo en el testing puede ser muy grande Topicos Avanzados en Pruebas de Software UNS 21 Planificación del Test (20) Topicos Avanzados en Pruebas de Software UNS 22

Estándares de Pruebas Software (1) ISEB (Information Systems Examinations Board) & ISTQB (International Software Testing Qualification Board) para certificación internacional de profesionales de testing. Adhiere a los Estándares de Pruebas: BS7925 1 Software Testing Vocabulary BS7925 2 Software Component Testing IEEE Std 829 1998 Standard for Software Test Documentation IEEE Std 1028 Standard for Reviews & Inspections IEEE Std 1044 & 1044.1 Standard Classification for Software Anomalies ISO9126 Software Quality Standard Topicos Avanzados en Pruebas de Software UNS 23 Documentación de Test (1) Todo lo que vimos hasta ahora debe DOCUMENTARSE Utilizando la IEEE Std. 829-1998 Standard for Software Test Documentation Topicos Avanzados en Pruebas de Software UNS 24

Documentación de Test (2) IEEE Std. 829-1998 Especificación del Plan de Test Maestro Especificación del Diseño del Test Especificación de Caso de Test Especificación de los Procedimientos de Test Topicos Avanzados en Pruebas de Software UNS 25 Documentación de Test (3) Especificación del Plan de Test Maestro IEEE Std. 829-1998 Señalar el enfoque, los recursos y el esquema de actividades de test, así como los elementos a verificar, las características, las actividades de test, el personal responsable y los riesgos asociados Topicos Avanzados en Pruebas de Software UNS 26

Documentación de Test (4) Especificación del Plan de Test Maestro IEEE Std. 829-1998 1. Identificador único del documento 2. Introducción y resumen de elementos y características a verificar 3. Elementos software a verificar Software (módulos, etc.) Documentación (Especificación de Análisis y de Diseño) 4. Características a verificar Deposito de efectivo usabilidad Transferencia de fondos seguridad Consultar el saldo de una cuenta performance Topicos Avanzados en Pruebas de Software UNS 27 Documentación de Test (5) Especificación del Plan de Test Maestro IEEE Std. 829-1998 5. Características que no se probarán Errores relacionados con el tiempo. Condiciones de error no detectadas. Condiciones especiales de los datos. Invalidez de la información mostrada por pantalla. Interacción con tareas en background. Fallos de configuración/compatibilidad con software Incapacidad de soportar el volumen de carga o fallos hardware 6. Enfoque general del test (actividades, técnicas, herramientas, etc) En todos los niveles (Test de Unidad, de Integración, etc.) Unidad Integración Sistema Aceptación Topicos Avanzados en Pruebas de Software UNS 28

Documentación de Test (6) Especificación del Plan de Test Maestro IEEE Std. 829-1998 7. Criterios de éxito/fallo para cada elemento Casos de Test que se han ejecutado con éxito/fallado: Número, tipo, severidad, y ubicación Topicos Avanzados en Pruebas de Software UNS 29 Documentación de Test (7) Especificación del Plan de Test Maestro 8. Criterios de suspensión y requisitos de reanudación 9. Documentos a entregar Planes de test, especificación del diseño del test, casos de test, herramientas, reportes 10. Actividades de preparación y ejecución de test Organización de Equipos Jefe de equipo JUAN PEREZ Preparación de casos de test Ejecución de tests Datos de los tests Preparar informe IEEE Std. 829-1998 Topicos Avanzados en Pruebas de Software UNS 30

Documentación de Test (8) Especificación del Plan de Test Maestro IEEE Std. 829-1998 11. Necesidades de entorno En cuanto a: SOFTWARE y HADWARE: Sistema operativo, procesador, impresora DOCUMENTACION: Absoluta comodidad, tranquilidad 12. Responsabilidades en la organización y realización de los test Pruebas de Documentación: Juan Perez Pruebas de software: Josefa Martinez 13. Necesidades de personal y formación (training) 14. Esquema de tiempos Topicos Avanzados en Pruebas de Software UNS 31 Documentación de Test (9) Especificación del Plan de Test Maestro IEEE Std. 829-1998 15. Riesgos asumidos por el plan y planes de contingencias Riesgos Fechas de entregas no realistas Disponibilidad del personal Necesidades de Entrenamiento Falta de requerimientos del producto Disponibilidad de los recursos Plan de contingencias Reducir el alcance de la aplicación Retrasar la implementación Agregar recursos Prever fallos críticos Procedimientos alternativos 16. Aprobaciones y firmas con nombre y puesto desempeñado Topicos Avanzados en Pruebas de Software UNS 32

Documentación de Test (10) Especificación del Diseño del Test IEEE Std. 829-1998 Especificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e identificar las características que se deben verificar con este diseño de test Topicos Avanzados en Pruebas de Software UNS 33 Documentación de Test (11) Especificación del Diseño del Test IEEE Std. 829-1998 1. Identificador único para la especificación (y la referencia al plan de test asociado) 2. Característica(s) de los elementos software a verificar (y combinaciones de características) Por ejemplo, depósito en una cuenta 3. Detalles sobre el plan de test del que surge este diseño, incluyendo las técnicas de test específicas y los métodos de análisis de resultados Describe todos los test necesarios para testear una característica No se describe cómo son ejecutados los test De cada test: identificador, casos que se van a utilizar procedimientos que se van a seguir Topicos Avanzados en Pruebas de Software UNS 34

Documentación de Test (12) Especificación del Diseño del Test IEEE Std. 829-1998 4. Criterios de éxito/fallo de la prueba (criterios para determinar si una característica o combinación de características ha pasado con éxito la prueba o no) Especificación del Diseño del Test Definir uno de los casos de prueba identificando por una especificación del diseño de las pruebas Topicos Avanzados en Pruebas de Software UNS 35 Documentación de Test (13) Especificación de Caso de Test IEEE Std. 829-1998 1. Identificador único de la especificación fecha, número y versión del caso de test 2. Ítems a testear (por ejemplo, módulos) que se van a probar Especificación de requerimientos, especificación de diseño, y código 3. Especificaciones de cada entrada requerida para ejecutar el caso incluyendo las relaciones entre las diversas entradas; por ejemplo, la sincronización de las mismas 4. Especificaciones de todas las salidas y las características requeridas Cómose debe ver el sistema luego de que se ejecutó el caso de test Se deben indicar características como, el tiempo respuesta para los elementos que se van a probar Topicos Avanzados en Pruebas de Software UNS 36

Documentación de Test (14) Especificación de Caso de Test IEEE Std. 829-1998 5. Necesidades de entorno hardware Software (creación de stubs y drivers) personal 6. Requisitos especiales de procedimiento restricciones especiales en los procedimientos para ejecutar este caso 7. Dependencias entre casos por ejemplo, listar los identificadores de los casos que se van a ejecutar antes de este caso de prueba Ejemplo: Debemos tener un test que requiera el depósito en una cuenta de $1000 que debe ejecutarse antes de ejecutar otro test que realiza el retiro (sino la cuenta no tendrá fondos) Topicos Avanzados en Pruebas de Software UNS 37 Documentación de Test (15) Especificación de los Procedimientos de Test IEEE Std. 829-1998 Especificar los pasos para la ejecución de un conjunto de casos de test o, más generalmente, los pasos utilizados para analizar un elemento software con el propósito de evaluar un conjunto de características del mismo Topicos Avanzados en Pruebas de Software UNS 38

Documentación de Test (16) Especificación de los Procedimientos de Test IEEE Std. 829-1998 1. Identificador único de la especificación y referencia a la correspondiente especificación del diseño del test 2. Objetivo del procedimiento y lista de casos que se ejecutan con él 3. Requisitos especiales para la ejecución (por ejemplo, entorno especial o personal especial) 4. Pasos en el procedimiento. Además de la manera de registrar los resultados y los incidentes de la ejecución, se debe especificar: La secuencia necesaria de acciones para preparar la ejecución Acciones necesarias para empezar la ejecución Acciones necesarias durante la ejecución Cómo se realizarán las medidas ( por ejemplo, el tiempo de respuesta) Topicos Avanzados en Pruebas de Software UNS 39 Documentación de Test (17) Especificación de los Procedimientos de Test IEEE Std. 829-1998 5. Pasos en el procedimiento. Además de la manera de registrar los resultados y los incidentes de la ejecución, se debe especificar: Acciones necesarias para suspender la prueba (cuando los acontecimientos no previstos lo obliguen) Puntos para reinicio de la ejecución y acciones necesarias para el reinicio en estos puntos Acciones necesarias para detener ordenadamente la ejecución Acciones necesarias para restaurar el entorno y dejarlo en la situación existente antes de las pruebas Acciones necesarias para tratar los acontecimientos anómalos Topicos Avanzados en Pruebas de Software UNS 40

IEEE Std. 29119 Estándares de Pruebas Software (2) Futuro de los Estándares de Testing: ISO/IEC 29119 Software Testing Bajo desarrollo por ISO/IEC JTC1/SC7 Working Group 26. Reemplazará a algunos de los estándares IEEE y BSI para testing de software: IEEE 829 Test Documentation IEEE 1008 Unit Testing BS 7925-1 Vocabulary of Terms in Software Testing BS 7925-2 Software Component Testing Standard Topicos Avanzados en Pruebas de Software UNS 41 IEEE Std. 29119 Estándares de Pruebas Software (3) Part 1 Concepts & Vocabulary BS 7925-1 Part 4 Testing Techniques Part 2 Processes Part 3 Documentation BS 7925-2 BS 7925-2 IEEE 829 IEEE 1008 Topicos Avanzados en Pruebas de Software UNS 42

ISO 9126 Calidad de Producto Software (1) El objetivo no es necesariamente alcanzar una calidad perfecta, sino la necesaria y suficiente para cada contexto de uso a la hora de la entrega y del uso por parte de los usuarios. ISO 9126 entrega la definición de las características y los procesos de evaluación de calidad asociados para usar cuando se especifican los requisitos y la evaluación de los productos de software a lo largo de su vida útil. ISO 9126 define la Calidad del Software como: La totalidad de características de un producto de software que se manifiesta en su habilidad para satisfacer necesidades establecidas o implícitas. Topicos Avanzados en Pruebas de Software UNS 43 ISO 9126 Calidad de Producto Software (2) Enfatiza tres puntos importantes: Los requisitos del software constituyen el fundamento para medir la calidad. La carencia de conformidad con los requisitos es carencia de calidad. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la manera en que el software se somete al trabajo ingenieril. Si no se siguen los criterios, la carencia de calidad será un resultado casi seguro. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo, mantenibilidad). Si el software se conforma con los requisitos explícitos pero falla en atender los requisitos implícitos, la calidad del software es sospechosa. Topicos Avanzados en Pruebas de Software UNS 44

ISO 9126 Calidad de Producto Software (3) Diferentes aspectos de la calidad Interna: medible a partir de las características intrínsecas, como el código fuente Externa: medible en el comportamiento del producto, como en una prueba En uso: durante la utilización efectiva por parte del usuario Topicos Avanzados en Pruebas de Software UNS 45 ISO 9126 Calidad Interna y Externa (1) Funcionalidad Mantenibilidad Qué tan fácil de modificar es el software? Las funciones requeridas están disponibles en el software? Qué tan confiable es el software? Confiabilidad Portabilidad Qué tan fácil es transferir el software a otro entorno? Qué tan eficiente es el software? Es fácil de usar el software? Usabilidad Eficiencia Topicos Avanzados en Pruebas de Software UNS 46

ISO 9126 Calidad Interna y Externa (2) Topicos Avanzados en Pruebas de Software UNS 47 ISO 9126 Calidad Interna y Externa (3) Functionality: Capacidad del producto software de proveer funciones que alcancen las necesidades establecidas y derivadas cuando el software es usado bajo condiciones especificadas. Suitability: La capacidad del producto software para proveer un conjunto apropiado de finciones para tareas y objetivos del usuario especificados. Accuracy: La capacidad del producto software de proveer resultados o efectos correctos y/o acordados. Interoperability: La capacidad del producto software de interactuar con uno o más sistemas especificados. Security: La capacidad del producto software de proteger información y datos de manera que personas o sistemas no autorizados no puedan leerlos o modificarlos y no rechazar el acceso de personas autorizadas. Compliance: La capacidad del producto software de adherir a estándares, convenciones o regulaciones legales o prescripciones similares. Topicos Avanzados en Pruebas de Software UNS 48

ISO 9126 Calidad Interna y Externa (4) Reliability: Capacidad del producto software de mantener un nivel especificado de performance cuando se usa bajo condiciones especificadas. Maturity: La capacidad del producto software para evitar fallas como resultado de defectos en el software. Fault Tolerance: La capacidad del producto software mantener un nivel especificado de performance en caso de existencia de defectos o de infringir la interface especificada. Recoverability: La capacidad del producto software de reestablecer un nivel especificado de performance y de recuperar los datos directamente afectados en el caso de una falla. Compliance: La capacidad del producto software de adherir a estándares, convenciones o regulaciones relacionadas a reliability. Topicos Avanzados en Pruebas de Software UNS 49 ISO 9126 Calidad Interna y Externa (5) Usability: Capacidad del producto software de ser entendido, aprendido, usado y atractivo al usuario, cuando se usa bajo condiciones especificadas. Understandability: La capacidad del producto software de posibilitar que el usuario entienda si el software es adecuado, y cómo puede ser usado en tareas y condiciones de uso particulares. Learnability: La capacidad del producto software de posibilitar que el usuario aprenda la aplicación. Operability: La capacidad del producto software de posibilitar que el usuario lo opere y controle. Attractiveness: La capacidad del producto software de ser atractivo al usuario. Compliance: La capacidad del producto software de adherir a estándares, convenciones o guías de estilo o regulaciones relacionadas a usability. Topicos Avanzados en Pruebas de Software UNS 50

ISO 9126 Calidad Interna y Externa (6) Efficiency: Capacidad del producto software de proveer adecuada performance, relativa a la cantidad de recursos usados, bajo condiciones establecidas. Time Behavior: La capacidad del producto software de proveer apropiados tiempos de respuesta y procesamiento y tasas de intercambio cuando se realizan sus funciones, bajo condiciones especificadas. Resource Utilization: La capacidad del producto software de usar la cantidad y tipo de recursos apropiada cuando el software realiza sus funciones bajo condiciones establecidas. Compliance: La capacidad del producto software de adherir a estándares, convenciones relacionadas a efficiency. Topicos Avanzados en Pruebas de Software UNS 51 ISO 9126 Calidad Interna y Externa (7) Maintainability: Capacidad del producto software de ser modificado. Las modificaciones pueden incluir correcciones, mejoras y adaptaciones del software a cambios en el entorno, así como en los requerimientos y en las especificaciones funcionales. Analysability: La capacidad del producto software de que se le diagnostiquen deficiencias o causas de fallas, o de que se identifiquen las partes que serán modificadas. Changeability: La capacidad del producto software de posibilitar que una modificación especificada sea implementada. Stability: La capacidad del producto software de evitar efectos no esperados ante cambios en el software. Testability: La capacidad del producto software de posibilitar que el software modificado sea validado. Compliance: La capacidad del producto software de adherir a estándares y convenciones relacionadas a maintainability. Topicos Avanzados en Pruebas de Software UNS 52

ISO 9126 Calidad Interna y Externa (8) Portability: Capacidad del producto software de ser transferido de un entorno a otro. Adaptability: La capacidad del producto software de ser adaptado para diferentes entornos sin aplicar otras acciones o medios que aquellas previstas para este propósito en el software especificado. Installability: La capacidad del producto software de ser instalado en un entorno especificado. Co existence existence: La capacidad del producto software de coexistir con otros software independientes en un entorno común compartiendo recursos comunes. Replaceability: La capacidad del producto software de ser usado en lugar de otro software especificado para el mismo propósito en el mismo entorno. Compliance: La capacidad del producto software de adherir a estándares y convenciones relacionadas a portability. Topicos Avanzados en Pruebas de Software UNS 53 ISO 9126 Calidad en Uso (1) Topicos Avanzados en Pruebas de Software UNS 54

ISO 9126 Calidad en Uso (2) Effectiveness: La capacidad del producto software de posibilitar a los usuarios alcanzar objetivos especificados con certeza y completitud en un contexto de uso especificado. Productivity: La capacidad del producto software de posibilitar a los usuarios usar la cantidad apropiada de recursos en relación con la efectividad alcanzada en un contexto de uso especificado. Safety: La capacidad del producto software de alcanzar un nivel aceptable de riesgo de daño a personas, software, equipos o entornos en un contexto de uso especificado. Satisfaction: La capacidad del producto software de satisfacer a los usuarios en en un determinado contexto de uso. Topicos Avanzados en Pruebas de Software UNS 55 Modelos CMM El Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización. Fue desarrollado inicialmente para los procesos relativos al software por la Universidad Carnegie Mellon para el SEI (Software Engineering Institute). A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de América, desarrolló una primera definición de un modelo de madurez de procesos en el desarrollo de software, que se publicó en septiembre de 1987. Este trabajo evolucionó al modelo CMM o SW CMM (CMM for Software), cuya última versión (v1.1) se publicó en febrero de 1993. Topicos Avanzados en Pruebas de Software UNS 56

Software CMM SW CMM se organiza en cinco niveles que priorizan acciones para incrementar la madurez del proceso de software. Nivel de madurez: cada nivel o capa suministra una base para la mejora continua. Topicos Avanzados en Pruebas de Software UNS 57 Software CMM INICIAL: proceso ad hoc, y ocasionalmente caótico. Pocos procesos están definidos y el éxito depende de esfuerzos individuales. REPETIBLE: procesos básicos de gestión de proyectos para controlar costos, tiempos y funcionalidad. La disciplina del proceso se basa en repetir éxitos anteriores sobre proyectos de aplicaciones similares. DEFINIDO: el proceso de software es documentado, estandarizado e integrado en la organización. Se institucionaliza el proceso de software. GESTIONADO: se recolectan medidas detalladas del proceso de software y de la calidad del producto. Ambos son entendidos y controlados cuantitativamente. OPTIMIZADO: la mejora continua del proceso es posible por la retroalimentación cuantitativa desde el proceso y a partir de nuevas ideas y tecnologías. Topicos Avanzados en Pruebas de Software UNS 58

Software CMM KPAs Topicos Avanzados en Pruebas de Software UNS 59 SW CMM NIVEL 2 Gestión de Requerimientos (Requirements Management): establecer una comprensión mutua entre el cliente y el proyecto en relación a los requerimientos que son la base para la planificación y el control. Planificación del Proyecto (Software Project Planning): establecer planes razonables para efectuar y manejar el proyecto. Son la base del proceso de gestión. Seguimiento del Proyecto (Software Project Tracking and Oversight): establecer una visibilidad adecuada del avance real del proyecto de manera que puedan tomarse acciones efectivas cuando existen desvíos. Topicos Avanzados en Pruebas de Software UNS 60

SW CMM NIVEL 2 Gestión de Contratos de Software (Software Subcontract Management): seleccionar contratistas de software calificados y gestionar de manera efectiva la relación con ellos. Asegurar la Calidad del Software (Software Quality Assurance): suministrar la visibilidad adecuada en los procesos y productos. Gestión de la Configuración de Software (Software Configuration Management): establecer y mantener la integridad de los productos del proyecto a través de todo el ciclo de vida. Topicos Avanzados en Pruebas de Software UNS 61 SW CMM NIVEL 3 Enfoque en el Proceso de la Organización (Organization Process Focus): establecer las responsabilidades organizacionales para las actividades del proceso. Definición del Proceso de la Organización (Organization Process Definition): desarrollar y mantener elementos del proceso de software que mejoren el rendimiento en los proyectos. Programa de Entrenamiento (Training Program): desarrollar las habilidades y conocimientos de los individuos de manera que puedan cumplir sus roles efectiva y eficientemente. Revisión de Pares (Peer Reviews): remover defectos de los productos de manera eficiente y temprana. Topicos Avanzados en Pruebas de Software UNS 62

SW CMM NIVEL 3 Gestión Integrada del Software (Integrated Software Management): integrar la ingeniería de software y las actividades de gestión en un proceso coherente y definido que se constituya en un estándar para la organización. Ingeniería del Producto Software (Software Product Engineering): realizar un proceso de ingeniería bien definido y consistente que integre todas las actividades, ej., análisis de requerimientos, diseño, codificación, etc. Coordinación entre grupos (Intergroup Coordination): establecer un medio para que el grupo de ingeniería de software participe activamente con otros grupos de ingeniería. Topicos Avanzados en Pruebas de Software UNS 63 SW CMM NIVEL 4 Gestión Cuantitativa del Proceso (Quantitative Process Management): controlar el rendimiento del proceso de manera cuantitativa. Se agrega un programa de medición a prácticas de nivel 3. Gestión de la Calidad del Software (Software Quality Management): desarrollar un entendimiento cuantitativo de la calidad de los productos de software y alcanzar objetivos de calidad específicos. Topicos Avanzados en Pruebas de Software UNS 64