Calidad de software y TDD

2.762 visualizaciones

Publicado el

Tópicos sobre calidad de software y conceptos sobre TDD

Publicado en: Tecnología
0 comentarios
1 recomendación
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
2.762
En SlideShare
0
De insertados
0
Número de insertados
955
Acciones
Compartido
0
Descargas
73
Comentarios
0
Recomendaciones
1
Insertados 0
No insertados

No hay notas en la diapositiva.

Calidad de software y TDD

  1. 1. CALIDAD DE SOFTWARE
  2. 2. Calidad de Software  Introducción: Mas allá de la codificación  Ciclo de vida: Desde la concepción hasta la descontinuación  Calidad: Lugar de la calidad en el desarrollo de software  Beneficios
  3. 3. ¿Qué es Calidad? Antes de Iniciar….
  4. 4. ¿Qué es Calidad? Hacer las cosas correctas Hacer las cosas correctamente Cumplir normas como ISO Satisfacción del ClienteCumplir con los requerimientos
  5. 5. Definiciones mayormente aceptadas (ANSI/IEEE 828, 1990) El nivel en el cual un sistema, componente o proceso cumple con los requerimientos definidos. El nivel en el cual un sistema, componente o proceso cumple con las necesidad o expectativas del cliente.
  6. 6. Ciclo de Vida del Software
  7. 7.  Introducción: Mas allá de la codificación.  El ciclo de vida: Desde la concepción hasta la descontinuación.  Calidad: Lugar de la calidad en el desarrollo de software.  Beneficios de la calidad en el ciclo de vida. Ciclo de Vida del Software
  8. 8. Ciclo de Vida del Software Introducción: Mas allá de la codificación Habilidades ROLES DE INGENIERÍA
  9. 9. Ciclo de Vida del Software Introducción: Mas allá de la codificación Ingeniería de Software Disciplina de implementación -Requerimientos - Arquitectura - Pruebas - Configuración de versiones - Gestión del proyecto
  10. 10. Ciclo de Vida del Software El ciclo de vida: Desde la concepción hasta la descontinuación Ingeniería de Sistemas Análisis de Requerimientos Diseño Codificación Pruebas Mantenimiento
  11. 11. Ciclo de Vida del Software Desde la concepción hasta la descontinuación - Concepción del proyecto - Interacción continua con el cliente - Recabación de información - Necesidades del Cliente Ingeniería de Sistemas
  12. 12. Ciclo de Vida del Software Desde la concepción hasta la descontinuación - Correcto entendimiento - Requerimientos correctos - Definición de requerimientos - Gestión de los requerimientos - Requerimientos Análisis de Requerimientos
  13. 13. Ciclo de Vida del Software Desde la concepción hasta la descontinuación - Modelos - Arquitectura - Procedimientos y Clases - Arquitectura Diseño
  14. 14. Ciclo de Vida del Software Desde la concepción hasta la descontinuación - Lenguajes de Programación - Implementación de modelos -Integración de componentes - Software o prototipos Codificación
  15. 15. Ciclo de Vida del Software Desde la concepción hasta la descontinuación - Verificación de componentes - Validación de requerimientos - Estándares y Procesos - Certificación de Producto Pruebas
  16. 16. Ciclo de Vida del Software Desde la concepción hasta la descontinuación - Gestión de Cambios - Actualizaciones - Descontinuación Mantenimiento
  17. 17. StatusStatusCodificación y Pruebas Codificación y Pruebas Document.Document. CambiosCambios Gestión de Config. Gestión de Config. EstándaresEstándares Ciclo de Vida del Software Calidad: Lugar de la calidad en el desarrollo de software. Revisiones y Auditorías Revisiones y Auditorías Gestión de Proyecto Gestión de Proyecto Revisión de Vendedores Revisión de Vendedores Revisión de Contratos Revisión de Contratos Empaqueta- miento y envío Empaqueta- miento y envío SeguridadSeguridad Gestión de la Calidad
  18. 18. Ciclo de Vida del Software Calidad: Beneficios Cliente Proveedor - Satisfacción - Confianza - Menos errores - Requerimientos cumplidos -Cumplir con requerimientos - Estabilidad - Implementación - Verificación - Procesos consistentes - Mejora de procesos
  19. 19. Software Testing
  20. 20. AGENDA:  Conceptos Básicos  Tipos de Testing  Ciclo de vida del Software Testing  Herramientas  Mitos
  21. 21. Conceptos Básicos ¿Qué es Software Testing?
  22. 22. Conceptos Básicos Software Testing Para Recordar QA Establece y evalúa los procesos que producen los productos QC Verifica y valida si los productos cumplen con los requerimientos o estándares Disciplina de Software Testing Conjunto de actividades llevadas a cabo con el objetivo de encontrar errores en el SW.
  23. 23. Software Testing Conceptos Básicos (IEEE Std 829)  Proceso que consiste en ejercitar el software para verificar si este satisface los requerimientos especificados y para detectar errores.  Proceso de analizar un sistema de software para detectar diferencias entre las condiciones existentes y las requeridas (osea bugs) y evaluar las características de dicho sistema de software.
  24. 24. Software Testing ¿Por qué hacer Software Testing? Conceptos Básicos
  25. 25. Software Testing Conceptos Básicos
  26. 26. Software Testing ¿Para qué hacer Software Testing? Conceptos Básicos
  27. 27. Software Testing ¿Para qué hacer Software Testing? Conceptos Básicos Detectar defectos en el software Reportar defectos Sugerir mejoras Facilitar implementación de requerimientos Incrementar el nivel de calidad del software Minimizar el número de errores encontrados por el cliente
  28. 28. Software Testing Conceptos Básicos ¿Quién? Equipo de QA de un proyecto Equipo de desarrollo de un proyecto Departamento de calidad de una compañía Compañía externa (Outsourcing) En general: Todo el equipo involucrado en el desarrollo de un producto
  29. 29. Pruebas de Integración Pruebas de Validación Pruebas de Sistema Pruebas de unidad Software Testing Conceptos Básicos ¿Cuando? A lo largo de todo el ciclo de vida del proyecto
  30. 30. - Unidad - Integración - Funcionalidad - Usabilidad - Sistema -Performance - Seguridad Tipos de Testing Software Testing REQSREQS TESTSTESTS
  31. 31. Tipos de Testing Software Testing Pruebas de Unidad Valida que las unidades individuales de código fuente están funcionando apropiadamente. Una unidad es la parte mas pequeña testeable de una aplicación. El objetivo de las pruebas de unidad es aislar cada parte del programa y mostrar que cada parte individual es correcto.
  32. 32. Tipos de Testing Software Testing Pruebas de Integración Las pruebas de integración es un tipo de pruebas en el cual diferentes módulos del software se combinan y testean como un grupo. El objetivo de este tipo de pruebas es verificar funcionalidades, la performance y la confiabilidad de un producto.
  33. 33. Tipos de Testing Software Testing Pruebas Funcionales Utilizado para verificar si un producto cumple con los requerimientos y especificaciones funcionales.
  34. 34. Tipos de Testing Software Testing Pruebas de Usabilidad Este tipo de pruebas sirve para evaluar un producto desde el punto de vista de un usuario y su rápida adecuación al sistema. Involucra input directo sobre como los usuarios reales usarán el sistema.
  35. 35. Tipos de Testing Software Testing Pruebas de Sistema Es llevado a cabo en un sistema integrado y completo para evaluar los requerimientos especificados como un todo. Este no debería requerir conocimiento del diseño interno del código o lógica de programación. Es ejecutado en la totalidad del sistema.
  36. 36. Tipos de Testing Software Testing Pruebas de Performance Permite determinar que tan rápido algunos aspectos del sistema funciona bajo una particular carga de trabajo. Es utilizado para determinar la velocidad o efectividad de un software.
  37. 37. Tipos de Testing Software Testing Pruebas de Seguridad Proceso para determinar que un sistema de información protege los datos y mantiene la funcionalidad tal y como se espera que fuese. Básicamente, lo que se quiere verificar en este tipo de pruebas es que el software brinde confidencialidad, integridad, autenticación, autorización, disponibilidad y auditoría
  38. 38. White Box TestingBlack Box Testing Tipos de Testing: Técnicas Software Testing Pruebas de Caja Negra: Pruebas en base a aun requerimiento como output sin necesidad de conocer la estructura interna o códigos del programa. Puede ser funcional o no funcional, aunque usualmente funcional. OUTPUTINPUT Pruebas de Caja Blanca: También conocido como “Glass Box”o “Clear Box” Testing, para cuya ejecución es necesario tener conocimiento acerca de la estructura interna y código fuente del programa
  39. 39. Ciclo de vida Software Testing PlanificaciónPlanificación DefiniciónDefinición EjecuciónEjecución ReporteReporte AnálisisAnálisis AutomatizaciónAutomatización
  40. 40. Ciclo de vida Software Testing PlanificaciónPlanificación - Estructura de Definición de Trabajo (EDT) - Plan de Gestión de las Pruebas
  41. 41. Ciclo de vida Software Testing DefiniciónDefinición - Plan de Pruebas
  42. 42. Ciclo de vida Software Testing AutomatizaciónAutomatización - Scripts de prueba - Inventario de scripts EjecuciónEjecución - Total de Casos de Prueba: - Ejecutados - Exitosos - Fallidos - Modificados
  43. 43. Ciclo de vida Software Testing ReporteReporte - Reporte de Defectos y Mejoras - Reporte de Performance - Reporte de Nivel de Seguridad AnálisisAnálisis - Informe de Evaluación del Sistema
  44. 44. Ciclo de vida Software Testing ReporteReporte - Reporte de Defectos y Mejoras - Reporte de Performance - Reporte de Nivel de Seguridad AnálisisAnálisis - Informe de Evaluación del Sistema
  45. 45. Herramientas Software Testing HerramientasHerramientas
  46. 46. Software Testing y Software Development
  47. 47. AGENDA:  Introducción  Que se Entiende por Pruebas Funcionales.  Que se Entiende por Pruebas de Rendimiento.  Desarrollo orientado a las pruebas.  Como debe de estar preparado tu equipo de desarrollo.  Tracking o seguimiento de errores.  Como asegurar la calidad de nuestro código.
  48. 48. TIPOS DE PRUEBA Que entiendes por pruebas funcionales? Que entiendes por pruebas de rendimiento?
  49. 49. Desarrollo orientado a las pruebas Test Driven Development “Desarrollo guiado por pruebas significa que escribes un test automático y, a continuación, escribes el código suficiente para pasar dicho test y después refactorizar el código, principalmente para mejorar la legibilidad y eliminar duplicaciones.”
  50. 50. REFLEXIONES SOBRE TDD  TDD es duro, los desarrolladores tardan tiempo en poder entenderlo. La estrategia de aprendizaje es juntar a un desarrollador con experiencia con los de menos experiencia.  Una vez que un desarrollador le agarra la “onda” es difícil que pueda dejar de usar TDD.  TDD tiene un efecto positivo en el diseño y costos del sistema del sistema.  TDD reduce los costos ocultos del software.
  51. 51. REFLEXIONES SOBRE TDD  Se tarda un tiempo en conseguir que TDD funciona en un nuevo producto, especialmente con pruebas de integración tipo “caja negra”,pero el retorno de la inversión es justificado.  Asegúrate de que inviertes suficiente tiempo en hacer que a los desarrolladores les resulte fácil escribir código para pruebas. Esto significa conseguir las herramientas adecuadas, educar a las personas, proporcionarles las clases de utilidad o clases básicas adecuadas, etc.
  52. 52. HERRAMIENTAS PARA USAR TDD  JUnit  HttpUnit  HSQLDB (como base de datos cargada en memoria para pruebas)  Jetty, Tomcat, Glassfish, JBoss como servidor de aplicaciones  El poderoso Framework Spring para montar diferentes tipos de instalaciones de pruebas ( Con base de datos externas, en memoria, etc)
  53. 53. Apariencia de JUnit
  54. 54. Un típico caso de pruebas de caja negra  Pruebas de aceptación (validar que el software realiza lo esperado) de tipo caja negra.  Estas pruebas arrancan todo el sistema en memoria, incluyendo las bases de datos y servidores Web, y acceden al sistema utilizando únicamente sus interfaces públicos (por ejemplo HTTP).  Esto hace extremadamente rápidos los ciclos de desarrollo-compilación-pruebas. También actúa como una red de seguridad, proporcionando a los desarrolladores suficiente confianza como para refactorizar a menudo, lo que significa que el diseño se mantiene limpio y simple incluso mientras el sistema crece.
  55. 55. Grafica de un equipo de desarrollo preparado para pruebas
  56. 56. TRACKING O SEGUIMIENTO DE ERRORES
  57. 57. HERRAMIENTAS PARA EL TRACKING DE ERRORES BUGZILLA TRACK OSTICKET ClearQuest
  58. 58. COMO ASEGURAR NUESTRO CODIGO  Primero se deben de identificar los parámetros o indicadores mínimos de calidad que requieres para tu código (Ej. orden).  Luego puedes aplicar lo siguiente: Programación en pares Realizar revisiones de código periódicas Integración continua Static code analyzers (Ejemplo Analizador de Eclipse) Búsqueda de Bugs CheckList de objetivos TDD Aplicar patrones de diseño Seguir estándares de programación.

×