GRUPO 6 - Procesos de Verificacion y Validacion en El Desarrollo de Software

Procesos de Validacin y Verificacin en el
Desarrollo de Software
AO DE LA INTEGRACION NACIONAL Y EL RECONOCIMIENTO DE NUESTRA DIVERSIDAD
UNIVERSIDAD NACIONAL
SAN LUIS GONZAGA DE ICA

FACULTAD DE INENIERIA DE SISTEMAS
Procesos de Validacin y Verificacin en el Desarrollo de Software

TEMA
Bendez Pizarro Sergio Ral Buenda Chilquillo Fredy Daro Campos Rosas Ral Alonso Cruz Rivas Christian Fernando Massa Morn Fredy Martn INTENGRANTES Calidad de Software CURSO Ing. Alonso Morales Loayza DOCENTE
ICA PER 2012
DEDICATORIA
El presente trabajo est dedicado en primer lugar a Dios, hacedor de todo y quien nos ha brindado la oportunidad de disfrutar la vida siempre guiados por seres especiales. A nuestros padres, quienes son aquellos seres, pilares fundamentales de nuestra formacin como personas de bien y porque es a ellos a quienes le debemos todo lo que tenemos en la vida. A nuestros docentes, que nos guan en el aprendizaje diario buscando convertirnos en excelentes profesionales y brindndonos los ltimos conocimientos para nuestro buen desenvolvimiento en la sociedad.
ENTREGABLES
MONOGRAFA Documento compuesto por 6 reas y 12 secciones distribuidas de la siguiente manera: REAS 1. Titulo 2. Conceptos Bsicos 3. Resumen del Proyecto 4. Contenido 5. Recomendaciones y Conclusiones 6. Referencias Bibliogrficas SECCIONES 1. Procesos de Verificacin y Validacin de Software 2. Inspeccin de Software 3. Lista De Fallos 4. Pruebas de Software 5. Tcnicas de Pruebas 6. Ciclo de Pruebas de Software 7. Planificacin y Diseo de Pruebas de software 8. Ejecucin de pruebas de software 9. Herramientas para la Ejecucin de Pruebas 10. Recomendaciones para la Ejecucin de Pruebas 11. Documentacin para la Ejecucin de pruebas 12. Proceso de Depuracin DVD Contiene el trabajo monogrfico en su versin digital, as como la bibliografa y recursos utilizados para su desarrollo. SKYDRIVE El presente trabajo de investigacin se encuentra disponible en la nube, al cual puede acceder desde la siguiente direccin:
http://sdrv.ms/UvO2Iz
Conceptos
Bsicos
RESUMEN
Durante y despus del proceso de implementacin, el programa que se est desarrollando debe ser comprobado para asegurar que satisface su especificacin y entrega la funcionalidad esperada por las personas que pagan por el software. La verificacin y la validacin es el nombre dado a estos procesos de anlisis y pruebas, que son un conjunto de actividades que se realizan durante cada etapa del proceso de software. Segn Boehm 1979 expreso la diferencia entre ellas: Validacin: estamos construyendo el producto correcto? Verificacin: estamos construyendo el producto correctamente? Esto implica que la verificacin debe estar de acuerdo con especificacin, satisfacer sus requerimientos funcionales y no funcionales. La validacin sin embargo es un proceso ms general cuyo objetivo es que el software satisfaga las expectativas del cliente. El objetivo primordial es la seguridad de que el sistema est hecho para un propsito. Dentro de la verificacin y validacin existen dos conceptos complementarios tales como: Inspecciones de software y Pruebas de software Las inspecciones son un proceso de verificacin y validacin esttica en el que un sistema se revisa para encontrar errores omisiones y anomalas. El proceso de inspeccin siempre se realiza utilizando una lista de los errores o fallos comunes de los programadores. Esta se somete a discusin por el personal con experiencia y se actualiza frecuentemente segn se vaya teniendo experiencia. Las Pruebas son bsicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrn ser implementadas en cualquier momento de dicho proceso de desarrollo. Las tcnicas de prueba de software son aplicables como buenas prcticas en el proceso de prueba en la etapa de desarrollo, cada una de ellas es importante y mientras ms compleja sea la codificacin ms de estas tcnicas se utilizaran, los cdigos as como las interfaces tienen sus propias tcnicas de prueba y en cada una de ellas depende necesariamente de los involucrados en el desarrollo y de qu manera aplicarlas.
El ciclo de vida del software presenta 4 componentes que son: Planear, Ejecutar, Chequear y Actuar; que es un ciclo que se repetir hasta llegar a los puntos de validacin acordados. El objetivo del proceso de diseo de casos de pruebas es crear un conjunto de casos de pruebas que sean efectivos descubriendo defectos y muestren que el sistema satisface sus requerimientos, existen distintas aproximaciones para disear casos de prueba. La documentacin es una parte fundamental de las pruebas para poder tener una gua exacta de lo que se realiza y no desperdiciar horas de trabajo. El diseo de casos de prueba es una parte de las pruebas de componentes y sistemas en las que se disea los casos de prueba (entradas y salidas esperadas) para probar el sistema. El objetivo del proceso de diseo de casos de pruebas es crear un conjunto de casos de pruebas que sean efectivos descubriendo defectos y muestren que el sistema satisface sus requerimientos. La ejecucin de pruebas de software se aplica como una etapa ms del proceso de desarrollo de software, su objetivo es asegurar que el software cumpla con las especificaciones requeridas y eliminar los posibles defectos que este pudiera tener. Para realizar la ejecucin de pruebas de software necesitamos de herramientas dedicadas a pruebas dentro de la organizacin. En la actualidad las herramientas para la ejecucin de pruebas de software son numerosas ya que estas deben hacer frente a una gran cantidad de metodologas de desarrollo, lenguajes de programacin, sistemas operativos, hardware, etc. En un principio la mayora de empresas de desarrollo contaban con una etapa de pruebas demasiado informal, en la actualidad las pruebas de software se han convertido en una de las etapas ms crticas del ciclo de vida del desarrollo de software y esto ha causado el origen de diversas metodologas. Durante la ejecucin de las pruebas es fundamental conocer el estado del proceso de prueba, saber qu pruebas se han ejecutado y cules quedan pendientes, qu defectos se han encontrado, etc. Para ello, se crean los registros de pruebas, Informes de Incidentes e Informes resumen de pruebas. Una vez realizadas las pruebas y definidos los posibles fallos o errores se procede a entrar en el proceso de depuracin, que es la correccin de errores que slo afectan a la programacin, porque no provienen de errores previos en el anlisis o en el diseo. A veces la depuracin se hace luego de la entrega del sistema al cliente y es parte del mantenimiento.
OBJETIVOS
OBJETIVO GENERAL El objetivo General del proceso de verificacin y validacin de software es entender la importancia del modelo de trabajo a seguir para desarrollar productos de software donde lo que se busca es mejorar la calidad del software producido. OBJETIVOS FUNDAMETALES Producir un modelo que represente el comportamiento de sistema real lo suficientemente prximo como para que el modelo pueda sustituir al sistema con el objetivo de experimentar determinados aspectos del mismo. Aumentar a un nivel aceptable la credibilidad del modelo, para que sea aceptado por los gestores y usuarios finales a nivel de toma de decisiones sobre los resultados proporcionados por dicho modelo. OBJETIVOS ESPECFICOS Entender la diferencia entre verificacin y validacin. Tener claro los tipos de pruebas y las tcnicas para usarlas. Entender el ciclo de vida de las pruebas. Dar herramientas para la planificacin, diseo y ejecucin de las pruebas de software.
VOCABULARIO TCNICO
Verificar Comprobar o examinar la verdad de algo. Es el proceso que se realiza para revisar si un determinado producto est cumpliendo con los requisitos y normas previstos. Validar Dar fuerza o firmeza a algo, hacerlo vlido. Es el proceso que se realiza para revisar si un determinado producto es el que el usuario necesita. Barry W. Boehm Es un ingeniero informtico estadounidense especialista en ciencias tecnolgicas, conocido por sus mltiples aportes a este campo. Trazabilidad Es la propiedad del resultado de una medida o del valor de un estndar donde ste pueda estar relacionado con referencias especificadas, usualmente estndares nacionales o internacionales, a travs de una cadena continua de comparaciones todas con incertidumbres especificadas. Michael Fagan Reconocido por ser el inventor de oficiales inspecciones de software que se refieren a un proceso estructurado que trata de encontrar defectos en los cdigos de programacin durante las diversas fases del proceso de desarrollo de software. Alexander Graham Bell Fue un cientfico, inventor y logopeda britnico. Contribuy al desarrollo de las telecomunicaciones y la tecnologa de la aviacin. Stakeholder Es un trmino en ingls para referirse a quienes pueden afectar o son afectados por las actividades de una empresa. Testing Conocido como pruebas de software cuyo objetivo es proporcionar informacin objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Stubs Un stub es, en el contexto del testeo del software, un trozo de cdigo usado como sustituto de alguna otra funcionalidad. Un stub puede simular el comportamiento de cdigo existente o ser el sustituto temporal para un cdigo an no desarrollado.
Beta Tester Es un usuario de programas que usan sus conocimientos informticos y su tiempo para detectar errores en el software y as poder informar de stos para que los desarrolladores los corrijan. Feedback Conocido como retroalimentacin y que es un mecanismo de control de los sistemas dinmicos por el cual una cierta proporcin de la seal de salida se redirige a la entrada, y as regula su comportamiento. Walkthrough Es una revisin estructurada de software hecha por colegas en la cual un diseador o programador lidera a los miembros de un equipo de desarrollo y donde los participantes hacen preguntas y comentarios acerca de posibles errores. Parmetros Una variable que puede ser recibida por una rutina o subrutina. Puede alterar su comportamiento en el tiempo de ejecucin. Almacenamiento dinmico Incrementar o reducir de forma dinmica el nmero de elementos. Compilador Programa informtico que traduce un lenguaje de programacin a otro lenguaje de programacin, generando un equivalente que la mquina ser capaz de interpretar Lenguaje formal Lenguaje cuyos smbolos primitivos y reglas para unir esos smbolos estn formalmente especificados. Test Plan Documento que detalla un enfoque sistemtico para probar un sistema. Contiene tpicamente una comprensin detallada de lo que es el flujo de trabajo. Scripts Un archivo de rdenes o archivo de procesamiento por lotes que se almacena en un archivo de texto plano. GUI Graphic User Interface o interfaz grfica de usuario. Identificador Son smbolos lxicos que nombran entidades.
Resumen del
Proyecto
INTRODUCCIN
El presente documento pretende dar a conocer todo lo referente al proceso de verificacin y validacin en el desarrollo de software, as como tambin extender el conocimiento sobre los conceptos de inspeccin de software, pruebas de software y las herramientas necesarias para realizar estas, adems de entender el ciclo de vida de las pruebas de software basndose en sus 4 pasos: Planear, Ejecutar, Chequear y Actuar. Estos conceptos son fundamentales a la hora de gestionar la calidad de un proyecto de software pero muchas veces no aplicados o no entendidos, es por ello que este documento pretende ser una gua de apoyo a la implementacin de dichas reas de proceso, y de sus metas y actividades. Describiremos las diferentes actividades relacionadas con dichos procesos. Se har un estudio de las pruebas, definiendo posibles estrategias, niveles y tipos de pruebas, buenas prcticas, y por otra parte de las revisiones o inspecciones. Tras la definicin de las actividades de validacin y verificacin se propondrn una serie de tcnicas y metodologas a seguir adems de algunas herramientas a utilizar para realizar las pruebas de software desde su concepcin, es decir cmo deben ser planificadas, su documentacin y como deben ser ejecutadas las mismas, as como tambin herramientas que pueden ser muy tiles para su ejecucin y de esta manera facilitar el desarrollo de las tareas relacionadas con dichos procesos. Por ltimo se har referencia a ciertas conclusiones y recomendaciones relacionadas con dichas reas de proceso tiles para tener otra perspectiva de los procesos.
INDICE GENERAL
1.- Procesos de Verificacin y Validacin de Software 17 Objetivos . 17 Tcnicas ... 17 Planificacin .... 20 2.- Inspeccin de Software . 22 Ventajas . 22 Proceso de inspeccin de programas . 22 Actividades en el proceso de inspeccin .. 23 Comprobaciones de inspeccin 24 Analisis esttico automatizado 25 -Etapas .. 25 3.- Lista De Fallos . 26 Fallos de datos Fallos de Control Fallos de entrada/salida Fallos de la interfaz Fallos de Gestin de Almacenamiento Fallos de Gestin de las Excepciones 4- Pruebas de Software .. 28 Tipos De Pruebas de Software . 28 - Revisiones de Cdigo . 28 - Pruebas Unitarias 29 - Pruebas de Integracin . 29 - Pruebas de Sistema .. 30 -Pruebas de Aceptacin 31 5.- Tcnicas de Pruebas 32 Tcnicas de Pruebas dinmicas 32 Basadas en la Especificacin .. 33 Basadas en la Estructura 35 Basadas en la experiencia . 36 Tcnicas de Control Estticas .. 36 Revisiones ... 38 Analisis Esttico .. 39 6.- Ciclo de Pruebas de Software 41 Planear Ejecutar Chequear Actuar
Calidad de Software
Ing. Alonso Morales Loayza
7.- Planificacin y Diseo de Pruebas de software 43 Diseo de casos de prueba . 43 Pruebas Funcionales (CAJA NEGRA) .. 44 Pruebas Estructurales (CAJA BLANCA) . 45 Enfoque prctico recomendado para el diseo de casos 46 Documentacin del diseo de pruebas . 47 Plan de Pruebas .. 48 Especificacin del Diseo de Pruebas . 48 Especificacin de Caso de Pruebas 49 Especificaciones del Procedimiento de Prueba 49 8.-Ejecucin de pruebas de software . 51 El proceso de ejecucin .. 51 El proceso de comprobacin . 52 9.- Herramientas para la Ejecucin de Pruebas 53 Herramientas E-Tester 53 Rational Functional Tester 53 Rational Manual Tester 54 Beneficios del Uso de Herramientas . 55 Riesgos del Uso de Herramientas 56 Factores a tener en cuenta para introducir una herramienta en una organizacin...57 10.- Recomendaciones para la Ejecucin de Pruebas 59 11.- Documentacin para la Ejecucin de pruebas .. 60 Histrico de Pruebas . 60 Informe de Incidente . 61 Informe resumen de pruebas . 61 12.- Proceso de Depuracin 63 Definicin. 63 Pasos para la Depuracin . 64
Procesos de Verificacin y Validacin en el Desarrollo de Software
14
INDICE DE FIGURAS
Clasificacin de Tcnicas Dinmicas (Figura 1) 32 Clasificacin de Tcnicas Estticas (Figura 2)... 37 Ciclo de Prueba de Software PDCA (Figura 3) 41 Esquema de una prueba de particiones (Figura 4)...44 Esquema de una prueba estructural (Figura 6) 46 Documentacin de un diseo de pruebas segn el estndar IEEE (Figura 7)... 47 Proceso de Ejecucin de Pruebas (Figura 8)... 51 Software Rational (Figura 9).. 53 Documentacin para la ejecucin de pruebas (Figura 10).. 60 Depuracin (Figura 11) 63
INDICE DE TABLAS
Equipo de Inscripcin de Programas (Tabla 1) 23 Comprobacin de inversin de software (Tabla 2). 24
Contenido
Calidad de Software
1. PROCESOS DE VERIFICACIN Y VALIDACIN DE SOFTWARE

La verificacin y validacin se realiza durante cada etapa del proceso de software desde las revisiones de los requerimientos, las etapas de diseo e inspecciones de cdigo hasta la prueba del producto. Para entender el concepto que implica el proceso de verificacin de software partiremos primero por descubrir en trminos exactos lo que quiere decir Verificacin y Validacin. La verificacin y validacin son conceptos distintos aunque suelen confundirse. La diferencia mayor radica en la respuesta a dos preguntas: Segn Boehm en 1979 expres lo siguiente: Estamos construyendo el producto correctamente? Es decir se comprueba que el software cumple los requisitos funcionales y no funcionales de su especificacin (Verificacin). Estamos construyendo el producto correcto? Es decir asegurar que el sistema satisface las expectativas del usuario (Validacin) Esto implica que la verificacin debe estar de acuerdo con especificacin, satisfacer sus requerimientos funcionales y no funcionales. La validacin sin embargo es un proceso ms general cuyo objetivo es que el software satisfaga las expectativas del cliente.
1.1.
Objetivo del proceso de verificacin y validacin El objetivo primordial del proceso de verificacin y validacin es la seguridad de que el sistema est hecho para un propsito, es decir que el sistema debe ser lo bastante bueno para su uso pretendido.
1.2.
Tcnicas de verificacin y validacin Existen 2 Tcnicas de Verificacin y Validacin
- 18 -
Calidad de Software
1.2.1 Tcnicas Estticas (Revisiones): Revisin de software: analizan y comprueban las representaciones del sistema tales como el documento de requerimientos, diagramas de diseo y cdigo fuente del programa. Puede usarse en todas las etapas del proceso Las revisiones software pueden ser Informales No hay procedimientos definidos, por lo que la revisin se realiza de la forma ms flexible posible. Ventajas: menor coste y esfuerzo, preparacin corta, etc. Desventajas: Detectan menos defectos Semi - Formales Se definen unos procedimientos mnimos a seguir (walkthroughs). Formales (Inspecciones) Se define completamente el proceso. Revisin en detalle, por una persona o grupo distintos del autor, para: Verificar si el producto se ajusta a sus especificaciones o atributos de Calidad y a los estndares utilizados en la empresa. Sealar las desviaciones sobre los estndares y las especificaciones. Recopilar datos que realimenten inspecciones posteriores defectos recogidos, esfuerzo empleado, etc.).
1.2.2 Tcnicas Dinmicas (Pruebas): Pruebas de software: Implica ejecutar una implementacin del software con datos de prueba. Se examinan las salidas del software y su entorno operacional para comprobar que funciona tal y como se requiere.
- 19 -
Calidad de Software
Solo puede probarse un sistema cuando est disponible un prototipo o versin ejecutable del sistema. Las tcnicas de inspeccin comprenden las inspecciones del programa el anlisis automtico del cdigo fuente y la verificacin formal. Sin embargo las tcnicas estticas solo pueden comprobar la correspondencia entre un programa y su especificacin (verificacin) no pueden demostrar que el software es operacionalmente til. Tampoco se pueden usar tcnicas estticas para comprobar las propiedades emergentes del software como rendimiento y fiabilidad. 1.3. Planificacin de la verificacin y validacin La verificacin y validacin es un proceso caro, es necesario una planificacin cuidadosa para obtener el mximo provecho de las inspecciones y pruebas controlando los costos del proceso de verificacin y validacin. Debera comenzarse desde etapas tempranas del proceso de desarrollo. Como parte del proceso de planificacin de verificacin y validacin habra que decidir un equilibrio entre las aproximaciones estticas y dinmicas de la verificacin y validacin, pensar en estndares y procedimientos para las inspecciones y pruebas de software, establecer listas de comprobacin y definir el plan de pruebas de software. El relativo esfuerzo destinado a las inspecciones y las pruebas depende del tipo de sistema a desarrollar y de los expertos de la organizacin en la inspeccin de programas. La planificacin de las pruebas est relacionada con el establecimiento de estndares para el proceso de pruebas, no solo con la descripcin de los productos de las pruebas. Los planes de pruebas adems de ayudar con los gestores a asignar recursos y estimar el calendario de las pruebas, son de utilidad para los ingenieros del software implicados en el diseo y la realizacin de las pruebas de sistema. Estos ayudan al personal tcnico a obtener una panormica general de las pruebas del sistema y ubicas su propio trabajo en este contexto.
- 20 -
Calidad de Software
Los principales componentes de un plan de pruebas para un sistema grande son: El proceso de pruebas: Una descripcin de las principales fases del proceso de prueba. Trazabilidad de requerimientos: Los usuarios son los ms interesados que el sistema sea de calidad. Elementos probados: deberan especificarse los elementos que van a ser probados. Calendarios de pruebas: Un calendario de todas las pruebas y asignacin de recursos. Procedimiento de registro de pruebas: No es suficiente ejecutar simplemente las pruebas los resultados deben ser registrados sistemticamente.
- 21 -
Calidad de Software
2. INSPECCIONES DE SOFTWARE
Son un proceso de Verificacin y Validacin esttica en el que un sistema se revisa para encontrar errores, omisiones y anomalas. Generalmente las inspecciones se centran en el cdigo fuente pero puede inspeccionarse cualquier representacin legible de software como requerimientos o modelos de diseo. 2.1 Ventajas
Existen 3 ventajas fundamentales de la inspeccin sobre las pruebas
Durante las pruebas los errores pueden enmascarar otros errores. Cuando se descubre un error nunca se puede estar seguro de si otras anomalas de salida son debidas a un nuevo error o son efectos laterales del error original. Pueden inspeccionarse versiones incompletas de un sistema sin costes adicionales. Una inspeccin tambin puede considerar atributos de calidad ms amplios de un programa tales como grado de cumplimiento con los estndares portabilidad y mantenibilidad.
2.2 El proceso de inspeccin de programas Son revisiones cuyo objetivo es la deteccin de defectos en el programa. El concepto de un proceso de inspeccin formalizado se desarroll por IBM en los aos 70 (Fagan 1976 -1986). Actualmente es un mtodo bastante utilizado de verificacin de programa, especialmente en ingeniera de sistemas crticos. A partir del mtodo original de Fagan, se han desarrollado varias aproximaciones alternativas de las inspecciones (Graham 1993). Todas ellas estn basadas en un grupo con miembros que tienen diferentes conocimientos realizando una revisin cuidadosa lnea por lnea del cdigo fuente de programa. La diferencia principal entre las inspecciones de programas y otros tipos de revisiones de calidad es que el objetivo primordial de las inspecciones es encontrar defectos en el programa en lugar de considerar cuestiones de diseo ms generales.
- 22 -
Calidad de Software
Los defectos pueden ser errores lgicos anomalas en el cdigo que podran indicar una condicin errnea o el incumplimiento de los estndares del proyecto o la organizacin. Por otra parte otros tipos de revisin pueden estar ms relacionados con la agenda, los costes, el progreso frente a hitos definidos o la evaluacin de si es probable que el software cumpla con los objetivos fijados por la organizacin La inspeccin de programas es un proceso formal realizado por un equipo de al menos cuatro personas. Los miembros del equipo analizan sistemticamente el cdigo y sealan posibles defectos.
EQUIPO DE INSCRIPCIN DE PROGRAMAS

Autor o Propietario El programador o diseador responsable de generar el programa o documento. Responsable de reparar los defectos descubiertos durante el proceso de inspeccin. Encuentra errores, omisiones o inconsistencias en los programas y documentos. Tambin puede identificar cuestiones ms generales que estn fuera del mbito de inspeccin. Presenta el cdigo o documento en una reunin de inspeccin Registra los resultados de la reunin de inspeccin Gestiona el proceso y facilita la inspeccin. Realiza un informe de resultados del proceso para el moderador jefe Responsable de las mejoras del proceso de inspeccin actualizacin de las listas de comprobacin, estndares de desarrollo
Inspector Lector Secretario Presidente o Moderador Moderador Jefe
TABLA 1 2.3. Actividades en el proceso de inspeccin

Antes que se comience una inspeccin del programa es esencial que: Se tenga una especificacin precisa del cdigo a inspeccionar. Los miembros del equipo de inspeccin estn familiarizados con los estndares de la organizacin. Se haya distribuido una versin compatible y actualizada del cdigo a todos los miembros del equipo.
- 23 -
Calidad de Software
Las Actividades que debe seguir un proceso de inspeccin son: Planificacin: El moderador del equipo de inspeccin es el responsable de la planificacin de la inspeccin. Esto implica seleccionar un equipo de inspeccin, organizar una sala de reuniones y asegurar que el material a inspeccionar y sus especificaciones estn completas. Visin de conjunto: El programa a inspeccionar se presenta al equipo de inspeccin durante la etapa de revisin general cuando el autor del cdigo describe lo que el programa debe hacer. Preparacin Individual: A continuacin cada miembro del equipo estudia la especificacin, el programa y busca defectos en el cdigo. Reunin de inspeccin: La inspeccin en si misma debera ser bastante corta no mayor a dos horas y debera centrarse en la deteccin de defectos, cumplimiento de estndares y detectar programacin de baja calidad. Repeticin de trabajo: El autor del programa deber realizar los cambios para corregir los problemas identificados. En esta etapa el moderador deber decidir si se requiere una re-inspeccin de cdigo o es aprobado.
Durante una inspeccin a menudo se utiliza una lista de comprobacin de errores de programacin comunes para centrar el anlisis. 2.4. Comprobaciones de inspeccin Las comprobaciones de inspeccin son las principales inspecciones que se realizan en el software. Las Comprobaciones y lo que realiza cada una son: COMPROBACIONES DE INVERSIN DE SOFTWARE
Defecto de Datos Defectos de Control Defectos Entrada/Salida Defectos de Interfaz Defectos de Gestin de Almacenamiento Defectos de Manejo de Excepciones Se Inicializa todas las variables?, Tiene nombre todas las constantes? Se garantiza que termina cada bucle? Se utilizan todas las variables de entrada? Se les asigna un valor a todas las variables de salida? Concuerdan los tipos de parmetros reales y formales? Estn en orden todos los parmetros? Si una estructura enlazada se modifica Se reasigna correctamente todos los enlaces? Si se utiliza almacenamiento dinmico Se asigna correctamente el espacio de memoria? Se tienen en cuenta todas las condiciones de error posibles?
TABLA 2
Procesos de Verificacin y Validacin en el Desarrollo de Software - 24 -
Calidad de Software
2.5. Anlisis esttico automatizado Los analizadores estticos son herramientas de software que escanean el cdigo fuente de un programa y detectan posibles defectos y anomalas. Pueden detectar si las sentencias estn bien formadas, hacer inferencias sobre el flujo de control del programa y calcular el conjunto de todos los posibles valores para los datos del programa. Complementan las facilidades de deteccin de los errores proporcionados por el compilador del lenguaje. Pueden utilizarse como parte del proceso de inspeccin o como una actividad separada del proceso de verificacin y validacin. El objetivo del anlisis esttico automatizado es llamar la atencin del inspector sobre anomalas del programa, tales como variables que se utilizan sin inicializacin, variables que no se usan o datos cuyo valor poda estar fuera de alcance 2.5.1. Etapas del anlisis esttico automatizado Las etapas implicadas en el anlisis esttico comprenden: Anlisis del flujo de control: esta etapa identifica y resalta bucles con mltiples salidas o puntos de entrada y cdigo no alcanzable. Anlisis de uso de los datos: Esta etapa revela cmo se utilizan las variables del programa detectan variables que se utilizan sin inicializacin previa, variables que se asignan dos veces y no se utilizan. Anlisis de interfaces este anlisis comprueba la consistencia de las declaraciones de funciones y procedimientos y su utilizacin. Anlisis del flujo de informacin: Esta fase identifica las dependencias entre las variables de entrada y salida. Mientras no detecte anomalas muestra cmo se deriva el valor de cada variable del programa a partir de otros valores de variables. En esta fase debera ser capaz de encontrar valores que han sido calculados errneamente. Anlisis de caminos: esta fase del anlisis semntico identifica los posibles caminos del programa y muestra la sentencia ejecutadas en dicho camino.
- 25 -
Calidad de Software
3.- LISTAS DE FALLOS O ERRORES

El proceso de inspeccin siempre se realiza utilizando una lista de los errores comunes de los programadores. Esta se somete a discusin por el personal con experiencia y se actualiza frecuentemente segn se vaya teniendo experiencia. La lista de errores debe estar en funcin del lenguaje de programacin que se utilice. La cantidad de cdigo que se puede inspeccionar debe estar limitado, ya que a partir de un tiempo de inspeccin se baja la atencin y se hace ineficaz. Existen estudios que establecen que no deberan examinarse ms de 125 lneas de cdigo por sesin, y no ms de 2 horas. Clases de Fallos: Fallos de datos: 1. Las variables se inicializan antes que de que se utilicen los valores? 2. Todas las constantes tienen nombre? 3. El lmite superior de los arrays es igual al tamao de los mismos? 4. Las cadenas de caracteres tienen delimitadores explcitos. 5. Existe posibilidad que el buffer se desborde? Fallos de control: 1. Para cada instruccin condicional Es correcta la condicin? 2. Todos los ciclos terminan? 3. Los bloques estn delimitados correctamente? 4. En las instrucciones case Se han tomado en cuenta todos los casos? 5. Si se requiere un break Se ha incluido? 6. Existe cdigo no alcanzable? Fallos de entrada/salida: 1. Se utilizan todas las variables de entrada? 2. Antes de que salgan Se le han asignado valores a las variables de salida? 3. Provocan corrupcin de los datos las entradas no esperadas? Fallos de la interfaz: 1. Las llamadas a funciones y mtodos tienen el nmero correcto de parmetros? 2. Concuerdan los tipos de los parmetros formales y reales? 3. Estn los parmetros en el orden adecuado? 4. Se utilizan los resultados de las funciones? 5. Existen funciones o procedimientos no invocados?
- 26 -
Calidad de Software
Fallos de gestin de almacenamiento: 1. Si una estructura con punteros se modifica, Se reasignan correctamente todos los punteros? 2. Si se utiliza almacenamiento dinmico, se asigna correctamente el espacio? 3. Se desasigna explcitamente la memoria despus de que se libera? Fallos de gestin de las excepciones: 1. Se toman en cuenta todas las condiciones de errores posibles?
- 27 -
Calidad de Software
4.- PRUEBAS DE SOFTWARE

Las Pruebas de Software, o "Testing" es una investigacin emprica y tcnica cuyo objetivo es proporcionar informacin objetiva e independiente sobre la calidad del producto bajo pruebas a la parte interesada o Stakeholder. Las Pruebas de Software son una actividad ms en el proceso de "Aseguramiento de la Calidad" Las Pruebas son bsicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrn ser implementadas en cualquier momento de dicho proceso de desarrollo. 4.1. Tipos de Pruebas de Software 4.1.1. Revisiones de cdigo Las revisiones de cdigo son las nicas que se podran omitir de todos los tipos de pruebas, pero tal vez sea buena idea por lo menos hacer alguna de ellas: Pruebas de escritorio La prueba de escritorio rinde muy poco, tal vez menos de lo que cuesta, pero es una costumbre difcil de desterrar. Es bueno concentrarse en buscar anomalas tpicas, como variables u objetos no inicializados o que no se usan, ciclos infinitos y dems Recorridos de cdigo Los recorridos rinden mucho ms. Son exposiciones del cdigo escrito frente a pares. El programador, exponiendo su cdigo, encuentra muchos errores. Adems da ideas avanzadas a programadores nuevos que se lleva a recorrer. Inspecciones de cdigo Las llamadas inspecciones de cdigo consisten en reuniones en conjunto entre los responsables de la programacin y los responsables de la revisin. Tienen como objetivo revisar el cdigo escrito por los programadores para chequear que cumpla con las normas que se hayan fijado y para verificar la eficiencia del mismo. Se realizan siguiendo el cdigo de un pequeo porcentaje de mdulos seleccionados al azar o segn su grado de complejidad.
Calidad de Software
4.1.2. Pruebas Unitarias Las pruebas unitarias se realizan para controlar el funcionamiento de pequeas porciones de cdigo como ser subprogramas (en la programacin estructurada) o mtodos (en POO). Generalmente son realizadas por los mismos programadores puesto que al conocer con mayor detalle el cdigo, se les simplifica la tarea de elaborar conjuntos de datos de prueba para testearlo. Si bien una prueba exhaustiva sera impensada teniendo en cuenta recursos, plazos, etc., es posible y necesario elegir cuidadosamente los casos de prueba para recorrer tantos caminos lgicos como sea posible. Inclusive procediendo de esta manera, deberemos estar preparados para manejar un gran volumen de datos de prueba. El tipo de prueba a la cual se someter a cada uno de los mdulos depender de su complejidad. Recordemos que nuestro objetivo aqu es encontrar la mayor cantidad de errores posible. Si se pretende realizar una prueba estructurada, se puede confeccionar un grafo de flujo con la lgica del cdigo a probar. De esta manera se podrn determinar todos los caminos por los que el hilo de ejecucin pueda llegar a pasar, y por consecuencia elaborar los juegos de valores de pruebas para aplicar al mdulo, con mayor facilidad y seguridad. 4.1.3. Pruebas de Integracin Las pruebas de integracin tienen como base las pruebas unitarias y consisten en una progresin ordenada de testeos para los cuales los distintos mdulos van siendo ensamblados y probados hasta haber integrado el sistema completo. Si bien se realizan sobre mdulos ya probados en forma individual, no es necesario que se terminen todas las pruebas unitarias para comenzar con las de integracin. El orden de integracin de los mdulos influye en: La forma de preparar los casos de prueba. Las herramientas a utilizar (mdulos ficticios, muones, impulsores o stubs). El orden para codificar y probar los mdulos. El costo de preparar los casos. El costo de la depuracin.
- 29 -
Calidad de Software
Existen principalmente dos tipos de integracin: La integracin incremental Consiste en combinar el conjunto de mdulos ya probados con los siguientes mdulos a probar. Luego se va incrementando progresivamente el nmero de mdulos unidos hasta que se forma el sistema completo. La integracin no incremental o Big Bang Se combinan todos los mdulos de una vez. Para ambos tipos de integracin se debern preparar los datos de prueba junto con los resultados esperados. Si en algn momento de la prueba se detectara uno o ms errores, se dejar constancia del hecho y se reenviarn los mdulos afectados al responsable de la programacin para que identifique la causa del problema y lo solucione. Luego se volvern a efectuar las pruebas programadas y as sucesivamente hasta que el sistema entero est integrado y sin errores. 4.1.4. Pruebas de Sistema Las pruebas de sistema se realizan una vez integrados todos los componentes. Su objetivo es ver la respuesta del sistema en su conjunto, frente a distintas situaciones. Se simulan varias alternativas que podran darse con el sistema implantado y en base a ellas se prueba la eficacia y eficiencia de la respuesta que se obtiene. Se pueden distinguir varios tipos de prueba, por ejemplo: Pruebas negativas: se trata de que el sistema falle para ver sus debilidades. Pruebas de recuperacin: se simulan fallas de software y/o hardware para verificar la eficacia del proceso de recuperacin. Pruebas de rendimiento: tiene como objeto evaluar el rendimiento del sistema integrado en condiciones de uso habitual. Pruebas de resistencia o de estrs: comprueban el comportamiento del sistema ante situaciones donde se demanden cantidades extremas de recursos (nmero de transacciones simultneas anormal, excesivo uso de las memorias, etc.).
- 30 -
Calidad de Software
Pruebas de seguridad: se utilizan para testear el esquema de seguridad intentando vulnerar los mtodos utilizados para el control de accesos no autorizados al sistema. Pruebas de instalacin: verifican que el sistema puede ser instalado satisfactoriamente en el equipo del cliente, incluyendo todas las plataformas y configuraciones de hardware necesarias. Pruebas de compatibilidad: se prueba al sistema en las diferentes configuraciones de hardware o de red y de plataformas de software que debe soportar.
4.1.5. Pruebas de Aceptacin Las pruebas de aceptacin, al igual que las de sistema, se realizan sobre el producto terminado e integrado; pero a diferencia de aquellas, estas estn concebidas para que sea un usuario final quien detecte los posibles errores. Se clasifican en dos tipos: Pruebas Alfa y Pruebas Beta. Las pruebas Alfa se realizan por un cliente en un entorno controlado por el equipo de desarrollo. Para que tengan validez, se debe primero crear un ambiente con las mismas condiciones que se encontrarn en las instalaciones del cliente. Una vez logrado esto, se procede a realizar las pruebas y a documentar los resultados. Por otro lado, las pruebas Beta se realizan en las instalaciones propias de los clientes. Para que tengan lugar, en primer trmino se deben distribuir copias del sistema para que cada cliente lo instale en sus oficinas, dependencias y/o sucursales. Si se tratase de un nmero reducido de clientes, el tema de la distribucin de las copias no representa grandes dificultades, pero en el caso de productos de venta masiva, la eleccin de los Beta Tester debe realizarse con sumo cuidado. En el caso de las pruebas Beta, cada usuario realizar sus propias pruebas y documentar los errores que encuentre para que el equipo de desarrollo los tenga en cuenta al momento de analizar las posibles modificaciones. Cuando el sistema tenga un cliente individual, las pruebas de aceptacin se hacen de comn acuerdo con ste, en cambio cuando se est desarrollando un producto masivo, los usuarios para pruebas se determinan de formas menos estrictas, y hay que ser muy cuidadoso en la evaluacin del Feedback que proveen. Por lo tanto, en este segundo caso hay que dedicar un esfuerzo considerable a la planificacin de las pruebas de aceptacin.
Calidad de Software
5.- TCNICAS DE PRUEBAS DE SOFTWARE

Existen distintas tcnicas de pruebas de software, con sus debilidades y sus puntos fuertes. Cada una de ellas es buena para encontrar un tipo especfico de defectos. Las pruebas realizadas en distintas etapas del ciclo de desarrollo del software encontrarn diferentes tipos de defectos. Las pruebas dinmicas slo se aplican sobre el cdigo del producto para detectar defectos y determinar atributos de calidad del software, por lo que estaran ms orientadas al rea de validacin. Por otra parte, las tcnicas de pruebas estticas son tiles para evaluar o analizar documentos de requisitos, documentacin de diseo, planes de prueba, o manuales de usuario, e incluso para examinar el cdigo fuente antes de ejecutarlo. En este sentido, ayudan ms a la implementacin del proceso de verificacin. Las pruebas estticas y las pruebas dinmicas son mtodos complementarios ya que ambas tratan de detectar distintos tipos de defectos de forma efectiva y eficiente, aunque las pruebas estticas estn orientadas a encontrar defectos mientras que las dinmicas fallos. 5.1. Tcnicas de pruebas dinmicas Las tcnicas de pruebas dinmicas ejecutan el software. Para ello introducen una serie de valores de entrada, y examinan la salida comparndola con los resultados esperados.
Basadas en Especificacion Basadas en Estructura Basadas en Experiencia
Particionamiento de Equivalencia
Pruebas de Sentencia
Adivinar errores
Analisis Frontera
Pruebas de Decision
Pruebas exploratorias
Tabla de decision
Pruebas de Caminos
Transicion estados
Caso de uso
Figura 1. Clasificacin de Tcnicas Dinmicas

- 32 -
Calidad de Software
a) Basadas en la especificacin Son conocidas como tcnicas de pruebas de caja negra o conducidas por entradas/salidas, porque tratan el software como una caja negra con entradas y salidas, pero no tienen conocimiento de cmo est estructurado el programa o componente dentro de la caja. Esencialmente, el tcnico de pruebas se concentra en qu hace el software y no en cmo lo hace. A continuacin, se detallarn las tcnicas basadas en la especificacin ms comunes. - Particionamiento de equivalencia Esta tcnica consiste en dividir un conjunto de condiciones de prueba en grupos o conjuntos que puedan ser considerados iguales por el sistema. Esta tcnica requiere probar slo una condicin para cada particin. Esto es as porque se asume que todas las condiciones de una particin sern tratadas de la misma manera por el software. Si una condicin en una particin funciona, se asume que todas las condiciones en esa particin funcionarn. De la misma forma, si una de las condiciones en una particin no funciona, entonces se asume que ninguna de las condiciones en esta particin en concreto funcionar. - Anlisis de valor frontera Los errores generados por los programadores tienden a agruparse alrededor de las fronteras. El anlisis del valor frontera est basado en probar los valores frontera de las particiones. Al hacer comprobaciones de rango, probablemente se est usando de forma inconsciente el anlisis del valor frontera. En esta tcnica, tambin, se cuenta con fronteras vlidas (en las particiones vlidas) y frontera no vlidas (en las particiones no vlidas).
- Tablas de decisin Las tcnicas de Particionamiento de equivalencia y anlisis del valor frontera son aplicadas con frecuencia a situaciones o entradas especficas. Sin embargo, si diferentes combinaciones de entradas dan como resultado diferentes acciones, resulta ms difcil usar las tcnicas anteriores. Las especificaciones suelen contener reglas de negocio para definir las funciones del sistema y las condiciones bajo las que cada funcin opera.
- 33 -
Calidad de Software
Las decisiones individuales son normalmente simples, pero el efecto global de las condiciones lgicas puede ser muy complejo. Los tcnicos de pruebas necesitan ser capaces de asegurarse que todas las combinaciones de las condiciones que puedan ocurrir han de ser probadas, por lo tanto, hay que capturar todas las decisiones de una forma que permita explorar sus combinaciones. El mecanismo usado con frecuencia para capturar las decisiones lgicas es la tabla de decisin. Una tabla de decisin lista todas las condiciones de entrada que pueden ocurrir y todas las acciones que pueden surgir de ellas. Estn estructuradas por filas, con las condiciones en la parte de arriba de la tabla y las posibles acciones en la parte de abajo. Cada columna, representa una regla de negocio individual y muestra cmo se combinan las condiciones de entrada para producir acciones. De esta manera, cada columna representa un posible caso de prueba, ya que identifica ambas entradas y salidas. - Transicin de estados La tcnica anterior (tabla de decisin) es particularmente til cuando las combinaciones de condiciones de entrada producen varias acciones. La tcnica de transicin de estados se utiliza con sistemas en los que las salidas son desencadenadas por cambios en las condiciones de entrada, o cambios de estado. Las pruebas de transicin de estados se usan cuando alguno de los aspectos del sistema se pueden describir en lo que se denomina una mquina de estados finitos. Esto significa que el sistema puede estar en un nmero (finito) de estados, y las transiciones de un estado a otro estn determinadas por las reglas de la mquina. Este es el modelo en el que se basan el sistema y las pruebas. Un sistema de estados finitos se suele representar mediante un diagrama de estados. - Pruebas de casos de Uso Las pruebas de caso de uso son una tcnica que ayuda a identificar casos de prueba que ejerciten el sistema entero transicin a transicin desde el principio al final. Un caso de uso es una descripcin de un uso particular del sistema por un actor (un usuario del sistema).
- 34 -
Calidad de Software
Cada caso de uso describe las interacciones que el actor tiene con el sistema para conseguir una tarea concreta. Los actores son generalmente gente pero pueden ser tambin otros sistemas. Resumidamente, los casos de uso son una secuencia de pasos que describen las interacciones entre el actor y el sistema.
b) Basadas en la estructura
Las pruebas estructurales son una aproximacin al diseo de casos de prueba donde las pruebas se derivan a partir del conocimiento de la estructura e implementacin del software. Esta aproximacin se denomina a veces pruebas de caja blanca. La comprensin del algoritmo utilizado en un componente puede ayudar a identificar particiones adicionales y casos de prueba, asegurando as un mayor rango de pruebas. Las tcnicas ms sofisticadas proporcionan, de forma incremental, una cobertura de cdigo completa. A continuacin, se detallarn las tcnicas basadas en la estructura ms comunes. - Pruebas de sentencia El objetivo de las pruebas de sentencia es ir probando las distintas sentencias a lo largo del cdigo. Si se prueban todas y cada una de las sentencias ejecutables del cdigo, habr una cobertura de sentencia total. Es importante recordar que estas pruebas slo se centran en sentencias ejecutables a la hora de medir la cobertura. Es muy til el uso de grficos de flujo de datos para identificar este tipo de sentencias, que se representan mediante rectngulos. - Pruebas de decisin El objetivo de estas pruebas es asegurar que las decisiones en un programa son realizadas adecuadamente. Las decisiones son parte de las estructuras de seleccin e iteracin, por ejemplo, aparecen en construcciones tales como: IF THEN ELSE, o DO WHILE, o REPEAT UNTIL. Para probar una decisin, es necesario ejecutarla cuando la condicin que tiene asociada es verdadera y tambin cuando es falsa. De esta forma, se garantiza que todas las posibles salidas de la decisin se han probado. Al igual que las pruebas de sentencias, las pruebas de decisin tienen una medida de cobertura asociada e intentan conseguir el 100% de la cobertura de decisin.
Calidad de Software
- Pruebas de caminos Las pruebas de caminos son una estrategia de pruebas estructurales cuyo objetivo es probar cada camino de la ejecucin independientemente. En todas las sentencias condicionales, se comprueban los casos verdadero y falso. En un proceso de desarrollo orientado a objetos, pueden utilizarse las pruebas de caminos cuando se prueban los mtodos asociados a los objetos. Las pruebas de caminos no prueban todas las posibles combinaciones de todos los caminos en el programa. Para cualquier componente distinto de un componente trivial sin bucles, este es un objetivo imposible. Existe un nmero infinito de posibles combinaciones de caminos en los programas con bucles. Incluso cuando todas las sentencias del programa se han ejecutado al menos una vez, los defectos del programa todava pueden aparecer cuando se combinan determinados caminos. c) Basadas en la experiencia Las tcnicas basadas en experiencia son aquellas a las que se recurre cuando no hay una especificacin adecuada desde la que crear casos de prueba basados en especificacin, ni hay tiempo suficiente para ejecutar la estructura completa del paquete de pruebas. - Adivinar errores Las tcnicas basadas en experiencia usan la experiencia de los usuarios y de los tcnicos de pruebas para determinar las reas ms importantes de un sistema y ejercitar dichas reas de forma que sean consistentes con el uso que se espera que tengan. - Pruebas exploratorias Tcnicas de pruebas ms sofisticadas que se realizan sobre la base del conocimiento y experiencia de los tcnicos de pruebas; dicha base es un factor decisivo para el xito de las pruebas.
5.2 Tcnicas de control estticas Aunque las tcnicas estticas son utilizadas cada vez ms, las pruebas dinmicas siguen siendo las tcnicas predominantes de validacin y verificacin.
- 36 -
Calidad de Software
Las tcnicas estticas permiten encontrar las causas de los defectos. Aplicar un proceso de pruebas estticas sobre el proceso de desarrollo permite una mejora del proceso evitando cometer errores similares en el futuro. Las tcnicas de pruebas estticas proporcionan una forma de mejorar la productividad del desarrollo del software. El objetivo fundamental de las pruebas estticas es mejorar la calidad de los productos software, ayudando a los ingenieros a reconocer y arreglar sus propios defectos en etapas tempranas del proceso de desarrollo. Aunque las tcnicas de este tipo de pruebas son muy efectivas, no conviene que sustituyan a las pruebas dinmicas. Estas pruebas, son las primeras que se aplican al software y buscan defectos sin ejecutar cdigo. Por esta razn, tambin se llaman tcnicas de no ejecucin. Las tcnicas estticas tienen que ver con el anlisis y control de las representaciones del sistema, es decir de los diferentes modelos construidos durante el proceso de desarrollo de software. La mayora de las tcnicas estticas son tcnicas de verificacin que pueden probar cualquier tipo de documentacin ya sea cdigo fuente, o documentacin y modelos de diseo, o especificacin funcional o de requisitos.
Revisiones
Anlisis Esttico
Informal
Analisis de flujo de control
Walkthrough
Analisis de uso de los datos
Revisin Tcnica
Analisis de Interfaz
Inspeccin
Analisis de flujo de informacion
Analisis de caminos
Figura 2. Clasificacin de tcnicas de control estticas

Calidad de Software
a) Revisiones Las revisiones son una tcnica esttica que consiste en realizar un anlisis de un documento con el objetivo de encontrar y eliminar errores. El tipo de una revisin vara en funcin de su nivel de formalidad. En este caso, formalidad se refiere a nivel de estructura y documentacin asociada con la revisin. Unos tipos de revisin son completamente informales mientras que otros son muy formales. No existe una revisin perfecta, sino que cada una tiene un propsito distinto durante las etapas del ciclo de vida del documento. Los principales tipos de revisiones se describen a continuacin: - Informal Dar un borrador de un documento a un colega para que lo lea es el ejemplo ms simple de revisin. Es una forma de conseguir beneficios (limitados) a un bajo costo ya que no siguen ningn proceso formal a seguir. La revisin puede implementarse mediante pares de programadores, donde uno revisa el cdigo del otro, o mediante un tcnico que lidere el diseo de las revisiones y el cdigo. - Walkthrough Un Walkthrough se caracteriza porque el autor del documento bajo revisin va guiando al resto de participantes a travs del documento exponiendo sus ideas para conseguir un entendimiento comn y recoger respuestas. Es especialmente til si los asistentes no estn relacionados con el software, o no son capaces de entender los documentos de desarrollo de software. En las revisiones Walkthrough se explica el contenido del documento paso a paso hasta llegar a un consenso en los cambios y en el resto de informacin. La reunin es dirigida por los autores y a menudo est presente un documentador, y para facilitar su ejecucin pueden usarse escenarios y simulaciones para validar el contenido. - Revisin tcnica Una revisin tcnica es una reunin que se centra en conseguir consenso sobre el contenido tcnico de un documento, por lo que es posible que sea dirigida por un experto tcnico. Los expertos necesarios para una revisin tcnica son, por ejemplo, responsables del diseo y usuarios clave.
Calidad de Software
El objetivo principal de este tipo de revisiones es evaluar el valor de conceptos tcnicos y alternativas del entorno del proyecto y del propio producto. Este tipo de revisin a menudo se lleva a cabo por pares (peer reviews) y para facilitar su ejecucin suelen utilizarse listas de comprobacin o listas de registro. - Inspeccin La inspeccin es el tipo de revisin ms formal. El documento bajo inspeccin es preparado y validado minuciosamente por revisores antes de la reunin, se compara el producto con sus fuentes y otros documentos, y se usan listas de comprobacin. En la reunin de la inspeccin, se registran los defectos encontrados y se pospone toda discusin para la fase de discusin. Todo esto hace que la inspeccin sea una reunin muy eficiente. La inspeccin es dirigida normalmente por un moderador formado, no por el propio autor del documento, quien realiza un seguimiento formal aplicando criterios de salida. Los defectos encontrados son documentados en una lista de registro, y de manera opcional, para mejorar los procesos y aprender de los defectos encontrados, se realiza un anlisis de las causas de los mismos. Tambin, es habitual tomar mtricas que posteriormente son agrupadas y analizadas para optimizar el proceso. b) Anlisis esttico El anlisis esttico, al igual que las revisiones, busca defectos sin ejecutar el cdigo. Sin embargo, el anlisis esttico se lleva a cabo una vez que se escribe el cdigo. Su objetivo es encontrar defectos en el cdigo fuente y en los modelos del software. Se utilizan herramientas de software para procesar cdigo fuente. stas analizan sintcticamente el programa y tratan de descubrir condiciones potencialmente errneas y llamar la atencin del equipo de validacin y verificacin. Existen distintos tipos de anlisis sintctico, entre los que se encuentran: - Anlisis de flujo de control Comprueba los bucles con mltiples puntos de entrada o salida, encuentra cdigos inalcanzables.
Calidad de Software
- Anlisis de uso de los datos Detecta variables no inicializadas, variables escritas dos veces sin que intervenga una asignacin, variables que se declaran pero nunca se usan. - Anlisis de interfaz Comprueba la consistencia de una rutina, las declaraciones del procedimiento y su uso. - Anlisis de flujo de informacin Identifica las dependencias de las variables de salida. No detecta anomalas en s pero resalta informacin para la inspeccin o revisin del cdigo. - Anlisis de caminos Identifica los caminos del programa y arregla las sentencias ejecutadas en el camino. Es potencialmente til en el proceso de revisin.
- 40 -
Calidad de Software
6.- CICLO DE PRUEBA DE SOFTWARE

Existen mltiples enfoques del ciclo de la prueba de software basados en las experiencias de distintos profesionales, si bien todos son vlidos existen pasos que podemos considerar comunes y que se podran agrupar entre todos los distintos modelos.
Figura 3. Ciclo de Prueba de Software (PDCA) a) Planear Es establecer los objetivos y procesos necesarios para conseguir resultados de acuerdo con los requisitos del cliente y las polticas de la organizacin. 1. Identificar servicios 2. Identificar clientes 3. Identificar requerimientos de los clientes 4. Trasladar los requerimientos del cliente a especificaciones 5. Identificar los pasos claves del proceso (diagrama de flujo) 6. Identificar y seleccionar los parmetros de medicin 7. Determinar la capacidad del proceso 8. Identificar con quien compararse
- 41 -
Calidad de Software
Un caso de prueba bien diseado tiene gran posibilidad de llegar resultados ms fiables y eficientes, mejorar el rendimiento del sistema, y reducir los costos en tres categoras (Perry, 1995): 1) Productividad: menos tiempo para escribir y mantener los casos 2) Capacidad de prueba: menos tiempo para ejecutarlos 3) Programar la fiabilidad: estimaciones ms fiables y efectivas.
b) Hacer o Ejecutar Hacer las condiciones. Realizar trabajo de entrenamiento y aprendizaje. Acordar el procedimiento. Se procede a ejecutar la prueba segn los parmetros previamente fijados y se documentan los resultados haciendo un seguimiento del camino de los fallos, si hubiera, dentro del sistema y sus caractersticas. Generando un historial de las ejecuciones. La ejecucin de las pruebas debera ser en un mnimo de tiempo y con el mnimo de esfuerzo. La ejecucin nos genera: documentacin de los detalles de la prueba y sus salidas, lista de fallos y sus orgenes. Vemos que en este punto la documentacin es muy importante pues lo que buscamos es expresar de la mejor manera el error y resultados. Para ello la documentacin tiene que ser detallada pero en un lenguaje formal. c) Chequear o Verificar Chequear el programa y los resultados obtenidos. En este punto se comparan los resultados obtenidos de las pruebas con los resultados esperados: informacin obtenida, tiempos de respuesta, respuestas ante ataques a la seguridad, etc. Donde se falla o que parte del software necesita ser reformulada, con el listado de los errores se generaran informes a los stakeholders. Se generaran sugerencias y niveles de prioridad a los errores.
d) Actuar Tomar los cursos de accin decididos respectos de los errores hallados sea reparar, replantear o implementar alguna otra solucin. Se documentaran los detalles de las modificaciones del software y se pedir que se ejecuten de nuevo pruebas a los sectores que han sido modificados.
Calidad de Software
7. PLANIFICACIN Y DISEO DE PRUEBAS DE SOFTWARE

7.1. Diseo de casos de prueba El diseo de casos de prueba es una parte de las pruebas de componentes y sistemas en las que se disea los casos de prueba (entradas y salidas esperadas) para probar el sistema. El objetivo del proceso de diseo de casos de pruebas es crear un conjunto de casos de pruebas que sean efectivos descubriendo defectos y muestren que el sistema satisface sus requerimientos. Para disear un caso de prueba, se selecciona una caracterstica del sistema o componente que se est probando. A continuacin, se selecciona un conjunto de entradas que ejecutan dicha caracterstica, documentan las salidas esperadas o rango de salidas y, donde sea posible, se disea una prueba automatizada que prueba que las salidas reales y esperadas fueron las mismas. Existen varias aproximaciones que pueden seguirse para disear casos de pruebas las dos principales son: Pruebas Funcionales: En donde se identifican particiones de entrada y salida y se disean pruebas para que el sistema ejecute entradas de todas las particiones y genere salidas en todas las particiones. Las particiones son grupos de datos que tienen caractersticas comunes, como todos los nmeros negativos, todos los nombres con menos de 30 caracteres, todos los eventos provocados por la eleccin de opciones en un men, y as sucesivamente. Pruebas Estructurales: En donde se utiliza el conocimiento de la estructura del programa para disear pruebas que ejecuten toldas las partes del programa. Esencialmente, cuando se prueba un programa, debera intentarse ejecutar cada sentencia al menos una vez. Las pruebas estructurales ayudan a identificar casos de prueba que puedan hacer esto posible
En general cuando se disean casos de pruebas se debera comenzar por las pruebas de ms alto nivel, a partir de los requerimientos y luego de forma progresiva aadir pruebas ms detalladas como las pruebas estructurales o de particiones.
- 43 -
Calidad de Software
7.1.1 Pruebas Funcionales Las pruebas funcionales o las pruebas de Caja Negra, se basan en los datos de entrada y los datos de salida, buscando solamente el resultado sin preocuparse como se consigui este. Sin embargo en estas pruebas los datos de entrada y los resultados de salida de un programa normalmente se pueden agrupar en varias clases diferentes que tienen caractersticas comunes tales como nmeros positivos, nmeros negativos y selecciones de men. Los programas normalmente se comportan de una forma similar para todos los miembros de una clase. Es decir, si se prueba un programa que realiza algn clculo y requiere 2 nmeros positivos, entonces se esperara que el programa se comporte de la misma forma para todos los nmeros positivos. Debido a este comportamiento equivalente, estas clases de denominan a menudo particiones de equivalencia o dominios. Una aproximacin sistemtica al diseo de casos de prueba se basa en identificar todas las particiones para un sistema o componente. Los casos de prueba se disean para que las entradas o salidas pertenezcan a estas particiones.
- 44 -
Calidad de Software
Las particiones de equivalencia son conjuntos de datos en donde todos los miembros de los conjuntos deberan ser procesados de forma equivalente. Las particiones de equivalencia de salida son resultados del programa que tienen caractersticas comunes, por lo que pueden considerarse como una clase diferente. Tambin se identifican particiones en donde las entradas estn fuera de otras particiones que se han elegido. Estas prueban si el programa maneja entradas invlidas de forma correcta. Las entradas validas e invlidas tambin forman particiones de equivalencia. Se identifican particiones usando las especificaciones del programa o documentacin del usuario y, a partir de la propia experiencia, se predice que clases de valores de entrada es probable que detecten errores. Cuando se estn probando problemas con secuencias, vectores o listas, existen varias recomendaciones que a menudo son tiles para disear casos de prueba: 1. Probar el software con secuencias que rene solo un valor. Los programadores piensan de forma natural que las secuencias estn formadas por varios valores y como consecuencia, el programa puede no funcionar correctamente cuando se te presenta una secuencia de un nico valor. 2. Utiliza varias secuencias de diferentes tamaos en distintas pruebas. Esto disminuye la probabilidad de que un programa con defectos produzca accidentalmente una salida correcta debido a alguna caracterstica ocasional en la entrada. 3. Generar pruebas para acceder al primer elemento, al elemento central y al ltimo elemento de la secuencia. Esta aproximacin pone de manifiesto problemas en los lmites de la particin 7.1.2 Pruebas estructurales Las pruebas estructurales se derivan a partir del conocimiento de la estructura e implementacin del software. Estas se denominan a veces pruebas de caja blanca para distinguirlas de las pruebas de caja negra.
- 45 -
Calidad de Software
La comprensin del algoritmo utilizado en un componente puede ayudar a identificar particiones y casos de prueba. 7.2 Enfoque prctico recomendado para el diseo de casos El enfoque prctico pretende ser una serie de recomendaciones para el mejor diseo de casos de pruebas considerando criterios bsicos y de distintas tcnicas 1. Si la especificacin contiene combinaciones de condiciones de entrada, comenzar formando grafos de causa-efecto (ayudan la comprensin de dichas combinaciones). 2. En todos los casos, usar anlisis de valores lmites para aadir casos de pruebas. 3. Identificar las clases vlidas y no vlidas de equivalencia para la entrada y la salida, y aadir los casos no incluidos anteriormente. 4. Utilizar la tcnica de conjetura de errores para aadir nuevos casos, referidos a valores especiales. 5. Ejecutar los casos generados hasta el momento y analizar la cobertura obtenida. 6. Examinar la lgica del programa para aadir los casos precisos (de caja blanca) para cumplir el criterio de cobertura elegido si los resultados de la ejecucin del punto anterior indican que no se ha satisfecho el criterio de cobertura elegido
- 46 -
Calidad de Software
A veces los desarrolladores se cuestionan por qu se debe examinar todos los caminos de un programa si es que la funcionalidad ha sido demostrada con las pruebas de requisitos: Los errores lgicos y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de que se ejecute un camino del programa Se suele creer que un camino lgico tiene pocas probabilidades de ejecutarse cuando, en realidad, se puede ejecutar regularmente. Los errores tipogrficos son aleatorios; pueden aparecer en cualquier parte del programa (sea muy usada o no).
La probabilidad y la importancia de un trozo de cdigo suele ser calculada de forma muy subjetiva. 7.3. Documentacin del diseo de pruebas Como se mencion la documentacin es una parte fundamental de las pruebas para poder tener una gua exacta de lo que se realiza y no desperdiciar horas de trabajo.
El primer paso se sita en la planificacin general del esfuerzo de prueba (plan de pruebas) para cada fase de la estrategia de prueba para el producto.
- 47 -
Calidad de Software
Se genera inicialmente la especificacin del diseo de la prueba (que surge de la ampliacin y el detalle del plan de pruebas). A partir de este diseo, se prueba definir con detalle cada uno de los casos mencionados escuetamente en el dselo de la prueba (se fijan los datos de pruebas exactos, los resultados esperados, etc.). Tras generar los casos de prueba detallados se debe especificar cmo proceder en detalle de la ejecucin de dichos casos (procedimiento de prueba). Toda la documentacin debe ser bsica para la ejecucin de la prueba pero son los procedimientos los que determinan como se desarrollara la ejecucin.
7.4 Plan de Pruebas: Sealar el enfoque, los recursos y el esquema de actividades, as como los elementos a probar, las caractersticas, las actividades, el personal responsable y los riesgos asociados. Estructura fijada en el estndar: Identificador nico del documento Introduccin y resumen de elementos y caractersticas a probar Elementos software a probar Caractersticas a probar Caractersticas que no se probarn Enfoque general de la prueba Criterios de paso/fallo para cada elemento Criterios de suspensin y requisitos de reanudacin Documentos a entregar Actividades de preparacin y ejecucin de pruebas Necesidades de entorno Responsabilidades en la organizacin y realizacin de las pruebas Necesidades de personal y formacin Esquema de tiempos Riesgos asumidos por el plan y planes de contingencias Aprobaciones y firmas con nombre y puesto desempeado
- 48 -
Calidad de Software
7.5 Especificacin del Diseo de Pruebas Especificar los refinamientos necesarios sobre el enfoque reflejado en el plan e identificar las caractersticas que se deben probar con este diseo de pruebas Identificador nico para la especificacin. Proporcionar tambin una referencia del plan asociado (si existe) Caractersticas a probar de los elementos software (y combinaciones de caractersticas) Detalles sobre el plan de pruebas del que surge este diseo, incluyendo las tcnicas de prueba especfica y los mtodos de anlisis de resultados Identificacin de cada prueba: o Identificador o Casos que se van a utilizar o Procedimientos que se van a seguir Criterios de paso/fallo de la prueba (criterios para determinar si una caracterstica o combinacin de caractersticas ha pasado con xito la prueba o no).
7.6 Especificacin de Caso de Pruebas Definir uno de los casos de prueba identificando por una especificacin del diseo de las pruebas Identificador nico de la especificacin Elementos software (por ejemplo, mdulos) que se van a probar: definir dichos elementos y las caractersticas que ejercitar este caso Especificaciones de cada entrada requerida para ejecutar el caso (incluyendo las relaciones entre las diversas entradas; por ejemplo, la sincronizacin de las mismas) Especificaciones de todas las salidas y las caractersticas requeridas (por ejemplo, el tiempo respuesta) para los elementos que se van a probar Necesidades de entorno (hardware, software y otras como, por ejemplo, el personal) Requisitos especiales de procedimiento (o restricciones especiales en los procedimientos para ejecutar este caso).
- 49 -
Calidad de Software
Dependencias entre casos (por ejemplo, listar los identificadores de los casos que se van a ejecutar antes de este caso de prueba)
7.7 Especificaciones del Procedimiento de Prueba Especificar los pasos para la ejecucin de un conjunto de casos de prueba o, ms generalmente, los pasos utilizados para analizar un elemento software con el propsito de evaluar un conjunto de caractersticas del mismo. Identificador nico de la especificacin y referencia a la correspondiente especificacin de diseo de prueba. Objetivo del procedimiento y lista de casos que se ejecutan con l. Requisitos especiales para la ejecucin (por ejemplo, entorno especial o personal especial). Pasos en el procedimiento. Adems de la manera de registrar los resultados y los incidentes de la ejecucin, se debe especificar: La secuencia necesaria de acciones para preparar la ejecucin. Acciones necesarias para empezar la ejecucin. Acciones necesarias durante la ejecucin. Cmo se realizarn las medidas (por ejemplo, el tiempo de respuesta) Acciones necesarias para suspender acontecimientos no previstos lo obliguen). la prueba (cuando los
Puntos para reinicio de la ejecucin y acciones necesarias para el reinicio en estos puntos. Acciones necesarias para detener ordenadamente la ejecucin. Acciones necesarias para restaurar el entorno y dejarlo en la situacin existente antes de las pruebas. Acciones necesarias para tratar los acontecimientos anmalos.
- 50 -
Calidad de Software
8. Ejecucin de pruebas de software

Es la identificacin y resolucin de problemas antes de ponerlos en produccin. Para asegurarse de que sus aplicaciones funcionen y se ejecuten segn los requisitos empresariales en produccin, necesita probarlos antes de la implementacin. Junto con pruebas manuales, para la mxima reutilizacin y eficacia, deben automatizarse determinados componentes. La ejecucin de pruebas le permite detectar y solucionar problemas de las aplicaciones antes de ponerlas en produccin con el objetivo de que pueda utilizarlas con seguridad. La ejecucin de pruebas evala la capa GUI de la aplicacin, as como los componentes fundamentales para una cobertura integral, junto con pruebas de rendimiento para asegurar la calidad adecuada en produccin.
8.1 El proceso de ejecucin Propiamente dicho De acuerdo con el estndar IEEE Std. 829-2008, consta de las siguientes fases: Se ejecutan las pruebas cuyos casos y procedimientos han sido ya diseados previamente. Se comprueba si ha habido algn fallo al ejecutar.
- 51 -
Calidad de Software
Si lo ha habido, se puede deber a un defecto del software, lo que nos lleva al proceso de depuracin o correccin del cdigo. Se puede deber tambin a un defecto en el propio diseo de las pruebas. En ambos casos, las nuevas pruebas o las corregidas se debern ejecutar. De no existir fallos, se pasar a la comprobacin de la terminacin de las pruebas.
8.2 El proceso de comprobacin Consta de las siguientes fases: Tras la ejecucin, se comprueba si se cumplen los criterios de complecin de pruebas descritos en el correspondiente plan de pruebas. En caso de terminar las pruebas, se pasa a la evaluacin de los productos probados sobre la base de los resultados obtenidos (terminacin normal). En caso de no terminar las pruebas se debe comprobar la presencia de condiciones anormales en la prueba. Si hubiesen existido condiciones anormales, se pasa de nuevo a la evaluacin; en caso contrario, se pasa a generar y ejecutar pruebas adicionales para satisfacer cualquiera de las dos terminaciones. Los criterios de complecin de pruebas hacen referencia a las reas (caractersticas, funciones, etc.) que deben cubrir las pruebas y el grado de cobertura para cada una de esas reas. Como ejemplos genricos de este tipo de criterios se pueden indicar los siguientes: Se debe cubrir cada caracterstica o requerimiento del software mediante un caso de prueba o una excepcin aprobada en el plan de pruebas. En programas codificados con lenguajes procedurales, se deben cubrir todas las instrucciones ejecutables mediante casos de prueba.
- 52 -
Calidad de Software
9.- HERRAMIENTAS PARA LA EJECUCION DE PRUEBAS

Este apartado va dirigido a conocer los beneficios que pueden aportar herramientas dedicadas a pruebas dentro de la organizacin. Tambin se vern los riesgos que suponen el uso de herramientas en las organizaciones. 9.1. Herramientas 9.1.1. E Tester Empirix e-Tester es una herramienta de prueba automatizada que forma parte de la suite de e-test de aplicaciones. Proporciona a los usuarios la capacidad de crear scripts automatizados de prueba de funcionamiento. Est diseado para ser utilizado para probar web, soluciones inalmbricas y aplicaciones multimedia. 9.1.2 Rational Functional Tester
Rational Functional Tester permite a los testers y a los desarrolladores de GUI automatizar los testings funcionales y la regresin de aplicaciones Java, .NET y basadas en Web.
Esta herramienta de testing automatizada es la mejor de su clase para los testings funcionales y la regresin de aplicaciones Java, Microsoft Visual Studio .NET y basadas en web. Ofrece a los testers avanzados una seleccin de idiomas de script y un editor de solidez, Java en Eclipse o Microsoft Visual Basic .NET en Visual Studio .NET, para la verificacin del montaje y la personalizacin. Proporciona a los testers con poca experiencia funciones automatizadas para actividades como, por ejemplo, la generacin de pruebas y el testing dirigido por datos. Incluye la tecnologa ScriptAssure y funciones de coincidencia de patrn para mejorar la capacidad de recuperacin del script de verificacin dado los frecuentes cambios que se producen en la interfaz del usuario de aplicaciones. Incorpora soporte para el control de la versin para permitir un desarrollo paralelo de los scripts de verificacin y el uso simultneo por parte de equipos distribuidos por el mundo.
- 53 -
Calidad de Software
Permite la realizacin de pruebas de aplicaciones creadas con VS.NET Winforms, J2SE/J2EE, HTML/DHTML, XML, JavaScript y applets de Java e incluye soporte exclusivo para la biblioteca SWT de Java asociada con el shell de Eclipse. Soporta el testing de aplicaciones 3270 (zSeries) y 5250 (iSeries) que utilizan las aplicaciones basadas en Rational Functional Tester Extension for Terminal. Caractersticas y Beneficios:
Toda organizacin que dependa de su propio desarrollo de aplicaciones para dar servicio a las necesidades de sus clientes o usuarios internos reconocen que la calidad de las aplicaciones son un prerequisito para el xito, no solo una opcin. Un ingrediente crucial para el mismo es tener un proceso de testing eficiente y disciplinado para verificar que las aplicaciones hayan alcanzado el nivel de aptitud que cumpla o exceda las expectativas del proyecto. Los cronogramas imprecisos, los cambios frecuentes en las interfaces de usuario de la aplicacin y las regresiones recurrentes de las caractersticas introducen variables que las prcticas de testing ad-hoc son incapaces de manejar. Rational Functional Tester fue creado para cubrir todas estas necesidades.
Rational Functional Tester es una herramienta avanzada de testing funcional y de regresin automatizado creada para los testeadores y los desarrolladores de GUI que necesitan de un control superior para probar sus aplicaciones Java, Microsoft Visual Studio .NET y Web.
9.1.3. Rational Manual Tester Es una herramienta de ejecucin y autorizacin de pruebas manuales para testers y analistas de negocio.

Introduce tcnicas nuevas de desarrollo para mejorar la velocidad, el alcance y la fiabilidad de los esfuerzos de pruebas manuales. Promueve la reutilizacin de los pasos de pruebas para reducir la repercusin de los cambios de software realizados en las actividades de mantenimiento de pruebas. Proporciona un editor de textos avanzado que soporta adjuntos e imgenes para mejorar la legibilidad de las pruebas.
- 54 -
Calidad de Software

Facilita la entrada de datos y verificacin durante la ejecucin de pruebas para reducir los posibles errores humanos. Importa pruebas manuales existentes previamente basadas en Microsoft Word y Excel; exporta los resultados de las pruebas en archivos basados en CSV para el anlisis en las herramientas preferidas de otros proveedores. Incorpora los requisitos de equipos exclusivos a travs de numerosas opciones de personalizacin; permite compartir contenido entre ubicaciones de pruebas distribuidas. Gratuito con la adquisicin del Rational Functional Tester para ayudar a los equipos a realizar tanto las pruebas manuales como las automatizadas.
Caractersticas y Beneficios: Muchas organizaciones les piden a analistas de negocio y testeadores que validen manualmente la operacin del sistema, registrando sus observaciones a medida que van interactuando con la aplicacin. Este proceso de testing manual puede consumir mucho tiempo y ser propenso a errores, particularmente si la aplicacin experimenta cambios frecuentes. Rational Manual Tester se cre para resolver este problema. Es una herramienta para creacin y ejecucin de tests manuales que promueve el re-uso de los pasos de test para reducir el impacto del cambio en el software sobre los testeadores y analistas de negocio. Cmo lo hace? Rational Manual Tester agrega organizacin y control a todas las actividades que estn involucradas en el esfuerzo del testing manual, incluyendo:

Creacin y modificacin del test Organizacin y consolidacin para miembros del equipo distribuido de test Ejecucin y coleccin de resultados del test Reporte de resultados del test
9.2. Beneficios del uso de herramientas Realizar el mismo trabajo de manera repetitiva y manualmente puede ser una tarea tediosa. Las personas tienden a aburrirse y por esa razn aumenta la probabilidad de que cometan errores al realizar la misma tarea una y otra vez. Este es el caso de las pruebas de regresin, por ejemplo, donde se introducen los mismos datos de
Calidad de Software
prueba una y otra vez, comparando los resultados contra los estndares de codificacin o creando bases de datos de pruebas especficos. Mediante la utilizacin de herramientas se puede conseguir reproducir cierto trabajo previamente realizado, obteniendo resultados consistentes. Esta caracterstica es especialmente til para confirmar que un defecto se ha arreglado, o para introducir datos de entrada a pruebas, por ejemplo. En ocasiones, si una persona calcula un valor a partir de informes de incidencias, por ejemplo, puede que omita algo sin darse cuenta o que interprete informacin de forma incorrecta (subjetividad). El uso de una herramienta consigue que esa predisposicin a interpretar de forma subjetiva los datos se elimine y de esta forma la evaluacin sea realizada de forma ms consistente. Por otro lado, el tener muchos datos no implica que la informacin sea comunicada de la manera correcta ni entendida por las personas interesadas. La informacin que se presenta de forma visual es mucho ms sencilla de retener e interpretar para la mente humana por lo que el uso de grficos es una forma mucho mejor de comunicar informacin que una larga lista de nmeros. Existen herramientas de propsito especial que ofrecen estas funcionalidades de forma directa a partir de la informacin que procesan. Algunos ejemplos del uso de grficos y estadsticas a la hora de mostrar la informacin se pueden encontrar en herramientas que permiten mostrar el progreso de las pruebas, las tasas de incidencias y rendimiento. En definitiva, los principales beneficios que aporta el uso de herramientas como medio para llevar a cabo el proceso de pruebas son: Reducir el trabajo repetitivo Mejorar la consistencia Facilitar las evaluaciones objetivas Facilitar el acceso a informacin relacionada con pruebas
Adems de los beneficios generales que se han descrito, cada tipo de herramienta ofrece unos beneficios especficos relacionados con el aspecto de las pruebas sobre el que la herramienta trabaja de forma particular. 9.3. Riesgos del uso de herramientas Introducir algo nuevo en una organizacin, en este caso una herramienta, no suele ser tarea sencilla, ya que siempre habr problemas tcnicos a los que sobreponerse. El uso por primera vez de una herramienta no siempre se har de la mejor forma y consiguiendo los mejores resultados posibles. Es necesario invertir tiempo para
Calidad de Software
desarrollar mtodos a seguir por la organizacin y as conseguir el mximo provecho posible de la herramienta. Otro factor importante que hay que considerar a la hora de hacer uso de herramientas durante el proceso de pruebas es la habilidad y conocimiento necesario para realizar buenas pruebas y para usar las herramientas de forma correcta. Aunque pueden obtenerse grandes beneficios del uso de herramientas durante el proceso de pruebas, es necesario tener en cuenta los riesgos que puede acarrear el uso de herramientas, independientemente de su uso especfico. Uno de los ms relevantes es tener expectativas poco realistas de la herramienta. Por ello, es importante tener claro qu puede hacer la herramienta, y en funcin de esto establecer objetivos realistas. Otros riesgos relacionados son: Subestimacin del tiempo, coste y esfuerzo necesario para la introduccin inicial de la herramienta en la organizacin Subestimacin del tiempo y esfuerzo necesario para conseguir beneficios significantes y continuos de la herramienta Subestimacin del esfuerzo requerido para mantener los activos de pruebas generados por la herramienta Sobre-confianza en la herramienta
9.4. Factores a tener en cuenta para introducir una herramienta en una organizacin Para introducir una herramienta en una organizacin habra que comenzar trabajando con la organizacin, ms que con la herramienta. Las organizaciones necesitan estar preparadas para los cambios que supondr la nueva herramienta. Si, por ejemplo, las prcticas que sigue una organizacin al ejecutar las pruebas no son buenas y la organizacin no es madura, por lo general sera ms eficiente mejorar dichas prcticas que buscar herramientas que den soporte a este tipo de prcticas. En ocasiones, se pueden mejorar los propios procesos de la organizacin de manera paralela a la insercin de una herramienta que de soporte a dichos procesos. Es importante tener claro que la herramienta no debera dirigir sino proporcionar soporte a lo que la organizacin haya definido. A la hora de introducir una herramienta en una organizacin es importante: Evaluar la madurez de la organizacin
- 57 -
Calidad de Software
Identificar las reas de la organizacin donde las herramientas puedan ayudar y dar soporte a los procesos de prueba Evaluar herramientas contra requisitos claros y criterios objetivos Planificar la implementacin interna de la herramienta Llevar a cabo una prueba de concepto para comprobar si el producto funciona como se desea y cumple los requisitos y objetivos definidos. Para ello se puede utilizar un proyecto piloto.
Los objetivos de un proyecto piloto para una nueva herramienta son aprender ms sobre la herramienta, decidir maneras estndar de usar la herramienta para usuarios potenciales, ver cmo la herramienta se adapta a los procesos o documentacin existentes y cmo estos procesos deberan cambiar para trabajar bien con la herramienta y, en definitiva, evaluar el proyecto piloto frente a los objetivos establecidos.
- 58 -
Calidad de Software
10.- RECOMENDACIONES PARA LA EJECUCIN DE PRUEBAS
El programador debe evitar probar sus propios programas, ya que desea (consciente o inconscientemente) demostrar que funcionan sin problemas. Cada caso de prueba debe definir el resultado de salida esperado que se comparar con el realmente obtenido. La experiencia parece indicar que donde hay un defecto hay otros, es decir, la probabilidad de descubrir nuevos defectos en una parte del software es proporcional al nmero de defectos ya descubierto. No deben hacerse planes de prueba suponiendo que, prcticamente, no hay defectos en los programas y, por lo tanto, dedicando pocos recursos a las pruebas. Se debe inspeccionar a conciencia el resultado de cada prueba, as, poder descubrir posibles sntomas de defectos
- 59 -
Calidad de Software
11. DOCUMENTACION PARA LA EJECUCIN DE PRUEBAS

Durante la ejecucin de las pruebas es fundamental conocer el estado del proceso de prueba, saber qu pruebas se han ejecutado y cules quedan pendientes, qu defectos se han encontrado, etc. Para ello, se crean los registros de pruebas, Informes de Incidentes e Informe resumen de pruebas.
11.1 Registro de Pruebas (Histrico de Pruebas o Test Log) Un objetivo fundamental del proceso de prueba es proporcionar informacin acerca del sistema que se est probando. El registro de pruebas documenta los aspectos relativos a la ejecucin de las pruebas: qu prueba se han ejecutado, quin y cundo los ha ejecutado, en qu orden, en qu entorno, si la prueba ha pasado o ha fallado. En este documento es importante tambin, asociar la informacin de ejecucin de cada prueba con versiones especficas del software en prueba para garantizar la trazabilidad. La informacin recogida en el registro de pruebas permite conocer el progreso de la fase de ejecucin de pruebas y tomar decisiones acerca de si el software est listo para pasar a la siguiente fase.
- 60 -
Calidad de Software
11.1.1 Estructura fijada en el estndar (IEEE 829) A. Identificador B. Descripcin de la prueba: elementos probados y entorno de la prueba C. Anotacin de datos sobre cada hecho ocurrido (incluido el comienzo y el final de la prueba) Fecha y hora Identificador de informe de incidentes D. Otras Informaciones 11.2 Informe de Incidentes Hay que resaltar la referencia al trmino incidente; un incidente no tiene porqu deberse necesariamente a un defecto en el sistema. Un incidente representa una discrepancia entre los resultados esperados y los resultados obtenidos. Esta discrepancia puede deberse a varios motivos, como un defecto, un error en la especificacin de los casos de prueba, una mala interpretacin de los requisitos, etc. El informe de incidentes debe contener toda la informacin necesaria para la identificacin y resolucin del incidente: entradas utilizadas, resultados esperados, resultados obtenidos, paso del procedimiento en el que se ha producido el incidente, configuracin del entorno, valoracin del impacto, etc. 11.2.1 Estructura fijada en el estndar (IEEE 829) A. Identificador B. Resumen del incidente C. Descripcin de datos objetivos (fecha/hora, entradas, resultados esperados, etc.) D. Impacto que tendr sobre las pruebas 11.3 Informe de Resumen de Pruebas El informe final de pruebas se crea en hitos determinados del proyecto o al finalizar un nivel de pruebas determinado. Permite comunicar a todos los stakeholders los resultados obtenidos para as decidir si el software est listo para pasar a la siguiente fase. Este informe proporciona informacin sobre las pruebas realizadas y el tiempo consumido, as como valoraciones acerca de la calidad del proceso de prueba realizado, del nivel de calidad alcanzado en el producto. Este informe final puede servir como base para planificar mejoras futuras en el proceso de prueba.
- 61 -
Calidad de Software
11.3.1 Estructura fijada en el estndar (IEEE 829) A. Identificador B. Resumen de la evaluacin de los elementos probados C. Variaciones del software respecto a su especificacin de diseo, as como las variaciones en las pruebas D. Valoracin de la extensin de la prueba (cobertura lgica, funcional, de requisitos, etc.) E. Resumen de los resultados obtenidos en las pruebas F. Evaluacin de cada elemento software sometido a prueba (evaluacin general del software incluyendo las limitaciones del mismo) G. Firmas y aprobaciones de quienes deban supervisar el informe
- 62 -
Calidad de Software
12. DEPURACION (DEBUGGIN)

12.1 Definicin La depuracin es la correccin de errores que slo afectan a la programacin, porque no provienen de errores previos en el anlisis o en el diseo. A veces la depuracin se hace luego de la entrega del sistema al cliente y es parte del mantenimiento. En realidad, en las revisiones de cdigo y las pruebas unitarias, encontrar un error es considerablemente ms sencillo, ya que se hace con el cdigo a mano. Aun cuando se hubiera optado por una prueba unitaria de caja negra, es sencillo recorrer el mdulo que revela un comportamiento errneo por dentro para determinar el lugar exacto del error. Existen incluso herramientas de depuracin de los propios ambientes de desarrollo que facilitan esta tarea, que incluso proveen recorrido paso a paso y examen de valores de datos. De todas maneras, es importante analizar correctamente si el error est donde parece estar o proviene de una falla oculta ms atrs en el cdigo. Para encontrar estos casos ms complejos son tiles las herramientas de recorrida hacia atrs, que permiten partir del lugar donde se genera el error y recorrer paso a paso el programa en sentido inverso. Las pruebas de integracin, de sistema y de aceptacin tambin pueden llevar a que sea necesaria una depuracin, aunque aqu es ms difcil encontrar el lugar exacto del error. Por eso a menudo se utilizan bitcoras, que nos permiten evaluar las condiciones que se fueron dando antes de un error mediante el anlisis de un historial de uso del sistema que queda registrado en medios de almacenamiento permanente.
- 63 -
Calidad de Software
12.2 Pasos para La Depuracin Reproducir el error Diagnosticar la causa. Corregirla. Verificar la correccin.
Si el error no se repite al intentar reproducirlo es muy difcil hacer el diagnstico. Como en casi todas las ciencias, se buscan causas y efectos, condiciones necesarias y suficientes para que se produzca el error. Luego hay que buscar el sector del cdigo donde se produce el error, lo que nos lleva a las consideraciones hechas recientemente. La correccin del error entraa mucho riesgo, porque a menudo se introducen nuevos errores. Y nunca hay que olvidarse de realizar una nueva verificacin despus de la correccin.
- 64 -
Recomendaciones y
Conclusiones
Calidad de Software
RECOMENDACIONES
1. No deben hacerse planes de prueba suponiendo que, prcticamente, no hay defectos en los programas y, por lo tanto, dedicando pocos recursos a las pruebas. 2. El programador debe evitar probar sus propios programas, ya que desea (consciente o inconscientemente) demostrar que funcionan sin problemas. 3. Se debe inspeccionar a conciencia el resultado de cada prueba, as, poder descubrir posibles sntomas de defectos. 4. Cada caso de prueba debe definir el resultado de salida esperado. 5. Al generar casos de prueba, se deben incluir tanto datos de entrada vlidos y esperados como no vlidos e inesperados 6. La experiencia parece indicar que donde hay un defecto hay otros, es decir, la probabilidad de descubrir nuevos defectos en una parte del software es proporcional al nmero de defectos ya descubierto. 7. Las pruebas son una tarea tanto o ms creativa que el desarrollo de software. Siempre se han considerado las pruebas como una tarea destructiva y rutinaria.
66
Calidad de Software
CONCLUSIONES
En conclusin , este trabajo demuestra que la verificacin y validacin son procesos importantes para el desarrollo de software con calidad, y que una adecuada verificacin del producto durante etapas de vidas del software puede detectar errores en el producto entregado, y una adecuada validacin comprueba que el producto de software vaya de acorde a los estndares del mercado. El objetivo principal de la Verificacin y Validacin es la seguridad de que el sistema est hecho para un propsito especfico y cumpliendo con los requisitos que el cliente necesita. Dentro de la verificacin y validacin existen dos conceptos complementarios tales como: Inspecciones de software y Pruebas de software Las inspecciones de software, descubren errores que pueden estar ocultos a la vista, una inspeccin tambin puede considerarse como atributos de calidad ms amplios de un programa tales como el grado de cumplimiento con los estndares de portabilidad y mantenibilidad. Las Pruebas de software, son bsicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrn ser implementadas en cualquier momento de dicho proceso de desarrollo. Tambin deducimos que la planificacin de las pruebas est relacionada con el establecimiento de estndares para el proceso de pruebas, no solo con la descripcin de los productos de las pruebas. Los planes de pruebas adems de ayudar con los gestores a asignar recursos y estimar el calendario de las pruebas, son de utilidad para los ingenieros del software implicados en el diseo y la realizacin de las pruebas de sistema. Estos ayudan al personal tcnico a obtener una panormica general de las pruebas del sistema y ubicas su propio trabajo en este contexto. En el caso del ciclo de vida de pruebas de software puede tener distintas interpretaciones pero siempre es importante tener los 4 puntos mencionados: Planear, Hacer, Verificar y Actuar; es de suma importancia identificar que diseo de casos de prueba debemos usar en una determinada rea del software y depende del criterio de los encargados del testeo, aunque las recomendaciones es que estos sean distintos de los que codificaron se mantiene. Con respecto a las herramientas de ejecucin de pruebas podemos ver que aunque se han desarrollado miles de herramientas de soporte, todas han limitado su xito a entornos muy concretos, slo sirviendo para el producto para el que se desarrollaron. Y por ltimo, durante la ejecucin de las pruebas es fundamental conocer el estado del proceso de prueba, saber qu pruebas se han ejecutado y cules quedan pendientes, qu defectos se han encontrado, etc. Para ello, se crean los registros de pruebas, Informes de Incidentes e Informe resumen de pruebas.
67
Referencias
Bibliogrficas
BIBLIOGRAFIA
Anlisis de los procesos de verificacin y validacin en las organizaciones software. Universidad Carlos III de Madrid Pressman, R. (2005): Ingeniera del Software: Un Enfoque Prctico. 6 Edicin. McGraw-Hill. (Captulos 13 y 14) SWEBOK - Guide to the Software Engineering Body of nowledge, 2004. (Captulos 4 y 5) - http://www.computer.org/portal/web/swebok http://materias.fi.uba.ar/7507/content/20101/lecturas/documentacion_pruebas.p df http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r56673.PDF http://200.69.103.48/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Prueba s/HTML%20-%20Pruebas%20de%20software/node20.html http://200.69.103.48/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Prueba s/HTML%20-%20Pruebas%20de%20software/node21.html http://200.69.103.48/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Prueba s/HTML%20-%20Pruebas%20de%20software/node22.html http://200.69.103.48/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Prueba s/HTML%20-%20Pruebas%20de%20software/node23.html 2003-2009, Rational Performance Tester Tutorial. Manual de Rational Performance Tester. Editado por Ben Smith andLaurie Williams. 26 de Agosto de 2007. http://agile.csc.ncsu.edu/SEMaterials/tutorials/rpt/index.html#section8_0 (ltimo acceso: Junio de 2012). Acua, Cesar Javier. Pruebas de Software. Universidad Rey Juan Carlos, s.f. ARQUISOFT, Grupo. Editado por Emilio Barrios. Johanna Rojas. 2007. http://200.69.103.48/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Prueba s/HTML%20-%20Pruebas%20de%20software/node19.html. Beizer B. Software Testing Techniques. Segunda Edicion. 1990. Bohem. Graphical Development Process Asistant. USA, 1979.
Calidad de Software
Cibertec. Pruebas de Software. Cibertec, 2011. Compatia. Estudios realizados por Compatia. Investigacion, USA, 2004. Fagan. Design and Code inspections to reduce errors in program development IBM Systems Journal, 1976 -1986: 182211. Graham Giib 1993. Grupo Standish. Resultados del informe CHAOS. Investigacion 1995. Guofeng, Yongkui. Ciclo de vida de las pruebas. 2009. Jose Luis Aristegui O. Los casos de prueba en la prueba de software. Revista Digital Lampsakos, s.f.: 27-34. Moranda, Jelinski -. Estimation and Prediction for a Simple Software Reliability Model. USA, 1972. Oficina de Cuentas del Gobierno Norteamericano, GAO. Resultados del Informe. Investigacion, USA, 1979. Parnas. The use of mathematics in software quality assurance. IEEE Computer 23, 1990: 17-22. Plattini Velthuis, Mario, Jose A. Calvo Manzano, Joaquin Cervera Bravo, y Luis Fernandez Sanz. Analisis y Diseo de Aplicaciones Informaticas de Gestin. RaMa, s.f. RAE. Diccionario de la Real Academia Espaola. 23. Madrid: RAE, 2010. Sommerville, Ian. Ingenieria de Software. Septima Edicion. Traducido por Maria Isabel Alfonso Galipienso. s.f. Whitaker. 2002.
70
Calidad de Software
71

GRUPO 6 - Procesos de Verificacion y Validacion en El Desarrollo de Software

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

GRUPO 6 - Procesos de Verificacion y Validacion en El Desarrollo de Software

Cargado por

Copyright:

Formatos disponibles

Procesos de Validacin y Verificacin en el

AO DE LA INTEGRACION NACIONAL Y EL RECONOCIMIENTO DE NUESTRA DIVERSIDAD

SAN LUIS GONZAGA DE ICA

Procesos de Validacin y Verificacin en el Desarrollo de Software

ICA PER 2012

Ing. Alonso Morales Loayza

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

1. PROCESOS DE VERIFICACIN Y VALIDACIN DE SOFTWARE

Tcnicas de verificacin y validacin Existen 2 Tcnicas de Verificacin y Validacin

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

EQUIPO DE INSCRIPCIN DE PROGRAMAS

Inspector Lector Secretario Presidente o Moderador Moderador Jefe

TABLA 1 2.3. Actividades en el proceso de inspeccin

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

Ing. Alonso Morales Loayza

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

3.- LISTAS DE FALLOS O ERRORES

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

4.- PRUEBAS DE SOFTWARE

Ing. Alonso Morales Loayza

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

Ing. Alonso Morales Loayza

5.- TCNICAS DE PRUEBAS DE SOFTWARE

Figura 1. Clasificacin de Tcnicas Dinmicas

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

Ing. Alonso Morales Loayza

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

Analisis de flujo de control

Analisis de uso de los datos

Analisis de flujo de informacion

Figura 2. Clasificacin de tcnicas de control estticas

Ing. Alonso Morales Loayza

Ing. Alonso Morales Loayza

Ing. Alonso Morales Loayza

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

6.- CICLO DE PRUEBA DE SOFTWARE

Procesos de Verificacin y Validacin en el Desarrollo de Software

Ing. Alonso Morales Loayza

Ing. Alonso Morales Loayza