Introducción
Las pruebas de un software se lo realizan mediante el análisis del desempeño del producto durante un tiempo determinado.
Las pruebas de software se consideran como las investigaciones empíricas y técnicas cuyo propósito es proporcionar información objetiva e independiente sobre la calidad del producto al momento de ser proporcionado a la parte que lo solicita (…).
Las pruebas son elementalmente un conjunto de acciones dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas acciones podrán ser implementadas en cualquier momento de dicho proceso de desarrollo. Existen distintos modelos de desarrollo de software, así como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento en las actividades de desarrollo.
Considerando la definicion de Sanches j, (2015), lo cual define que al construir software habitualmente se cometen errores. En la industria las técnicas para solucionar los problemas derivados de dichos errores, serán las pruebas del software, que consistirían en una serie de pasos realizados antes y después de la construcción de este software.
Estos pasos más que importantes son muy necesarios debido a que se estaría tomando en cuenta las posibles vías de desarrollo del software y así mismo se analizarían y se especificaría lo que se desea alcanzar y de esta manera se presentarían menos fallas al momento de ejecutar el producto.
Es muy importante también tener presente, que en todo trabajo que se realice se debe estipular una planificación, ya que así se podrá determinar el tiempo que el software estará en una etapa de prueba y que en aquella etapa se analizaran y se solucionarán los errores que pueda presentar. Así mismo teniendo una planificación, se diagnosticara todos los recursos que se necesitan para que un software tenga un excelente desempeño en la etapa de pruebas y en su periodo de funcionamiento.
Por aquello, lo aconsejable es que el producto o también llamado software vaya siendo evaluado a medida que se va desarrollando. De tal manera, se hace necesario llevar cabo, en paralelo al proceso de desarrollo, un proceso de evaluación o comprobación de los distintos productos o modelos que se van generando, en el que participarán desarrolladores y clientes.
La posibilidad de querer conseguir programas perfectos que no presenten ningún inconveniente sigue siendo una cima inaccesible que aunque se realice una planificación no se puede tener un producto libre de errores y, se debe, por tanto, aceptar las actuales restricciones que padece la construcción de software. Aunque también es difícil establecer cuál es la cantidad media de defectos que un sistema software normal contiene.
Contenido
Referente al contenido de EcuRed, (s.f) la prueba es un proceso que se enfoca sobre la lógica interna del software y las funciones externas del mismo. Es un proceso de realización de un programa con la intención de descubrir un error, no puede asegurar la ausencia de defectos, debido a que en toda prueba es muy probable que exista algún error en el producto; por lo tanto sólo puede demostrar que existen defectos en el software.
En un proceso de pruebas formal, suelen confundirse con mucha facilidad, los niveles de pruebas con los tipos de prueba, y a pesar de que se encuentren íntimamente relacionadas, tienen connotaciones diferentes en el proceso. Para entender un poco más, vamos a partir del hecho de que las pruebas pueden ejecutarse en cualquier punto del proceso de desarrollo de software, y es aquí donde los niveles de prueba nos permiten entender con claridad los diferentes puntos o etapas en donde pueden ejecutarse ciertos tipos de prueba. (Zapata J, 2013).
Niveles de prueba
Los niveles de prueba son: 1) pruebas Unitarias, 2) pruebas de Integración, 3) prueba del Sistema y 4) Pruebas de Aceptación.
Las pruebas unitarias o de componente se implementan habitualmente por el equipo de desarrollo, debido a que consisten en la ejecución de actividades que le permitan verificar al desarrollador que los componentes unitarios están codificados bajo condiciones de firmeza, esto es, soportando el ingreso de datos erróneos o inesperados y demostrando así la capacidad de tratar errores de manera controlada, también con la finalidad de poder identificar estos errores y así buscarles una solución.
La prueba de integración tiene como objetivo presentar el software de manera completa ya que se lo puede realizar por módulos, pero de esta manera al momento de querer identificar un error existirán muchas dificultades tal como lo afirma (Juristo N, 2006) "al combinar todos los módulos y probar todo el programa en su conjunto. El resultado puede ser un poco caótico con un gran conjunto de fallos y la consiguiente dificultad para identificar el módulo (o módulos) que los provocó".
Las pruebas del sistema (…) tienen como propósito ejercitar profundamente el sistema para verificar que se han integrado adecuadamente todos los elementos del sistema (hardware, otro software, etc.) y que realizan las funciones adecuadas.
Las pruebas del sistema se consideran (…) como el propósito de ejercitar profundamente el sistema para verificar que se han integrado adecuadamente todos los elementos del sistema (hardware, otro software, etc…) y que realizan las funciones adecuadas. Concretamente se debe comprobar que:
1) Las funciones que realice sean de acuerdo a lo establecido, 2) el funcionamiento y rendimiento de las interfaces hardware, software y de usuario se ejecuten correctamente, 3) la adecuación de la documentación de usuario este bien planteada y el rendimiento y respuesta en condiciones límite y de sobrecarga.
Realizar este tipo de prueba es muy indispensable ya que es el punto donde se va a identificar los errores o fallas que presente el software por lo tanto este tipo de pruebas se suelen hacer inicialmente en el entorno del desarrollador, denominadas pruebas alfa, y seguidamente en el entorno del cliente denominadas pruebas beta.
Las pruebas de aceptación del software es cuando el producto esta idóneo para ser utilizado por los cliente, por lo tanto no debe de presentar ningún tipo de inconveniente en el entorno donde tenga que ser implementado.
Es muy recomendable que las pruebas de aceptación se realicen en el entorno en que se va a explotar el sistema (incluido el personal que lo maneje). En caso de un producto de interés general, se realizan pruebas con varios usuarios que reportarán sus valoraciones sobre el producto.
Independientemente de que se haya tercerizado el proceso de pruebas y así la firma responsable de estas actividades haya emitido un certificado de calidad sobre el sistema objeto de prueba, es indispensable, que el cliente designe al personal que haga parte de los procesos de negocio para la ejecución de pruebas de aceptación, es incluso recomendable, que los usuarios finales que participen en este proceso, sean independientes al personal que apoyó el proceso de desarrollo (…). En los casos en que las pruebas de aceptación del producto se hayan ejecutado en el ambiente del proveedor, el aplicativo no podrá salir a producción, sin que se hayan ejecutados las respectivas pruebas Beta en el ambiente del cliente (…).
OBJETIVOS DE LAS PRUEBAS DE SOFTWARE.
La prueba de software es un elemento crítico para la garantía del correcto funcionamiento del software(…).
Los objetivos son: 1) detectar defectos en el software, 2) verificar la integración adecuada de los componentes, 3) verificar que todos los requisitos se han implementado correctamente 4) identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente, 5) diseñar casos de prueba que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.
Para lograr los objetivos propuestos, un ingeniero de software deberá conocer los principios básicos que guían las pruebas del software.
(Rodriguez E, 2012) Afirma que existen dos métodos básicos para diseñar casos de prueba los cuales son:
De caja blanca (o estructurales)
De caja negra (o funcionales)
El metodo basico de caja blanca se encarga de veri?car la correcta implementación de las unidades internas, las estructuras y sus relaciones y asi mismo hacen énfasis en la reducción de errores internos.
Los métodos de caja blanca o estructurales permiten derivar casos de prueba que garanticen que todas las rutas independientes dentro del módulo se ejecuten al menos una vez.
El metodo de caja negra veri?ca el correcto manejo de funciones externas provistas o sopor tadas por el software, veri?ca que el comportamiento observado se apegue a las especi?caciones del producto y a las expectativas del usuario. Los casos de prueba se construyen a partir de las especi?caciones del sistema, por lo tanto es primordial realizar una especificacion de sistemas antes de realizar una prueba.
Metodología de pruebas
Los procesos de aseguramiento de calidad de un producto de software suelen dividirse en lo que respecta a su componente analítico en pruebas estáticas y dinámicas. La diferencia fundamental entre estos tipos de pruebas, radica en que las pruebas estáticas se centran en evaluar la calidad con la que se está generando la documentación del proyecto, por medio de revisiones periódicas, mientras que las pruebas dinámicas, requieren de la ejecución del software con el fin de medir el nivel de calidad con la que este fue codificado y el nivel de cumplimiento en relación con la especificación del sistema.
Realizar pruebas dinámicas a un producto de software, suele en la mayoría de los casos confundirse con una simple actividad de ejecución de pruebas y reporte de incidencias, sin embargo, para productos de complejidad media en adelante, lo recomendable es implementar de manera formal una metodología de pruebas que se ajuste y acople uniformemente con la metodología de desarrollo seleccionada por la firma desarrolladora.
Para procesos de desarrollo basados en métodos más habituales, implementar una metodología de pruebas es totalmente factible, teniendo en cuenta que estas metodologías están orientadas a la documentación y a la formalización de todas las actividades ejecutadas. Si por el contrario, la firma desarrolladora guía su proceso bajo lineamientos basados en metodologías ágiles, será necesario reevaluar la conveniencia de ejecutar todas las actividades que implica un proceso de pruebas formal, lo que en la mayoría de los casos, encamina a reducir al mínimo las actividades relacionadas con un proceso de pruebas, circunstancia que naturalmente puede desencadenar en la liberación de productos con bajos niveles de eficacia.
Planeación de Pruebas.
La planeacion de pruebas es la etapa en donde se ejecutan las primeras actividades correspondientes al proceso de pruebas y tiene como resultado un entregable denominado plan de pruebas el cual debe estar conformado en cuando menos por aspectos tales como:
Alcance de la prueba: determina que funcionalidades del producto y/o software serán probadas durante el transcurso de la prueba. Este listado de funcionalidades a probar se extrae con base a un análisis de riesgos realizado de manera previa, que tienen en cuenta variables tales como el impacto que podría ocasionar la falla de una funcionalidad y la probabilidad de falla de una funcionalidad. Producto de este análisis, se cuenta con información adicional que permite determinar además del alcance detallado del proceso de pruebas, la prioridad con la que las funcionalidades deben probarse y la profundidad de las pruebas.
Tipos de Prueba: en este punto se debe determinar qué tipos de pruebas requeriría el producto. No todos los productos de software requieren la aplicación de todos los tipos de pruebas que existen, por esta razón, es estrictamente necesario que el líder de pruebas se plantee preguntas que le permitan determinar qué tipos de prueba son aplicables al proyecto en evaluación. Los posibles tipos de prueba a aplicar son: pruebas de stress, pruebas de rendimiento, pruebas de carga, pruebas funcionales, pruebas de usabilidad, pruebas de regresión, entre otros.
Estrategia de Pruebas: teniendo en cuenta que no es viable probar con base a todas las posibles combinaciones de datos, es necesario determinar a través de un análisis de riesgos sobre que funcionalidades debemos centrar nuestra atención. Adicionalmente, una buena estrategia de pruebas debe indicar los niveles de pruebas (ciclos) que aplicaremos y la intensidad o profundidad a aplicar para cada nivel de pruebas definido. En este punto también es importante definir los criterios de entrada y salida para cada ciclo de pruebas a ejecutar.
Criterios de Salida: entre las partes involucradas en el proceso, se define de manera formal, bajo qué condiciones se puede considerar que una actividad de pruebas fue finalizada. Los criterios de salida se deben definir para cada nivel de pruebas a ejecutar. Algunos ejemplos de criterios de salida que pueden ser utilizados son: porcentaje de funcionalidades de alto riesgo probadas con éxito, número defectos críticos y mayores aceptados, etc.
Otros aspectos: tal y como se realiza en cualquier plan de proyecto, se debe incluir una estimación de tiempos, los roles y recursos que harán parte del proceso, la preparación del entorno de pruebas, cronograma base, etc.
El diseño de Pruebas una vez elaborado y aprobado, el equipo de trabajo debe iniciar el análisis de toda la documentación existente con respecto al sistema, con el objeto de iniciar el diseño de los casos de prueba. Los entregables claves para iniciar este diseño pueden ser: casos de uso, historias de usuario, arquitectura del sistema, diseños, manuales de usuario (si existen), manuales técnicos (si existen). El diseño de los casos, debe considerar la elaboración de casos positivos y negativos. Los casos de prueba negativos permiten validar cómo se comporta el sistema ante situaciones atípicas y permite verificar la robustez del sistema, atributo que constituye uno de los requerimientos no funcionales indispensable para cualquier software. Por último, es necesario definir cuáles son los datos de prueba necesarios para la ejecución de los casos de prueba diseñados.
Implementación y Ejecución de Pruebas: La ejecución de pruebas debe iniciar con la creación de los datos de prueba necesarios para ejecutar los casos de prueba diseñados. La ejecución de estos casos, puede realizarse de manera manual o automatizada; en cualquiera de los casos, cuando se detecte un fallo en el sistema, este debe ser documentado y registrado en una herramienta que permita gestionar los defectos (…). Una vez el defecto ha sido corregido por la firma desarrolladora en su respectivo proceso de depuración, es necesario realizar un re-test que permita confirmar que el defecto fue solucionado de manera exitosa. Por último, es indispensable ejecutar un ciclo de regresión que nos permita garantizar, que los defectos corregidos en el proceso de depuración de la firma, no hayan desencadenado otros tipos de defectos en el sistema.
Evaluación de Criterios de Salida: Los criterios de salida son necesarios para determinar si es posible dar por finalizado un ciclo de pruebas. Para esto, es conveniente definir una serie de métricas que permitirán al finalizar un proceso de pruebas, comparar los resultados obtenidos contra las métricas definidas, sí los resultados obtenidos no superan la métricas definidas, no es posible continuar con el siguiente ciclo de pruebas.
Existen varios tipos de criterios de salida dentro de los cuales se pueden mencionar:
1) Cubrimiento de funcionalidades en general. 2) Cubrimiento de funcionalidades críticas para el sistema. 3) Número de defectos críticos y mayores detectados, etc.
El proceso de pruebas puede ser suspendido o paralizado, debido a otros aspectos relacionados con el presupuesto y la calidad mínima del sistema requerida para el inicio formal de pruebas.
Técnicas de evaluación del software
Las técnicas de Evaluación de desarrollo según Juristo N, (2006), se las conoce de modo genérico por Revisiones. Las revisiones pretenden detectar manualmente defectos en cualquier producto del desarrollo (…). Existen varios tipos de revisiones, dependiendo de qué se busca y cómo se analiza ese producto. Las revisiones se las realiza secuencialmente en orden debido a que el producto debe de estar compuesto por módulos, además si se busca un excelente desempeño en el software durante su ejecución, se debe analizar cada una de las funciones específicas que debe cumplir y si tiene algún tipo de fallos se debe recurrir a su estructura de códigos.
Beneficios de las revisiones
La razón para buscar defectos en productos tempranos es porque éstos se traducen en defectos en el producto final. Es decir, defectos en los requisitos se traducirán en defectos en el sistema final. Veamos una analogía con la arquitectura de edificios. Si en un plano el color de una línea indica su significado, una confusión en el color se traducirá en un error en el edificio. Por ejemplo, si el azul indica tuberías de agua y el amarillo cables eléctricos y el arquitecto comete un error usando el azul en una conducción eléctrica, los electricistas que usen el plano como guía para su trabajo no colocarán cables eléctricos mientras que los fontaneros colocarán tuberías de agua donde no debían ir.
El plano de un edificio es el artefacto equivalente al diseño de un producto software. Si un diseño contiene defectos, seguramente estos defectos se trasmitirán al código cuando los programadores usen ese diseño como guía para su trabajo. La detección temprana de errores acarrea grandes beneficios. Si las revisiones únicamente se aplican al código mejoran la calidad y producen ahorros en los costos del proyecto.
Pero los ahorros son mayores si se inspeccionan artefactos tempranos del desarrollo. Estudiando los resultados publicados sobre ahorros con las revisiones, puede afirmarse que la utilización de inspecciones de código produce un ahorro del 39% sobre el coste de detectar y corregir defectos, frente a únicamente utilizar la evaluación dinámica. Sin embargo, el ahorro es del 44% si se inspecciona también el diseño. La experiencia demuestra que entre el 30% y el 70% de los defectos, de diseño y código son detectados por las técnicas estáticas. Esto supone un gran ahorro, pues la corrección es más fácil y menos costosa durante la evaluación estática que durante la dinámica. Nótese que cuando durante la evaluación dinámica del sistema se detecta un fallo en un programa, lo que se detecta es el fallo, no la falta que lo provoca. Es decir, tras la detección del fallo, se requiere una labor de localización en el programa de la falta que provocó el fallo. Sin embargo, con las técnicas estáticas, lo que se detecta son directamente faltas. Por tanto, una vez detectada, se puede pasar a la fase de corrección.
Es decir, desaparece la tarea de localización de la falta. Esto significa, que las técnicas estáticas son más baratas por falta que las dinámicas.
Objetivos de la evaluación estática
La evaluación estática de los distintos productos que se generan en el desarrollo de software (especificación de requisitos, modelos conceptuales, diseño, código, etc.) pretende comprobar su calidad al momento de presentar sus habilidades.
La calidad simboliza una forma distinta para cada producto, precisamente porque son software distinto y un software que será utilizado para verificar el sistema de funcionamiento de avión no será igual que un software para controlar el desempeño de unos trabajadores. Del mismo modo que la calidad de un plano y la calidad de una casa significa cosas distintas. En un plano de un futuro edificio se desea que sea claro, que sea correcto, que no tenga inconsistencias, etc… Sin embargo, de una casa se espera que sea robusta por ejemplo, que no se caiga, usable es decir, que las partes que la conforman estén bien ajustadas y compactadas. Por tanto, cuando se esté evaluando estáticamente un producto software, es importante que el evaluador tenga en mente qué tipo de defectos está buscando y cuál sería un producto de ese tipo de calidad adecuada.
Además es muy importante considerar que no solo se debe buscar los defectos del producto, sino también estar seguro del desempeño que va a tener ya que al momento de ejecutarlos en el lugar solicitado debe de tener una funcionalidad insuperable por otros productos.
El proceso de inspección
Las Inspecciones están conformadas por dos puntos: 1) la comprensión del artefacto que se inspecciona; 2) la búsqueda de faltas en dicho artefacto.
Pero además la inspección consta de cuatro fases primordiales:
1. Inicio tiene la finalidad de preparar la inspección y proporcionar la información que se necesita sobre el artefacto para realizar la inspección.
2. Detección de defectos todos los componentes del equipo realiza individualmente la lectura del material, compresión del producto a revisar y la detección de faltas. Las Técnicas de Lectura ayudan en esta etapa al inspector tanto a comprender el desenvolvimiento del producto como a detectar faltas. Basándose en las faltas detectadas cada miembro debe realizar una estimación subjetiva del número de faltas remanentes en el artefacto.
3. Colección de defectos el registro de las faltas encontrada por cada miembro del equipo es compilado en un solo documento que servirá de basa a la discusión sobre faltas que se realizará en grupo. Utilizando como base las faltas comunes encontradas por los distintos inspectores se puede realizar una estimación objetiva del número de faltas remanentes. En la reunión se discutirá si las faltas detectadas son falsos positivos (faltas que algún inspector cree que son defectos pero que en realidad no lo son) y se intentará encontrar más faltas ayudados por la asociación del grupo.
4. Corrección y seguimiento el diseñador del producto inspeccionado debe corregir las faltas encontradas e informar de las correcciones realizadas a modo de seguimiento.
Técnicas de evaluación dinámica
Características y fases de la prueba
Se considera a la aplicación de técnicas de evaluación dinámicas también como prueba del software. Específicamente la Prueba de software se puede definir como una actividad en la cual un sistema o uno de sus componentes se ejecutan en circunstancias previamente detalladas, registrándose los resultados obtenidos. De manera secuencial se realiza un proceso de evaluación en el que los resultados obtenidos se comparan con los resultados esperados para localizar fallos en el software. Estos fallos conducen a un proceso de Depuración en el que es necesario identificar la falta asociada con cada fallo y corregirla, pudiendo dar lugar a una nueva prueba. Como resultado final se puede obtener una determinada predicción de fiabilidad, tal como se indicó anteriormente, o un cierto nivel de confianza en el software probado.
El objetivo de las pruebas no es asegurar la ausencia de defectos en un software, únicamente puede demostrar que existen defectos en el software. El objetivo del analista del producto es diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, realizándolo en un tiempo mínimo y con muy poco esfuerzo.
Para ser más específicos es decir con más alta probabilidad de encontrar fallas en el software, las pruebas deberían ser realizadas por un equipo independiente al que realizó el software. El ingeniero de software que creó el sistema no es el más adecuado para llevar a cabo las pruebas de dicho software, ya que inconscientemente tratará de demostrar que el software tiene un desenvolvimiento muy elevado, y no que no que tiene fallas, por lo que la prueba puede tener menos éxito. De tal forma el análisis lo debe realizar una persona especializada en la evaluación de todo tipo de software y sobre todo encargada de encontrar las fallas que puede tener un producto.
Características de una buena prueba:
Una excelente prueba debe de tener una alta probabilidad de encontrar un fallo. Para alcanzar este objetivo el responsable de la prueba debe entender el software e intentar desarrollar una imagen mental de cómo podría fallar y cada falla como se la podría solucionar.
Control de calidad del software
La demanda por tener un producto de excelente calidad aumenta de forma continua, a medida que los clientes se vuelven más selectivos y comienzan a rechazar los productos poco fiables o que realmente no dan respuesta a sus necesidades. Es conveniente e imprescindible diferenciar entre la calidad del producto software y la calidad del proceso de desarrollo, estos dos puntos están encadenados entre sí, ya que un buen proceso lleva a la construcción de un excelente producto. Las metas que se establezcan para la calidad del producto van a determinar las metas a establecer para la calidad del proceso de desarrollo, ya que la calidad del producto va a estar en función de la calidad del proceso de desarrollo. Sin la planificación de un buen proceso de desarrollo es muy difícil alcanzar un buen producto. También es importante destacar que la calidad de un producto software debe ser considerada en todo sus estados de evolución a medida que avanza el desarrollo de acuerdo al ciclo de vida seleccionado para su construcción especificando diseño, código, etc.). La calidad del producto no es suficiente una vez finalizado, cuando los problemas de mala calidad ya no tienen solución o la medida de solucionarlo es muy elevada.
Los primeros inconvenientes a los que se enfrenta el desarrollo de software a la hora de tratar la calidad de un producto software son la definición de calidad y su comprobación, La calidad es un concepto que se caracteriza por presenta productos terminados y con funcionalidades elevadas.
Atributos que hacen más concreta la definición de la calidad del software:
1) Funcionalidad es la habilidad del software para realizar el trabajo deseado. 2) Fiabilidad es la capacidad del software para mantenerse operativo. 3) Eficiencia es el desempeño que tiene el software para responder a una petición de usuario con la velocidad apropiada. 4) Usabilidad calidad y excelencia que tiene el software para satisfacer al usuario. 5) Mantenibilidad habilidad del software para poder realizar cambios en él fácilmente y con una adecuada proporción. 6) Portabilidad es el alcance que tiene el software para operar en diferentes entornos informáticos.
Conclusión
En la actualidad en toda organización se utilizan software para agilizar las tarea y así mismo maximizar el desarrollo del trabajo, para aquello los software que utilizan deben de tener un análisis y por eso necesitan pasar por un periodo de pruebas, para identificar las funciones específicas que debe realizar y también si el producto tiene un desempeño ajustado a las funciones que se realizan en dicho lugar.
Esta etapa de prueba se considera indispensable, ya que si existe algún error o tiene algún tipo de fallas el producto, es un buen momento para ser corregido y ser ajustado a las funciones destinadas. Además estas técnicas ayudan a identificar en qué etapa se dan este tipo de fallas, y así evitar ese tipo de problemas en el desarrollo de otro producto.
Referencias
EcuRed. (s.f). EcuRed. Recuperado el 3 de marzo de 2017, de file:///E:/SEXTO%20SEMESTRE/ING%20DEL%20SOFTWARE/SEGUNDO%20PARCIAL/EXPOSICION/Pruebas%20de%20software%20-%20EcuRed.html
Florian B. (2013). campus virtual . Obtenido de https://campusvirtual.univalle.edu.co/moodle/pluginfile.php/477552/mod_resource/content/1/2013A_TPSW_Clase04_PruebasDin%C3%A1micasVistaGeneral.pdf
Juristo N, M. A. (17 de octubre de 2006). Tecnicas de evaluacion de software.
Rodriguez E. (2012). Estrategias y técnicas de prueba del software. En Rodriguez E.
Sanchez J. (2015). Prueba de software, fundametos tecnicos. En Sanchez J. Madrid, España .
Zapata J. (13 de enero de 2013). Ingenieria de software con énfasis en pruebas. Obtenido de file:///E:/SEXTO%20SEMESTRE/ING%20DEL%20SOFTWARE/SEGUNDO%20PARCIAL/EXPOSICION/PRUEBAS%20DE%20SOFTWARE%20_%20Ingenieria%20de%20Software%20con%20%C3%A9nfasis%20en%20pruebas..html
Autor:
Galo Andrés Rodríguez Baque.
Estudiante del Sexto Semestre de la Carrera de Ingeniería en Computación y Redes. Ecuador.