Pruebas de Calidad de Software (PCS)

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

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?

Contenido 1.0 Conceptos 2.0 Roles 3.0 Entregables 4.0 Actividades
Anexos

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

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

Método Hitachi Fuente: Process Consulting

Método Hitachi – Resumen de fases

Éxito versus Catástrofe

Resumen de Observaciones
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 Fuente: Process Consulting

Errores detectados Fuente: Process Consulting

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”).

Anexos

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

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

Anexos

PCS - E - Plan de Pruebas – Plantilla.doc
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

PCS - E - Catálogo de Pruebas - Plantilla.xls
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

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

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

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

Anexos

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

Anexos

Gestión de Calidad ¿Cuánto cuesta corregir un error?
Costo $ 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. Inicio Desarrollo Estabilización Tiempo

Modelo de Referencia: Aseguramiento de Calidad en un Proceso Productivo
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. Construcción Construcción Construcción Verificación

IDEA / M+S: Base para Metodologías de TI
Inicio Desarrollo Estabilización Aprendizaje FP Planificación ... Metodología para Gestión de Proyectos (GPR) DC Control ... Gestión ID Modelamiento ... Metodología para Desarrollo de Software (DSW) PF Materialización ... Ejecución Metodología para Aseguramiento de la Calidad de Software (ACS) Metodología para Gestión de Cambios en Software (GCS)

Aseguramiento de Calidad: Verificación de Entregables de Gestión y de Ejecución
Inicio Desarrollo Estabilización Aprendizaje Definiciones Metodológicas Criterios de Calidad FP Planificación EG1 EG2 ... EG3 DC Control EG4 EG5 ... EG6 Gestión Control de Calidad para Entregables de Gestión (MGP) ID Modelamiento EE1 EE2 EE3 ... Control de Calidad para Entregables de Ejecución (MDS) RF Materialización EE4 EE5 ... EE6 Ejecución MGP = Metodología para Gestión de Proyectos MDS = Metodología para Desarrollo de Sistemas

CMMI: Capability Maturity Model Integration
Nivel Capacidad Resultado 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) 5 Mejora Continua de Procesos Innovación Organizativa y Despliegue Análisis Causal y Resolución Productividad & Calidad Opti-mizado Adminis-trado Cuantita-tivamente Adminis-tración Cuanti-tativa Administración de Procesos Cuantitativos Administración de Calidad de Software 4 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 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 Administrado 2 Esfuerzos Heroicos Diseño Desarrollo Integración Pruebas 1 Inicial Riesgo & Residuos

TMMI: Test Maturity Model Integration
(5) Optimización Prevención de Defectos Optimización de Proceso de Pruebas Control de Calidad (4) Gestión y Medición Medición de Pruebas Evaluación de Calidad del Software Revisión avanzada 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 (2) Planificación Estrategia de Pruebas Plan de Pruebas Seguimiento Diseño y Ejecución Ambiente de Pruebas 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. (1) Iniciación

ISTQB: International Software Testing Qualifications Boards
Revisar Niveles de Pruebas Definir una Estratégia o Plan de Pruebas Diseño de Casos de Prueba Gestión de Pruebas Herramientas de Pruebas Controlar (Evaluar y Reaccionar) Priorizar 1 2 3 4 Operar Pruebas a través del Ciclo de Vida de Desarrollo del Software Objetivos Descripción Criterios de Término Responsabilidades Adm.Biblioteca de Casos Herramientas Tipos de Pruebas Actividades Configuraciones Recursos 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 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.

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

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

Testing – Análisis Causal

La Medida de Yield Fase Yield Proceso 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

Testing PRINCIPIOS DE TESTING Fuente: Process Consulting

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

Podemos usar testing estático y dinámico
Testing temprano 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 Fuente: Process Consulting

¿Cuánto testing es suficiente?
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 Fuente: Process Consulting

Duración del testing 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 Fuente: Process Consulting

Duración del testing Atributos que afectan la duración del testing
Bajo impacto Aumenta la duración del testing  Alto impacto única Número de plataformas multi Usuarios internos Alcance del sistema Usuarios externos internas Interfases externas estable Estabilidad de los requerimientos En evolución incremental Estrategia de release Big-bang Familiar/establecida Tecnología Nueva/emergente bajo Impacto en el negocio del malfuncionamiento del sistema alto Stand-alone Conectividad Multi-sistema Read-only Acceso a la base de datos update Pre-construido Entorno de pruebas nuevo Fuente: Process Consulting

Duración del testing 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 Fuente: Process Consulting

Duración del testing 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) Fuente: Process Consulting

Clustering de los defectos
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 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 Fuente: Process Consulting

Segundo, el testing debe enfocarse en testing de alto impacto, en código de alto uso 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 Fuente: Process Consulting

Paradoja del pesticida
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 Fuente: Process Consulting

¿Está el software libre de defectos?
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 Fuente: Process Consulting

Falacia de la ausencia de errores
Si no encontramos defectos, significa que ¿los usuarios aceptarán el software? 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 Fuente: Process Consulting

Testing PROCESO DE TESTING Fuente: Process Consulting

Implementar y ejecutar Evaluar criterio de finalización e informar
Planificar el testing 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 Fuente: Process Consulting

Testing CONCEPTOS Y TÉCNICAS Fuente: Process Consulting

Planificar el testing Á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 Fuente: Process Consulting

Planificar el testing Á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 Fuente: Process Consulting

Planificar el testing 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 Fuente: Process Consulting

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

Fases ó Niveles de testing Testing de integración
Planificar el testing 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) Fuente: Process Consulting

Testing TÉCNICAS DE TESTING Fuente: Process Consulting

Técnicas de testing ¿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 Fuente: Process Consulting

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

Técnicas de testing 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 Fuente: Process Consulting

Técnicas de testing Reusar Profundidad Seguro
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 Fuente: Process Consulting

Técnicas de testing 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 Fuente: Process Consulting

Testing Basado en Riesgo
Técnicas de testing 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 Fuente: Process Consulting

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

Partición Equivalente
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 Fuente: Process Consulting

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

Principio del análisis de valores límites
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 Fuente: Process Consulting

Principio del análisis de valores límites
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 Fuente: Process Consulting

Es intuitivo y creativo Difícil de procedimentar
Probar errores 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 Fuente: Process Consulting

Testing con tablas de decisión
Condiciones Regla 1 Regla 2 Regla 3 Regla 4 Se ha ingresado importe de repago V F Se ha ingresado términos del contrato Acciones / Resultados Importe del proceso de préstamos SI Términos del proceso Fuente: Process Consulting

Transición de estado 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 Fuente: Process Consulting

Técnica de Transición de Estados
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 Fuente: Process Consulting

Testing ISO 9126 Fuente: Process Consulting

ISO 9126 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 Fuente: Process Consulting

Security: relativa al acceso no autorizado a las funciones de software
ISO 9126 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 Fuente: Process Consulting

Maturity: frecuencia de fallas del software
ISO 9126 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 Fuente: Process Consulting

Changeability: cantidad de esfuerzo para cambiar un sistema
ISO 9126 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 Fuente: Process Consulting

Installability: esfuerzo requerido para instalar el software
ISO 9126 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 Fuente: Process Consulting

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

Pruebas de Calidad de Software (PCS)

Presentaciones similares

Presentación del tema: "Pruebas de Calidad de Software (PCS)"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Pruebas de Calidad de Software (PCS)

Presentaciones similares

Presentación del tema: "Pruebas de Calidad de Software (PCS)"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback