Fundamentos de La Prueba de Software

FUNDAMENTOS DE LA PRUEBA DE SOFTWARE
Universidad Nacional San Luis Gonzaga Facultad de Ingeniera de Sistemas Pruebas de Software. Alonso Morales Loayza
PRUEBA DE SOFTWARE
Pgina 1
Fundamento de la Prueba de Software

INTRODUCCIN ................................................................................................................................... 5 1. CALIDAD Y EL SOFTWARE ........................................................................................................... 6 1.1. CONCEPTOS BSICOS DE CALIDAD...................................................................................... 6 DESDE UNA PERSPECTIVA DE VALOR. ......................................................................... 6 DEFINICIONES FORMALES. .......................................................................................... 6 ORIGEN. ....................................................................................................................... 8 CONCEPTOS. ................................................................................................................ 9 1.1.1. 1.1.2. 1.2. 1.2.1. 1.2.2. 1.3. 2. 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 3. 3.1. 3.2. 4. 4.1. 4.2. 5. 5.1. 5.2.
CALIDAD DE SOFTWARE. ..................................................................................................... 8
ASEGURAMIENTO DE SOFTWARE Y TCNICAS ASOCIADAS. ............................................. 10 MODELO DE MCCALL. ....................................................................................................... 12 MODELO DE BOEHM. ........................................................................................................ 13 CMM (CAPABILITY MATURITY MODEL). ............................................................................ 14 ISO (INTERNATIONAL STANDARD ORGANIZATION). ......................................................... 15 PSP (PERSONAL SOFTWARE PROCESS) /TSP (TEAM SOFTWARE PROCESS). ..................... 15 SPICE (SOFTWARE PROCESS IMPROVEMENT AND CAPABILITY DETERMINATION). ......... 16 PEMM (PERFORMANCE ENGINEERING MATURITY MODEL)............................................. 17 TICKIT................................................................................................................................. 18 DEFINICIN DE VERIFICACIN Y VALIDACIN. ................................................................. 19 VALIDACIN Y VERIFICACIN EN EL CICLO DE VIDA ......................................................... 21 OBJETIVOS. ........................................................................................................................ 21 RESTRICCIONES. ................................................................................................................ 22 ESTRATEGIAS DE PRUEBAS DE SOFTWARE ....................................................................... 24 PLAN DE PRUEBAS ............................................................................................................. 24 IDENTIFICADOR DEL PLAN. ........................................................................................ 24 ALCANCE .................................................................................................................... 24 TEMS A PROBAR ....................................................................................................... 24 ESTRATEGIA ............................................................................................................... 24 CATEGORIZACIN DE LA CONFIGURACIN............................................................... 25
MODELOS DE CALIDAD DE SOFTWARE .................................................................................... 12
DEFINICIN DE VERIFICACIN Y VALIDACIN.......................................................................... 19
OBJETIVOS Y RESTRICCIONES ................................................................................................... 21
PLANIFICACIN ......................................................................................................................... 23
5.2.1. 5.2.2. 5.2.3. 5.2.4. 5.2.5.
PRUEBA DE SOFTWARE
Pgina 2
5.2.6. 5.2.7. 5.2.8. 5.2.9. 5.2.10. 5.2.11. 6. 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. 7. 7.1. 7.2. 7.3.
TANGIBLES ................................................................................................................. 25 PROCEDIMIENTOS ESPECIALES ................................................................................. 25 RECURSOS.................................................................................................................. 25 CALENDARIO.............................................................................................................. 26 MANEJO DE RIESGOS............................................................................................. 26 RESPONSABLES ...................................................................................................... 26
METTRICAS Y MEDICIONES. ..................................................................................................... 26 DEFINICION........................................................................................................................ 26 QU SON LAS MTRICAS DE SOFTWARE? ....................................................................... 26 PROCESO DE MEDICION: ................................................................................................... 27 ACTIVIDADES DE LAS METRICAS DE SOFTWARE. .............................................................. 27 CLASIFICACIN DE MTRICAS ........................................................................................... 28 MTRICAS DEL SOFTWARE ................................................................................................ 28 DIFERENTES ENFOQUES DE MTRICAS ............................................................................. 29 EL PROCESO V & V ............................................................................................................. 30 METAS DE LA V&V ............................................................................................................. 31 CONFIANZA DE LA V&V ..................................................................................................... 31 FUNCIN DEL SOFTWARE. ........................................................................................ 31 EXPECTATIVAS DEL USUARIO. ................................................................................... 31 ENTORNO DE MARKETING. ....................................................................................... 31
V4V EN EL PROCESO DE DESARROLLO DE SOFTWARE ............................................................ 30
7.3.1. 7.3.2. 7.3.3. 7.4. 7.5. 7.6. 7.7.
VERIFICACIN DINMICA Y ESTTICA............................................................................... 31 PLANIFICACIN DE V &V ................................................................................................... 32 EL MODELO-V DE DESARROLLO ........................................................................................ 32 FASE DE LA VERIFICACIN ................................................................................................. 33 ANLISIS DE REQUISITOS .......................................................................................... 33 DISEO DEL SISTEMA ................................................................................................ 33 DISEO DE LA ARQUITECTURA.................................................................................. 34 DISEO DEL MDULO ............................................................................................... 34 PRUEBA DE LA UNIDAD ............................................................................................. 34 PRUEBA DE LA INTEGRACIN .................................................................................... 34 PRUEBA DEL SISTEMA ............................................................................................... 35 PRUEBA DE ACEPTACIN DE USUARIO ..................................................................... 35
7.7.1. 7.7.2. 7.7.3. 7.7.4. 7.8. 7.8.1. 7.8.2. 7.8.3. 7.8.4.
FASES DE LA VALIDACIN.................................................................................................. 34
PRUEBA DE SOFTWARE
Pgina 3
CONCLUSIONES ................................................................................................................................. 36 REFERENCIAS ..................................................................................................................................... 38
PRUEBA DE SOFTWARE
Pgina 4
INTRODUCCIN
El software es un producto abstracto de la mente humana. A travs de los aos, nos hemos dado cuenta de que no es posible crear sistemas grandes y complejos sin seguir un proceso definido que organice nuestro trabajo: la ingeniera de software. De igual forma, la experiencia nos ha mostrado que para entregar sistemas correctos y que satisfagan las necesidades de nuestros clientes es necesario probar nuestro software. Las empresas ms grandes y experimentadas en desarrollo de software, tales como IBM, Microsoft y otras, estn conscientes de esto y dedican cada vez un mayor nmero de recursos a las reas de aseguramiento de la calidad para sus proyectos de software, muchas veces equiparando o incluso superando los recursos destinados al desarrollo. El diseo, implementacin y la ejecucin de pruebas de software no son tareas triviales, puesto que exigen la aplicacin de estrategias y tcnicas formales que permitan desarrollar pruebas adecuadas para medir efectivamente la calidad del producto. Los ingenieros de pruebas de software cuentan con habilidades tcnicas y desarrollan en mayor medida la creatividad y la atencin al detalle, adems de tener la perspectiva del usuario final.
PRUEBA DE SOFTWARE
Pgina 5
1. CALIDAD Y EL SOFTWARE
Con el paso de los aos se han ido inventando nuevas formas de mejorar los sistemas. Estas mejoras son tomadas en cuenta dada la necesidad de obtener productos (software) de mejor calidad.
1.1. CONCEPTOS BSICOS DE CALIDAD.

1.1.1. DESDE UNA PERSPECTIVA DE VALOR.
La calidad significa aportar valor al cliente, esto es, ofrecer unas condiciones de uso del producto o servicio superiores a las que el cliente espera recibir y a un precio accesible. Tambin, la calidad se refiere a minimizar las prdidas que un producto pueda causar a la sociedad humana mostrando cierto inters por parte de la empresa a mantener la satisfaccin del cliente.
1.1.2. DEFINICIONES FORMALES.

ISO 9000: Calidad: grado en el que un conjunto de caractersticas inherentes cumple con los requisitos. ISO 8042:1994: Conjunto de propiedades y de caractersticas de un producto o servicio que le confieren capacidad para satisfacer necesidades expresadas o implcitas.
PRUEBA DE SOFTWARE
Pgina 6
Luis Andres Arnauda Sequera Define la norma ISO 9000 Conjunto de normas y directrices de calidad que se deben llevar a cabo en un proceso. Real Academia de la Lengua Espaola: Propiedad o conjunto de propiedades inherentes a una cosa que permiten apreciarla como igual, mejor o peor que las restantes de su especie. Philip Crosby: Calidad es cumplimiento de requisitos. Joseph Juran: Calidad es adecuacin al uso del cliente. Armand V. Feigenbaum: Satisfaccin de las expectativas del cliente. Genichi Taguchi: Calidad es la prdida (monetaria) que el producto o servicio ocasiona a la sociedad desde que es expedido. William Edwards Deming: Calidad es satisfaccin del cliente. Walter A. Shewhart: La calidad como resultado de la interaccin de dos dimensiones: dimensin subjetiva (lo que el cliente quiere) y dimensin objetiva (lo que se ofrece).
PRUEBA DE SOFTWARE
Pgina 7
1.2. CALIDAD DE SOFTWARE.

1.2.1. ORIGEN.
El proceso de desarrollo de software a lo largo de los aos ha adquirido un grado de profesionalismo caracterstico de la ingeniera. Gran parte de este profesionalismo se debe a la madurez adquirida por la Ingeniera de Software y la creciente complejidad de los sistemas de software. Consecuentemente con el crecimiento en la complejidad del software, se manifestaron entornos y clientes cada vez ms exigentes en materia de calidad, cumplimiento de objetivos funcionales y econmicos. Esta situacin demand la necesidad de contar con procesos seguros para el desarrollo del software, y los organismos e instituciones acadmicas trabajaron en la definicin de modelos conceptuales que cumplieran con la demanda de software de calidad. En general, concentraron as sus esfuerzos en definir modelos centrados en la calidad de procesos de ingeniera de software e indujeron a adoptarlos como estndares que permitieran enmarcar un proceso de desarrollo de software en un determinado nivel de "madurez", e incrementar a travs de ellos la calidad del mismo y disminuir los riesgos que afecten al resultado final. Un concepto importante a tener en cuenta es la diferencia entre la calidad y validez de un producto de software entregado al cliente, versus la calidad del proceso de desarrollo de software que dio origen a dicho producto. El primero de los conceptos responde al grado de cumplimiento de la solucin entregada de acuerdo a los requerimientos y expectativas que se tiene en cuanto a rendimiento, funcionalidad, usabilidad, etc. Mientras que el segundo concepto permite certificar para as garantizar la calidad del modelo empleado como directriz del proceso de desarrollo de software, siendo ste un conjunto de actividades, tareas, mtodos y procedimientos que indican las pautas a conservarse y respetarse a efectos de generar un producto final de calidad. El aseguramiento de la Calidad del Software (SQA, Software Quality Assurance) es una actividad de proteccin que se aplica durante todo el ciclo de vida del software. Para el aseguramiento de la Calidad del Software, ADA Software Factory desarroll un Modelo Integral de Calidad de Software, que se basa en estndares de tecnologa informtica y administracin de proyectos ampliamente reconocidos. Este modelo de calidad pretende mejorar la calidad del software a travs de la optimizacin de las propiedades de los productos resultantes, y de los procesos utilizados en su desarrollo. Para conseguirlo, pone nfasis en conceptos como la gestin de calidad
PRUEBA DE SOFTWARE
Pgina 8
de productos y procesos, la implementacin de procesos repetibles, la recopilacin de datos estadsticos sobre los elementos integrantes de un proyecto, y el trabajo a nivel de proceso. La idea clave es "las herramientas y las plataformas cambian de forma continua. Pero siempre se puede medir la calidad de un producto de software y siempre se puede usar el mismo proceso si ste est bien definido y se sabe utilizar de forma adecuada".
1.2.2. CONCEPTOS.
La calidad del software es aquel proceso en donde se verifica que el software o aplicacin cumpla con los requerimientos o necesidades del cliente, integrando la velocidad de respuesta de la aplicacin, el sistema de seguridad y confiabilidad. Tambin se puede definir como la coordinacin, integridad y la aplicacin de los estndares que tiene que ver con la correcta funcionabilidad y desarrollo de una aplicacin. Tambin se debe tener en cuenta que en el mantenimiento de hardware es muy diferente al de software, porque el hardware se puede reemplazar la pieza, mientras el software requiere de ingeniera, el software no se deteriora con el tiempo pues su curva de fallos es muy diferente a la de hardware. Es la concordancia con los requerimientos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se esperan de todo software desarrollado profesionalmente.
PRUEBA DE SOFTWARE
Pgina 9
Existen 3 puntos importantes de la definicin de calidad de software: Los requerimientos del software son los fundamentos desde los que se mide la calidad. Los estndares especficos definen un conjunto de criterios de desarrollo que guan la forma de aplicacin de la ingeniera de software. Existen requerimientos implcitos que no se mencionan.
Es el grado con el que un sistema, componente o proceso cumple con los requerimientos y las necesidades o expectativas del cliente o usuario. (IEEE 610/1990)
Concordancia del software producido con los requerimientos explcitamente establecidos, con los estndares de desarrollo prefijados y con los requerimientos implcitos no establecidos formalmente que desea el usuario. (Pressman, 2006).
1.3. ASEGURAMIENTO DE SOFTWARE Y TCNICAS ASOCIADAS.

El aseguramiento de calidad del software es el conjunto de actividades planificadas y sistemticas necesarias para aportar la confianza adecuada en que el producto (software) satisfacer los requisitos dados de calidad. El Aseguramiento pretende dar confianza en que el producto tiene calidad. Este aseguramiento se debe disear para
PRUEBA DE SOFTWARE
Pgina 10
cada aplicacin antes de comenzar a desarrollarlo y no durante su ejecucin. Mientras el software que se est desarrollando rene los requerimientos y su desempeo sea el esperado, es preciso que se supervisen las actividades de desarrollo del software y su rendimiento, en distintas oportunidades durante cada fase del ciclo de vida. Este es el papel del aseguramiento de la calidad del software.
EL ASEGURAMIENTO DE LA CALIDAD DE SOFTWARE COMPRENDE UNA GRAN VARIEDAD DE TAREAS: Participar en descripcin del proyecto de software. Asegurar que las divergencias en el trabajo de software sean documentadas de acuerdo a los estndares definidos. Almacenar cualquier inconformidad y reportarla a la gerencia media. Revisiones del software que se aplican durante cada paso del desarrollo del mismo, de manera que puedan eliminar defectos cuanto antes. Gestin de configuraciones de software (control de la documentacin del software y de los cambios realizados). El proceso de control de cambios contribuye directamente a la calidad del software. Mtricas de software para el control del proyecto. Verificacin y validacin del software a lo largo del ciclo de vida (Incluye las pruebas y los procesos de revisin e inspeccin).
TCNICAS ASOCIADAS AL ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE. Las tcnicas de revisin de los productos software y las pruebas estn fundamentalmente orientadas a la deteccin de defectos en el SW que a la evaluacin de aspectos orientados a la calidad. Mtricas de software para el control del proyecto. Verificacin y validacin del software a lo largo del ciclo de vida. La gestin de la configuracin del software.
PRUEBA DE SOFTWARE
Pgina 11
2. MODELOS DE CALIDAD DE SOFTWARE

En un mercado globalizado donde las empresas deben innovar y mejorar continuamente para crecer y ser ms competitivas, es necesario tener acceso a certificaciones de calidad internacionales que les den un respaldo y puedan mantenerse en este mercado. Las certificaciones de calidad en la industria del software ayudan a las empresas a ser ms productivas disminuyendo costos y tiempo en sus desarrollos. Las empresas de desarrollo de software de nuestro pas en su mayora son micro y pequeas empresas, y para este tipo de empresas existe una certificacin internacional.
2.1. MODELO DE MCCALL.

El modelo de McCall fue el primero en ser presentado en 1977 y se origino motivado por Air Forc y Dod. Se focaliza en el producto final identificando atributos claves desde el punto de vista del usuario. Estos atributos se denominan factores de calidad y son normalmente atributos externos. pero tambin se incluyen algunos atributos posiblemente internos. los factores de calidad son demasiados abstractos para ser medidos directamente, por lo que por cada uno de ellos se introduce atributos de bajo nivel denominados criterios de calidad. algunos criterios de calidad son atributos internos segn McCall que el atributo interno tiene un efecto directo en el atributo externo correspondiente. McCall propone tres perspectivas para agrupar los factores de calidad: REVISIN DEL PRODUCTO HABILIDAD PARA SER CAMBIADO.
PRUEBA DE SOFTWARE
Pgina 12
La revisin del producto incluye los siguientes factores de calidad: Mantenibilidad. Esfuerzo requerido para localizar y corregir fallas. Flexibilidad. Facilidad de realizar cambios. Testeabilidad. Facilidad para realizar el testing, para asegurarse que el producto no tiene errores y cumple con la especificacin.
TRANSICIN DEL PRODUCTO ADAPTABILIDAD AL NUEVO AMBIENTE. La transicin del producto incluye los siguientes factores de calidad: Portabilidad esfuerzo requerido para transferir entre distintos ambientes de operacin. Reusabilidad facilidad de reusar el software en diferentes contextos. Interoperabilidad esfuerzo requerido para acoplar el producto con otros sistemas.
OPERACIN DEL PRODUCTO CARACTERSTICAS DE OPERACIN. La operacin del producto incluye los siguientes factores de calidad: Correctitud. El grado en el que el producto cumple con su especificacin. Confiabilidad. La habilidad del producto de responder ante situaciones no esperadas. Eficiencia. El uso de los recursos tales como tiempo de ejecucin y memoria de ejecucin. Integridad. Proteccin del programa y sus datos de accesos no autorizados. Usabilidad. Facilidad de operacin del producto por parte de los usuarios.
2.2. MODELO DE BOEHM.

El segundo modelo de calidad ms conocido es presentado por Barry Boehm en 1978. Este modelo introduce caractersticas de alto nivel, caractersticas de nivel intermedio y caractersticas primitivas, cada una de las cuales contribuye al nivel general de calidad.
Las caractersticas de alto nivel representan requerimientos generales de uso pueden ser: Utilidad per-se cuan (usable, confiable, eficiente) es el producto en s mismo. Mantenibilidad cuan fcil es modificarlo, entenderlos y retestearlo. Utilidad general si puede seguir usndose si se cambia el ambiente.
PRUEBA DE SOFTWARE
Pgina 13
Criterio correctitud integridad eciencia testeabilidad exibilidad portabilidad modicab. entendib.
McCall + + + + + +
Boehm + + + + + + +
Criterio conabilidad usabilidad mantenim. Interoperab. reusabilidad claridad document. validez
McCall + + + + +
Boehm + + + + + + +
2.3. CMM (CAPABILITY MATURITY MODEL).

El CMM tiene como objetivo evaluar los procesos en sus distintos niveles de madurez, identificar los niveles a travs de los cuales una organizacin debe formarse para establecer una cultura de excelencia en la ingeniera de software. El modelo de madurez de procesos fue generado a travs de la experiencia colectiva de los proyectos ms exitosos de software, generando as un conjunto de prcticas importantes que deben ser implantadas por cualquier entidad que desarrolla o mantiene software.
PRUEBA DE SOFTWARE
Pgina 14
2.4. ISO (INTERNATIONAL STANDARD ORGANIZATION).

La norma ISO/IEC 9003 proporciona una gua necesaria en las organizaciones para la aplicacin de la ISO 9001 a la adquisicin de suministro, desarrollo, operacin y mantenimiento de software y sus servicios relacionados. Identifica todos los aspectos que deberan ser tratados y es independiente de la tecnologa, modelos de ciclos de vida, procesos de desarrollo y estructuras organizacionales. La norma ISO 9001, especifica los requisitos para un sistema de gestin de la calidad cuando una organizacin necesita demostrar su capacidad de proporcionar de forma coherente productos que satisfagan los requisitos del cliente y aspira a aumentar su satisfaccin a travs de la aplicacin eficaz del sistema, incluyendo los procesos para la mejora continua del sistema y el aseguramiento de la conformidad con los requisitos y de acuerdo a las reglamentaciones existentes.
2.5. PSP (PERSONAL SOFTWARE PROCESS) /TSP (TEAM SOFTWARE PROCESS).
PRUEBA DE SOFTWARE
Pgina 15
El PSP es una tecnologa que tiene como justificacin la premisa de que la calidad de software depende del trabajo de cada uno de los ingenieros de software y de aqu que el proceso diseado debe ayudar a controlar, manejar y mejorar el trabajo de los ingenieros. El objetivo de PSP es lograr una mejor planeacin del trabajo, conocer con precisin el desempeo, medir la calidad de productos y mejorar las tcnicas para su desarrollo. La instrumentacin de esta tecnologa consiste en lo que se denomina evolucin del PSP. El TSP se concentra en los aspectos del desarrollo de software realizado por equipos de trabajo, definiendo aspectos como la asignacin y control de tareas para los diversos miembros del equipo.
2.6. SPICE (SOFTWARE PROCESS IMPROVEMENT AND CAPABILITY DETERMINATION).

El SPICE es un modelo de madurez de procesos internacional. SPICE fomenta productos de calidad, promueve la optimizacin de procesos y facilita la evaluacin del producto a travs de los procesos de desarrollo. SPICE tiene diversos alcances, se aplica tanto a nivel directivo como a nivel de usuarios para asegurar que el proceso se encuentra alineado con las necesidades del negocio, apoya en que los proveedores de software tengan que someterse a una sola evaluacin para aspirar a nuevos negocios y busca que las organizaciones de software dispongan de una herramienta universalmente reconocida para dar soporte a su programa de mejoramiento continuo.
PRUEBA DE SOFTWARE
Pgina 16
2.7. PEMM (PERFORMANCE ENGINEERING MATURITY MODEL).

El PEMM presenta un modelo para evaluar los niveles de integracin, aplicacin, ejecucin y diseo, llamado ingeniera de la ejecucin del modelo de madurez. Al igual que SPICE se apoya en el modelo de madurez de capacidades CMM. El objetivo de PEMM es poder evaluar la Ejecucin de la Ingeniera as como la integracin del proceso. El modelo sirve tanto para evaluar una organizacin como los propios desarrollos de procesos tecnolgicos especficos. Sirve tambin para definir el criterio al escoger un proveedor de software para los productos crticos o semi-crticos de la compaa.
PRUEBA DE SOFTWARE
Pgina 17
2.8. TICKIT.
Desarrollado por el Departamento de Comercio e Industria del Reino Unido, surge por la poca adopcin de las normas internacionales de calidad ISO 9000 para el rea de desarrollo de software. TickIt es primordialmente una gua que presenta las estrategias para lograr la certificacin en la produccin de software a travs de la interpretacin de los estndares ISO. Los objetivos principales de TickIt son, adems de desarrollar un sistema de certificacin aceptable en el mercado, estimular a los desarrolladores de software a implementar sistemas de calidad, dando la direccin y guas necesarias para tal efecto.
PRUEBA DE SOFTWARE
Pgina 18
3. DEFINICIN DE VERIFICACIN Y VALIDACIN

3.1. DEFINICIN DE VERIFICACIN Y VALIDACIN.
El proceso de desarrollo adoptado por un proyecto depender de los objetivos y metas que tenga el proyecto. Existen distintos modelos de ciclo de vida que se han desarrollado para conseguir diferentes objetivos, pero en cualquiera de ellos ser necesario un proceso que asegure la calidad a travs de todo el ciclo de vida de desarrollo del producto. Al final de cada fase del ciclo de vida debera comprobarse que el trabajo realizado hasta ese momento cumple con todos los objetivos previstos. Este es el punto clave, en el que tiene lugar la evaluacin del producto, donde se decide si est o no preparado para pasar a la siguiente fase. De esta forma, si hay errores y son detectados, ser ms eficiente corregirlos que si se descubriesen en etapas ms avanzadas. Este tipo de comprobaciones a lo largo del ciclo de vida incluyen dos actividades: la verificacin y la validacin. La validacin y la verificacin son procesos de evaluacin de productos que son tiles para determinar si se satisfacen las necesidades del negocio y si se estn construyendo acorde a las especificaciones.
PRUEBA DE SOFTWARE
Pgina 19
La verificacin y la validacin no son lo mismo, aunque a menudo se confunden. Boehm expres la diferencia entre ellas de la siguiente manera: - Verificacin: Se est construyendo el producto de la manera correcta? - Validacin: Se est construyendo el producto correcto? El papel de la verificacin implica comprobar que el software est de acuerdo con su especificacin. Debera comprobarse que satisface sus requisitos funcionales y no funcionales. La validacin, sin embargo, tiene como objetivo asegurar que el sistema satisface las expectativas del cliente. Va ms all de la comprobacin de que el sistema satisface su especificacin para demostrar que el software hace lo que el cliente espera que haga, ya que las especificaciones del sistema no siempre reflejan los deseos o necesidades reales de los usuarios y los propietarios del sistema. El objetivo ltimo del proceso de verificacin y validacin es comprobar que el sistema est hecho para un propsito. Esto significa que el sistema debe ser lo suficientemente bueno para su uso previsto. El nivel de confianza requerido depende de:
El propsito o funcin del sistema. El nivel de confianza necesario depende de lo crtico que sea el software para una organizacin. Por ejemplo, el nivel de confianza del software que se utiliza para controlar un sistema de seguridad crtico es mucho ms alto que el requerido para un prototipo de un sistema software que ha sido desarrollado para demostrar nuevas ideas. Las expectativas del usuario. Una reflexin lamentable sobre la industria del software es que a muchos usuarios no les sorprende cuando su software falla durante su uso. Estn dispuestos a aceptar estos fallos del sistema cuando los beneficios de su uso son mayores que sus desventajas. Sin embargo, la tolerancia de los usuarios a los fallos de los sistemas est decreciendo en los ltimos aos. Actualmente es menos aceptable entregar sistemas no fiables, por lo que las compaas deben invertir ms esfuerzo en llevar a cabo las actividades de verificacin y validacin. Entorno de mercado actual. Cuando un sistema se comercializa, los vendedores del sistema deben tener en cuenta los programas competidores, el precio que sus clientes estn dispuestos a pagar por el sistema y los plazos requeridos para entregar dicho sistema. Cuando una compaa tiene pocos competidores, puede decidir entregar un programa antes de que haya sido completamente probado y depurado, debido a que quiere ser el primero en el mercado. Cuando los clientes no estn dispuestos a pagar precios altos por el software, pueden estar dispuestos a tolerar ms defectos en l. Todos estos factores pueden considerarse cuando se decide cunto esfuerzo debera invertirse en el proceso de validacin y verificacin.
PRUEBA DE SOFTWARE
Pgina 20
3.2. VALIDACIN Y VERIFICACIN EN EL CICLO DE VIDA

La validacin y la verificacin son procesos costosos y para algunos sistemas, tales como los sistemas de tiempo real con complejas restricciones no funcionales, ms de la mitad del presupuesto para el desarrollo del sistema puede invertirse en ambos procesos. Es necesario que haya una planificacin cuidadosa para obtener el mximo provecho de las inspecciones y pruebas, y controlar los costes de los procesos de validacin y verificacin. Dicha planificacin debera comenzar en etapas tempranas del proceso de desarrollo, como se ver, con la ayuda de los modelos de ciclo de vida. Existen distintos modelos que representan el ciclo de vida del producto. El modelo en cascada es uno de los ms sencillos en cuanto a su diseo. Es el enfoque metodolgico que ordena rigurosamente las etapas del ciclo de vida del software, de forma que el inicio de cada etapa debe esperar a la finalizacin de la inmediatamente anterior. En este modelo, las pruebas se realizan al final del ciclo de vida del proyecto por lo que los defectos son detectados cerca de la fecha de implementacin del producto o sistema, lo que supone un coste muy elevado en la correccin de defectos. El modelo en cascada es un modelo tradicional, pero existen otros modelos que se ajustan mejor a los proyectos actuales y que se explican a continuacin.
4. OBJETIVOS Y RESTRICCIONES
4.1.
OBJETIVOS.
El proceso de pruebas de software tiene 2 objetivos distintos:
a.
Para demostrar al desarrollador y al cliente que el software satisface sus requerimientos.
PRUEBA DE SOFTWARE
Pgina 21
Para el software a medida, esto significa que debera haber al menos una prueba para cada requerimiento de los documentos de requerimientos del sistema y del usuario. Para productos de software genricos, significa que debera haber pruebas para todas las caractersticas del sistema que se incorporaran en la entrega del producto. Pueden tener una fase de pruebas de aceptacin explicita en la que el cliente comprueba formalmente que el sistema entregado cumple su especificacin. Este objetivo conduce a las pruebas de validacin, en las que se espera que el sistema funcione correctamente usando un conjunto determinado de casos de prueba que reflejan el uso esperado de aquel. Para las pruebas de validacin, una prueba con xito es aquella en la que el sistema funciona correctamente.
b. Para descubrir defectos en el software en que el comportamiento de este es incorrecto, no deseable o no cumple su especificacin. La prueba de defectos est relacionada con la eliminacin de todos los tipos de comportamientos del sistema no deseables, tales como: Cadas del sistema. Interacciones no permitidas con otros sistemas. Clculos incorrectos y corrupcin de datos.
Este objetivo conduce a la prueba de defectos, en los que los casos de prueba se disean para exponer los defectos. Los casos de prueba pueden ser deliberadamente oscuros y no necesitan reflejar cmo se utiliza normalmente el sistema. Para las pruebas de defectos, una prueba con xito es aquella que muestra un defecto que hace que el sistema funciona incorrectamente.
4.2. RESTRICCIONES.
PRUEBA DE SOFTWARE
Pgina 22
Idealmente algunas compaas deberan tener polticas para elegir este subconjunto de pruebas en lugar de dejar esto al equipo de desarrollo. Estas polticas podran basarse en polticas generales de pruebas, tal como una poltica en la que todas las sentencias de los programas deberan ejecutarse al menos una vez. De forma alternativa, las polticas de pruebas pueden basarse en la experiencia de uso del sistema y puede centrarse en probar las caractersticas del sistema operacional. Por ejemplo: 1. Deberan probarse todas las funciones del sistema a las que se accede a travs de mens. 2. Deben probarse todas las combinaciones de funciones (por ejemplo, formateado de textos) a las que se accede a travs del mismo men. 3. En los puntos del programa en los que el usuario introduce datos, todas las funciones deben probarse con datos correctos e incorrectos.
5. PLANIFICACIN
La planificacin de pruebas significa tomar su estrategia de prueba y ponerla en accin, a menudo durante un periodo especfico como por ejemplo una iteracin, un sprint o un pequeo proyecto.
Cuando se piensa en su proceso de planificacin de pruebas, el mismo no deber iniciarse con un documento. Es un proceso. Lo primero que se debe hacer es comprender el contexto de su empresa o proyecto en particular. Comprender el contexto es otra manera de decir comprender los valores, los procesos, las prcticas, las filosofas, las polticas y las personalidades de aquellos con quienes se trabaja. Esto es ms que los objetivos y requerimientos del proyecto: significa comprender cmo y por qu funcionan la empresa y el equipo.
PRUEBA DE SOFTWARE
Pgina 23
5.1. ESTRATEGIAS DE PRUEBAS DE SOFTWARE

El propsito de esta actividad es delinear y comunicar los detalles del esfuerzo de prueba para un periodo determinado. Esto significa que se desea que la informacin sea lo ms correcta y minuciosa posible.
5.2. PLAN DE PRUEBAS

El propsito del plan de pruebas es explicitar el alcance, enfoque, recursos requeridos, calendario, responsables y manejo de riesgos de un proceso de pruebas. Note que puede haber un plan global que explicite el nfasis a realizar sobre los distintos tipos de pruebas (verificacin, integracin e integracin). Un plan de pruebas incluye:
5.2.1. IDENTIFICADOR DEL PLAN. Preferiblemente de alguna forma mnemnica que permita relacionarlo con su alcance, por ej. TP Global (plan global del proceso de pruebas), TP-Req-Seguridad1 (plan de verificacin del requerimiento 1 de seguridad), TP-Contr-X (plan de verificacin del contrato asociado al evento de sistema X), TP-Unit-Despachador. Iniciar (plan de prueba unitario para el mtodo iniciar de la clase Despachador). Como todo artefacto del desarrollo, est sujeto a control de configuracin, por lo que debe distinguirse adicionalmente la versin y fecha del plan.
5.2.2. ALCANCE Indica el tipo de prueba y las propiedades/elementos del software a ser probado.
5.2.3. TEMS A PROBAR Indica la configuracin a probar y las condiciones mnimas que debe cumplir para comenzar a aplicarle el plan. Por un lado, es difcil y riesgoso probar una configuracin que an reporta fallas; por otro lado, si esperamos a que todos los mdulos estn perfectos, puede que detectemos fallas graves demasiado tarde.
5.2.4. ESTRATEGIA Describe la tcnica, patrn y/o herramientas a utilizarse en el diseo de los casos de prueba. Por ejemplo, en el caso de pruebas unitarias de un procedimiento, esta seccin podra indicar: "Se aplicar la estrategia caja-negra de fronteras de la precondicin" o "Ejercicio de los caminos ciclomticos vlidos". En lo posible la
PRUEBA DE SOFTWARE
Pgina 24
estrategia debe precisar el nmero mnimo de casos de prueba a disear, por ej. 100% de las fronteras, 60% de los caminos ciclomticos... La estrategia tambin explicita el grado de automatizacin que se exigir, tanto para la generacin de casos de prueba como para su ejecucin.
5.2.5. CATEGORIZACIN DE LA CONFIGURACIN Explicita las condiciones bajo las cuales, el plan debe ser: Suspendido Repetido Culminado
En algunas circunstancias el proceso de prueba debe suspenderse en vista de los defectos o fallas que se han detectado. Al corregirse los defectos, el proceso de prueba previsto por el plan puede continuar, pero debe explicitarse a partir de qu punto, ya que puede ser necesario repetir algunas pruebas.
5.2.6. TANGIBLES Explicita los documentos a entregarse al culminar el proceso previsto por el plan p. ej. Subplanes, especificacin de pruebas, casos de prueba, resumen gerencial del proceso y bitcora de pruebas.
5.2.7. PROCEDIMIENTOS ESPECIALES Identifica el grafo de las tareas necesarias para preparar y ejecutar las pruebas, as como cualquier habilidad especial que se requiere.
5.2.8. RECURSOS Especifica las propiedades necesarias y deseables del ambiente de prueba, incluyendo las caractersticas del hardware, el software de sistemas (p. ej. el sistema de operacin), cualquier otro software necesario para llevar a cabo las pruebas, as como la colocacin especfica del software a probar (p. ej. qu mdulos se colocan en qu mquinas de una red local) y la configuracin del software de apoyo. La seccin incluye un estimado de los recursos humanos necesarios para el proceso. Tambin se indican cualquier requerimiento especial del proceso: actualizacin de licencias, espacio de oficina, tiempo en la mquina de produccin, seguridad.
PRUEBA DE SOFTWARE
Pgina 25
5.2.9. CALENDARIO Esta seccin describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de las tareas a realizar.
5.2.10. MANEJO DE RIESGOS Explicita los riesgos del plan, las acciones mitigantes y de contingencia.
5.2.11. RESPONSABLES Especifica quin es el responsable de cada una de las tareas previstas en el plan.
6. METTRICAS Y MEDICIONES.
6.1. DEFINICION.
La palabra mtrica, es muy comn asociarla con las palabras medicin y medida, aunque estas tres son distintas. LA MEDICIN es el proceso por el cual los nmeros o smbolos son asignados a atributos o entidades en el mundo real tal como son descritos de acuerdo a reglas claramente definidas. [Fenton91]. MEDIDA proporciona una indicacin cuantitativa de extensin, cantidad, dimensiones, capacidad y tamao de algunos atributos de un proceso o producto. [Pressman98]. El IEEE Standard Glosaryof Software Engering Terms define como MTRICA a una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado. [LenO.Ejiogo91]. Muchos investigadores han intentado desarrollar una sola mtrica que proporcione una medida completa de la complejidad del software. Aunque se han propuesto docenas de mtricas o medidas, cada una de stas tiene un punto de vista diferente; y por otro lado, existe la necesidad de medir y controlar la complejidad del software, es difcil de obtener un solo valor de estas mtricas de calidad.
6.2. QU SON LAS MTRICAS DE SOFTWARE?
PRUEBA DE SOFTWARE
Pgina 26
Es la aplicacin continua de mediciones basadas en tcnicas para el proceso de desarrollo del software y sus productos para suministrar informacin relevante a tiempo, as el administrador junto con el empleo de estas tcnicas mejorar el proceso y sus productos. Las mtricas de software proveen la informacin necesaria para la toma de decisiones tcnicas. Michael [99]
Las mtricas son la maduracin de una disciplina, que, segn Pressman [98] van a ayudar a la Evaluacin de los modelos de anlisis y de diseo.
6.3. PROCESO DE MEDICION:

Ayudar en el diseo de pruebas ms efectivas; es por eso que propone un proceso de medicin, el cual se puede caracterizar por cinco actividades: FORMULACIN: La obtencin de medidas y mtricas del software apropiadas para la representacin de software en cuestin. COLECCIN: El mecanismo empleado para acumular datos necesarios para obtener las mtricas formuladas. ANLISIS: El clculo de las mtricas y la aplicacin de herramientas matemticas. INTERPRETACIN: La evaluacin de los resultados de las mtricas en un esfuerzo por conseguir una visin interna de la calidad de la representacin. REALIMENTACIN: Recomendaciones obtenidas de la interpretacin de mtricas tcnicas trasmitidas al equipo de software.
6.4. ACTIVIDADES DE LAS METRICAS DE SOFTWARE.
PRUEBA DE SOFTWARE
Pgina 27
Las mtricas de software incluyen otras actividades, tales como: Estimacin de costo y el esfuerzo. Medicin de la productividad. Acumulacin de datos. Realizacin de modelos y mediciones de la calidad. Evaluacin y modelos de desempeo. Valoracin de las capacidades y de la madurez. Administracin por mtricas. Evaluacin del mtodo y herramientas.
6.5. CLASIFICACIN DE MTRICAS

La clasificacin de una mtrica de software refleja o describe la conducta del software. A continuacin se muestra una breve clasificacin de mtricas de software, descritas por LemO. Ejiogu [91]: MTRICAS DE COMPLEJIDAD: Son todas las mtricas de software que definen de una u otra forma la medicin de la complejidad; Tales como volumen, tamao, anidaciones, costo (estimacin), agregacin, configuracin, y flujo. MTRICAS DE CALIDAD: Son todas las mtricas de software que definen de una u otra forma la calidad del software, Tales como exactitud, estructuracin o modularidad, pruebas, mantenimiento, reusabilidad, cohesin del mdulo, acoplamiento del mdulo, etc. Estas son los puntos crticos en el diseo, codificacin, pruebas y mantenimiento. MTRICAS DE COMPETENCIA: Son todas las mtricas que intentan valorar o medir las actividades de productividad de los programadores o practicantes con respecto a su certeza, rapidez, eficiencia y competencia. MTRICAS DE DESEMPEO: Corresponden a las mtricas que miden la conducta de mdulos y sistemas de un software, bajo la supervisin del sistema operativo o hardware. Generalmente tienen que ver con la eficiencia de ejecucin, tiempo, almacenamiento, complejidad de algoritmos computacionales, etc.
6.6. MTRICAS DEL SOFTWARE
PRUEBA DE SOFTWARE
Pgina 28
Son las que estn relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia. a. MTRICAS TCNICAS: Se centran en las caractersticas de software. Mide la estructura del sistema, el cmo est hecho. b. MTRICAS DE CALIDAD: proporcionan una indicacin de cmo se ajusta el software a los requisitos implcitos y explcitos del cliente. Es decir cmo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente. c. MTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniera del software. Es decir que tan productivo va a ser el software que voy a disear. d. MTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e informacin sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y mtodos. e. MTRICAS ORIENTADAS AL TAMAO. Es para saber en qu tiempo voy a terminar el software y cuantas personas voy a necesitar. f. MTRICAS ORIENTADAS A LA FUNCIN. Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcularlas las LDC, las mtricas orientadas a la funcin se centran en la funcionalidad o utilidad del programa.
6.7. DIFERENTES ENFOQUES DE MTRICAS

Se han propuesto cientos de mtricas para el software, pero no todas proporcionan suficiente soporte prctico para su desarrollo. Algunas demandan mediciones que son demasiado complejas, otras son tan esotricas que pocos profesionales tienen la esperanza de entenderlas, y otras violan las nociones bsicas intuitivas de lo que realmente es el software de alta calidad. Es por eso que se han definido una serie de atributos que deben acompaar a las mtricas efectivas de software, por lo tanto la
PRUEBA DE SOFTWARE
Pgina 29
mtrica obtenida y las medidas que conducen a ello deben cumplir con las siguientes caractersticas fundamentales: SIMPLE Y FCIL DE CALCULAR: debera ser relativamente fcil de aprender a obtener la mtrica y su clculo no obligara a un esfuerzo o a una cantidad de tiempo inusuales. EMPRICA E INTUITIVAMENTE PERSUASIVA: la mtrica debera satisfacer las nociones intuitivas del ingeniero de software sobre el atributo del producto en cuestin. CONSISTENTE EN EL EMPLEO DE UNIDADES Y TAMAOS: el clculo matemtico de la mtrica debera utilizar medidas que no lleven a extraas combinaciones de unidades. INDEPENDIENTE DEL LENGUAJE DE PROGRAMACIN: las mtricas deberan apoyarse en el modelo de anlisis, modelo de diseo o en la propia estructura del programa. No deberan depender de los caprichos de la sintaxis o semntica del lenguaje de programacin. UN MECANISMO EFICAZ PARA LA REALIMENTACIN DE CALIDAD: la mtrica debera suministrar al desarrollador de software informacin que le lleve a un producto final de superior calidad. No obstante que la mayora de las mtricas de software compensan las caractersticas anteriores, algunas de las mtricas usualmente empleadas no cumplen una o dos caractersticas.
7. V4V EN EL PROCESO DE DESARROLLO DE SOFTWARE

7.1. EL PROCESO V & V
Es el proceso de todo un ciclo vital: La V & V debe aplicarse en cada etapa del software. Tiene dos objetivos principales. El descubrimiento de defectos en el sistema. La evaluacin de si el sistema es til y utilizable en una situacin operacional o no.
PRUEBA DE SOFTWARE
Pgina 30
7.2. METAS DE LA V&V

La verificacin y la validacin deberan establecer la confianza de que el software es adecuado al propsito. Esto NO significa que est completamente libre de defectos. Sino que debe ser lo suficientemente bueno para su uso previsto y el tipo de uso determinar el grado de confianza que se necesita.
7.3. CONFIANZA DE LA V&V

Depende del propsito del sistema, las expectativas del usuario y el entorno de marketing. 7.3.1. FUNCIN DEL SOFTWARE. El nivel de confianza depende de lo crtico que es el sistema para una organizacin.
7.3.2. EXPECTATIVAS DEL USUARIO. Los usuarios pueden tener bajas expectativas para ciertas clases de software.
7.3.3. ENTORNO DE MARKETING. Introducir un producto en el mercado pronto puede ser ms importante que encontrar defectos en el programa
7.4. VERIFICACIN DINMICA Y ESTTICA
PRUEBA DE SOFTWARE
Pgina 31
PRINCIPAL TCNICA V&V
INSPECCIONES DE SOFTWARE. Se ocupa del anlisis de representaciones estticas del sistema para describir problemas (verificacin esttica). Pueden ser complementadas por documentos basados en herramientas y anlisis del cdigo. PRUEBAS DEL SOFTWARE. Se ocupa de la ejercitacin y la observacin del comportamiento del producto (verificacin dinmica). El sistema se ejecuta con datos de pruebas y se observa su comportamiento operativo.
7.5. PLANIFICACIN DE V &V

Se requiere una cuidadosa planificacin para sacar el mximo de los procesos de inspeccin y pruebas. La planificacin debera comenzar pronto en el proceso de desarrollo. El plan debera identificar el balance entre la verificacin esttica y las pruebas. La planificacin trata de definir estndares para el proceso de prueba en lugar de describir pruebas de productos.
7.6. EL MODELO-V DE DESARROLLO
PRUEBA DE SOFTWARE
Pgina 32
V-MODELO Es a proceso del desarrollo del software cul se puede presumir para ser la extensin del modelo de la cascada. En vez de la mudanza abajo de una manera linear, los pasos de proceso estn doblados hacia arriba despus de codificacin fase, formar la forma de V tpica. El V-Modelo demuestra las relaciones entre cada fase del ciclo vital del desarrollo y su fase asociada de prueba.
7.7. FASE DE LA VERIFICACIN

7.7.1. ANLISIS DE REQUISITOS En esta fase, los requisitos del sistema propuesto son recogidos analizando las necesidades de los usuarios. Esta fase se refiere sobre establecer lo que tiene que realizarse el sistema ideal. Sin embargo, no se determina cmo el software ser diseado o construido. Generalmente, se entrevistan con los usuarios y un documento llamado el documento de las exigencias del consumidor se genera. El documento de las exigencias del consumidor describir tpicamente el sistema funcional, fsico, el interfaz, el funcionamiento, los datos, los requisitos de la seguridad segn lo esperado por el usuario.
7.7.2. DISEO DEL SISTEMA Los tcnicos analizan y entienden el negocio del sistema propuesto estudiando el documento de las exigencias del consumidor. Calculan hacia fuera las posibilidades y las tcnicas por las cuales las exigencias del consumidor pueden ser puestas en ejecucin. El documento de la especificacin del software que sirve mientras que un modelo para la fase del desarrollo se genera. Este documento contiene la organizacin general del sistema, estructuras del men, estructuras de datos etc.
PRUEBA DE SOFTWARE
Pgina 33
7.7.3. DISEO DE LA ARQUITECTURA Esta fase se puede tambin llamar como diseo de alto nivel. La lnea de fondo en seleccionar la arquitectura es que debe realizar todo que consista en tpicamente la lista de mdulos, breve funcionalidad de cada mdulo, su interfaz relaciones, dependencias, base de datos tablas, los diagramas de la arquitectura, tecnologa detallan el etc. El diseo de prueba de la integracin se realiza en esta fase.
7.7.4. DISEO DEL MDULO Esta fase se puede tambin llamar como diseo bajo. El sistema diseado est quebrado para arriba adentro a unidades ms pequeas o se explica los mdulos y cada uno de ellas de modo que el programador pueda comenzar a cifrar directamente. Las especificaciones del documento o del programa del diseo del nivel bajo contendrn una lgica funcional detallada del mdulo, adentro pseudocdigo, tablas de la base de datos, con todos los elementos, incluyendo su tipo y tamao todos los detalles del interfaz.
7.8. FASES DE LA VALIDACIN

7.8.1. PRUEBA DE LA UNIDAD En el V-modelo del desarrollo del software, la prueba de la unidad implica la primera etapa de prueba dinmica proceso. Implica el anlisis del cdigo escrito con la intencin de eliminar errores. Tambin verifica que los cdigos sean eficientes y tengan estndares de la codificacin. La prueba est generalmente caja blanca. Se hace usando el diseo de la prueba de unidad elaborada durante la fase de diseo del mdulo.
7.8.2. PRUEBA DE LA INTEGRACIN En la integracin la prueba de los mdulos separados ser probada junta para exponer averas en interfaces y en la interaccin entre los componentes integrados. La prueba est generalmente caja negra pues el cdigo no se comprueba directamente para saber si hay errores. Se hace usando el diseo de la prueba de la integracin elaborada durante la fase de diseo de la arquitectura.
PRUEBA DE SOFTWARE
Pgina 34
7.8.3. PRUEBA DEL SISTEMA La prueba del sistema comparar las especificaciones de sistema contra el sistema real. El diseo de la prueba del sistema se deriva de los documentos del diseo del sistema y se utiliza en esta fase. La prueba del sistema est a veces automatizado usar las herramientas de prueba. Una vez que se integren todos los mdulos varios errores pueden presentarse. La prueba hecha en esta etapa se llama prueba del sistema.
7.8.4. PRUEBA DE ACEPTACIN DE USUARIO
a. PRUEBA DE ACEPTACIN: Para determinarse si un sistema satisface sus criterios de la aceptacin o no. Para permitir al cliente determinarse si aceptar el sistema o no. Para probar el software en el del mundo real por las audiencias previstas. PROPSITO DE LA PRUEBA DE ACEPTACIN: Para verificar el sistema o los cambios segn las necesidades originales.
b. PROCEDIMIENTOS PARA CONDUCIR LA PRUEBA DE ACEPTACIN: Defina los criterios de la aceptacin: Requisitos de la funcionalidad y funcionamiento. Requisitos de calidad del interfaz. Requisitos de calidad totales del software. Desarrolle un plan de la aceptacin: Descripcin del proyecto. Responsabilidades del usuario. Descripcin de la aceptacin. Ejecute el plan de prueba de aceptacin.
PRUEBA DE SOFTWARE
Pgina 35
CONCLUSIONES
Una aplicacin probada reduce el riesgo de errores crticos en produccin. El testeo de software es fundamental durante todo el ciclo de produccin de las aplicaciones de software. Las pruebas de Software ejecuta el software con el objetivo de establecer si se ajusta a las especificaciones y si se adapta correctamente al ambiente de operacin. Por lo tanto, el software testing no solo busca errores. Si el cdigo es difcil de probar, entonces debera considerarse la re-escritura del cdigo. Los testers tienen que considerar el software y las funciones que realiza, sus entradas y como se pueden combinar, y el ambiente en el que el software (eventualmente) operar. El desarrollo del testing se ha visto favorecido en ambientes acadmicos. Se requiere traspasar este trabajo acadmico a ideas ms prcticas para su aplicacin en el desarrollo de software.
PRUEBA DE SOFTWARE
Pgina 36
PRUEBA DE SOFTWARE
Pgina 37
REFERENCIAS
http://www.rodolfoquispe.org/blog/que-es-la-calidad-de-software.php http://desasof2004.blogspot.com/2009/06/plan-de-pruebas-de-software.html http://elchrboy.blogspot.com/2010/03/estrategias-de-pruebas-de-software.html http://desasof2004.blogspot.com/2009/06/plan-de-pruebas-de-software.html http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/gonzalez_d_h/capitulo2.pdf http://www.buenastareas.com/ensayos/Verificacion-Y-Validacion-De-Sofware/312349.html http://www.willydev.net/descargas/willydev_planeasoftware.pdf8 http://www.slideshare.net/loreknelamorena/mtricas-de-proceso-y-proyecto-de-software http://empleo.trovit.es/ofertas-empleo/verificacion-calidad-desarrollo-software http://www.buenastareas.com/login.php?save_page=%2Fensayos%2FVerificacion-Y-ValidacionDe-Sofware%2F312349.html http://www.worldlingo.com/ma/enwiki/es/V-Model_%28software_development%29
PRUEBA DE SOFTWARE
Pgina 38

Fundamentos de La Prueba de Software

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Fundamentos de La Prueba de Software

Загружено:

Авторское право:

Доступные форматы

FUNDAMENTOS DE LA PRUEBA DE SOFTWARE