Escolar Documentos
Profissional Documentos
Cultura Documentos
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
Anexos
Contenido
Anexos
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
Fuente: Process Consulting
Phase 3 100%
6
50
Resumen de Observaciones
Errores detectados
35
30
25
20
15 W1 W2 W3 W4 W5 W6 W7 W8
10
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
13
PCS - R Pruebas de Calidad de Software - Roles .xls. PCS - C - Gua Pruebas de Calidad de Software - Presentacin .ppt
14
Contenido
Anexos
15
16
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.
17
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
19
Contenido
Anexos
20
Cronograma de Sesiones
21
Contenido
Anexos
22
Inicio
- Implantacin : 4 semanas.
- En uso : 2 meses.
Tiempo
23
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
Planificacin
FP
... ...
Control
DC
Gestin
Modelamiento
ID
...
PF
Ejecucin
Materializacin
...
Metodologa para Aseguramiento de la Calidad de Software 25 (ACS)
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
EE3
Control de Calidad para Entregables de Ejecucin (MDS)
Materializacin
EE4
Ejecucin
EE6
Capacidad
Innovacin Organizativa y Despliegue Anlisis Causal y Resolucin
Resultado
Productividad & Calidad
5 4
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
Definido
Esfuerzos Heroicos
27
(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
Gestin de Pruebas
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
30
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
31
32
La Medida de Yield
Fase Yield
Proceso Yield
33
Testing
PRINCIPIOS DE TESTING
34
35
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 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
37
38
Pre-construido
Entorno de pruebas
nuevo
39
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
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
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
43
Segundo, el testing debe enfocarse en testing de alto impacto, en cdigo de alto uso
High
Extensive Testing
Te f o
in st
eq
D Lo w
Low Low
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
45
46
47
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
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 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
Planificar el testing
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
Planificar el testing
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
Planificar el testing
Tipos de testing
Estructural
Performance Backup y Recuperacin Pruebas de Seguridad Pruebas de Operacin Pruebas de Stress / de Volumen
55
Planificar el testing
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
58
Tcnicas de testing
Caja Negra
Caja Blanca
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?
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
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
66
67
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
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
71
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
Fuente: Process Consulting
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
Calidad de Arquitectura
Prueba de Funcionalidad
Prueba de Esfuerzo
Calidad de Codificacin
Calidad de GUIs
Calidad de Documentacin
80