1. Seminario: Introducción a la
Gerencia Pública Informática
Módulo de Aseguramiento y
1
Módulo de Aseguramiento y
Control de calidad de software
Instructor: Alfonsina Morgavi
Disertante: Alfonsina Morgavi

2. Agenda
1. Introducción
2. Qué es el Aseguramiento de calidad
3. Qué es el Control de calidad
4. El entorno de la calidad
5. Qué es un modelo de calidad de software
6. Acerca de los modelos y estándares de calidad
7. El enfoque basado en procesos
8. Las metodologías ágiles
¿Qué es la calidad de software?
2
9. ¿Qué es la calidad de software?
10. La perspectiva del usuario
11. El proceso de pruebas como parte del proceso de desarrollo
12. Estadísticas
13. Bibliografía y sites recomendados

3. Introducción
• El concepto de calidad ha evolucionado a lo largo del tiempo… de Juran y
Deming … a la mejora de los procesos de una organización incluyendo a las
personas involucradas en dichos procesos.
• En la actualidad , la calidad ha pasado a ser una política de gestión
empresarial, donde el compromiso de todos los niveles organizativos es un
requisito para el éxito.
3
• El objetivo ya no es sólo la ausencia de defectos, sino la adecuación a los
requisitos de negocio y del cliente.
• Así la calidad está presente en todas las actividades del ciclo de vida de un
proyecto de software.

4. Introducción
Pilares sobre los que se sustentan las actividades de calidad:
• infraestructura apropiada de soporte
• un grupo de personas especializada en esta disciplina y
• procesos alineados con los objetivos de negocio de forma que permitan
una mayor industrialización en el desarrollo y mantenimiento.
4
TecnologíaRecursos humanos
B
Procesos
A
C
D

5. Introducción
La calidad del software puede gestionarse desde diferentes niveles:
• Visión de producto: enfoque en las pruebas a realizar en cada etapa del
ciclo de vida del desarrollo, para detectar y corregir los posibles defectos
que puedan surgir.
• Visión de proceso: se enfoca en gestionar todas las áreas de proceso de
una organización mediante la implementación de una metodología de
5
una organización mediante la implementación de una metodología de
trabajo.
• El enfoque basado en procesos permite obtener mayor información de
los procesos, de modo que puedan controlarse y mejorarse, y produzcan
así un aumento de la calidad de los productos y servicios relacionados
con ellos.

6. • Tiene su foco de atención sobre los procesos
• El rol del aseguramiento de calidad es
– gestionar la calidad
– monitorear y mejorar los procesos de trabajo
– establecer el control de calidad a realizar, pero no necesariamente
realizarlo
¿Qué es el aseguramiento de calidad?
6
realizarlo
– utilizar los resultados del control de calidad para mejorar los procesos
• El una actividad “preventiva”

7. • Tiene su foco de atención sobre los productos
• El rol del control de calidad es
– medir los productos contra estándares ó atributos previamente
definidos
– identificar defectos, informarlos y verificar sus correcciones
– desarrollar tareas de validación y verificación de productos
¿Qué es el control de calidad?
7
– desarrollar tareas de validación y verificación de productos
– chequear la calidad de los productos intermedios, como así también la
del producto final
• El una actividad “detectiva”

8. Es un conjunto de buenas prácticas para el ciclo de vida del
software, enfocado en los procesos de gestión y desarrollo
de proyectos.
Los modelos de calidad dicen QUE hacer no COMO hacerlo.
¿Que es un modelo de calidad de software?
8
¿Porque?
• Depende las metodologías que se utilice
• Depende de los objetivos de negocio

9. • McCall’s Quality Model
• Boehm’s Quality Model
• FURPS/FURPS+
• Dromey's Quality Model
• ISO 9001:2008
• ISO 9126
• Spice ISO/IEC 15504
Acerca los modelos y estándares de calidad
9
• Spice ISO/IEC 15504
• ISO 12207
• Estándares IEEE
• CMMI Capability Maturity Model Integration - TSP - PSP
• ITIL
• Six Sigma
• Métrica 3
• Moprosoft
• Competisoft
• Otros…

10. El enfoque basado en Procesos
• La calidad de un producto está directamente influenciada
por la calidad de los procesos que se utilizaron para
desarrollarlo y mantenerlo
• ¿Porqué son importantes los procesos?
– Porque los productos derivan de ellos
10
• Enfocándose en el proceso es posible predecir:
– Repetitibilidad de los productos intermedios y finales
– Tendencias en los proyectos
– Características de los productos

11. • Los modelos de calidad tradicionales están basados en la mejora de
procesos
• En general consisten en utilizar las mejores prácticas para el desarrollo y
mantenimiento de productos y servicios
El enfoque basado en Procesos
11
• Proporcionan un punto de partida y un marco de referencia, para definir
las mejoras a realizar en los procesos de una organización
• Describen un camino de mejora evolutivo para que las organizaciones
pasen de procesos inmaduros a procesos maduros de forma disciplinada

12. Actividad
Actividad
Actividad
Objetivos
¿Qué es un proceso?
12
Proceso
Actividad
Actividad Actividad
Infraestructura y recursos
SalidasEntradas

13. Administrado
Cuantitativamente
Optimizado
4
5 Foco en la mejora de procesos
Proceso medido y controlado
Representación en etapas
El modelo CMMI
13
Definido
Inicial
Administrado
Proceso impredecible,
pobremente controlado
y reactivo
2
3
1
Proceso definido por
proyecto y generalmente
reactivo
Proceso definido por la organización,
y proactivo
SEI original draws from course “Introduction to CMMI Staged representation V1.2”
Patents & Trademark Office By Carnegie Mellon University
®

14. ISO 9001:2008
14

15. Este modelo de calidad clasifica en la primera parte del estándar, ISO 9126-1, la calidad del
software en un conjunto estructurado de características y subcaracterísticas de la siguiente
manera:
ISO 9126
15

16. Las metodologías ágiles
• En el 2001 algunos disidentes del desarrollo de software basados en procesos,
exponen una nueva metodología denominada XP Extreme Programming.
• Nace el término “Métodos Ágiles” para definir a los métodos que estaban
surgiendo como alternativa a las metodologías formales a las que consideraban
excesivamente “pesadas” y rígidas por su carácter normativo y fuerte
dependencia de planificaciones detalladas previas al desarrollo.
16
• Esta nueva alternativa de desarrollo resume su método de trabajo en cuatro
postulados. Este postulado ha sido denominado como Manifiesto Ágil.
• Son frecuentes las posturas radicales entre los defensores de los modelos de
procesos y los defensores de modelos ágiles…

17. 1. Valorar más a los individuos y su interacción que a los procesos y las
herramientas
2. Valorar más el software que funciona que la documentación
exhaustiva
3. Valorar más la colaboración con el cliente que la negociación
Los 4 postulados del Manifiesto Ágil
17
3. Valorar más la colaboración con el cliente que la negociación
contractual
4. Valorar más la respuesta al cambio que el seguimiento de un plan

18. • Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y
continua de software de valor.
• Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo
• Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
• Entregar con frecuencia software que funcione, en periodos de un par de semanas
Los principios del Manifiesto Ágil 1/2
18
• Entregar con frecuencia software que funcione, en periodos de un par de semanas
hasta un par de meses, con preferencia en los periodos breves.
• Las personas del negocio y los desarrolladores deben trabajar juntos de forma
cotidiana a través del proyecto.
• Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y
el respaldo que necesitan y procurándoles confianza para que realicen la tarea.

19. • La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de
un equipo de desarrollo es mediante la conversación cara a cara.
• El software que funciona es la principal medida del progreso.
• Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores,
desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
• La atención continua a la excelencia técnica enaltece la agilidad.
Los principios del Manifiesto Ágil 2/2
19
• La atención continua a la excelencia técnica enaltece la agilidad.
• La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es
esencial.
• Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-
organizan.
• En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y
ajusta su conducta en consecuencia

20. Proceso creativo
1
Niveldemadurez
delosprocesos
Skill de los
recursos
Procesos - Personas
20
Proceso definido
5
Niveldemadurez
delosprocesosDefinición
de procesos
0% 100%
Porcentaje de procesos definidos

21. Todo proyecto tiene como objetivo producir
¿Qué es calidad en software?
La calidad del software es
una preocupación a la que se
dedican muchos esfuerzos.
Sin embargo, el software
nunca es perfecto.
21
Todo proyecto tiene como objetivo producir
software de la mejor calidad posible, que
cumpla, y si puede supere las expectativas
de los usuarios.
¿Pero qué esperan realmente del software
los distintos actores, involucrados en el
proceso de desarrollo?

22. ¿Qué es calidad en software?
IEEEd.
610-1990
“La calidad del software es el grado con el que un sistema,
componente o proceso cumple con los requerimientos
especificados y las necesidades o expectativas del cliente o
usuario”.
“Un software de calidad es aquel que cumple
con los requerimientos funcionales y de performance,
además de ser fácil de mantener, es confiable y
aceptable”
Un Manager
de TI…
22
aceptable”
Un Usuario
Un software que permite llevar adelante correctamente la
operatoria de un negocio en el mundo real, que pueda
iniciar y finalizar las operaciones que tengo que realizar sin
sorpresas…
Otros…
• Calidad, es mucho más que ausencia de “Bugs”
• La calidad no es un destino final, sino un viaje
• La calidad es un concepto multidimensional

23. Planificación:
• si la planificación es poco realista…
Requerimientos:
• si los requerimientos son pobres, confusos, incompletos, demasiado
generales y no se pueden testear…
Algunos problemas de la industria…
23
Pruebas:
• si no se realizan las pruebas adecuadas no se sabrá el verdadero
status del software hasta que nos lo diga el usuario final…
Comunicación:
• si los involucrados en el proceso de desarrollo no conocen qué se
espera del software…

24. Una organización inmadura
Trabaja desde el “matafuegos” en vez de
prevenir y controlar
Improvisa y actúa en respuesta a las crisis
Una organización madura
Define
Previene
Estima basándose en experiencias
Tipos de organizaciones…
24
Estima en forma idealista
No define la calidad de los productos
sobre una base objetiva
Estima basándose en experiencias
anteriores, reales y cuantificadas
Tiene objetivos cuantificables para medir
la calidad de sus productos
Controla la calidad de los productos que
produce
No puede predecir la calidad de los productos Puede predecir la calidad de los productos

25. Requerimientos
• Documentados
• Claros
• Completos
• Alcanzables
• Acordados
Planificación
• Deben planificarse
tiempos para:
• El diseño
• Las pruebas
• La corrección de
errores:
• Nuevas pruebas
Pruebas
• Planificadas
• Diseñadas
• Ejecutadas
• Informadas
Comunicación
• Implementar
instrumentos de
comunicación
• Fomentar el
trabajo en equipo
• Asegurarse de que
la información del
Algunas soluciones para la industria
25
• Documentar
• Y todas las otras
actividades a realizar
durante el proyecto
la información del
proyecto esté
disponible y
actualizada
Se trata de implementar prácticas que por experiencia
sabemos, mejorarán el proceso de desarrollo y el producto final

26. La perspectiva del Usuario
26

27. 27
Propaganda TBI –Caliber RM – Magazine Testing
and Quality Engineering October 2000

28. ¿Qué percibe el Usuario?
¿Si hace que sean más extensos que antes?
¿Si hace que sea necesario definir procesos adicionales, dejando algunos
antiguos procesos obsoletos?
¿Y si este software no encaja con los procesos del negocio?
¿Si hace que los procesos sean más complejos o dificultosos que antes?
¿Cubre este software mis necesidades?
28
¿Cubre este software mis necesidades?
¿Hasta dónde responde a mis requerimientos?
¿Cómo funcionará en mi ambiente real de
trabajo?

29. ¿Qué percibe el Usuario?
29

30. ¿Cuánto dinero gastan las
empresas en batallas entre áreas
de la misma Organización?
¿Qué percibe el Usuario?
30
¿Cuánto dinero gastan las
empresas por no haber
explicitado los requerimientos
adecuadamente?

31. Hablemos de costos
• Los costos por el incumplimiento son, entre otros, los gastos en los
que incurrimos por reparar las cosas que hicimos mal.
• Pocas organizaciones calculan, los costos “de tener que volver
hacia atrás”
• Costo de demandas …
31
• Costo de demandas …
¿ Cuál es el costo del daño de la marca?
¿ Cuál es el costo de la interrupción de un servicio?
¿ Cuál es el costo de un usuario insatisfecho?

32. El proceso de pruebas
como parte del proceso de
32
como parte del proceso de
desarrollo de software

33. ¿Qué es testear?
Es el proceso de analizar los componentes
del software para detectar diferencias
entre lo existente y las condiciones
requeridas y evaluar
33
las características o rasgos de cada
componente del mismo.
IEEE

34. Las pruebas (proceso dinámico)
implican operar un sistema en
condiciones controladas y realizar la
evaluación de los resultados.
¿Qué es Testear?
Es hacer una investigación empírica, con el objetivo de proveer información
objetiva acerca de la calidad de un producto.
34
evaluación de los resultados.
Las condiciones controladas deberían
incluir tanto condiciones normales
como anormales.
Es un proceso detectivo

35. Modelo V&V
Test de
Aceptación
Visión general
del
sistema
Especificación
del sistema
Diseño y
arquitectura
Test de
Integración
Test del
Sistema
35
Verificación Validación
arquitectura
Diseño
detallado
Test
Unitario
Integración
Código
Proceso de test estático
Aplicable a documentos
y al código
Detecta un alto número de
errores
Proceso de test dinámico
Involucra ejecución
Usualmente revela
síntomas
Verificación y Validación son complementarios
“Test” es genérico puede significar verificación, validación ó ambos
Históricamente “test” ha significado validación

36. Modelo W
36
Validación: consiste
mayormente en la ejecución de
código
Verificación: algunos definen
esta etapa como la del “test
humano”, ya que consiste en
trabajar sobre documentos “en
papel”, trabajo de escritorio

37. Modelo W
37
Una vez identificados los riesgos se especifica los productos que necesitan ser probados, a
continuación, seleccione las técnicas de pruebas (estáticas y dinámicas) a continuación, se planifican
las actividades de prueba lo más cerca posible a las actividades de desarrollo que generan los
productos a testear.

38. Test estático - Verificación
Se realiza sobre los requerimientos, especificaciones , y todo tipo de
documentos ó artefactos generados durante la 1ra etapa del desarrollo.
• Revisión de diferentes tipos de documentos tales como: revisiones
formales, inspecciones, walkthroughs entre otros. Cada una de estas
técnicas tiene su método de trabajo.
• Análisis estático de código: se verifica la adherencia del código a normas
y estándares predefinidos. Existen herramientas para realizar análisis
38
y estándares predefinidos. Existen herramientas para realizar análisis
estático de código…
• El test estático detecta errores tempranamente, también errores
potenciales.
• Realizar tests estáticos brinda una mejor visión y conocimiento del
de los objetivos del software , sus fortalezas y debilidades; lo que se
deberá reflejar en las previsiones de pruebas dinámicas a realizar en el
proceso de validación

39. Un auto es un sistema complejo, con
muchos componentes.
Cada componente individual es
inspeccionado y probado. (Pruebas
de Unidad)
Una vez que todos los componentes
son probados individualmente, los
Test dinámico - Validación
39
componentes son integrados hasta
construir un auto. (Pruebas de
Integraciòn)
Las Pruebas de Sistema se realizan
una vez ensamblado el auto
completo para aseguar que el auto
trabaja correctamente en varias
condiciones.
Gentileza de Gesdas IT

40. Proceso general de test
40
Proceso general de test

41. Capacitación
Inicial Planificación Preparación Ejecución
Evaluación
final
Proceso general de test
41
Inicial
(Inducción)
Planificación Preparación Ejecución
final

42. Capacitación Inicial
Recopilación de documentación existente
Verificación de grado de actualización (versión…)
Relevamiento a: analistas, usuarios, áreas de negocio
42
Generación de documentación adicional
Validación de la documentación generada

43. Planificación
• Relevamiento funcional de los circuitos críticos (riesgos)
• Diseño del plan de pruebas, (entre otros puntos) se deberá especificar:
• Especificación de tipos de Test a realizar y alcance de las pruebas
• Definición de procedimientos estándares para las pruebas
43
• Definición de procedimientos estándares para las pruebas
• Definición de circuitos de información entre Test y Desarrollo
• Definición estándar para la clasificación de defectos
• Definición de recursos a utilizar
• Objetivos de cada etapa del test (unit, integración, sistema, UAT,
otros)

44. Planificación
• Criterio de finalización
• Calendarios
• Roles y Responsabilidades:
• quien diseña, quien ejecuta, quien verifica los casos de prueba…
• quien corrige los errores, y ejecuta el test de regresión…
• Herramientas a utilizar
• Configuraciones especificas de hardware
44
• Configuraciones especificas de hardware
• Procedimientos de Seguimiento del proyecto de test
• Validación con stakeholders

45. Preparación
• Diseño de casos de prueba
• Carga de inicial de información en la herramienta de gestión
• Generación de informes de avance del proyecto
45
• Generación de informes de avance del proyecto
• Evaluación preliminar de transacciones a automatizar
• Validación con analistas funcionales, ó áreas de negocio

46. Ejecución
• Ejecución de los casos de prueba
• Generación de reportes de defectos
• Seguimiento de reportes de defecto
46
• Seguimiento de reportes de defecto
• Generación de informes de avance del proyecto
• Ajuste de Plan y Casos de prueba
• Validación con analistas funcionales / áreas de negocio

47. Evaluación final
• Generación del Informe de final de pruebas
• Revisión de informe final con stakeholders
• Evaluación general del proyecto y ajustes (definición de
pruebas adicionales)
47
pruebas adicionales)
Revisión interna
• Evaluación de mejoras al proceso de test
• Análisis de backlog de defectos
• Lecciones aprendidas

48. Desarrollo Producción
Circuito de Test
48
Versiones
a probar
Ciclos de
Test
Versión a
implementar

49. Ciclo de recorrido del producto
Ambiente de
Producción
Ambiente de
Desarrollo
Ambiente de
Test
49

50. Modelos y estándares
para test
50
para test

51. TMMI – Test Maturity Model Integration
Administrado
Cuantitativamente
Optimizado
4
5
Foco en la mejora de procesos, y en las herramientas
Proceso medido y controlado, objetivos
cuantitativos para la calidad del producto y el
rendimiento de los procesos
51
Definido
Inicial
Administrado
Proceso caótico, sin
definición
2
3
1
Valida que el producto
satisface los requerimientos,
Solo se realiza test post-codificación
Proceso y estándares definidos,
proactividad en la mejora de los mismos
TMMi® is the registered trademark of the TMMi Foundation.

52. TMAP –Test Management Approach
Plan
Ctrl
Prep Spec Exec Comp
Preparación Especificación Ejecución Evaluación
Control
Es un estándar para pruebas estructuradas
Business Driven Test Management -BDTM.
Gestiona los proyectos basándose en 4
aspectos fundamentales:
• Tiempo
• Costos
52TMap was created by the dutch division of Sogeti which is part of Capgemini.
Planificación
Plan
Infra
Prep Spec Exec Comp
Setup y mantenimiento de infraestructura
• Costos
• Riesgos
• Resultados
Modelo de ciclo de vida de TMAP

53. TPI NEXT – Test Process Improvement
El modelo TPI ha crecido a partir de la experiencia y proporciona un marco de referencia
para determinar los puntos fuertes y débiles del proceso de pruebas y formular acciones
concretas y realistas de mejora para este proceso.
53Copyright © 2009 Sogeti or one of its affiliates. All rights reserved TPI® is a registered trademark of Sogeti.

54. TPI – Test Process Improvement
Área Clave Inicial Controlado Eficiente Optimizado
Organización del Test
Métricas
54
Gestión del proceso de Test
Otros…

55. Otros modelos
• Test Organisation Maturity Model (TOM™ )
• Test Improvement model TIM
• Minimal Test Practice Framewok MTPF
• Otros
55

56. Algunas estadísticas
56

57. ¿Dónde se originan mayormente los defectos?
30%
40%
50%
60%
27%
56%
57Datos publicados con la autorización del Quality Assurance Institute -
57
La mayor parte de los defectos son creadoscreados en las “primeras“primeras
etapas”etapas” de los proyectos
0%
10%
20%
Código Otros Diseño Requerimientos
7%
10%

58. 20%
25%
30%
35%
40%
45%
50%
15%
50%
15%
¿Dónde son utilizados más habitualmente los recursos de test?
58
0%
5%
10%
15%
Propuestas Requerimientos Diseño Código Test Instalación
3%
10%
7%
La mayor parte de los defectos son encontradosencontrados en las “últimas“últimas etapas”etapas” del
proyecto.
Datos publicados con la autorización del Quality Assurance Institute -

59. El lado humano de la calidad
59
“La calidad no está en las cosas,
sino en la gente que hace las cosas”

60. El lado humano de la calidad
Si tuviéramos que dar una descripción de
las habilidades que serían necesarias para
un tester, deberíamos verlo desde 2
perspectivas:
60
habilidades técnicas y habilidades
personales

61. El lado humano de la calidad
LosLos testerstesters se entrenan, no nacense entrenan, no nacen
• Específico, en los distintos aspectos de la actividad
En herramientas específicas
61
• En herramientas específicas
• En nuevas tecnologías
• En aspectos de negocios (finanzas, energía, telcos, etc.etc.)

62. El lado humano de la calidad
Algunas cualidades personales a desarrollar:
• buena comunicación oral y escrita
• trabajo en equipo
• escucha activa
62
• actitud integradora
• visión global
• habilidades de negociación
• pasión por aprender

63. La calidad nunca es un accidente;
siempre es el resultado del
esfuerzo inteligente.
63
esfuerzo inteligente.
John Ruskin

64. Bibliografía recomendada
• Ingeniería del Software – Un Enfoque práctico Roger S. Pressman
Mac Graw Hill 4ta. Edición
• Effective Methods for Software Testing - William Perry
Wiley – QED
• Testing Computer Software – Kaner – Falk – Nguyen
International Thomson Computer Press
• Managing the Testing Process – Rex Black Microsoft Press
64
• Surviving the chalenges of Software Testing
William Perry – Randall Rice - Dorset House Publishing
• The Journal of the Quality Assurance Institute
• Magazine: “Software Testing & Quality Engineering” – STQE Magazine
• Magazine: Testing experiences. www.testingexperience.com (la revista de los
profesionales de test)
• Magazine: Software Guru: www.softwareguru.com.mx

65. http://www.sqatester.com/documentation/testcasesmpl.htm
http://www.softwareqatest.com/qatfaq2.html
http://www.softwaremetrics.com/Articles/defects.htm
www.stickyminds.com
http://blogs.msdn.com/chappell/archive/2004/03/25/96541.aspx
http://www.satisfice.com/
Sites recomendados
65
http://www.softwaretest.force9.co.uk/cont431.htm
http://www.faqs.org/qa/qa-6667.html
http://www.sdmagazine.com/documents/s=7360/sdm0003c/
www.QualityVista.com
http://www.qaforums.com/
http://www.testing.com/writings.html
http://www.aptest.com/glossary.html#M

66. Gracias por su atenciónGracias por su atención
Consultas......Consultas......
66
alfonsina.morgavi@gmail.com