Aseguramiento control calidad-software
66
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
Transcript of Aseguramiento control calidad-software
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
Agenda
1. Introducción2. Qué es el Aseguramiento de calidad3. Qué es el Control de calidad4. El entorno de la calidad5. Qué es un modelo de calidad de software6. Acerca de los modelos y estándares de calidad7. El enfoque basado en procesos8. Las metodologías ágiles
¿Qué es la calidad de software?
2
9. ¿Qué es la calidad de software?10. La perspectiva del usuario11. El proceso de pruebas como parte del proceso de desarrollo12. Estadísticas13. Bibliografía y sites recomendados
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 laspersonas 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 unrequisito 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 unproyecto de software.
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
AC
D
Introducción
La calidad del software puede gestionarse desde diferentes niveles:
• Visión de producto: enfoque en las pruebas a realizar en cada etapa delciclo de vida del desarrollo, para detectar y corregir los posibles defectosque puedan surgir.
• Visión de proceso: se enfoca en gestionar todas las áreas de proceso deuna organización mediante la implementación de una metodología de
5
una organización mediante la implementación de una metodología detrabajo.
• El enfoque basado en procesos permite obtener mayor información delos procesos, de modo que puedan controlarse y mejorarse, y produzcanasí un aumento de la calidad de los productos y servicios relacionadoscon ellos.
• 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”
• Tiene su foco de atención sobre los productos
• El rol del control de calidad es
– medir los productos contra estándares ó atributos previamentedefinidos
– 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 ladel producto final
• El una actividad “detectiva”
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
• 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…
El enfoque basado en Procesos
• La calidad de un producto está directamente influenciadapor la calidad de los procesos que se utilizaron paradesarrollarlo 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
• 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
Actividad
Actividad
Actividad
Objetivos
¿Qué es un proceso?
12
Proceso
Actividad
Actividad Actividad
Infraestructura y recursos
SalidasEntradas
Administrado Cuantitativamente
Optimizado
4
5Foco en la mejora de procesos
Proceso medido y controlado
Representación en etapas
El modelo CMMI
13
Definido
Inicial
Administrado
Proceso impredecible,pobremente controladoy reactivo
2
3
1
Proceso definido porproyecto 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
®
ISO 9001:2008
14
Este modelo de calidad clasifica en la primera parte del estándar, ISO 9126-1, la calidad delsoftware en un conjunto estructurado de características y subcaracterísticas de la siguientemanera:
ISO 9126
15
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 estabansurgiendo como alternativa a las metodologías formales a las que considerabanexcesivamente “pesadas” y rígidas por su carácter normativo y fuertedependencia de planificaciones detalladas previas al desarrollo.
16
• Esta nueva alternativa de desarrollo resume su método de trabajo en cuatropostulados. 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…
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
• 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 yel respaldo que necesitan y procurándoles confianza para que realicen la tarea.
• 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
Proceso creativo1
Niv
el d
e m
adu
rez
de
los
pro
ceso
s
Skill de los recursos
Procesos - Personas
20
Proceso definido
5
Niv
el d
e m
adu
rez
de
los
pro
ceso
sDefiniciónde procesos
0% 100%
Porcentaje de procesos definidos
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?
¿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 Managerde 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
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é seespera del software…
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
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
La perspectiva del Usuario
26
27Propaganda TBI –Caliber RM – Magazine Testing
and Quality Engineering October 2000
¿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?
¿Qué percibe el Usuario?
29
¿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 requerimientosadecuadamente?
Hablemos de costos
• Los costos por el incumplimiento son, entre otros, los gastos en losque incurrimos por reparar las cosas que hicimos mal.
• Pocas organizaciones calculan, los costos “de tener que volverhacia 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?
El proceso de pruebas
como parte del proceso de
32
como parte del proceso de
desarrollo de software
¿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
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
Modelo V&V
Test deAceptación
Visión general del
sistema
Especificación del sistema
Diseño yarquitectura
Test deIntegración
Test delSistema
35
Verificación Validación
arquitectura
Diseño detallado
TestUnitario
Integración
Código
Proceso de test estático
Aplicable a documentosy al códigoDetecta un alto número deerrores
Proceso de test dinámico
Involucra ejecuciónUsualmente 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
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
Modelo W
37
Una vez identificados los riesgos se especifica los productos que necesitan ser probados, acontinuación, seleccione las técnicas de pruebas (estáticas y dinámicas) a continuación, se planificanlas actividades de prueba lo más cerca posible a las actividades de desarrollo que generan losproductos a testear.
Test estático - VerificaciónSe 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: revisionesformales, 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 normasy estándares predefinidos. Existen herramientas para realizar análisis
38
y estándares predefinidos. Existen herramientas para realizar análisisestá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 sedeberá reflejar en las previsiones de pruebas dinámicas a realizar en el proceso de validación
Un auto es un sistema complejo, con muchos componentes.
Cada componente individual esinspeccionado y probado. (Pruebasde Unidad)
Una vez que todos los componentesson probados individualmente, los
Test dinámico - Validación
39
componentes son integrados hastaconstruir un auto. (Pruebas de Integraciòn)
Las Pruebas de Sistema se realizanuna vez ensamblado el auto completo para aseguar que el auto trabaja correctamente en variascondiciones.
Gentileza de Gesdas IT
Proceso general de test
40
Proceso general de test
Capacitación
Inicial Planificación Preparación EjecuciónEvaluación
final
Proceso general de test
41
Inicial
(Inducción)
Planificación Preparación Ejecuciónfinal
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
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)
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
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
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
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 depruebas adicionales)
47
pruebas adicionales)
Revisión interna
• Evaluación de mejoras al proceso de test• Análisis de backlog de defectos• Lecciones aprendidas
Desarrollo Producción
Circuito de Test
48
Versiones a probar
Ciclos de Test
Versión aimplementar
Ciclo de recorrido del producto
Ambiente de Producción
Ambiente deDesarrollo
Ambiente de Test
49
Modelos y estándares
para test
50
para test
TMMI – Test Maturity Model Integration
Administrado Cuantitativamente
Optimizado
4
5Foco 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, sindefinició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.
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
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 accionesconcretas 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.
TPI – Test Process Improvement
Área Clave Inicial Controlado Eficiente Optimizado
Organización del Test
Métricas
54
Gestión del proceso de Test
Otros…
Otros modelos
• Test Organisation Maturity Model (TOM™ )
• Test Improvement model TIM
• Minimal Test Practice Framewok MTPF
• Otros
55
Algunas estadísticas
56
¿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%
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 -
El lado humano de la calidad
59
“La calidad no está en las cosas,
sino en la gente que hace las cosas”
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
El lado humano de la calidad
Los Los 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.)
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
La calidad nunca es un accidente;
siempre es el resultado del
esfuerzo inteligente.
63
esfuerzo inteligente.
John Ruskin
Bibliografía recomendada
• Ingeniería del Software – Un Enfoque práctico Roger S. PressmanMac Graw Hill 4ta. Edición
• Effective Methods for Software Testing - William PerryWiley – QED
• Testing Computer Software – Kaner – Falk – NguyenInternational Thomson Computer Press
• Managing the Testing Process – Rex Black Microsoft Press
64
• Surviving the chalenges of Software TestingWilliam 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 losprofesionales de test)
• Magazine: Software Guru: www.softwareguru.com.mx
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
