FUNDAMENTOS DE CALIDAD DEL DESARROLLO SOFTWARE QUALITY ASSURANCE

Tamaño: px
Comenzar la demostración a partir de la página:

Download "FUNDAMENTOS DE CALIDAD DEL DESARROLLO SOFTWARE QUALITY ASSURANCE"

Transcripción

1 FUNDAMENTOS DE CALIDAD DEL DESARROLLO SOFTWARE QUALITY ASSURANCE

2 2 INTRODUCCIÓN 27/05/2013

3 3 INTRODUCCIÓN Software testing es un proceso usado para indentificar la corrección, la entereza y calidad del software desarrollado Incluye una serie de actividades con el propósito de encontrar errores en el software para poder ser corregidos antes de que el producto es lanzado al cliente. Software testing es una actividad para asegurar que los resultados actuales equivalen a los esperados y asegurar que el software está libre de defectos.

4 INTRODUCCIÓN 4 Por qué el testeo es importante?

5 INTRODUCCIÓN 5 ChinaAirlines Airbus A300 se estrelló debido a un bug en el software el 26 de Abril de 1994 matando a 264 inocentes. Los bugs pueden causar pérdidas monetarias y humanas, la historia está llena de ejemplos En 1985, El Canada's Therac-25 una máquina de terapia por radiación malfuncionó debido a un bug de software y causó deliveradas radiaciones letales a los pacientes. Murieron 3 personas y otras 3 quedarón críticamente perjudicadas

6 6 OBJETIVOS DE LAS PRUEBAS Como se ha podido ver, testing es importante porque los defectos del producto pueden causar altos costes y pueden ser peligrosos Como Paul Ehlrich escribió Errar es humano, pero para cargarla realmente hace falta un ordenador Objetivos de las pruebas Adquirir conocimiento sobre los defectos en un objeto de prueba ( test object ) Comprobar la funcionalidad Generar información Generar confianza

7 7 SIETE PRINCIPIOS DEL TESTEO 27/05/2013

8 SIETE PRINCIPIOS DEL TESTEO 8 Principio 1: El proceso de pruebas demuestra la presencia de defectos La causa de un fallo puede no ser obvia El proceso de pruebas no puede demostrar la ausencia de defectos Las pruebas reducen la probabilidad de la presencia de defectos que permanecen sin ser detectados El mismo proceso de pruebas puede contener errores Principio 2: No es posible realizar pruebas exhaustivas Pruebas exhaustivas ( exhaustive testing ) Enfoque de pruebas donde el conjunto de pruebas abarca todas las combinaciones de valores de entrada y precondiciones Explosión de casos de pruebas ( test case explosion ) Define el incremento exponencial de esfuerzo y coste en el caso de pruebas exhaustivas Prueba de muestra ( sample test ) Incluye un subconjunto de todos los posibles valores de entrada Probar todas las combinaciones posibles de entradas y precondiciones sólo es económicamente viable en casos triviales Se necesita una cantidad óptima de tests basados en la evaluación del riesgo de la aplicación

9 9 SIETE PRINCIPIOS DEL TESTEO Principio 3: Pruebas tempranas ( early testing ) La correción de un defecto es menos costosa en la medida en la cual su detección se realiza en fases más tempranas del proceso software Se obtiene una máxima rentabilidad cuando los errores son corregidos antes de la implementación Los conceptos y especificaciones pueden ser probados Los defectos detectados en la fase de concepción son corregidos con menor esfuerzo y costos Ls preparación de una prueba también consume tiempo El proceso de prueba implica más que sólo la ejecución de pruebas Las actividades de prueba deben ser ejecutadas en paralelo a la especificación y diseño software

10 10 SIETE PRINCIPIOS DEL TESTEO Que operación es la más problable que cause el fallo del Operating system? 1. Abrir Microsoft Word 2. Abrir Internet Explorer 3. Abrir 10 aplicaciones diferentes al mismo tiempo Multitarea

11 11 SIETE PRINCIPIOS DEL TESTEO Principio 4: Agrupamiento de defectos ( defect clustering ) Encuentre un defecto y encontrará más defectos cerca! Los defectos aparecen agrupados como hongos o cucarachas Cuando se detecta un defecto es convenienti investigar el mismo módulo en el que ha sido detectado Los probadores (testers) deben ser flexibles La identificación/localización de un defecto puede ser investigada con un mayor grado de detalle, por ejemplo, realizando pruebas adicionales o modificando pruebas existentes

12 12 SIETE PRINCIPIOS DEL TESTEO Principio 5: Paradoja pesticida Repetir pruebas en las mismas condiciones no es efectivo Cada caso de prueba debe contar con una combinación única de parámetros de entrada para un objeto de prueba particular, de lo contrario no se prodrá obtener información adicional Si se ejecutan las mismas pruebas de forma reiterada no se podrán encontrar nuevos defectos Las pruebas deben ser revisadas/modificadas regularmente para los distintos módulos (código) La automatización de pruebas puede resultar conveniente si un conjunto de casos de prueba se debe ejecutar frecuentemente

13 13 SIETE PRINCIPIOS DEL TESTEO Principio 6: Las pruebas dependen del contexto Las pruebas se desarrollan de forma diferente en diferentes contextos Objetos de prueba diferentes son probados de forma diferente Entorno de pruebas ( test environment, cama de pruebas test bed ) vs entorno de producción ( production environment ) El entorno de pruebas debe ser similar al entorno de producción

14 14 SIETE PRINCIPIOS DEL TESTEO Principio 7: La falacia de la ausencia de errores Un proceso de pruebas adecuado detectará los fallos más importantes En la mayoría de los de los casos el proceso de pruebas no enconrará todos los defectos del sistema (ver principio 2), pero los defectos más imprtantes deberían ser detectados Esto en sí no prueba la calidad del software La funcionalidad del software puede no satisfacer las necesidades y expectativas de los usuarios No se puede introducir la calidad a través de las pruebas, ella tiene que construirse desde el principio

15 15 No se puede asegurar que el software está libre de bugs

16 SIETE PRINCIPIOS DEL TESTEO 16 Resumen Las pruebas pueden ayudar a detectar defectos en el software, sin embargo las mismas no pueden demostrar la ausencia de defectos Salvo en casos triviales las pruebas exhaustivas son imposibles, las pruebas de muestra son necesarias Las pruebas tempranas ayudan a reducir costos dado que los defectos descubiertos en fases tempranas del proceso software son corregidos con menor esfuerzo Los defectos se presentan agrupados Repetir pruebas idénticas no genera nueva información Cada entorno particular determina la forma en la cual se ejecutarán/desarrollarán las pruebas Un software libre de errores no implica que sea adecuado para el uso

17 SIETE PRINCIPIOS DEL TESTEO 17 Principios Principio 1 Principio 2 Principio 3 Principio 4 Principio 5 Principio 6 Definición Testing muestra la presencia de defectos Testing exaustivo es imposible Testing tan pronto como sea posible Defect Clustering Pesticide Paradox Testing es dependiente del contexto Principio 7 Abstinencia de defectos - ERROR

18 18 SDLC VS STLC 27/05/2013

19 DESARROLLO SOFWARE PARA EL CLIENTE Obtener toda la información posible sobre los detalles y especificaciones del software deseado para el cliente 2. Decidir el lenguaje de programación como Java, Sofware PhP,.NET, development database live como cycle Oracle, mysql etc los cuales idean el proyecto. SDLC Alto nivel de arquitectura 3. Implementación del software 4. Testear el software para verificar que se ha implementado acorde con las especificaciones dadas por el cliente Requisitos Diseño Programación Test Mantenimiento

20 DESVENTAJAS 20 Requisitos Errores en requisitos Diseño Diseño para contemplar los requisitos Programación Test Mantenimiento Desarrollo para contemplar el diseño Producto incorrecto Se tendrá que comenzar de nuevo con el proyecto

21 DESVENTAJAS 21 Requisitos Requisitos Diseño Cerca del 50% de los defectos son introducidos durante las fases de Programación requerimientos y diseño Diseño Incorrecto Desarrollo para contemplar el diseño Test Producto incorrecto Mantenimiento Rediseño para corregir los defectos

22 PRUEBAS A TRAVÉS DEL MODELO-V GENERAL 22 Desarrollo y pruebas son dos ramas iguales Cada nivel de desarrollo tiene su correspondiente nivel de pruebas Rama desarrollo software Rama pruebas software Definición de requisitos Pruebas de aceptación Diseño funcional del sistema Pruebas de sistema Diseño técnico del sistema Pruebas de integración Especificación de los componentes Programación Pruebas de componente

23 23 VERIFICACIÓN VS VALIDACIÓN Verificación Comprobación de la conformidad con los requisitos establecidos (ISO 9000). Si los requisitos y definiciones de niveles previos han sido implementados correctamente Cuestión clave: Se ha procedido correctamente en la construcción del sistema? Hemos sumado 1+1 correctamente? Cada nivel de desarrollo se verifica respecto de los contenidos del nivel que precede Validación Comprobación de la idoneidad para el uso esperado (ISO 9000). Validar significa comprobar lo adecuado de los resultados de un nivel de desarrollo Cuestión clave: Hemos construido el sistema software correcto? El objetivo era sumar 1+1 o debeíamos haber restado? La validación se refiere a la correción de cada nivel de desarrollo

24 CICLO DE VIDA ITERATIVO 24 Fase 1 Fase 2 Fase 3 Requisitos Requisitos Requisitos Diseño Diseño Diseño Build Build Build Test Test Test Mantenimiento Mantenimiento Mantenimiento

25 TESTEO EN LOS MODELOS DE CICLO DE VIDA 25 Hay numerosos modelos del ciclo de vida de desarrollo El modelo de desarrollo seleccionado depende de las necesidades y objetivos del proyecto Testing no es una actividad stand-alone y tiene que adaptarse al modelo de desarrollo seleccionado para el proyecto En cualquier modelo seleccionado, testing debe ser aplicado en todos los niveles (para mantener los requerimientos)

26 26 PRUEBAS DE COMPONENTE (UNIT TESTING) 27/05/2013

27 27 UNIT TESTING Por qué es importante el unit testing? Desarrolladores software optimizan el tiempo aplicando un mínimo de unit testing Unit testing reduce el coste de arreglar desfectos durante las fases de system testing, integration testing e incluso beta testing una vez la aplicación es desarrollada por completo Aplicar unit testing durante el estado de desarrollo reduce tanto tiempo como dinero empleado en el proyecto

28 28 CONSTRUIR CASOS DE COMPONENTE Comunmente Unit Testing es ejecutado de manera automática pero puede ser manual Aproximación automática Un desarrollador puede implementar otra sección de código en la aplicación solo para testear la funcionalidad (el código de testeo es eliminado una vez el desarrollo es completado) Se puede asilar la funcionalidad para ser testeada más rigurosamente. Aislar el código ayuda a revelar innecesarias dependencias entre el código testeado y otras unidades del producto Se puede usar un Unit Test Framework para desarrollar casos automatizados Reporte automático de casos fallidos

29 29 UNIT TESTING Mock Objects Objetos creados para testear secciones de código aún incompletas Simulan variables u objetos unicamente con el propósito de testear esa sección del código Unit Testing Tools Rational Software By IBM as Rational Test Realtime. Go to JavaScript Assertion Unit. Go to CUT CUT Freeware unit test tool for C. Go to Dotunit Dotunit,.NET framework. Go to

30 30 PROGRAMACIÓN EXTREMA & UNIT TESTING Programación extrema implica el uso extensivo de testing frameworks Beneficios de la programación extrema Tests son escritos antes que el código Fiabilidad de herramientas específicadas. Unit Test Framework Todas las clases en la aplicación son testeadas Posibilidad de una facil y sencilla integración

31 31 MITOS DEL UNIT TESTING Requiere tiempo y siempre estoy retrasado Mi código es inmejorable! No necesito unit tests La verdad es: Unit testing incrementa la velocidad de desarrollo Integration testing contendrá todos los defectos. Unit testing previo implica una integración con defectos triviales facil de solucionar

32 32 RESUMEN Pruebas de componente (Unit testing) Un componente es la unidad más pequeña especificada de un sistema Prueba de módulo, de clase, de unidad y de desarrollador son utilizados como sinónimos Las pruebas de componente podrán comprobar características funcionales y no funcionales de un sistema

33 33 PRUEBAS DE INTEGRACIÓN (INTEGRATION TESTING) 27/05/2013

34 34 PRUEBAS DE INTEGRACIÓN Definición y terminología En el testeo de integración, los módulos software individuales son integrados lógicamente y testeados como un grupo Un proyecto software consiste en multiples módulos implementados por diferentes desarrolladores El testeo de integración está enfocado en probar la comunicación entre esos módulos El testeo de integración es llevado a cabo por los testeadores También denominado como I & T (Integration and Testing), String Testing y aveces Thread Testing

35 35 PRUEBAS DE INTEGRACIÓN Necesidad del testeo de integración Módulos son testeados individualmente (Unit Testing), sin embargo los defectos pueden aún existir por las siguientes razones Un módulo es asignado a un programador con un entendimiento y manera lógica diferente de otro programador. Integration testing se convierte en necesario para verificar que los módulos funcionan en unidad Cambios en los requisitos que implican modificaciones en los componentes. Los nuevos requisitos pueden no ser testeados individualmente y por tanto el testeo de integración es necesario Las interfaces de los módulos con la base de datos pueden ser erroneas Interfaces hardware esternas pueden ser erroneas Excepciones no controladas pueden causar defectos

36 PRUEBAS DE INTEGRACIÓN 36 Casos de testeo Enfocados principalmente en las interfaces y flujo de datos/ información entre modulos Prioriza la integración de links frente a las funciones unitarias las cuales son previamente testeadas Ejemplo de una aplicación con 3 módulos: Loging page, Mail Box y Borrar s Test case ID Objetivo Descripción Resultado esperado 1 Comprobar el link entre el Login y MailBox 2 Comprobar el link entre el MailBox y el Borrado de s Introducir las credenciales de logueo y cliclar en el boton de login Desde la bandeja de entrada, seleccionar un y clicar en el botón de borrado Redirección a la bandeja de correo (MailBox) El seleccionado debe aparecer en la carpeta de borrado

37 37 PRUEBAS DE INTEGRACIÓN Metodologías vs Estrategias Aproximación Big Bang Aproximación incremental: Top down Bottom Up Sandwitch Combinación de Top down y Bottom Up

38 38 METODOLOGÍAS Big Bang Todos los componentes son integrados a la vez y después son testeados Ventajas: Conveniente para sistemas pequeños Desventajas Dificultad para localizar el fallo El testeo de algún link de interfaz puede ser olvidado facilmente Integration testing comienza una vez todos los módulos son dispuestos por tanto el equipo de testeo tienes menos tiempo para ejecución de los casos Módulos críticos no son aislados y testeados con prioridad

39 METODOLOGÍAS 39 Bottom up integration Cada módulo del nivel inferior es testeado con módulos de niveles más altos hasta que todos los módulos son testeados. Utiliza drivers Ventajas Fácil localización del fallo Tiempo no perdido esperando por el desarrolo de todos los módulos Desventajas Módulos criticos son los últimos en testear y pueden tener defectos colaterales

40 METODOLOGÍAS 40 Top Down integration Cada módulo del nivel superior es testeado con módulos de niveles inferiores hasta que todos los módulos son testeados. Utiliza Stubs Ventajas Fácil localización del fallo Módulos criticos son los últimos en testear y pueden tener defectos colaterales Desventajas Necesidad de numerosos Stubs Módulos más inferiores no testeados adecuadamente

41 41 PRUEBAS DE INTEGRACIÓN Procedimiento 1. Preparación del Test Plan 2. Diseño, escenarios, casos de prueba y scripts 3. Ejecución de los casos de prueba y reporte de defectos 4. Arreglo y re-testing de defectos 5. Pasos 3 y 4 hasta completar la integración satisfactoriamente Descripción Test Plan Métodos utilizados para testear Alcances y fuera del alcance Roles y responsabilidades Pre-requisitos Testing environment Riesgos y Mitigation Plans

42 42 INTEGRATION TESTING Best Practices/ Guidelines Primero determina la estrategia de testeo que será adoptada y después prepara los casos de testeo y test data Estudia el diseño de la arquitectura de la aplicación e identifica los módulos críticos. Estos deben ser testeados con prioridad Obten el diseño de interfaces del equipo de arquitectura y crea los test cases para verificar todas las interfaces en detalle (database/external hardware/software) Siempre tener el mock data preparado previamente a la ejecución. No seleccionar el test data durante la ejecución de los casos de prueba

43 43 RESUMEN Pruebas de integración Integración significa construir grupos de componentes Las pruebas de integración comprueban la interacción entre componentes respecto de la especificación de interfaces La intergración ocurre de forma ascendente ( botton up ), descendente ( top-down ) o en forma de big bang Cualquier estrategia de integración distinta a las anteriores es integración ad hoc

44 44 PRUEBAS DE SISTEMA ( SYSTEM TESTING ) Y DE ACEPTACIÓN ( ACCEPTANCE TESTING ) 27/05/2013

45 PRUEBAS DE SISTEMA 45 Las pruebas de sistema ( system testing ) verifican el completo escenario End to End y comprueban el cumplimiento de los requisitos especificados La calidad es observada dede el punto de vista del usuario Se refieren a requisitos funcionales y no funcionales (funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad, portabilidad) Los casos de prueba podrán ser obtenidos a partir de : Especificaciones funcionales Casos de uso Procesos de negocio Evaluación de riesgos Login Current Balance Transfer encia Logout

46 46 PRUEBAS DE SISTEMA Alcance: Prueba de un sistema integrado desde el punto de vista del usuario Implementación completa y correcta de los requisitos Despliegue en el entorno real del sistema con datos reales El entorno de pruebas debería coincidir con el entorno real Todas las interfaces externas son probadas en condiciones reales Emulación próxima al futuro entorno real del sistema No se realizan pruebas en el entorno real!

47 PRUEBAS DE ACEPTACIÓN 47 Las pruebas de aceptación son pruebas formales llevadas a cabo con el objeto de verificar la conformidad del sistema con los requsitos. Aportar confianza en el sistema para que pueda ser aceptado por el cliente Es habitual que sean las primeras pruebas en las cuales se vea involucrado el cliente El cliente selecciona casos de prueba para las pruebas de aceptación Las pruebas se realizan en el entorno del cliente El foco no es encontrar defectos sino confirmar que cumple con los requerimientos Puede ser realizado de dos maneras: pruebas alpha y pruebas beta Es necesario una versión preliminar y estable del software El cliente utiliza el software para hacer el tratamiento de sus procesos de negocio cotidianos en las dependencias del proveedor ( Alpha Testing ) o en sus propias dependencias ( Beta Testing ) Ventajas de las pruebas alpha y beta Reduce el costo de las pruebas de aceptación Se utilizan distintos entornos Involucran a un alto número de usuarios

48 48 RESUMEN Pruebas de sistema Las pruebas de sistema se desarrollan utilizando casos de prueba funcionales y no funcionales Las pruebas de sistema funcionales confirman que los requisitos para un uso específico previsto han sido satisfechos (validación) Las pruebas no funcionales verifican los atributos de calidad no funcionales, por ejemplo usabilidad, eficiencia, portabilidad, etc Con frecuencia, los atributos de calidad no funcionales son una parte implícita de los requisitos, esto hace dificil validarlos Pruebas de aceptación Las pruebas de aceptación son pruebas de sistema por parte del cliente La prueba de aceptación es una actividad de carácter contractual, se verificará entonces que el software satisface los requisitos del cliente Las pruebas alpha y beta son pruebas ejecutadas por clientes reales o potenciales

49 49 SMOKE & SANITY TESTING 27/05/2013

50 SMOKE/SANITY TESTING 50 Login -> Ver Balance > Transferir 500 eur > Logout Amaris Miriam ******* Boom

51 SMOKE/SANITY TESTING 51

52 SMOKE/SANITY TESTING 52 Sanity/Smoke testing Para verificar funcionalidades críticas del sistema antes de ser aceptado para un nivel de testeo más importante Sanity testing es rápido y no es exhaustivo El objetivo no es encontrar defectos sino verificar la estabilidad del sistema

53 53 PRUEBAS DE MANTENIMIENTO ( MAINTENANCE TESTING ) Y REGRESIÓN 27/05/2013

54 PRUEBAS DE MANTENIMIENTO 54 Una vez desarrollado el software, los cambios en el sistema, mejoras o correciones forman parte del maintenance testing Balance actual

55 REGRESIÓN DEL SISTEMA Cambios introducidos en el código (módulo de balance únicamente) provocan que el módulo de tranferencia se vea afectado Regression testing es llevado a cabo para verificar que las modificaciones en el producto no causan defectos adversos 55 Balance actual = 2000 Balance Actual 500 Transfere Error en la transacción ncia 1000 Balance antiguo = 500

56 56 PRUEBAS NO FUNCIONALES ( NON-FUNCTIONAL TESTING ) 27/05/2013

57 PRUEBAS NO FUNCIONALES 57 Aparte de Functional testing, factores asociados al non-functional testing como performance, usability, load son también importantes Performance testing: Comprueba una respuesta óptima del sistema. El objetivo es reducir el tiempo de respuesta a un nivel aceptable Load testing: Respuesta del sistema sometida a diferentes cargas, por ejemplo, el número de usuarios accediendo al sistema

58 TIPOS DE PRUEBAS 58 Tipos de testing Funcionales No Funcionales Mantenimiento Unit Testing Integration Testing Smoke/Santy Testing User Acceptance Localization Globalization Interoperability Etc.. Performance Endurance Load Volume Scalability Usabilty Etc.. Regresión Maintenance

59 CONSIDERACIONES 59 Mas de 150 tipos de testing No todos los tipos de testing pueden ser aplicables a todos los proyectos, depende de la naturaleza y el alcance del proyecto

60 60 DESARROLLO DE CASOS DE PRUEBA 27/05/2013

61 CONSIDERACIONES AL DESARROLLAR UN CASO DE PRUEBA 61 Testing implica la ejecución de varias secciones de codigo y la verificación de los resultados Testing es una actividad muy formal que es documentada en detalle El grado de formalidad depende del tipo de aplicación a testear, los estandares seguidos por la organización y la madurez del proceso de desarrollo

62 62 CASOS DE PRUEBA Test Cases Los escenarios de prueba pueden repercutir en un elevado números de posibilidades El testing debe ser muy específico Test Data Identificar los datos de test puede implicar un consumo de tiempo elevado y puede aveces requerir de la creación de estos datos Escenario Test Case Test Data Verificar la funcionalidad de logueo Verificar la respuesta frente a un usuario válido y contraseña Usuario: Miriam99 Contraseña: AMARIS Usuario: Miriam Contraseña: AMAris Usuario: 9999 Contraseña: amaris

63 RESULTADOS ESPERADOS 63 Escenario Test Case Test Data Resultados Esperados Verificar la funcionalidad de logueo Verificar la respuesta frente a un usuario válido y contraseña Usuario: Miriam99 Contraseña: AMARIS Usuario: Miriam Contraseña: AMAris Usuario: 9999 Contraseña: amaris Usuario se loguea satisfactoriamente Si los resultados esperados no son documentados no podremos confirmar que el resultado de una pruebas es OK.

64 PASOS DE TESTEO 64 Escenario Test Case Test Steps Test Data Resultados Esperados Verificar la funcionalidad de logueo Verificar la respuesta frente a un usuario válido y contraseña 1. Lanzar la aplicación 2. Introducir el usuario 3. Introducir la contraseña 4. Clicar el botón OK Usuario: Miriam99 Contraseña: AMARIS Usuario: Miriam Contraseña: AMAris Usuario: 9999 Contraseña: amaris Usuario se loguea satisfactoriamen te

65 PRECONDICIONES 65 Escenario Test Case Pre- Condition s Verificar la funcionalidad de logueo Verificar la respuesta frente a un usuario válido y contraseña La aplicación de reserva de un vuelo debe ser instalada Test Steps Test Data 1. Lanzar la aplicación 2. Introducir el usuario 3. Introducir la contraseña 4. Clicar el botón OK Usuario: Miriam99 Contraseña: AMARIS Usuario: Miriam Contraseña: AMAris Usuario: 9999 Contraseña: amaris Resultado s Esperados Usuario se loguea satisfactoria mente Precondiciones indican detalles previos a realizar para poder ejecutar los casos de prueba

66 POST-CONDITIONS 66 Escenario Test Case Pre- Condition s Verificar la funcionalidad de logueo Verificar la respuesta frente a un usuario válido y contraseña La aplicación de reserva de un vuelo debe ser instalada Test Steps Test Data 1. Lanzar la aplicación 2. Introducir el usuario 3. Introducir la contraseña 4. Clicar el botón OK Usuario: Miriam99 Contraseña: AMARIS Usuario: Miriam Contraseña: AMAris Usuario: 9999 Contraseña: amaris Resultado s Esperado s Usuario se loguea satisfactoriame nte Post-conditions indican la tarea necesaria a ejecutar una vez que el test es completado El ejemplo: El tiempo y las fecha de loqueo es guardada en la base de datos

67 RESULTADOS 67 Escenari o Test Case Pre- Conditio ns Test Steps Test Data Resultad os Esperado s Actual Results PASS/F AIL Verificar la funcionalida d de logueo Verificar la respuesta frente a un usuario válido y contraseña La aplicación de reserva de un vuelo debe ser instalada 1. Lanzar la aplicación 2. Introducir el usuario 3. Introducir la contraseña 4. Clicar el botón OK Usuario: Miriam99 Contraseña: AMARIS Usuario: Miriam Contraseña: AMAris Usuario: 9999 Contraseña: amaris Usuario se loguea satisfactoria mente Logue con éxito PASS

68 68 TÉCNICAS DEL TESTEO No es posible verificar absolutamente todas las condiciones de la aplicación. Las tecnicas de casos de prueba ayudan a seleccionar los casos de prueba con una posibilidad mayor de encontrar defectos Boundary Value Analysis (BVA): Técnica que define las pruebas de frontera/límites para la gama especificada de valores Partición de Equivalencia (PE): Técnica que particiona y agrupa casos que tienen el mismo comportamiento Transición de estados: Este método es usado cuando el comportamiento del software cambia de un estado a otro siguiendo una acción particular Error Guessing: Anticipación a los posibles errores que puedan ser detectados durante el testeo. No es un método formal y depende de la experiencia del terster

69 69 CONSIDERACIONES AL ESCRIBIR CASOS DE PRUEBA 1. Los casos de prueba deben ser simples y transparentes 2. Crear casos de prueba considerando el usuario final 3. Evitar repetir casos de prueba 4. No tener asunciones 5. Asegurar el 100% de la cobertura 6. Casos de prueba indentificado por un ID 7. Implementar tecnicas de escritura de casos 8. Revisión de los casos de prueba

70 70 MATRIZ TRAZABILIDAD Si los requerimientos son numerados y son referenciados en una test suit sería muy fácil trazar los casos de prueba que son afectados por un cambio. Esto no es nada más que trazabilidad La matriz de trazabilidad linca un requerimiento con su correspondiente requerimiento funcional y por tanto sus correspondientes casos de prueba Si un caso de prueba falla, la trazabilidad ayuda a determinar la correspondiente funcionalidad facilmente Asegura que todos los requerimientos son testeados

71 71 TÉCNCAS DE TESTEO Partición de equivalencia y Análisis de agrupación de valores Tabla de decisión Diagrama de transición de estados Caso de Uso Testing Review 27/05/2013

72 TECNICAS DE TESTEO 72 Hemos aprendido que el testing exhaustivo no es posible Se necesitan técnicas para indentificar casos de pruebas con la mayor probabilidad de encontrar defectos Hay muchas técnicas de diseño de casos de prueba

73 73 PARTICIÓN DE EQUIVALENCIA Es una técnica de caja negra la cual se puede aplicar en todos los niveles de testing como unit, integration, system etc. Divide un juego de condiciones de prueba en particiones que son consideradas la misma Ejemplo: Tickets en la reserva de un vuelo Valores entre 1-10 son considerados válidos para reservar Valores entre 11 y 99 son considerados inválidos ERROR mesage Introducir un valor igual a 100 o mayor: el múmero de ticket por defecto será de dos dígitos Introducir un valor igual a 0 o menor: el número de tickets por defecto será 1 No es viable testear todos los valores, el números de casos de prueba será mayor de 100 Dividimos los posibles valores en grupos donde el comportamiento del sistema es considerado el mismo

74 PARTICIÓN DE EQUIVALENCIA 74 Las agrupaciones son denominadas particiones de equivalencia o clases de equivalencia Se escoje un único valor para cada partición La hipótesis detrás de esta técnica es que si una condición/valor de la partición pasa, el resto también Si una condición falla, el resto de condiciones en esa partición serán consideradas fallidas

75 75 ANÁLISIS DE VALORES FRONTERA En boundary values analysis, se testean valores frontera de la partición de equivalencia Ejemplo anterior: Se verifican los valores 0, 1, 10 y 11 Se testean los valores que constituyen los límites de aceptación y fallo Boundary values analysis también es denominado como range checking Las técnicas de partición de equivalencia y valores frontera estan cercanamente relacionadas y pueden ser usadas conjuntamente en todos los niveles de testing

76 76 TABLA DE DECISIÓN Es una manera de lidiar con combinaciones de valores de entrada los cuales producen resultados diferentes Ejemplo: Reserva de vuelo Origen y destino vacios implica boton desactivado. Se introduce como FALSE el origen y destino en la tabla de decisión Origen seleccionado pero destino vacío implica botón desactivado. Se registra origen a TRUE y el resto a FALSE Origen vacío y destino seleccionado implica boton desactivado. Se introduce como FALSE el destino en la tabla de decisión Origen y destino seleccionados implica botón Activado. Valores a TRUE en la tabla de decisión Reglas 1, 2 y 3 permanecen igual. Por tanto solo se selecciona una de ellas aparte de la regla 4 Esta técnica pone en claro el incremento de los posibles valores de entrada. Combinaciones posible 2^n (n=10, 1024)

77 DIAGRAMA DE TRANSICIÓN DE ESTADOS 77 Esta técnica es ayuda cuando es requerido testear diferentes transiciones en el sistema Introducir Usuario Contraseña Incorrecta Cierre Start 1º inten to 2º inten to 3º inten to 4º inten to Contraseña correcta Acceso

78 78 DIAGRAMA DE TRANSICIÓN DE ESTADOS El diagrama es llamado State Chart o Graph Hay 4 componentes principales 1. Estados del software Start 2. Transición desde un estado a otro 3. Evento que causa la transición Contraseña correcta 4. Acciones causadas por eventos Cierre

79 TABLA DE ESTADO TRANSICIONES INVALIDAS 79 Contraseña Correcta Contraseña Incorrecta S1 - Start S6 S2 S2 1º Intento S6 S3 S3 2º Intento S6 S4 S4 3º Intento S6 S5 S5 4º Intento S6 S7 S6 - Acceso?? S7 - Cierre - -

80 80 CASO DE USO Esta técnica ayuda a identificar los casos de prueba que cubren el sistema completo basados en transiciones desde desde el comienzo al final Un caso de uso es una descripción de un uso particular del sistema por un usuario Técnica usada en el desarrollo de casos de prueba en el nivel de sistema o de aceptación Escenario principal de éxito Pasos Descripción A: Usuario S: Sistema 1 A: Introducir usuario y contraseña 2 S: Validar contraseña 3 S: Permitir acceso Extensiones 2a Contraseña invalida Mostrar mensaje de error y preguntar por 4 intentos 2b Contraseña invalidada 4 veces

81 81 TESTING REVIEW Review es una reunión donde se analiza el funcionamiento del producto software y se recomiendan cambios con el objetivo de mejorar la calidad Puede ser convocada para un documento de diseño, especificaciones de los requerimientos del sistema, codigo, test plan etc Ayuda a detectar defecto de manera temprana en el ciclo de vida del desarrollo y reduce costes El equipo de testeo debe de estar presente en las reuniones de revisión

82 FASES EN LA REUNIÓN DE REVISIÓN 82 Planning stage Enviar convocatoria con la localización y fecha, indicar la agenda y adjuntar la información necesaria Kick Off (opcional) Revisión previa del motivo de la reunión. Los participanten deben tener conocimiento Preparación Identificar defectos, comentarios y preguntas para la reunión Asignación de roles Moderador Autor Anotador Revisores Re-work El autor aplica los cambios considerados durante la reunión Seguimiento Verificación de los cambios por parte de los participantes

83 83 TIPOS DE REVISIÓN Walk Through Liderada por el autor Revisión Técnica Liderada por un moderador experto sin necesidad de la presencia de QA manager Inspección Liderada por un moderador experto aplicando un criterio de evaluación

84 84 TEST MANAGEMENT Estimación Test Plan 27/05/2013

85 ESTIMACIÓN 85 Estrategia Bottom - Up Basada en la estimación de tareas. Se indica la duración, las dependencias y recursos Contribuidores individuales, expertos y miembros experimentados dan estimaciones La idea es obtener una estimación de tests precisa gracias a la colaboración del equipo Estrategia Top - Down Basada en la experiencia Basada en en el tamaño (pequeño, mediano o grande) y complejidad (simple, moderado o complejo) del proyecto a partir de experiencias pasadas Basado en el esfuerzo medio empleado en casos de prueba similares en el pasado La mayoría de los proyectos usan estrategias top-down para estimar La estimación de los casos de prueba puede verse afectada por otros factores como la presión, distribución geográfica del equipo etc

86 TEST PLAN 86 Scope (dentro del alcance) Ejemplo: functional testing, performance testing, load testing Out of scope (fuera del alcance) Ejemplo: Platform testing, localization testing Riesgos Riegos de proyecto Ejemplo: Un miembro senior del equipo deja el proyecto sin previo aviso Estimar la probabilidad y el impacto Identificar la posible solución Riesgos basados en la estrategia de testing Tiempo consumido Budget La estrategia de test Estimaciones de casos de prueba El equipo de testeo. Roles Schedule El test plan ayuda a monitorizar el progreso de varias actividades de testeo además de controlar acciones de cambio en caso del desvio respecto a las actividades planeadas

87 87 DEFECTOS Defectos Ciclo de vida del bug Testing Tools 27/05/2013

88 88 QUE ES UN DEFECTO? Resultados actuales difieren de los resultados esperados También denominado incidente, bug, problema o issue Que información sería conveniente para ayudar al desarrollador a entender el defecto?

89 89 REPORTE DEL BUG Defect_ID: Número identificativo para el defecto Descripción: Información sobre el módulo en el cual el defecto fué encontrado Versión: Pasos: Información para reproducir el problema Fecha: Cuando el defecto fué encontrado Referencia: Requerimientos, diseño, arquitectura Estado: Abierto, en progreso, arreglado y cerrado Reporter: Nombre/ID de quién lo encontró Fixed by: Nomnre/ID de quién lo arregló Fecha de cierre Severidad: Impacto del defecto en la aplicación Prioridad: Urgencia

90 CICLO DE VIDA DE UN BUG Code 90 Tester encuentra un defecto Estado = En progreso Estado = Nuevo Code Fixed Manager de desarrollo analiza el defecto Estado = Arreglado Valido Si Alcan ce Si Dupli cado Retesteo No No No Si PASS? No Estado = Rechazado Estado = Retrasado Estado = Duplicado Estado = Cerrado Estado = Reabierto

91 91 WEB TESTING 27/05/2013

92 92 Que es el testeo Web? Es un término para describir la verificación de una plaicación Web frete a defectos antes de que el código es llevado a producción Durante este proceso se comprueba tanto la seguridad, el funcionamient de la página, el acceso por los usuarios como la habilidad de manejar el tráfico

93 TESTING FUNCIONAL 93 Usado para verificar que el producto asegura los requerimientos funcionales. Las actividades de testeo son: Testear todos los links en la página web Outgoing links Internal links MailTo links Anchor links Testear Forms Scripting para verificar que funcionan correctamente. Por ejemplo: se muestra un error si un campo no es rellenado Verificar los valores por defecto son rellenados Una vez rellenado, los datos son guardados en la base de datos o son lincados a una dirección de correo Forms son formateados para una mejor legibilidad Testear cookies Cookies son borradas cuando la cache es limpiada o expiran Borrar un cookie y testear que las credenciales son solicitadas Testear HTML y CSS Verificar la sintaxis Legibles esquemas de colores Asegurar estandares como W3C, OASIS, ISO Testear business workflow Verificar End to End workflow/business escenarios que llevan al usuaro al completado de páginas web Verificar escenarios negativos

94 94 USABILITY TESTING Se ha convertido en una parte vital de cualquier proyecto Web Puede ser testeado por testers o incluso grupo de usuarios Testear la navegación de la página Menus, botones o links que llevan a paginas diferentes deben ser facilmente visibles y consistentes en todas las páginas Testear el contenido El contenido debe ser legible sin errores gramaticales Si hay imagenes deben contener texto

95 95 INTERFACE TESTING Hay tres areas a testear Aplicación: Peticiones son enviadas correctamente a la base de datos y la salida en pantalla por parte del cliente es mostrada perfectamente. Los errores deben ser registrados y solo mostrados al administrados Web server: Manejo de todas las peticiones de cliente sin problemas de servicio Database server: Asegurar que las peticiones enviadas a la base de datos dan los resultados esperados Testear las respuestas del sistema cuando la comunicación entre las tres layers (aplicación, Web y database) no puede ser establecida Errores son mostrados al usuario final

96 96 DATABASE TESTING La base de datos es un componente crítico en la aplicación web y es importante verificar su comportamiento frente a actividades de carga Testear si los errores son mostrados cuando se ejecutan peticiones La integridad de los datos se mantiene si se crean, actualizan o se borran datos de la base de datos Verificar el tiempo de respuesta Testear la muestra de datos procedentes de la base de datos

97 97 COMPATIBILITY TESTING Aseguran que la aplicación web es mostrada correctamente en diferentes dispositivos. Browser compatibility test: Misma website en diferentes browsers es mostrada correctamente. Testear si es mostrada sobre browsers, javascript, AJAX y la autenticación funciona correctamente Mobile browser compatibility Operating System: Windows, Linux, Mac y browsers como Firefox, IE, Safari etc

98 98 PERFORMANCE TESTING Verificación frente a cargas Tiempo de respuesta de la aplicación Website a diferentes velocidades de conexión Tests de carga para verificar el comportamiento frente a picos altos Test de estres para determinar si hay un punto de rotura frente a altos picos Testear si la aplicación crashes, como se recupera? Tecnicas de optimización como la compresión gzip

99 99 SECURITY & CROWD TESTING Security testing es vital para los website de e-commerce los cuales guardan información sensible de clientes Verificar accesos desautorizados para securizar paginal Ficheros restringidos deben no ser descargables sin un acceso correcto Verificar que las sesiones con un largo periodo de inactividad son cerradas Con el uso de certificados SSL, la pagina web debe ser redireccionada a una página encriptada SSL Se selecciona a un gran número de personas (crowd) para ejecutar tests. Esto ayudar a encontrar defectos escondidos

100 100 AUTOMATION TESTING 27/05/2013

101 POR QUÉ DEBEMOS AUTOMATIZAR 101 Automatizar es importante por las siguientes razones El testeo manual de de los flujos de trabajo, los campos, los escenarios negativos implica un consumo de tiempo y costes elevados Es complejo testear multi lenguajes de sitios manualmente La automatización no requiere intervención humana La automatización incrementa la velocidad de ejecución de los casos de prueba La automatización ayuda a incrementar la cobertura de los tests El testeo manual se puede convertir en aburrido y causar errores

102 QUE CASOS DE PRUEBA SE DEBEN AUTOMATIZAR? 102 Los casos de prueba automáticos pueden ser seleccionados siguiendo el siguiente criterio Alto riesgo casos de prueba críticos para el producto Casos de prueba que son ejecutados repetidamente Casos de prueba complejos de ejecutar manualmente o aburridos Casos de prueba que requieren un consumo de tiempo elevado Casos de prueba que no deben ser automatizados Nuevos casos de prueba que aún no han sido ejecutados manualmente Casos de pruebas en lo cuales los requerimientos cambian constantemente Casos de prueba ejecutado de una manera ad-hoc

103 103 PROCESO DE AUTOMATIZACIÓN Pasos a seguir en el proceso de automatización Selección de la herramienta Definición del alcance de la automatización Plan, diseño y desarrollo Ejecución de los tests Mantenimiento Selección de la herramienta Depende de la tecnología de construcción de la aplicación a testear Prueba de concepto de la herramienta

104 PROCESO DE AUTOMATIZACIÓN 104 Definición del calcance de la automatización. Los siguientes puntos ayudan en determinar el alcance Funcionalidad que es importante para el negocio Escenario con una alta cantidad de datos Funcionalidades comunes del producto Complejidad de los casos de prueba Viabilidad tecnica Plan, diseño y desarrollo. Detalles en la estrategia de automatización Herramienta seleccionada Diseño del framework y sus funcionalidades In-scope y Out-of-scope items de automatización Preparación de test bed Schedule y timeline de la ejecucion y desarrollo de los scripts Entregas del testeo automático

105 105 PROCESO DE AUTOMATIZACIÓN Ejecución de los tests Los scripts automáticos son ejecutados durante esta fase Los scripts necesitan datos de entrada previos a ser ejecutados Una vez ejecutados proporcionan reportes La ejecución pueder ser realizada por la herramienta de automatización directamente o a través de la herramienta de management Mantenimiento Nuevas funcionalidades son añadidas al sistema con ciclos excitosos Los scripts automáticos necesitan ser añadidos, revisados y mantenidos para cada release cycle El mantenimiento se convierte necesario para mejorar la efectividad de los scripts automáticos

106 COMO SELECCIONAR UNA HERRAMIENTA DE AUTOMATIZACION 106 La selección de la herramienta es uno de los mayores desafíos. Primero identifica los requerimientos, explora varias herramientas y sus capacidades, realiza una prueba de concepto Soporte del entorno Facilidad en el uso Testeo de la base de datos Testeo de imagenes Lenguaje de scripting Soporte para varios tipos de testeo funcional, mobile etc Facil de debugar Reporte y resultdos extensivos Training mínimo

107 OBTENER EL MAYOR PARTIDO DE LA AUTOMATIZACIÓN 107 Las necesidades del alcance de la automatización deben ser determinadas antes de estar el proyecto Slecciona la herramienta apropiada. No debe ser seleccionada por popularidad sino por cubrir mejor los requerimientos Escoger un framework apropiado Estandares de scripting Medición de las métricas Porcentaje de defectos encontrados Tiempo requirido para automatizar en el ciclo de lanzamiento (release cycle) Tiempo mínimo tomado para el lanzamiento Indice de satisfacción del cliente Mejora en la productividad

108 108 BENEFICIOS 70% más rápido que los tests manuales Más amplia cobertura de pruebas de las funcionalidad Asegura consistencia Reduce tiempo y coste Mejora la precisión Intervención humana no requerida Mejor velocidad ejecutando los casos de prueba Scripts reusables Reducción del tiempo para el lanzamiento al mercado

109 109 PERFORMANCE TESTING 27/05/2013

110 QUE ES EL TETING DE PERFORMANCE? 110 Implica testear la aplicación software para asegurar un comportamiento aceptable frente a las espectativas de carga Tiempo de respuesta es importante para el rendimiento El objetivo del performance testing no es encontrar bugs sino eliminar cuellos de botella Puntos de enfoque: Velocidad Determina si la aplicación responde rapidamente Escalabilidad Determina la carga máxima de usuarios que la aplicación puede soportar Estabilidad Determina si la aplicación es estable frentre a varias cargas

111 111 POR QUÉ EL PERFORMANCE TESTING? Cubre parte de las pruebas necesarias para la mejora del producto antes de ser lanzado al mercado Sin performance testing, el software tendrá problemas frente: Comportamiento lento frente a una carga simultánea de usuarios Inconsistencias debido a diferentes Operating systems Pobre usabilidad Determina si el software tiene una velocidad, escalabilidad y estabilidad aceptable

112 112 TIPOS DE PERFORMANCE Load testing Verifica la habilidad de respuesta de la aplicación frente a una previa carga Stress testing tráfico alto o procesamiento de datos. El objetivo es identificar puntos de rotura de la aplicación Endurance testing Comportamiento de la aplicación frente a una carga durante un periodo largo de tiempo Volume testing Monitorización del comportamiento del sistema frente a un volumen de datos altos en la base de datos Scalabilty testing Determinar la efectividad del software mediante el incremento del volumen de usuarios

113 113 PROBLEMAS COMUNES EN EL PERFORMANCE Largo tiempo de carga Load time es normalmente el tiempo inicial tomado por la aplicación para arrancar Pobre tiempo de respuesta tiempo consumido por el usuario desde hacer una petición has tener respuesta. Debería ser muy rápido, en caso contrario, el usuario pierde interes Pobre escalabilidad No poder atender a un número esperado de usuarios Cuello de botella Obstrucciones en el sistema las cuales degradan el performance de la aplicación Utilización de la CPU Utilizaciñon de la memoria Utilización de la red Limitaciones en el OS Uso del disco

114 PROCESO DEL PERFORMANCE TESTING 114 La metodología doptada depende depende de los objetivos de los tests de performance. El proceso generico es el siguiente Identificar el entorno de test Determinar el criterio de performance Plan y diseño Configurar el entorno de test Imprementar los test diseñados Ejecutar los tests Analizar y retestear

Control de Calidad de Software. Ing. Jorge Montaño Párraga

Control de Calidad de Software. Ing. Jorge Montaño Párraga Control de Calidad de Software Ing. Jorge Montaño Párraga Agenda Contenido Porque es necesario controlar la calidad? Que es testear? 7 Principios de Control de Calidad Proceso Fundamental de SQA Porque

Más detalles

E 2.4.1 Documento de entrega de Aplicación

E 2.4.1 Documento de entrega de Aplicación E 2.4.1 Documento de entrega de Aplicación Versión: 0.1 Fecha: 11/08/11 Autor: Email: Antoni Bertran Bellido abertran@opentrends.net Historial de cambios Versión Fecha Autor Cambios 0.1 11/08/11 Antoni

Más detalles

Plan de estudios ISTQB: Nivel Fundamentos

Plan de estudios ISTQB: Nivel Fundamentos Plan de estudios ISTQB: Nivel Fundamentos Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE

Más detalles

Ingeniería de Software Dr. Marcello Visconti Z. Ingeniería de Software

Ingeniería de Software Dr. Marcello Visconti Z. Ingeniería de Software Universidad Técnica Federico Santa María Departamento de Informática Ingeniería de Software Dr. Marcello Visconti Z. Programa Proceso de Software y Paradigmas de Desarrollo Gestión de Proyectos Fases del

Más detalles

Temario III Testing in the Large

Temario III Testing in the Large Temario III Testing in the Large 1ra Parte Verificación y Validación de Software UNS 1 Contenidos Testing de Integración Testing de Sistema Testing de Regresión Verificación y Validación de Software UNS

Más detalles

NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE IGNACIO BAYUGAR

NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE IGNACIO BAYUGAR NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE IGNACIO BAYUGAR Ignacio.bayugar@mercadolibre.com, i id nachobayugar@gmail.com NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE El desarrollo ágil El nuevo rol de

Más detalles

UTN Proyecto. Testing de Software - Calidad de productos de Software. Autor: Gabriela Muñoz

UTN Proyecto. Testing de Software - Calidad de productos de Software. Autor: Gabriela Muñoz UTN Proyecto Testing de Software - Calidad de productos de Software Autor: Gabriela Muñoz Índice ÍNDICE 2 1 FUNDAMENTOS DEL TESTING 7 1.1 CALIDAD DE SOFTWARE 7 1.2 CALIDAD 7 1.3 POR QUÉ ES NECESARIA LA

Más detalles

Ingeniería del Software. Pruebas. Pruebas en el PUD. Las pruebas del software. Tipos de prueba Estrategias de prueba

Ingeniería del Software. Pruebas. Pruebas en el PUD. Las pruebas del software. Tipos de prueba Estrategias de prueba Pruebas Pruebas en el PUD Las pruebas del software Diseño de casos de prueba Tipos de prueba Estrategias de prueba 1 2 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos

Más detalles

SSTQB. Nivel Fundamentos. Examen ejemplo. Programa de estudios 2010

SSTQB. Nivel Fundamentos. Examen ejemplo. Programa de estudios 2010 SSTQB Nivel Fundamentos Examen ejemplo Página 1 de 12 Fecha publicación: 28 - octubre - 2015 Índice Preguntas... 3 Respuestas... 12 Página 2 de 12 Fecha publicación: 28 - octubre - 2015 Preguntas 1 2 Una

Más detalles

capacitación y guía para el desarrollo de software Pruebas de Software Pruebas de Software 1

capacitación y guía para el desarrollo de software Pruebas de Software Pruebas de Software 1 Pruebas de Software Pruebas de Software 1 PRUEBAS DE SOFTWARE... 3 INTRODUCCIÓN... 3 Definiciones [1]... 3 Filosofía y Economía... 4 Justificación... 4 PRINCIPIOS [1]... 7 NIVELES DE PRUEBAS... 8 TIPOS

Más detalles

Ingeniería de Software Avanzada

Ingeniería de Software Avanzada Universidad Técnica Federico Santa María Departamento de Informática Ingeniería de Software Avanzada Dr. Marcello Visconti Z. Conceptos básicos de testing Una falla (failure) ocurre cuando un programa

Más detalles

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO.

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. 0. Consideraciones iniciales. Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Por esta razón,

Más detalles

Claves de la automatización de pruebas de software

Claves de la automatización de pruebas de software SQS Software Quality Systems Claves de la automatización de pruebas de software Jaime Paniagua Madrid, 26 de Septiembre 2012 Índice 1. Introducción al Proceso de Automatización 2. Fases en el Proceso de

Más detalles

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1. Cliente: FCM-UNA Página 1 de 14 PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA Cliente: FCM-UNA Página 2 de 14 Tabla de contenido 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. ALCANCE 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga. Documento técnico de Oracle Junio de 2009

Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga. Documento técnico de Oracle Junio de 2009 Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga Documento técnico de Oracle Junio de 2009 Identificación rápida de cuellos de botella: Una mejor manera de realizar

Más detalles

Empresa Financiera Herramientas de SW Servicios

Empresa Financiera Herramientas de SW Servicios Empresa Financiera Herramientas de SW Servicios Resulta importante mencionar que ésta es una empresa cuya actividad principal está enfocada a satisfacer las necesidades financieras de los clientes, a través

Más detalles

Implantación y Aceptación del Sistema

Implantación y Aceptación del Sistema y Aceptación del Sistema 1 y Aceptación del Sistema ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN...5 Tarea IAS 1.1: De finición del Plan de... 5 Tarea IAS

Más detalles

Criterios de clasificación

Criterios de clasificación Criterios de clasificación Usualmente clasificamos para agrupar elementos con características comunes, simplificando la realidad y analizando un conjunto de elementos desde distintos puntos de vista. Sobre

Más detalles

Mejoras en el Proceso de Testing

Mejoras en el Proceso de Testing Mejoras en el Proceso de Testing Fernando Calles Gato Indra Sistemas fcalles@indra.es The premiere software and product delivery event. 4 de Noviembre, Madrid 2 MARCO CONCEPTUAL Por qué es necesario el

Más detalles

Agile Testing. Sesión 8. Metodologías Ágiles de Desarrollo de Software Domingo Gallardo, DCCIA, Univ. Alicante

Agile Testing. Sesión 8. Metodologías Ágiles de Desarrollo de Software Domingo Gallardo, DCCIA, Univ. Alicante Agile Testing Sesión 8 Unas palabras previas de cautela Las pruebas no son una verificación formal de un programa, no pueden garantizar la corrección del software para todos los posibles casos de entrada

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

Más detalles

Unidad Didáctica 1: Introducción y conceptos básicos (test de software embebido) Sistemas embebidos para tiempo real

Unidad Didáctica 1: Introducción y conceptos básicos (test de software embebido) Sistemas embebidos para tiempo real Unidad Didáctica 1: Introducción y conceptos básicos (test de software embebido) Sistemas embebidos para tiempo real Agenda Test de software embebido Conceptos generales Tipos de test Técnicas de depuración

Más detalles

Business white paper. Siete mejores prácticas para construir aplicaciones que cumplan con los requisitos del negocio

Business white paper. Siete mejores prácticas para construir aplicaciones que cumplan con los requisitos del negocio Business white paper Siete mejores prácticas para construir aplicaciones que cumplan con los requisitos del negocio Índice de contenidos 3 Resumen ejecutivo 3 Introduction 3 Enterprise-level best practices

Más detalles

Cartera de soluciones Silk: la opción más ligera para la realización de pruebas, el desarrollo y la gestión

Cartera de soluciones Silk: la opción más ligera para la realización de pruebas, el desarrollo y la gestión Cartera de soluciones : la opción más ligera para la realización, el desarrollo y la gestión Ligera Creada tan solo con la funcionalidad que necesita Asequible Desde soluciones gratuitas hasta concesiones

Más detalles

Testing Software S.A

Testing Software S.A Testing S.A info@testingsoft.com www.testingsoft.com Tel. Oficina: +506 2573.6959, Costa Rica Testing se complace en presentar su oferta de Capacitación para el año 2014. Nuestra Capacitación está divida

Más detalles

PLIEGO DE PRESCRIPCIONES TECNICAS PARTICULARES PARA EL REDISEÑO DE LA WEB MUNICIPAL USANDO DISEÑO ADAPTATIVO

PLIEGO DE PRESCRIPCIONES TECNICAS PARTICULARES PARA EL REDISEÑO DE LA WEB MUNICIPAL USANDO DISEÑO ADAPTATIVO ASUNTO: PLIEGO DE PRESCRIPCIONES TECNICAS PARTICULARES PARA EL REDISEÑO DE LA WEB MUNICIPAL USANDO DISEÑO ADAPTATIVO Informazioaren Teknologien Saila Departamento de Tecnologías de la Información Herritarrentzako

Más detalles

Mantenimiento de Sistemas de Información

Mantenimiento de Sistemas de Información de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD MSI 1: REGISTRO DE LA PETICIÓN...4 Tarea MSI 1.1: Registro de la Petición... 4 Tarea MSI 1.2: Asignación de la Petición... 5 ACTIVIDAD

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

Más detalles

Temario del curso de

Temario del curso de Temario del curso de Capacitación en QA Testing Software S.A Tel. Oficina: +506 2573.6959, Costa Rica info@testingsoft.com www.testingsoft.com Testing Software Temario del Curso de Capacitación en QA 2014

Más detalles

CAPÍTULO 5. Hemos utilizado la técnica de programación orientado a objetos por su

CAPÍTULO 5. Hemos utilizado la técnica de programación orientado a objetos por su 88 CAPÍTULO 5 5. IMPLEMENTACIÓN 5.1 Modelo Utilizado en Programación. Hemos utilizado la técnica de programación orientado a objetos por su eficiencia y eficacia en el modelo mvc, ya que permite la reutilización

Más detalles

METODOLOGÍA DE GESTION DE PROYECTOS

METODOLOGÍA DE GESTION DE PROYECTOS METODOLOGÍA DE GESTION DE PROYECTOS CONTENIDO CONTENIDO... 2 ALCANCE... 4 MARCO METODOLÓGICO... 4 ETAPAS DEL PROCESO... 5 1. ETAPA 0: INICIACIÓN...5 FASE DE INICIO...5 2. ETAPA 1: PLANEAMIENTO...6 FASE

Más detalles

Gestión de calidad a lo largo del ciclo de vida de productos y aplicaciones

Gestión de calidad a lo largo del ciclo de vida de productos y aplicaciones IBM Software Gestión de ciclo de vida de productos y aplicaciones Junio 2011 Gestión de calidad a lo largo del ciclo de vida de productos y aplicaciones Soluciones IBM para un planeta más inteligente 2

Más detalles

Sistema de Gestión del Plan de Obras Plan de Verificación y Validación Versión 1.0. Historia de revisiones

Sistema de Gestión del Plan de Obras Plan de Verificación y Validación Versión 1.0. Historia de revisiones Sistema de Gestión del Plan de Obras Plan de Verificación y Validación Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 22/08/2005 1.0 Versión preliminar Horacio Nova 25/08/2005 1.0 Versión

Más detalles

Mejores prácticas en las pruebas de aplicaciones móviles

Mejores prácticas en las pruebas de aplicaciones móviles Diciembre 2013 Santiago Díaz Responsable técnico en el Centro experto en movilidad de atsistemas En este artículo: Introducción Tests en dispositivos o en simuladores Tipos de pruebas Pruebas funcionales

Más detalles

José Alberto García Coria Director CENIT Salamanca. Salamanca, Febrero 2011

José Alberto García Coria Director CENIT Salamanca. Salamanca, Febrero 2011 José Alberto García Coria Director CENIT Salamanca Salamanca, Febrero 2011 Índice Objetivos Servicios de Pruebas Ciclo de Vida de las Pruebas Tipos de Pruebas Herramientas Objetivos Objetivos Exponer el

Más detalles

WEBSIGNER APPLET FAQS

WEBSIGNER APPLET FAQS WebSigner 6.4 WEBSIGNER APPLET FAQS Versión 1.1 HOJA DE CONTROL DOCUMENTAL Resumen El propósito de este documento es proveer una guía de FAQs para resolver las preguntas más comunes sobre este componente.

Más detalles

Novedades de Soluciones para la Gestión del Ciclo de Vida de Aplicaciones (CLM 2012)

Novedades de Soluciones para la Gestión del Ciclo de Vida de Aplicaciones (CLM 2012) Novedades de Soluciones para la Gestión del Ciclo de Vida de Aplicaciones (CLM 2012) Ana López-Mancisidor Rueda Arquitecto de Soluciones para la Gestión del Ciclo de Vida de las Aplicaciones ana.lopez@es.ibm.com

Más detalles

Calidad y Software. Evento ONGEI 29 mar 11. www.asistp.com 1

Calidad y Software. Evento ONGEI 29 mar 11. www.asistp.com 1 Calidad y Software Evento ONGEI 29 mar 11 www.asistp.com 1 Agenda La Calidad y los Procesos El Proceso de Software Las pruebas de Software www.asistp.com 2 Calidad www.asistp.com 3 Calidad algunas definiciones

Más detalles

SEIDA TOOLS: MANUAL DE USO

SEIDA TOOLS: MANUAL DE USO 15/4/2011 SUNAT SEIDA TOOLS: MANUAL DE USO Nuevo SIGAD Equipo de Arquitectura Contenido 1 Introducción 4 2 Requisitos 5 3 Instalación 5 4 Uso 7 5 Configuración 8 6 Envíos 11 6.1 Escenario 1: envío por

Más detalles

Implantación de Sistemas

Implantación de Sistemas Implantación de Sistemas Maria Ines Parnisari 17 de Diciembre de 2014 Índice Parte 1: Implantación... 2 Factores clave para una implantación exitosa... 2 Etapas de un proyecto de Sistemas... 2 Fases de

Más detalles

HERRAMIENTAS Y METODOLOGÍAS VERSIÓN 3

HERRAMIENTAS Y METODOLOGÍAS VERSIÓN 3 HERRAMIENTAS Y METODOLOGÍAS VERSIÓN 3 RESUMEN EJECUTIVO Herramientas y Metodologías Herramientas de Desarrollo o Desarrollo de aplicaciones Oracle Designer Oracle Software Configuration Manager (SCM) Oracle

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Panda Perimetral Management Console. Guía para Partners

Panda Perimetral Management Console. Guía para Partners Panda Perimetral Management Console Guía para Partners Aviso de copyright Panda Security 2014. Todos los derechos reservados. Ni la documentación, ni los programas a los que en su caso acceda, pueden copiarse,

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

Importancia de las pruebas de software

Importancia de las pruebas de software Dr. Eduardo A. RODRÍGUEZ TELLO CINVESTAV-Tamaulipas 30 de marzo del 2011 Dr. Eduardo RODRÍGUEZ T. (CINVESTAV) Pruebas de software 30 de marzo del 2011 1 / 40 1 Importancia de las pruebas de software Introducción

Más detalles

DIRECCIÓN DE SISTEMAS DE INFORMACIÓN DEPARTAMENTO CERES

DIRECCIÓN DE SISTEMAS DE INFORMACIÓN DEPARTAMENTO CERES DIRECCIÓN DE SISTEMAS DE INFORMACIÓN DEPARTAMENTO CERES SERVICIO DE NOTIFICACIONES ELECTRÓNICAS Y DIRECCIÓN ELECTRÓNICA HABILITADA MANUAL DE CONFIGURACIÓN PARA SISTEMAS WINDOWS NOMBRE FECHA Elaborado por:

Más detalles

K2BIM Plan de SQA Versión 1.1

K2BIM Plan de SQA Versión 1.1 K2BIM Plan de SQA Versión 1.1 Historia de revisiones Fecha VersiónDescripción Autor 18/08/2009 1.0 Creación del documento. Diego Píriz 23/08/2009 1.1 Pequeñas correciones. Alan Descoins 1 Contenido 1.

Más detalles

Conceptos útiles y glosario de definiciones

Conceptos útiles y glosario de definiciones http://www.java.com/es/download/faq/helpful_concepts.xml junio 16, 2015 Conceptos útiles y glosario de definiciones Para ayudar a los que visiten las páginas de ayuda con los conceptos y términos con los

Más detalles

CLASE # 4 DESCRIPCIÓN GENERAL DE LAS PRUEBAS DINÁMICAS

CLASE # 4 DESCRIPCIÓN GENERAL DE LAS PRUEBAS DINÁMICAS CLASE # 4 DESCRIPCIÓN GENERAL DE LAS PRUEBAS DINÁMICAS 750105M - TÉCNICAS DE PRUEBAS DE SOFTWARE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN UNIVERSIDAD DEL VALLE SEMESTRE 2013A - DOCENTE BEATRIZ FLORIAN GAVIRIA

Más detalles

Pruebas de software la salvación, un proceso sin utilidad, trivial, simplemente una moda, o...?

Pruebas de software la salvación, un proceso sin utilidad, trivial, simplemente una moda, o...? Pruebas de software la salvación, un proceso sin utilidad, trivial, simplemente una moda, o...? Maria Clara Choucair Cárdenas mcchoucair@choucairtesting.com Choucair Testing S.A. (574) 316 6300, Medellín

Más detalles

Aseguramiento de Calidad de Software Guía de revisión

Aseguramiento de Calidad de Software Guía de revisión Aseguramiento de Calidad de Software Guía de revisión Control de versiones Autor Fecha Ver. Cambio mcano 05 de marzo de 2012 0.9 Pre release. vmoreno, rrodriguez, mcano 08 de Marzo de 2012 1.0 Versión

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Servicio de Notificaciones Electrónicas y Dirección Electrónica Habilitada

Servicio de Notificaciones Electrónicas y Dirección Electrónica Habilitada Servicio de Notificaciones Electrónicas y Dirección Electrónica Habilitada Apartado Postal Electrónico Manual de Configuración de Navegadores Abril 2011 Versión: Abril 2011 Página 1 de 28 Índice de Contenidos

Más detalles

SCR6150c Versión 2.0(12/01/05)

SCR6150c Versión 2.0(12/01/05) SCR6150c Versión 2.0(12/01/05) Mantis: Manual de Usuario Fecha: 11/09/2007 Referencia: EJIE S.A. Mediterráneo, 3 Tel. 945 01 73 00* Fax. 945 01 73 01 01010 Vitoria-Gasteiz Posta-kutxatila / Apartado: 809

Más detalles

Visual Studio Team System 2010

Visual Studio Team System 2010 Visual Studio Team System 2010 5. Pruebas Automatizadas con Visual Studio 6. Pruebas codificadas de interfaz de usuario 7. Pruebas Web de desempeño Identificación de candidatos para la automatización Visual

Más detalles

HP COSTA RICA R&D CENTER

HP COSTA RICA R&D CENTER HP COSTA RICA R&D CENTER Taller Exploratorio De Pruebas Universidad de Costa Rica Luis García Ileana Montealegre Roy Campos 1 1 R&D EN COSTA RICA - Desarrollo de ASICs (HPN/BCS/ISS) - Esquipo en desarrollo

Más detalles

Historia de revisiones

Historia de revisiones Proyecto Help-Desk Plan de Verificación y Validación Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 16/08/2005 1.0 Primera versión del documento Martín Boero Plan de Verificación y

Más detalles

ACELERANDO DEVOPS JORNADAS DE INFORMÁTICA DEL URUGUAY JIAP 2015. César Búa Solutions Services Manager Red Hat Latin America - TILSOR

ACELERANDO DEVOPS JORNADAS DE INFORMÁTICA DEL URUGUAY JIAP 2015. César Búa Solutions Services Manager Red Hat Latin America - TILSOR JORNADAS DE INFORMÁTICA DEL URUGUAY JIAP 2015 César Búa Solutions Services Manager Red Hat Latin America - TILSOR AGENDA El mundo en que vivimos Las organizaciones de IT Entorno típico de fabricación de

Más detalles

Ingeniería de Software. Pruebas

Ingeniería de Software. Pruebas Ingeniería de Software Pruebas Niveles de prueba Pruebas unitarias Niveles Pruebas de integración Pruebas de sistema Pruebas de aceptación Alpha Beta Niveles de pruebas Pruebas unitarias Se enfocan en

Más detalles

WEBSIGNER APPLET MANUAL DE USUARIO

WEBSIGNER APPLET MANUAL DE USUARIO WebSigner 6.4 WEBSIGNER APPLET MANUAL DE USUARIO Versión 1.0 HOJA DE CONTROL DOCUMENTAL Resumen El propósito de este documento es proveer Manual de Usuario para la instalación, desinstalación y solución

Más detalles

Manual de Quipux para usuarios finales

Manual de Quipux para usuarios finales Quipux, gestiona la documentación digital y/o impresa, dicha documentación puede se interna, es decir aquella que se remite y se recibe en los departamentos de la misma organización. Asimismo, el Quipux

Más detalles

Collaborative Lifecycle Management

Collaborative Lifecycle Management Collaborative Lifecycle Management IBM Rational Software Portafolio.. Documentación Técnica... COLLABORATIVE LIFECYCLE MANAGEMENT La solución de IBM Rational para la Gestión del Ciclo de Vida Colaborativo

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S3 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

Más detalles

Arquitectura software EN-HORA

Arquitectura software EN-HORA Arquitectura de en:hora Arquitectura software EN-HORA en:hora es un software de control de acceso y presencia con una arquitectura modular. El software se implementa mediante un conjunto de componentes

Más detalles

1. O3 Server Administrator... 2 1.1 Usando O3 Server Administrator... 2 1.2 Administrando el O3 Server... 4 1.3 Administrando los Cubos... 14 1.

1. O3 Server Administrator... 2 1.1 Usando O3 Server Administrator... 2 1.2 Administrando el O3 Server... 4 1.3 Administrando los Cubos... 14 1. O3 Server Administrator...................................................................................... 2 1 Usando O3 Server Administrator...........................................................................

Más detalles

Paula Izaurralde. Especialista en Calidad en ARRIS Argentina. Ayudante en Metodologías Ágiles en el Desarrollo de Software

Paula Izaurralde. Especialista en Calidad en ARRIS Argentina. Ayudante en Metodologías Ágiles en el Desarrollo de Software Marcela Garay Moyano Test Manager en ARRIS Argentina. Paula Izaurralde Especialista en Calidad en ARRIS Argentina. Luciano Marzo Tester en ARRIS Argentina ISTQB Certified Tester. Docente en la Diplomatura

Más detalles

Continuous Integration Contenido

Continuous Integration Contenido Continuous Integration Contenido Continuous Integration... 1 Principios del Manifiesto Ágil... 3 Concepto... 3 Qué es integrar?... 3 Qué implica construir?... 3 Entonces, Qué es la Integración Continua?...

Más detalles

APLICATECA MANTIS. Manual de administrador. By Open Sistemas. www.telefonica.es

APLICATECA MANTIS. Manual de administrador. By Open Sistemas. www.telefonica.es APLICATECA MANTIS Manual de administrador. By Open Sistemas www.telefonica.es INDICE APLICATECA 1 QUÉ ES MANTIS?... 4 2 FLUJO DE TRABAJO... 5 2.1 CICLO DE VIDA DE UNA INCIDENCIA... 5 2.2 ESTADOS DE UNA

Más detalles

La Implementación de SAP R/3

La Implementación de SAP R/3 SESIÓN 3 La implementación de SAP R/3 Etapas del Proyecto y Tareas a Realizar Entorno de la Implementación SAP Taller de Introducción a ERP SESIÓN 3/1 La Implementación de SAP R/3 El significado usual

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S1 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

Más detalles

Aseguramiento de la Calidad

Aseguramiento de la Calidad ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ESTUDIO DE VIABILIDAD DEL SISTEMA... 2 ACTIVIDAD EVS-CAL 1: IDENTIFICACIÓN DE LAS PROPIEDADES DE CALIDAD PARA EL SISTEMA... 3 Tarea EVS-CAL 1.1: Constitución del Equipo

Más detalles

MANTENIMIENTO DE SOFTWARE

MANTENIMIENTO DE SOFTWARE MANTENIMIENTO DE SOFTWARE Definición de Mantenimiento El estándar IEEE 1219 [IEEE, 1993] define el Mantenimiento del Software como la modificación de un producto software después de haber sido entregado

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

Manual de Usuario Versión 1.0 MANUAL DE USUARIO DEL PORTAL

Manual de Usuario Versión 1.0 MANUAL DE USUARIO DEL PORTAL MANUAL DE USUARIO DEL PORTAL 1 ÍNDICE DE CONTENIDOS: Premisas...3 Requerimiento de hardware y software...3 Descripción del portal...3 Ingreso al portal...3 Módulo de configuración...4 Perfil y firma...4

Más detalles

1. Introducción. 2. El concepto de calidad del software. 3. Estándares de calidad existentes. 4. La norma ISO 9000-3

1. Introducción. 2. El concepto de calidad del software. 3. Estándares de calidad existentes. 4. La norma ISO 9000-3 Contenido INGENIERIA DE SOFTWARE Tema 6: Administración de la calidad del software Presenta: David Martínez Torres Universidad Tecnológica de la Mixteca dtorres@mixteco.utm.mx Cubo 37 1. Introducción 2.

Más detalles

SCL Artículos CONSULTING. Luis Aguado SCl Consulting CONSULTING

SCL Artículos CONSULTING. Luis Aguado SCl Consulting CONSULTING SCL Artículos Luis Aguado SCl Consulting Two value releases per year Este concepto es simple: la TI debe ser capaz de liberar 2 nuevas versiones (releases) para las soluciones de negocio al año, basadas

Más detalles

Badboy: Manual de usuario

Badboy: Manual de usuario Badboy: Manual de usuario Fecha: Referencia: EJIE S.A. Mediterráneo, 3 Tel. 945 01 73 00* Fax. 945 01 73 01 01010 Vitoria-Gasteiz Posta-kutxatila / Apartado: 809 01080 Vitoria-Gasteiz www.ejie.es Este

Más detalles

CompuwareCorporation. Maximizar la Calidad de la aplicación con Continuous Integrated Testing

CompuwareCorporation. Maximizar la Calidad de la aplicación con Continuous Integrated Testing CompuwareCorporation Maximizar la Calidad de la aplicación con Continuous Integrated Testing Page 2 Un líder en la industria del Software 32 años ayudando a las principales compañías del mundo a aumentar

Más detalles

13º Unidad Didáctica. RAID (Redundant Array of Independent Disks) Eduard Lara

13º Unidad Didáctica. RAID (Redundant Array of Independent Disks) Eduard Lara 13º Unidad Didáctica RAID (Redundant Array of Independent Disks) Eduard Lara 1 RAID: INTRODUCCIÓN Sistema de almacenamiento que usa múltiples discos duros entre los que distribuye o replica los datos.

Más detalles

Buenas prácticas en el diseño de software

Buenas prácticas en el diseño de software Buenas prácticas en el diseño de software Guión Introducción Conceptos clave Test de usuarios Metodología y procesos de diseño Ejemplos y casos de uso. Preguntas y dudas Objetivos - Explicar un proceso

Más detalles

BMC ProactiveNet Performance Management

BMC ProactiveNet Performance Management SERVICE ASSURANCE INFORMACIÓN DE PRODUCTO DATASHEET BMC ProactiveNet Performance Management Beneficios clave» Genera menos eventos y más inteligentes a través del motor de análisis de autoaprendizaje y

Más detalles

Técnicas Avanzadas de Testing Automático

Técnicas Avanzadas de Testing Automático Técnicas Avanzadas de Testing Automático Marcelo Frias ITBA - Buenos Aires, Argentina CONICET Preliminares: Calidad Validación y Verificación Especificaciones y V&V Análisis estático y dinámico Inspecciones

Más detalles

Tema 5. Gestión de Proyectos (ISG3)

Tema 5. Gestión de Proyectos (ISG3) Tema 5. Gestión de Proyectos (ISG3) Antonio José Sáenz Albanés (C.T.O) Reconocimiento No Comercial Compartir Igual - 2.5 - España 1 Planificación 1ª Clase: Presentación y Conceptos Generales 2ª Clase:

Más detalles

Consejería de Hacienda y Administración Pública. Cliente 3.1.0 @firma v5: Preguntas, problemas y respuestas

Consejería de Hacienda y Administración Pública. Cliente 3.1.0 @firma v5: Preguntas, problemas y respuestas Sevilla, noviembre de 2010 Control de Versiones Hoja de control Fecha Autor Descripción 15/11/2010 RPV Versión 1.0 Página 2 de 15 Contenido 1 Sobre el cliente de firma... 4 2 Entornos soportados... 4 3

Más detalles

Construcción y Pruebas de Software

Construcción y Pruebas de Software UNIVERSIDAD DE CARABOBO Facultad Experimental de Ciencias y Tecnología Departamento de Computación Construcción y Pruebas de Software Elaborado por: Gustavo Bazán Francisco Rosas Bárbula, Junio de 2012

Más detalles

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

Más detalles

ADMINISTRACIÓN DE PROYECTOS

ADMINISTRACIÓN DE PROYECTOS ADMINISTRACIÓN DE PROYECTOS QUÉ ES LA ADMINISTRACIÓN DE PROYECTOS? Es la planeación, organización, dirección y control de los recursos para lograr un objetivo a corto plazo. También se dice que la administración

Más detalles

Diseño e implementación de la herramienta Cristali Programming

Diseño e implementación de la herramienta Cristali Programming Tecnológico de Costa Rica Escuela de Ingeniería en Computación Diseño e implementación de la herramienta Cristali Programming Informe Final de Práctica de Especialidad para optar por el título de Ingeniero

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S4 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

Más detalles

Palabras clave: Eficiencia, Pruebas de Software, Herramientas.

Palabras clave: Eficiencia, Pruebas de Software, Herramientas. Evaluación de la Eficiencia en Productos de Software. Experiencia desde el Departamento de Evaluación de Productos de Software de CALISOFT. Evaluation of the efficiency in Software Products. Experience

Más detalles

Guía de instalación de Presto 2015.01 (20/07/2015)

Guía de instalación de Presto 2015.01 (20/07/2015) Guía de instalación de Presto 2015.01 (20/07/2015) Guía de instalación 1 Requisitos del sistema 1 Permisos necesarios 1 Presto 2 Instalación de Presto: Monopuesto 2 Instalación de Presto: Servidor de red

Más detalles

Plantilla de Información Periódica

Plantilla de Información Periódica Manual de Usuario Versión 1.2 Plantilla de Información Periódica Segunda Generación de Sistemas Ingresadores Marzo 2007 TABLA DE CONTENIDOS 1. INTRODUCCIÓN...1 2. OBJETIVO...2 3. TÉRMINOS Y DEFINICIONES...2

Más detalles

Porque hacemos Testing? BY: ALFREDO ALVAREZ

Porque hacemos Testing? BY: ALFREDO ALVAREZ Porque hacemos Testing? BY: ALFREDO ALVAREZ Base para nuestra conversación Cual es el trabajo de un tester? En el pasado-> Mantener la calidad y encontrar Bugs. En estos días-> Mantener el equipo al tanto

Más detalles

Nomenclador de cargos

Nomenclador de cargos Nomenclador de cargos ROLES Áreas de I T Definición de módulos y roles Versión: 1.0 Pagina 1 Módulos interactuantes en un área de IT 1. Infraestructura Tecnológica 2. Producción de Software 3. Asistencia

Más detalles

Introducción 90% Figura 1 Síndrome del 90%

Introducción 90% Figura 1 Síndrome del 90% El Problema Quality Control = Project Control? Indicadores Objetivos para Control de Proyectos de Desarrollo de Software Lic. Juan Pablo Pussacq Laborde Jefe de la Oficina de Proyectos, RMyA Introducción

Más detalles

Sistemas de Programas Universidad Simón Bolívar

Sistemas de Programas Universidad Simón Bolívar Pruebas en sistemas orientados a objetos Sistemas de Programas Universidad Simón Bolívar Agenda 2 Introducción Qué es probar software? Por qué necesitamos probar el software? Terminología de Pruebas Black

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

Aseguramiento de la calidad del software

Aseguramiento de la calidad del software Aseguramiento de la calidad del software Standard for Software Reviews and Audits [IEEE 1028] IEEE 1028 Para qué sirve Provee definiciones y requerimientos uniformes para los procesos de revisión y auditoría.

Más detalles