PCS - C - Gua - Pruebas de Calidad de Software - Presentacin - 2011 04 18

Pruebas de Calidad de Software (PCS)
Gua del Componente Metodolgico
Aplica el Meta Modelo de Metodologas CREA (Conceptos, Roles, Entregables, Actividades)
Algunos problemas a enfrentar
Qu criterios de priorizacin y que tcnicas permitirn usar el tiempo de la manera ms productiva (maximizar el promedio de defectos identificados por hora)? Cul es la secuencia de Ciclos de Pruebas, incluyendo pilotos y paralelos ms adecuadas para nuestro proyecto especfico?
Cmo seleccionar las tcnicas que nos resulten de mayor valor, partiendo de las mejores prcticas incluidas en los enfoques metodolgicos disponibles?
Contenido
1.0 Conceptos 2.0 Roles 3.0 Entregables 4.0 Actividades
Anexos
Contenido
Anexos
Curva S: Cundo detener el testing?

120 100
Number of Tests
80 60 40 20 0 W1 W2 W3 W4 W5 W6 W7 W8 Project Week
Fuente: Process Consulting
Mtodo Hitachi
150
100
50
0 Phase 2 Phase 1
Phase 3 100%
6
Mtodo Hitachi Resumen de fases
xito versus Catstrofe

150 Success Failure 100 Catastrophe
50
0 Phase 2 Phase 1 Phase 3 100%

Resumen de Observaciones
Velocidad para terminar la fase 1 es relativamente constante a lo largo de proyectos
La duracin 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
Errores detectados
35
30
25
20
15 W1 W2 W3 W4 W5 W6 W7 W8
10
Curva Acumulativa de Errores: En que momento hacer el Pase a produccin
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 prximo ciclo de pruebas. Cuando esta pendiente empieza a disminuir es momento de decidir el lanzamiento a produccin (como se sabe no existe software sin errores, solo software cuto prximo error an no ha sido detectado).
11
Contenido
Anexos
12
Roles: Los genricos para Proyecto de Cambio

ADC - C - Gua - Aprendizaje y Desarrollo Colaborativo Presentacin .ppt
ADC - R - Aprendizaje y Desarrollo - Roles .xls
13
Roles: Los especficos para este Componente Metodolgico
PCS - R Pruebas de Calidad de Software - Roles .xls. PCS - C - Gua Pruebas de Calidad de Software - Presentacin .ppt
14
Contenido
Anexos
15
Plantilla: Plan de Pruebas

El Plan de Pruebas es un documento que establece las prcticas especficas 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
16
Plantilla: Catlogo de Pruebas
El Catlogo de Pruebas es un compendio de los casos de prueba que permiten verificar una serie de escenarios y elementos de una aplicacin de Software.
PCS - E - Catlogo de Pruebas - Plantilla.xls
17
Plantilla: Seguimiento de Observaciones al Software (Errores y Mejoras)
Propicia la adecuada identificacin de las observaciones crticas, separndolas de las nuevas necesidades o expectativas. Impulsa la solucin de problemas. PCS - E - Seguimiento de Observaciones al Software - Plantilla.xls.
18
Plantilla: Informe de Avance de Pruebas Integrales
19
Contenido
Anexos
20
Cronograma de Sesiones
21
Contenido
Anexos
22
Gestin de Calidad Cunto cuesta corregir un error?

Costo $ Ejemplo :
La frmula con que se calcula la mora fue mal definida desde el inicio.
Estabilizacin Desarrollo
Tiempo que toma corregir en :

- Arquitectura : 1h. - Programacin : 3 das. - Pruebas Integrales : 1 semana.
Inicio
- Implantacin : 4 semanas.
- En uso : 2 meses.
Tiempo
23
Modelo de Referencia: Aseguramiento de Calidad en un Proceso Productivo

A) Al final del Proceso
B) Durante todo el Proceso
Construccin
Construccin
Construccin
Verificacin
El aseguramiento de la calidad, en la Gestin y en la Ejecucin, debera ser efectuado en varios momentos del Desarrollo del Proyecto y no slo al final.
24
IDEA / M+S: Base para Metodologas de TI

Inicio Desarrollo Estabilizacin Aprendizaje
Planificacin
FP
... ...
Control
DC
Gestin
Metodologa para Gestin de Proyectos (GPR)
Modelamiento
ID
...
PF
Ejecucin
Metodologa para Desarrollo de Software (DSW)
Materializacin
...
Metodologa para Aseguramiento de la Calidad de Software 25 (ACS)
Metodologa para Gestin de Cambios en Software (GCS)
Aseguramiento de Calidad: Verificacin de Entregables de Gestin y de Ejecucin

Inicio Desarrollo Estabilizacin Aprendizaje
Definiciones Metodolgicas
Planificacin
EG1
FP E G2 ... DC ... E G5
EG3
Criterios de Calidad
Control
EG4
Gestin
EG6
Control de Calidad para Entregables de Gestin (MGP)
Modelamiento
EE1
ID E E2 ... RF EE5 ...
EE3
Control de Calidad para Entregables de Ejecucin (MDS)
Materializacin
EE4
Ejecucin
EE6
MGP = Metodologa para Gestin de Proyectos
MDS = Metodologa para Desarrollo de Sistemas 26
CMMI: Capability Maturity Model Integration

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) Nivel
Administrado Cuantita- Optitivamente mizado
Capacidad
Innovacin Organizativa y Despliegue Anlisis Causal y Resolucin
Resultado
Productividad & Calidad
5 4
Mejora Continua de Procesos Administracin Cuantitativa
Administracin de Procesos Cuantitativos Administracin de Calidad de Software
Estandarizacin de Procesos
Desarrollo de Requerimientos Solucin Tcnica Integracin de Productos Verificacin Validacin Enfoque Organizacional del Proceso Definicin Organizacional del Proceso Capacitacin Organizacional Administracin Integrada de Productos Administracin de Riesgos Equipo de Trabajo Integrado Administracin Integrada de Proveedor Anlisis Decisin y Resolucin Entorno de la Organizacin para la Integracin Administracin de Requerimientos Planificacin de Proyectos Monitoreo y Control de Proyectos Acuerdo de Gestin de Proveedor Medicin y Anlisis Aseguramiento de la Calidad del Producto y Proceso Administracin de la Configuracin Diseo Desarrollo Integracin Pruebas
Registro de Datos (Plan, Do, Check, Act) Control Estadstico del Proceso (Desviaciones)
2 1
Inicial
Administrado
Ingeniera del Proceso (Estndares de Pruebas)
Definido
Administracin Bsica de Proyectos
Esfuerzos Heroicos
Riesgo & Residuos
27
TMMI: Test Maturity Model Integration

(5) Optimizacin
Prevencin de Defectos Optimizacin de Proceso de Pruebas Control de Calidad
(4) Gestin y Medicin

Medicin de Pruebas Evaluacin de Calidad del Software Revisin avanzada de Pares
(3) Implementacin
Organizacin de Pruebas Elaboracin de Datos de Prueba Prueba de Ciclo de vida e Integracin Prueba No Funcional Revisin de Pares
(2) Planificacin
Estrategia de Pruebas Plan de Pruebas Seguimiento Diseo y Ejecucin Ambiente de Pruebas
(1) Iniciacin
El modelo TMMI, desarrollado por el Illinois Institute of Technology, como gua 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. 28
ISTQB: International Software Testing Qualifications Boards

Software Testing
Revisar Niveles de Pruebas
Definir una Estratgia o Plan de Pruebas
Diseo de Casos de Prueba
Gestin de Pruebas
Herramientas de Controlar Pruebas (Evaluar y Reaccionar)
Priorizar
Pruebas a travs del Ciclo de Vida de Desarrollo del Software
1
Objetivos Descripcin Criterios de Trmino Responsabilida des Adm.Biblioteca de Casos Herramientas Tipos de Pruebas Actividades Configuraciones Recursos
2
Tcnicas de Caja Negra Tcnicas de Caja Blanca Tcnicas Basadas en la Experiencia Seleccin de las Tcnicas de Pruebas
Operar
Organizacin Grabar Proceso Estadsticas Planificacin y de Negocio Estimacin Modificar Prueba Seguimiento y bajo Mltiples Control de Estado Escenarios Gestin de la Correr Pruebas Configuracin Usando Datos Riesgos Variables Gestin de Reportar Incidencias Diferencias Pruebas de Regresin
La norma internacional de la ISTQB con sede en Blgica, 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 proyeccin nica. 29
Dos conceptos importantes
ANLISIS CAUSAL Y YIELD
30
Tipos de Errores y Defectos

Especificacin
Errores en la especificaci n Errores en el diseo Diseo incorrecto por errores en especificacin
Diseo
Codificacin y PU
Testing
Codificacin Codificacin errada por incorrecta por errores en el errores en la diseo especificacin Es poco probable identificar y Es probable identificar y remover estos defectos, porque remover durante el testing. nadie sabe que existen o cules son. Se planifica su existencia? Se planifica su existencia? Tenemos datos de su Tenemos datos de su identificacin identificacin y remocin? y remocin? Pero el usuario los identificar en produccin
Errores en codificacin y PU
Defectos identificados despus del pase a produccin Tenemos datos?

31
Testing Anlisis Causal
32
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
33
Testing
PRINCIPIOS DE TESTING
34
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 crtica se prueba de forma diferente a un sitio de comercio electrnico
35
Testing temprano
Testing temprano
Como sea posible en el ciclo de vida del desarrollo de software o sistema y debe enfocarse en objetivos definidos una razn o propsito para disear y ejecutar un test. Los objetivos usualmente incluyen: Encontrar defectos Aumentar la confianza y proporcionar informacin acerca del nivel de calidad Prevenir defectos Podemos usar testing esttico y dinmico
36
Cunto testing es suficiente?

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
37
Duracin del testing

La cantidad de tiempo requerido para un testing adecuado depende de cuatro factores principales:
Calidad objetivo Cuan infestado de errores est el cdigo Capacidad y preparacin del equipo de testing El costo y presupuesto disponible
Estos factores dependen a su vez de otras caractersticas del equipo y sistema
38
Duracin del testing

Atributos que afectan la duracin del testing Bajo impacto nica Usuarios internos internas estable incremental Familiar/estableci da bajo Stand-alone Read-only Aumenta la duracin del testing Nmero de plataformas Alcance del sistema Interfases Estabilidad de los requerimientos Estrategia de release Tecnologa Impacto en el negocio del malfuncionamiento del sistema Conectividad Acceso a la base de datos Alto impacto multi Usuarios externos externas En evolucin Big-bang Nueva/emergente alto Multi-sistema update
Pre-construido
Entorno de pruebas
nuevo
39
Duracin del testing

Hay algunas circunstancias en las que las consecuencias de no cumplir con la fecha de trmino 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 trmino, perderemos participacin 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 trmino es mayor que el riesgo de detener el testing e implementar con menos calidad que la esperada
40
Duracin 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 informacin)
Severidad 1: un problema serio, el testing no puede continuar, no hay forma alternativa de continuar, si no se corrige rpidamente, 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 das) el plazo del testing puede continuar Severidad 3: todos los dems problemas (corregir o no a discrecin del gerente de proyecto en consulta con el analista funcional y el analista de negocio)
41
Clustering de los defectos

Un pequeo nmero de mdulos contienen la mayora de los defectos descubiertos durante las pruebas antes de liberar el producto o son responsables de la mayora de las fallas operacionales
42
Use Frequency
Literatura en testing apoya la visin que los defectos suceden en clusters, es decir, un pequeo porcentaje del cdigo, el llamado cdigo de alto riesgo, contendr un porcentaje desproporcionalmente alto de defectos Por tanto, el testing debe enfocar primero en identificar y validar el cdigo de alto riesgo La estrategia debe ser categorizar el nmero de casos de prueba. Cdigo de alto riesgo debe recibir saturacin de testing. Cdigo de bajo riesgo debe ser testeado muestralmente
HI
Value
LO LO Function Value HI
Hot Spots targeted for saturation testing based on shotgun results
43
Segundo, el testing debe enfocarse en testing de alto impacto, en cdigo de alto uso
High
High Degree of Testing

H r ui ed ig h
Extensive Testing
Function Usage Frequency

e gr e
Te f o
in st
eq
D Lo w
Low Low
Diagram Copyright IBM Corporation 1999

Business Impact
High
44
Combinando estas dos reas de enfoque tendremos una estrategia robusta en base a la aplicacin del principio 80/20 de deteccin de defectos
High
Extensive Testing
Function Usage Frequency
Low Low Business Impact High
45
Paradoja del pesticida

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 ms defectos
46
Est el software libre de defectos?

El testing muestra la presencia de defectos El testing puede mostrar que los defectos estn 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
47
Si no encontramos defectos, significa que los usuarios aceptarn 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
48
Testing
PROCESO DE TESTING
49
Planificar el testing
El testing es un proceso iterativo que incluye las siguientes actividades:
Planear y controlar Analizar y disear Implementar y ejecutar Evaluar criterio de finalizacin e informar Actividades de cierre
50
Testing
CONCEPTOS Y TCNICAS
51
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 tcnicos Por qu?
Usualmente no es factible un testing exhaustivo No es realista ni econmicamente viable Asegura que los aspectos crticos tanto desde el punto de vida de negocio como tcnico se pruebas para minimizar el riesgo
52
reas de enfoque del testing
reas de enfoque tpicas
Auditabilidad Continuidad operativa Correcto Flexible al mantenimiento Operabilidad Performance Portabilidad Confiabilidad Seguridad Facilidad de uso
53
Tipos de testing
Funcionalmente
Auditabilidad Flexibilidad de mantenimiento Facilidad de uso Pruebas de conversin Pruebas de documentacin y de procedimientos Manejos de errores de testing Pruebas funcionales Pruebas de instalacin Pruebas de interfases / y dentro del sistema Pruebas de paralelo
Pruebas de regresin
Pruebas de flujo de transaccin Pruebas de facilidad de uso
54
Tipos de testing
Estructural
Performance Backup y Recuperacin Pruebas de Seguridad Pruebas de Operacin Pruebas de Stress / de Volumen
55
Fases Niveles de testing
Testing unitario Testing de integracin Testing de sistema Testing de operabilidad validacin (aceptacin del usuario o tester independiente en ambiente similar al de operacin)
56
Testing
TCNICAS DE TESTING
57
Tcnicas de testing
Cmo disear el mejor conjunto de casos de prueba?
Cul subconjunto de casos de prueba tiene la probabilidad mas alta de detectar la mayor cantidad de errores? Respuesta: Usando tcnicas de testing
Tcnicas 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
58
Tcnicas de testing
Caja Negra
Caja Blanca
Producen casos de prueba basados exclusivamente en las especificaciones
Producen casos de prueba basados exclusivamente en el cdigo del programa
59
Tcnicas de testing
Tcnicas de seleccin de datos
Valores lmites Cobertura de sentencias Cobertura de condicin Mas probable Menos probable Verificacin de nulos Simular errores
60
Tcnicas de testing
Reusar
Siempre que sea posible reutilice casos de prueba
Profundidad
Primero mdulos crticos Para requerimientos de alto riesgo cuanto sea necesario y el tiempo lo permita
Seguro
Agregue pruebas aleatorias para escenarios de estrs e invlidos para estar seguros
Los casos de prueba deben considerar condiciones de entrada invlidas e inesperadas as como vlidas y esperadas No planifique el esfuerzo de testing asumiendo que no habrn errores La probabilidad que existan ms errores en la seccin de un programa es proporcional al nmero de errores ya encontrados
61
Tcnicas de testing
Rutas positivas (test to pass)
Hace el sistema lo que se supone que hace?
Rutas negativas (test to fail)

Cmo podemos hacer que esto falle?
Testing funcional
Cobertura completa Crear al menos un caso de prueba para cada requerimiento Verifica cada funcin o caracterstica del sistema en prueba, por lo menos con los casos de prueba necesarios para determinar cmo cada funcin es ejecutada
62
Tcnicas de testing
Testing de Dominio
nfasis en las variables de entrada, de salida, de configuracin o internas (por ejemplo relacionadas a archivos). Para cada variable o combinacin 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 ms casos de prueba en el cdigo ms 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
63
Tcnicas de testing
Particin Equivalente Anlisis de Valores o Condiciones Lmites
Probar Errores
Pruebas con tablas de decisin Probar Transicin de Estado
64
Particin Equivalente
Reduce el nmero 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 detectaran un error
Ejemplo
Vlido e invlido
65
Ejemplo de clases equivalentes

El campo X slo puede aceptar valores entre 1 y 50
1 vlido: 1 < input < 50 2 invlido: tem < 1, > 50
66
Principio del anlisis de valores lmites

Son situaciones directamente por encima o por debajo de los lmites de entrada y salida de clases equivalentes El anlisis de valores lmites requiere que los elementos estn seleccionados de tal forma que cada lmite de la clase equivalente sea sujeto a testing Busque:
nmeros, velocidad, caracteres, localizacin, posicin, tamao, cantidad
67
Principio del anlisis de valores lmites

Piense en las siguientes caractersticas
First/Last Min/Max Start/Finish Over/Under Empty/Full Shortest/Longest Slowest/Fastest Soonest/Latest Largest/Smallest Highest/Lowest Next-To/Farthest-From
68
Probar errores
Es intuitivo y creativo Difcil de procedimentar
La experiencia nos dan una percepcin 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
La presencia de 0 en clculos siempre producir una situacin de error Listas: vacas, un solo valor, todos con el mismo valor, lista con valores ya ordenados
Ejemplo
69
Testing con tablas de decisin
Condiciones Se ha ingresado importe de repago Se ha ingresado trminos del contrato Acciones / Resultados Importe del proceso de prstamos Trminos del proceso
Regl a1 V V
Regl a2 V F
Regl a3 F V
Regl a4 F F
SI SI
SI SI
70
Transicin de estado
Un modelo para hacer testing a alto nivel para la mayora de sistemas Enfoca en los requerimientos crticos 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 lnea y batch Enfoca en transacciones y en cmo se rutean dentro del sistema
71
Tcnica de Transicin de Estados

Un mapa de transicin de estados tiene:
Cada nico estado en el que el software puede estar La entrada o condicin que toma ir de un estado al siguiente Que condiciones se establecen y cules 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
72
Testing
ISO 9126
73
ISO 9126
Es un estndar internacional para la evaluacin de la calidad de software. El objetivo fundamental de este estndar es resolver algunos de los bien conocidos sesgos que pueden afectar negativamente la entrega y percepcin de un proyecto de desarrollo de software. Estos sesgos incluyen cambiar prioridades despus del inicio de un proyecto o no tener definiciones claras de xito.
El estndar ISO 9126 Evaluacin de Productos de Software Caractersticas de Calidad y Guas enfoca en la medicin de la calidad de los sistemas de software.
Este estndar internacional define la calidad de un producto de software en trminos de 6 caractersticas principales y 21 subcaractersticas y define un proceso para evaluar cada una de ellas
74
ISO 9126
El modelo clasifica la calidad de software en un conjunto estructurado de caractersticas y sub-caractersticas:
Funcionalidad (functionality): conjunto de atributos relativos a la existencia de un conjunto de funciones y sus propiedades especificadas
Suitability: es la caracterstica esencial de funcionalidad y se refiere a si las funciones del software son apropiados respecto a la especificacin
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
75
ISO 9126
Confiabilidad (reliability): conjunto de atributos relativos a la capacidad del software de mantener su nivel de desempeo 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 operacin 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 evaluacin 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 fcilmente operado por un determinado usuario en un ambiente determinado
76
ISO 9126
Eficiencia (efficiency): conjunto de atributos relativos a la relacin entre el nivel de desempeo del software y la cantidad de recursos usados, bajo condiciones establecidas
Time behaviour: tiempo de respuesta para una carga determinada, es decir, ratio de transaccin 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 raz de una falla dentro del sistema Changeability: cantidad de esfuerzo para cambiar un sistema Testability: esfuerzo necesario para verificar (testear) un cambio de sistema
77
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, cun fcil es intercambiar un componente especfico de software en un entorno determinado Adaptability: caracteriza la habilidad del sistema para cambiar a nuevas especificaciones o entornos de operacin Conformance: similar a compliance en funcionalidad, pero esta caracterstica se refiere a portabilidad, por ejemplo a un estndar de base de datos en particular
78
Bibliografa
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
79
Tipos de Controles de Calidad
Calidad de Arquitectura
Prueba de Funcionalidad
Prueba de Esfuerzo
Calidad de Codificacin
Calidad de GUIs
Calidad de Documentacin
80

PCS - C - Gua - Pruebas de Calidad de Software - Presentacin - 2011 04 18

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PCS - C - Gua - Pruebas de Calidad de Software - Presentacin - 2011 04 18

Cargado por

Copyright:

Formatos disponibles

Pruebas de Calidad de Software (PCS)

Gua del Componente Metodolgico

Aplica el Meta Modelo de Metodologas CREA (Conceptos, Roles, Entregables, Actividades)

Algunos problemas a enfrentar

1.0 Conceptos 2.0 Roles 3.0 Entregables 4.0 Actividades

1.0 Conceptos 2.0 Roles 3.0 Entregables 4.0 Actividades

Curva S: Cundo detener el testing?

Mtodo Hitachi Resumen de fases

Fuente: Process Consulting

xito versus Catstrofe

0 Phase 2 Phase 1 Phase 3 100%

Velocidad para terminar la fase 1 es relativamente constante a lo largo de proyectos

La duracin de la fase 1 determina el xito

Fuente: Process Consulting

Fuente: Process Consulting

Curva Acumulativa de Errores: En que momento hacer el Pase a produccin

1.0 Conceptos 2.0 Roles 3.0 Entregables 4.0 Actividades

Roles: Los genricos para Proyecto de Cambio

ADC - R - Aprendizaje y Desarrollo - Roles .xls

Roles: Los especficos para este Componente Metodolgico

1.0 Conceptos 2.0 Roles 3.0 Entregables 4.0 Actividades

Plantilla: Plan de Pruebas

PCS - E - Plan de Pruebas Plantilla.doc

Plantilla: Catlogo de Pruebas

PCS - E - Catlogo de Pruebas - Plantilla.xls

Plantilla: Seguimiento de Observaciones al Software (Errores y Mejoras)

Plantilla: Informe de Avance de Pruebas Integrales

1.0 Conceptos 2.0 Roles 3.0 Entregables 4.0 Actividades

1.0 Conceptos 2.0 Roles 3.0 Entregables 4.0 Actividades

Gestin de Calidad Cunto cuesta corregir un error?

Tiempo que toma corregir en :

Modelo de Referencia: Aseguramiento de Calidad en un Proceso Productivo

B) Durante todo el Proceso

IDEA / M+S: Base para Metodologas de TI

Metodologa para Gestin de Proyectos (GPR)

Metodologa para Desarrollo de Software (DSW)

Metodologa para Gestin de Cambios en Software (GCS)

Aseguramiento de Calidad: Verificacin de Entregables de Gestin y de Ejecucin

ID E E2 ... RF EE5 ...

MGP = Metodologa para Gestin de Proyectos

MDS = Metodologa para Desarrollo de Sistemas 26

CMMI: Capability Maturity Model Integration

Mejora Continua de Procesos Administracin Cuantitativa

Administracin de Procesos Cuantitativos Administracin de Calidad de Software

Ingeniera del Proceso (Estndares de Pruebas)

Administracin Bsica de Proyectos

Riesgo & Residuos

TMMI: Test Maturity Model Integration

(4) Gestin y Medicin

ISTQB: International Software Testing Qualifications Boards

Revisar Niveles de Pruebas

Definir una Estratgia o Plan de Pruebas

Diseo de Casos de Prueba

Herramientas de Controlar Pruebas (Evaluar y Reaccionar)

Dos conceptos importantes

ANLISIS CAUSAL Y YIELD

Fuente: Process Consulting

Tipos de Errores y Defectos

Defectos identificados despus del pase a produccin Tenemos datos?

Testing Anlisis Causal

Fuente: Process Consulting

Es el porcentaje de defectos que son removidos en una fase de desarrollo de software

Es el yield de todas las fases hasta un determinado punto del proceso

Fuente: Process Consulting