1 Aplica el Meta Modelo de Metodologías CREA (Conceptos, Roles, Entregables, Actividades) Pruebas de Calidad de Software (PCS) Guía del Componente Metodológico.

Presentación del tema: "1 Aplica el Meta Modelo de Metodologías CREA (Conceptos, Roles, Entregables, Actividades) Pruebas de Calidad de Software (PCS) Guía del Componente Metodológico."— Transcripción de la presentación:

1

2 1 Aplica el Meta Modelo de Metodologías CREA (Conceptos, Roles, Entregables, Actividades) Pruebas de Calidad de Software (PCS) Guía del Componente Metodológico

3 2 Algunos problemas a enfrentar ● ¿Qué criterios de priorización y que técnicas permitirán usar el tiempo de la manera más productiva (maximizar el promedio de “defectos identificados por hora”)? ● ¿Cuál es la secuencia de Ciclos de Pruebas, incluyendo pilotos y paralelos más adecuadas para nuestro proyecto específico? ● ¿Cómo seleccionar las técnicas que nos resulten de mayor valor, partiendo de las mejores prácticas incluidas en los enfoques metodológicos disponibles?

4 3 Contenido 2.0 Roles 1.0 Conceptos 4.0 Actividades 3.0 Entregables Anexos

5 4 Contenido 2.0 Roles 1.0 Conceptos 4.0 Actividades 3.0 Entregables Anexos

6 5 Tipos de Controles de Calidad Prueba de Funcionalidad Calidad de Codificación Calidad de Documentación Calidad de Arquitectura Prueba de Esfuerzo Calidad de GUI´s

7 6 Curva ‘S’: Cuándo detener el testing? Fuente: Process Consulting

8 7 Método Hitachi Fuente: Process Consulting

9 8 Método Hitachi – Resumen de fases Fuente: Process Consulting

10 9 Éxito versus Catástrofe Fuente: Process Consulting

11 10 Resumen de Observaciones Fuente: Process Consulting ● Velocidad para terminar la fase 1 es relativamente constante a lo largo de proyectos ● La duración de la fase 1 determina el éxito ● La fase 3 es relativamente insensible a la historia previa del proyecto ● El proyecto falla cuando la fase 2 se sale del cronograma ● La clave es moverse de la fase 1 a la fase 2 pronto ● Mantener la fase 1 tan corta como sea posible ● Mantener la fase 2 tan extensa como sea posible: reduciendo la fase 3

12 11 Errores detectados Fuente: Process Consulting

13 12 Curva Acumulativa de Errores: En que momento hacer el “Pase a producción” Inicialmente los ciclos de prueba arrojan mayor cantidad de errores que los ciclos posteriores. La pendiente de la curva acumulativa tiene un comportamiento similar a la probabilidad de encontrar errores en un próximo ciclo de pruebas. Cuando esta pendiente empieza a disminuir es momento de decidir el lanzamiento a producción (como se sabe “no existe software sin errores, solo software cuto próximo error aún no ha sido detectado”).

14 13 Contenido 2.0 Roles 1.0 Conceptos 4.0 Actividades 3.0 Entregables Anexos

15 14 Roles: Los genéricos para Proyecto de Cambio ADC - R - Funciones...xls

16 15 Roles: Los específicos para este Componente Metodológico PCS - R – Funciones..xls”.

17 16 Contenido 2.0 Roles 1.0 Conceptos 4.0 Actividades 3.0 Entregables Anexos

18 17 Plan de Pruebas El Plan de Pruebas es un documento que establece las prácticas específicas de pruebas, recursos y secuencia de actividades relativas a un producto, servicio, contrato o proyecto, en particular. El Cronograma de Pruebas es uno de sus elementos pricipales. El Plan de Pruebas es un documento que establece las prácticas específicas de pruebas, recursos y secuencia de actividades relativas a un producto, servicio, contrato o proyecto, en particular. El Cronograma de Pruebas es uno de sus elementos pricipales. PCS - E - Plan de Pruebas – Plantilla.doc

19 18 Catálogo de Pruebas El Catálogo de Pruebas es un compendio de los casos de prueba que permiten verificar una serie de escenarios y elementos de una aplicación de Software. PCS - E - Catálogo de Pruebas - Plantilla.xls

20 19 Seguimiento de Observaciones al Software (Errores y Mejoras) Propicia la adecuada identificación de las observaciones críticas, separándolas de las nuevas necesidades o expectativas. Impulsa la solución de problemas. PCS - E - Seguimiento de Observaciones al Software - Plantilla.xls”. 19

21 20 Informe de Avance de Pruebas Integrales PCS - E – Informe de Avance de Pruebas Integrales - Plantilla.xls”.

22 21 PCS - E - Tablero de Gestión de Prueba…xls Tablero de Gestión

23 22 Contenido 2.0 Roles 1.0 Conceptos 4.0 Actividades 3.0 Entregables Anexos

24 23 Fases A. Análisis B. Preparación de Casos de Prueba C. Gestión de Recursos D. Ejecución

25 24 Contenido 2.0 Roles 1.0 Conceptos 4.0 Actividades 3.0 Entregables Anexos

26 25 Gestión de Calidad ¿Cuánto cuesta corregir un error? Ejemplo : La fórmula con que se calcula la mora fue mal definida desde el inicio. Tiempo que toma corregir en : - Arquitectura : 1h. - Programación : 3 días. - Pruebas Integrales : 1 semana. - Implantación : 4 semanas. - En uso : 2 meses. Tiempo Costo $ Inicio Estabilización Desarrollo

27 26 Modelo de Referencia: Aseguramiento de Calidad en un Proceso Productivo Construcción Verificación A) Al final del Proceso B) Durante todo el Proceso El aseguramiento de la calidad, en la Gestión y en la Ejecución, debería ser efectuado en varios momentos del Desarrollo del Proyecto y no sólo al final.

28 27 IDEA / M+S: Base para Metodologías de TI M odelamiento M aterialización... DC... FP P lanificación C ontrol I nicio D esarrollo E stabilización A prendizaje... ID... PF Gestión Ejecución Metodología para Gestión de Proyectos (GPR) Metodología para Desarrollo de Software (DSW) Metodología para Aseguramiento de la Calidad de Software (ACS) Metodología para Gestión de Cambios en Software (GCS)

29 28 Aseguramiento de Calidad: Verificación de Entregables de Gestión y de Ejecución M odelamiento M aterialización... DC... FP P lanificación C ontrol I nicio D esarrollo E stabilización A prendizaje... ID... RF Gestión Ejecución E G1 E G2 E G3 E G4 E G5 E G6 E E1 E E2 E E3 E E4 E E5 E E6 Criterios de Calidad MGP = Metodología para Gestión de ProyectosMDS = Metodología para Desarrollo de Sistemas Definiciones Metodológicas Control de Calidad para Entregables de Ejecución (MDS) Control de Calidad para Entregables de Gestión (MGP)

30 29 CMMI: Capability Maturity Model Integration Riesgo & Residuos Esfuerzos Heroicos Diseño Desarrollo Integración Pruebas 1 Inicial Administración Básica de Proyectos Administración de Requerimientos Planificación de Proyectos Monitoreo y Control de Proyectos Acuerdo de Gestión de Proveedor Medición y Análisis Aseguramiento de la Calidad del Producto y Proceso Administración de la Configuración 2 Administrado Estandarización de Procesos Desarrollo de Requerimientos Solución Técnica Integración de Productos Verificación Validación Enfoque Organizacional del Proceso Definición Organizacional del Proceso Capacitación Organizacional Administración Integrada de Productos Administración de Riesgos Equipo de Trabajo Integrado Administración Integrada de Proveedor Análisis Decisión y Resolución Entorno de la Organización para la Integración 3 Definido Adminis- tración Cuanti- tativa Administración de Procesos Cuantitativos Administración de Calidad de Software 4 Adminis- trado Cuantita- tivamente Mejora Continua de Procesos Innovación Organizativa y Despliegue Análisis Causal y Resolución Productividad & Calidad ResultadoCapacidadNivel 5 Opti- mizado El modelo CMMI, desarrollado por el Carnegie Mellow Software Engineering Institute, establece un conjunto de actividades que deben ejecutarse para que el software cumpla con los criterios esperados de calidad: Entrenamiento para realizar las pruebas Aseguramiento de Calidad de Software (SQA) Ingeniería del Proceso (Estándares de Pruebas) Registro de Datos (Plan, Do, Check, Act) Control Estadístico del Proceso (Desviaciones) El modelo CMMI, desarrollado por el Carnegie Mellow Software Engineering Institute, establece un conjunto de actividades que deben ejecutarse para que el software cumpla con los criterios esperados de calidad: Entrenamiento para realizar las pruebas Aseguramiento de Calidad de Software (SQA) Ingeniería del Proceso (Estándares de Pruebas) Registro de Datos (Plan, Do, Check, Act) Control Estadístico del Proceso (Desviaciones)

31 30 TMMI: Test Maturity Model Integration (1) Iniciación (2) Planificación Estrategia de Pruebas Plan de Pruebas Seguimiento Diseño y Ejecución Ambiente de Pruebas (2) Planificación Estrategia de Pruebas Plan de Pruebas Seguimiento Diseño y Ejecución Ambiente de Pruebas (3) Implementación Organización de Pruebas Elaboración de Datos de Prueba Prueba de Ciclo de vida e Integración Prueba No Funcional Revisión de Pares (3) Implementación Organización de Pruebas Elaboración de Datos de Prueba Prueba de Ciclo de vida e Integración Prueba No Funcional Revisión de Pares (4) Gestión y Medición Medición de Pruebas Evaluación de Calidad del Software Revisión avanzada de Pares (4) Gestión y Medición Medición de Pruebas Evaluación de Calidad del Software Revisión avanzada de Pares (5) Optimización Prevención de Defectos Optimización de Proceso de Pruebas Control de Calidad (5) Optimización Prevención de Defectos Optimización de Proceso de Pruebas Control de Calidad El modelo TMMI, desarrollado por el Illinois Institute of Technology, como guía y referencia que aplica los criterios del modelo de madurez en la mejora los procesos de pruebas, lo que a su vez repercute directamente en la calidad del producto final.

32 31 ISTQB: International Software Testing Qualifications Boards Objetivos Descripción Criterios de Término Responsabilida des Adm.Biblioteca de Casos Herramientas Tipos de Pruebas Actividades Configuraciones Recursos Pruebas a través del Ciclo de Vida de Desarrollo del Software Técnicas de Caja Negra Técnicas de Caja Blanca Técnicas Basadas en la Experiencia Selección de las Técnicas de Pruebas Organización Planificación y Estimación Seguimiento y Control de Estado Gestión de la Configuración Riesgos Gestión de Incidencias Grabar Proceso de Negocio Modificar Prueba bajo Múltiples Escenarios Correr Pruebas Usando Datos Variables Reportar Diferencias Pruebas de Regresión Estadísticas Revisar Niveles de Pruebas Priorizar 1 1 2 2 3 3 Definir una Estratégia o Plan de Pruebas Diseño de Casos de Prueba Gestión de Pruebas 4 4 Herramientas de Pruebas Operar Controlar (Evaluar y Reaccionar) Software Testing La norma internacional de la ISTQB con sede en Bélgica, certifica la calidad de los profesionales que intervienen en el testing de alto nivel. Plantea un esquema de calidad para las pruebas de software y el conocimiento necesario para aportar una proyección única.

33 32 Dos conceptos importantes ANÁLISIS CAUSAL Y YIELD Fuente: Process Consulting

34 33 Tipos de Errores y Defectos Especificación Errores en la especificació n Diseño Errores en el diseño Diseño incorrecto por errores en especificación Codificación y PU Errores en codificación y PU Codificación errada por errores en el diseño Codificación incorrecta por errores en la especificación Testing Es probable identificar y remover durante el testing. ¿Se planifica su existencia? ¿Tenemos datos de su identificación y remoción? Es poco probable identificar y remover estos defectos, porque nadie sabe que existen o cuáles son. ¿Se planifica su existencia? ¿Tenemos datos de su identificación y remoción? Pero el usuario los identificará en producción Defectos identificados después del pase a producción ¿Tenemos datos? Fuente: Process Consulting

35 34 Testing – Análisis Causal Fuente: Process Consulting

36 35 La Medida de Yield ● Fase Yield ► Es el porcentaje de defectos que son removidos en una fase de desarrollo de software ● Proceso Yield ► Es el yield de todas las fases hasta un determinado punto del proceso Fuente: Process Consulting

37 36 Testing PRINCIPIOS DE TESTING Fuente: Process Consulting

38 37 Contexto de los Sistemas de Software Principio 1 de testing El testing es dependiente del contexto El testing se hace diferente en contextos diferentes Por ejemplo, software de seguridad crítica se prueba de forma diferente a un sitio de comercio electrónico Fuente: Process Consulting

39 38 Testing temprano Fuente: Process Consulting Principio 2 de testing Testing temprano Como sea posible en el ciclo de vida del desarrollo de software o sistema y debe enfocarse en objetivos definidos una razón o propósito para diseñar y ejecutar un test. Los objetivos usualmente incluyen: Encontrar defectos Aumentar la confianza y proporcionar información acerca del nivel de calidad Prevenir defectos Podemos usar testing estático y dinámico

40 39 ¿Cuánto testing es suficiente? Fuente: Process Consulting Principio 3 de testing Testing exhaustivo es imposible Probar todo (todas las combinaciones de entradas y precondiciones) no es factible excepto para casos triviales. En vez de un testing exhaustivo, usamos riesgos y prioridades para enfocar nuestros esfuerzos de testing

41 40 Duración del testing Fuente: Process Consulting La cantidad de tiempo requerido para un testing adecuado depende de cuatro factores principales: Calidad objetivo Cuan infestado de errores está el código Capacidad y preparación del equipo de testing El costo y presupuesto disponible Estos factores dependen a su vez de otras características del equipo y sistema

42 41 Duración del testing Fuente: Process Consulting Atributos que afectan la duración del testing Bajo impactoAumenta la duración del testing  Alto impacto únicaNúmero de plataformasmulti Usuarios internosAlcance del sistemaUsuarios externos internasInterfasesexternas estableEstabilidad de los requerimientosEn evolución incrementalEstrategia de releaseBig-bang Familiar/estableci da TecnologíaNueva/emergente bajoImpacto en el negocio del malfuncionamiento del sistema alto Stand-aloneConectividadMulti-sistema Read-onlyAcceso a la base de datosupdate Pre-construidoEntorno de pruebasnuevo

43 42 Duración del testing Fuente: Process Consulting Hay algunas circunstancias en las que las consecuencias de no cumplir con la fecha de término es peor que las consecuencias de implementar a tiempo con calidad reducida En este caso, haz lo mejor que puedas con los recursos disponibles … las fechas no van a cambiar! Si fallamos en la fecha de término, perderemos participación de mercado … no vamos a permitir que esto suceda! En estos casos la gerencia debe decidir si el riesgo de negocio de continuar probando y fallar en la fecha de término es mayor que el riesgo de detener el testing e implementar con menos calidad que la esperada

44 43 Duración del testing Fuente: Process Consulting Cuando encontramos problemas, debemos enfocar en corregir los problemas principales, es decir, corregir los defectos con severidad 1 y 2, no con severidad 3 A los problemas deben asignarse una severidad (que puede cambiarse en cualquier momento por el gerente de proyecto en base a nueva información) Severidad 1: un problema serio, el testing no puede continuar, no hay forma alternativa de continuar, si no se corrige rápidamente, el plazo de testing está en riesgo Severidad 2: un problema serio, pero hay una alternativa para continuar, si se corrige en un tiempo relativamente corto (pocos días) el plazo del testing puede continuar Severidad 3: todos los demás problemas (corregir o no a discreción del gerente de proyecto en consulta con el analista funcional y el analista de negocio)

45 44 Clustering de los defectos Fuente: Process Consulting Principio 4 de testing Clustering de los defectos Un pequeño número de módulos contienen la mayoría de los defectos descubiertos durante las pruebas antes de liberar el producto o son responsables de la mayoría de las fallas operacionales

46 45 Clustering de los defectos Fuente: Process Consulting ● Literatura en testing apoya la visión que los defectos suceden en clusters, es decir, un pequeño porcentaje del código, el llamado código de alto riesgo, contendrá un porcentaje desproporcionalmente alto de defectos ● Por tanto, el testing debe enfocar primero en identificar y validar el código de alto riesgo ● La estrategia debe ser categorizar el número de casos de prueba. Código de alto riesgo debe recibir saturación de testing. Código de bajo riesgo debe ser testeado muestralmente

47 46 Clustering de los defectos Fuente: Process Consulting ● Segundo, el testing debe enfocarse en testing de alto impacto, en código de alto uso

48 47 Clustering de los defectos Fuente: Process Consulting ● Combinando estas dos áreas de enfoque tendremos una estrategia robusta en base a la aplicación del principio 80/20 de detección de defectos

49 48 Paradoja del pesticida Fuente: Process Consulting Principio 5 de testing Paradoja del pesticida Si las mismas pruebas se repiten una y otra vez, eventualmente el mismo conjunto de casos de prueba no encontrará defecto nuevo alguno. Para derrotar esta ‟ paradoja del pesticida”, necesitamos revisar y actualizar con regularidad los casos de prueba y se necesita escribir nuevos y diferentes pruebas para ejecutarlos en partes diferentes del software o sistema para encontrar posiblemente más defectos

50 49 ¿Está el software libre de defectos? Fuente: Process Consulting Principio 6 de testing El testing muestra la presencia de defectos El testing puede mostrar que los defectos están presentes, pero no puede probar que no hay defectos. El testing reduce la probabilidad de defectos no descubiertos remanentes en el software, pero inclusive si no se encuentran defectos, no puede ser una prueba de estar correcto

51 50 Si no encontramos defectos, significa que ¿los usuarios aceptarán el software? Fuente: Process Consulting Principio 7 de software Falacia de la ausencia de errores Identificar y remover defectos no ayuda si el sistema construido no puede usarse y no satisface las necesidades y expectativas de los usuarios

52 51 Testing Fuente: Process Consulting PROCESO DE TESTING

53 52 Planificar el testing Fuente: Process Consulting El testing es un proceso iterativo que incluye las siguientes actividades: Planear y controlar Analizar y diseñar Implementar y ejecutar Evaluar criterio de finalización e informar Actividades de cierre

54 53 Testing Fuente: Process Consulting CONCEPTOS Y TÉCNICAS

55 54 Planificar el testing Fuente: Process Consulting Áreas de enfoque del testing Atributos de un sistema que deben ser probados a fin de asegurar que se satisfacen los requerimientos de negocio y técnicos ¿Por qué? Usualmente no es factible un testing exhaustivo No es realista ni económicamente viable Asegura que los aspectos críticos tanto desde el punto de vida de negocio como técnico se pruebas para minimizar el riesgo

56 55 Planificar el testing Fuente: Process Consulting Áreas de enfoque del testing Áreas de enfoque típicas Auditabilidad Continuidad operativa Correcto Flexible al mantenimiento Operabilidad Performance Portabilidad Confiabilidad Seguridad Facilidad de uso

57 56 Planificar el testing Fuente: Process Consulting Tipos de testing Funcionalmente Auditabilidad Flexibilidad de mantenimiento Facilidad de uso Pruebas de conversión Pruebas de documentación y de procedimientos Manejos de errores de testing Pruebas funcionales Pruebas de instalación Pruebas de interfases / y dentro del sistema Pruebas de paralelo Pruebas de regresión Pruebas de flujo de transacción Pruebas de facilidad de uso

58 57 Planificar el testing Fuente: Process Consulting Tipos de testing Estructural Performance Backup y Recuperación Pruebas de Seguridad Pruebas de Operación Pruebas de Stress / de Volumen

59 58 Planificar el testing Fuente: Process Consulting Fases ó Niveles de testing Testing unitario Testing de integración Testing de sistema Testing de operabilidad ó validación (aceptación del usuario o tester independiente en ambiente similar al de operación)

60 59 Testing Fuente: Process Consulting TÉCNICAS DE TESTING

61 60 Técnicas de testing Fuente: Process Consulting ¿Cómo diseñar el mejor conjunto de casos de prueba? ¿Cuál subconjunto de casos de prueba tiene la probabilidad mas alta de detectar la mayor cantidad de errores? Respuesta: Usando técnicas de testing Técnicas de testing: Pruebas de caja negra No se asume conocimiento del interior del sistema Pruebas de caja blanca Se asume conocimiento del interior del sistema

62 61 Técnicas de testing Fuente: Process Consulting Caja NegraCaja Blanca Producen casos de prueba basados exclusivamente en las especificaciones Producen casos de prueba basados exclusivamente en el código del programa

63 62 Técnicas de testing Fuente: Process Consulting Técnicas de selección de datos Valores límites Cobertura de sentencias Cobertura de condición Mas probable Menos probable Verificación de nulos Simular errores

64 63 Técnicas de testing Fuente: Process Consulting Reusar Siempre que sea posible reutilice casos de prueba Profundidad Primero módulos críticos Para requerimientos de alto riesgo cuanto sea necesario y el tiempo lo permita Seguro Agregue pruebas aleatorias para escenarios de estrés e inválidos para estar seguros Los casos de prueba deben considerar condiciones de entrada inválidas e inesperadas así como válidas y esperadas No planifique el esfuerzo de testing asumiendo que no habrán errores La probabilidad que existan más errores en la sección de un programa es proporcional al número de errores ya encontrados

65 64 Técnicas de testing Fuente: Process Consulting Rutas positivas (test to pass) ¿Hace el sistema lo que se supone que hace? Rutas negativas (test to fail) ¿Cómo podemos hacer que esto falle? Testing funcional Cobertura completa Crear al menos un caso de prueba para cada requerimiento Verifica cada función o característica del sistema en prueba, por lo menos con los casos de prueba necesarios para determinar cómo cada función es ejecutada

66 65 Técnicas de testing Fuente: Process Consulting Testing de Dominio Énfasis en las variables de entrada, de salida, de configuración o internas (por ejemplo relacionadas a archivos). Para cada variable o combinación de variables, considera el dominio de los valores posibles. Este dominio es dividido en subconjuntos y valores de cada subconjunto son utilizados como entradas para las pruebas Testing Basado en Riesgo Generar más casos de prueba en el código más riesgoso. Un programa es considerado un conjunto de oportunidades donde pueden suceder errores. Para cada oportunidad de error (riesgo) proyectar casos de prueba para determinar si el programa fallará o no

67 66 Técnicas de testing Fuente: Process Consulting Partición Equivalente Análisis de Valores o Condiciones Límites Probar Errores Pruebas con tablas de decisión Probar Transición de Estado

68 67 Partición Equivalente Fuente: Process Consulting Reduce el número de otros casos de prueba que deben ser desarrollados para conseguir un testing razonable Cubre un conjunto grande de otros posibles casos de prueba La prueba de un valor representativo es equivalente a probar cualquier otro valor representativo. Por ejemplo si un caso dentro de una clase equivalente detectó un error entonces todos los casos equivalentes detectarían un error Ejemplo Válido e inválido

69 68 Ejemplo de clases equivalentes Fuente: Process Consulting El campo X sólo puede aceptar valores entre 1 y 50 1 válido:1 < input < 50 2 inválido: ítem 50

70 69 Principio del análisis de valores límites Fuente: Process Consulting Son situaciones directamente por encima o por debajo de los límites de entrada y salida de clases equivalentes El análisis de valores límites requiere que los elementos estén seleccionados de tal forma que cada límite de la clase equivalente sea sujeto a testing Busque: números, velocidad, caracteres, localización, posición, tamaño, cantidad

71 70 Principio del análisis de valores límites Fuente: Process Consulting Piense en las siguientes características First/Last Min/Max Start/Finish Over/Under Empty/Full Shortest/Longest Slowest/Fastest Soonest/Latest Largest/Smallest Highest/Lowest Next-To/Farthest-From

72 71 Probar errores Fuente: Process Consulting Es intuitivo y creativo Difícil de procedimentar La experiencia nos dan una percepción de aquellas pruebas que regularmente dan error Enumerar una lista de errores posibles o situaciones que pueden producir error y escribir casos de prueba en base a ello Ejemplo La presencia de ‘0’ en cálculos siempre producirá una situación de error Listas: vacías, un solo valor, todos con el mismo valor, lista con valores ya ordenados

73 72 Testing con tablas de decisión Fuente: Process Consulting CondicionesRegl a 1 Regl a 2 Regl a 3 Regl a 4 Se ha ingresado importe de repago VVFF Se ha ingresado términos del contrato VFVF Acciones / Resultados Importe del proceso de préstamos SI Términos del procesoSI

74 73 Transición de estado Fuente: Process Consulting Un modelo para hacer testing a alto nivel para la mayoría de sistemas Enfoca en los requerimientos críticos de sistema Se requiere crear un modelo de flujo de transacciones Examina atributos del flujo de datos Está basado en transacciones y datos, especialmente lugares de nacimiento y muerte Aplicable a sistemas en línea y batch Enfoca en transacciones y en cómo se rutean dentro del sistema

75 74 Técnica de Transición de Estados Fuente: Process Consulting Un mapa de transición de estados tiene: Cada único estado en el que el software puede estar La entrada o condición que toma ir de un estado al siguiente Que condiciones se establecen y cuáles resultados se producen cuando se ingresa o sale de un estado Para reducir la cantidad de casos de prueba Visite cada estado al menos una vez Prueba las transiciones mas comunes o populares Pruebe los caminos menos comunes entre estados Prueba los errores de estado y como regresar de un error de estado Prueba transiciones de estado aleatorias

76 75 Testing Fuente: Process Consulting ISO 9126

77 76 ISO 9126 Fuente: Process Consulting Es un estándar internacional para la evaluación de la calidad de software. El objetivo fundamental de este estándar es resolver algunos de los bien conocidos sesgos que pueden afectar negativamente la entrega y percepción de un proyecto de desarrollo de software. Estos sesgos incluyen cambiar prioridades después del inicio de un proyecto o no tener definiciones claras de éxito. El estándar ISO 9126 “Evaluación de Productos de Software – Características de Calidad y Guías” enfoca en la medición de la calidad de los sistemas de software. Este estándar internacional define la calidad de un producto de software en términos de 6 características principales y 21 subcaracterísticas y define un proceso para evaluar cada una de ellas

78 77 ISO 9126 Fuente: Process Consulting El modelo clasifica la calidad de software en un conjunto estructurado de características y sub-características: Funcionalidad (functionality): conjunto de atributos relativos a la existencia de un conjunto de funciones y sus propiedades especificadas Suitability: es la característica esencial de funcionalidad y se refiere a si las funciones del software son apropiados respecto a la especificación Accuracy: se refiere a si las funciones son correctas, por ejemplo un cajero dispensa dinero, pero ¿dispensa la cantidad correcta? Interoperability: habilidad de un componente de software de interactuar con otros componentes ó sistemas Compliance: cuando ciertas leyes y lineamientos apropiados de la industria deben satisfacerse Security: relativa al acceso no autorizado a las funciones de software

79 78 ISO 9126 Fuente: Process Consulting Confiabilidad (reliability): conjunto de atributos relativos a la capacidad del software de mantener su nivel de desempeño bajo condiciones establecidas por un periodo de tiempo establecido Maturity: frecuencia de fallas del software Recoverability: habilidad de restaurar un sistema que falló hacia la operación completa, incluyendo conexiones de datos y de red Fault tolerance: habilidad del software de resistir y recuperarse de una falla de componente o ambiente Facilidad de uso (usability): conjunto de atributos relativos al esfuerzo necesario para su uso y a la evaluación individual para tal uso, para un conjunto de usuarios Learnability: esfuerzo de aprendizaje para diferentes usuarios, es decir, novato, experto, casual, etc. Understandability: determina la facilidad con la cual las funciones del sistema pueden entenderse Operability: habilidad del software de ser fácilmente operado por un determinado usuario en un ambiente determinado

80 79 ISO 9126 Fuente: Process Consulting Eficiencia (efficiency): conjunto de atributos relativos a la relación entre el nivel de desempeño del software y la cantidad de recursos usados, bajo condiciones establecidas Time behaviour: tiempo de respuesta para una carga determinada, es decir, ratio de transacción Resource behaviour: recursos necesarios, por ejemplo uso de memoria, cpu y redes Facilidad de mantenimiento (maintainability): conjunto de atributos relativos al esfuerzo necesario para realizar modificaciones especificadas Stability: caracteriza la sensibilidad al cambio de un sistema dado, es decir, el impacto negativo que puede ser causado por cambios al sistema Analyzability: habilidad para identificar la causa raíz de una falla dentro del sistema Changeability: cantidad de esfuerzo para cambiar un sistema Testability: esfuerzo necesario para verificar (testear) un cambio de sistema

81 80 ISO 9126 Fuente: Process Consulting Portabilidad (portability): conjunto de atributos relativos a la habilidad del software a ser transferido e un entorno a otro Installability: esfuerzo requerido para instalar el software Replaceability: caracteriza el aspecto plug and play (pegar y funcionar) de los componentes de software, es decir, cuán fácil es intercambiar un componente específico de software en un entorno determinado Adaptability: caracteriza la habilidad del sistema para cambiar a nuevas especificaciones o entornos de operación Conformance: similar a compliance en funcionalidad, pero esta característica se refiere a portabilidad, por ejemplo a un estándar de base de datos en particular

82 81 Bibliografía ● CHRISSIS MARY BETH, KONRAD MIKE AND SHRUM SANDY (2003). CMMI: Guidelines for Process Integration an Producto Improvement. Addison Wesley, Abril 2003 ● DENNIS, M. AHERN (2003). CMMI Distilled: A Practical Introduction to Integrated Process Improvement. Second Edition, Addison Wesley, September 2003. ● CARNEGIE MELLON UNIVERSITY (2006). Capability Matutity Model Integration (CMMI) 1.1. ● ERIK VAN VEENENDAAL (2009). TMMI Fundation. Test Maturity Model Integration (TMMi) V2.0 ● WHITTAKER (2009). Exploratory Software Testing. Addison Wesley 2009. ● ELFRIEDE DUSTIN (2008). Implementing Automated Software Testing. Addison Wesley, 2008