• Author / Uploaded
• BRAIAN

Citation preview

PLAN DE PRUEBAS

Pruebas de Software Sistema de gestión de inventarios COBESoft S.A

Abril 2019

HISTÓRICO DE CAMBIOS Fecha 11/04/2019

Versión 1.0

Descripción Plan de Pruebas de software para el proyecto de formación.

Autor Omar Augusto Bautista Mora Edward Stiven Martinez Castiblanco Cristian Orlando Rincon Bonilla Brayan Alexis Jimenez Lopez

Índice 1.1.

Objetivos y tareas 4 1.1.1.

Objetivos

1.1.2.

Tareas 4

4

1.2.

Audiencia prevista 4

1.3.

Referencias

2.1.

Ítems a probar (funciones)

2.2.

Cuestiones de riesgo 6

2.3.

Características a probar

2.4.

Características que no se van a probar 8

2.5.

Enfoque (estrategia)

8

3.1.

Criterios de entrada

9

3.2.

Criterios de salida 9

3.3.

Criterios de suspensión

3.4.

Criterios de reanudación 10

3.5.

Criterios de éxito y fallo

10

4.1.

Estrategia de pruebas

12

5 6

7

9

4.1.1. Pruebas Unitarias 12 4.1.1.1 Plan de pruebas unitarias 12 4.1.2 Pruebas de Compatibilidad 13 4.1.3. Pruebas de Aceptación 15 5.1.

Planificación

5.2.

Recursos

16

18

5.2.1.

Hardware

18

5.2.2.

Software

19

5.2.2.1. 5.2.3.

Herramientas

19

Dotación de personal 20

5.2.3.1.

Responsabilidades 20

6.1 Revisión del plan de pruebas

21

1.

INTRODUCCIÓN

El presente plan de pruebas busca aplicarse al proyecto de formación del grupo GAES 13, “Sistema de gestión de inventarios para empresas comerciales de venta al por menor en Cundinamarca”, desarrollado como un sistema de información web, en el cual se administrará la información de productos, proveedores, clientes, movimientos de productos para la gestión de inventario, administración de roles de usuarios y generación de reportes para análisis del negocio. Se tuvieron en cuenta 5 requerimientos a validar del sistema de información: 1. Gestionar la información de productos. 2. Gestionar los movimientos de entrada (compra) y salida (venta) de productos. 3. Gestionar la información de proveedores. 4. Gestionar las existencias de productos para registro en el inventario. 5. Gestionar los roles de usuario para acceso al sistema de información.

1.1. 1.1.1.

OBJETIVOS Y TAREAS Objetivos



Desarrollar conceptos de pruebas de software aplicados a requerimientos del sistema de información.



Implementar casos de pruebas para identificar fallas potenciales en el sistema de información.



Establecer los roles en el equipo de desarrollo del proyecto para llevar a cabo las pruebas necesarias.



Aplicar técnicas tradicionales de pruebas de software como son las pruebas de caja negra y caja blanca para identificar errores lógicos.

1.1.2.

Tareas

El informe de pruebas que se presentará contendrá la aplicación de técnicas de prueba de condición, técnicas de prueba de equivalencia y técnicas de análisis de valores límite sobre funciones base que son necesarias para cumplir los requerimientos del sistema de información.

1.2.

AUDIENCIA PREVISTA

En todas las fases de pruebas se destinan los resultados a: -

Equipo de pruebas. Equipo de desarrollo.

Tanto el equipo de pruebas como el de desarrollo estará conformado por los integrantes del proyecto de formación.

1.3.

REFERENCIAS

Los documentos que se han utilizado para crear este plan, que se usarán en el desarrollo de casos de pruebas o durante la ejecución de pruebas son: Documento

Autor

Versión

Localización

Lista de requerimientos funcionales y no funcionales del Proyecto.

Grupo GAES 13

1.0

https:// drive.google.com/ open? id=129d3zBfgTLIAa1 dJGOwtaqPtfH3EPK Ss

Informe de especificación de requerimientos

Grupo GAES 13

1.0

https:// drive.google.com/ open? id=1WFvU6s7sg3gzZ IrPXtu9FtsuOYMl4wb _

Informe de Análisis del Sistema de Información

Grupo GAES 13

1.0

https:// drive.google.com/ open? id=1LOUBZCG_TkW Ci7QPHQwg9G1F1jU 8Rkcm

Plan de Construcción del Sistema de Información

Grupo GAES 13

1.0

https:// drive.google.com/file/ d/ 1fESnIa7HgmEfAdn mA95zbjp1xg6aOEjF/ view

2.

ALCANCE Y ENFOQUE

2.1.

ÍTEMS A PROBAR (FUNCIONES)

Dentro del alcance de este plan de pruebas, se aplicarán las técnicas a las siguientes funciones declaradas en el sistema de información: 

Función de registro de productos, registrarProducto().



Función de movimientos de entrada de productos, registrarOrdenCompra().



Función de movimientos de salida de productos, registrarFacturaVenta().



Función de registro de proveedores, registrarProveedor().



Función de conteo de productos en stock, conteoProductos().



Función de registro de asignación de rol de usuario, perfilUsuario().

2.2.

CUESTIONES DE RIESGO

Según los requerimientos más importantes sobre los cuales se realizaran las pruebas de software tenemos las siguientes funciones que son críticas para la ejecución del sistema de información: 

Función que gestiona la información de productos.



Función que gestiona los movimientos de entrada (compra) y salida (venta) de productos.



Función que gestiona la información de proveedores.



Función que gestiona las existencias de productos para registro en el inventario.



Función que gestiona los roles de usuario para acceso al sistema de información.

Es importante tener en claro los requerimientos del sistema de información establecidos en el documento llamado “Plantilla de requerimientos funcionales y no funcionales del sistema de información”. Algunos de los requerimientos que pueden presentar problemas por inconsistencias en los datos ingresados son: 

Generar las listas de ingreso y cruce de información.



Obtener listados de codificación estandarizada y registro de mercancía

2.3.

CARACTERÍSTICAS A PROBAR

Las características que se han de probar desde el punto de vista del usuario de lo que el sistema ha de hacer son las siguientes: Función Crítica a Probar

Características a probar Validar productos existentes.

registrarProducto()

existentes

registrarFacturaVenta()

registrarProveedor()

y

no

Alto

Medio Bajo

Validar campos establecidos como Alto numéricos y dentro de los rangos.

Medio Bajo

Validar existencia mínima > 0

Alto

Medio Bajo

y Alto

Medio Bajo

Validar que el producto esté en el rango Alto mínimo y máximo de existencia.

Medio Bajo

Verificar proveedor registrado

Alto

Medio Bajo

Validar valor total de la orden

Alto

Medio Bajo

Validar que el producto esté en el rango Alto mínimo y máximo de existencia.

Medio Bajo

Verificar cliente registrado.

Alto

Medio Bajo

Validar valor total de la factura

Alto

Medio Bajo

no Alto

Medio Bajo

Validar campos establecidos como Alto numéricos y dentro de los rangos.

Medio Bajo

Validar formato de correo electrónico

Medio Bajo

Validar existencia máxima > existencia mínima

registrarOrdenCompra()

Nivel de riesgo

Validar proveedor existente.

existente

>

0

y

Alto

conteoProductos()

perfilUsuario()

2.4.

Validar que el producto esté en el rango Alto mínimo y máximo de existencia.

Medio Bajo

Validar solamente productos activos

Alto

Medio Bajo

Validar usuario y contraseña existentes Alto y activos

Medio Bajo

Validar permisos a los módulos y Alto acciones permitidas a su respectivo rol

Medio Bajo

Validar campos establecidos como Alto numéricos y dentro de los rangos.

Medio Bajo

Validar formato de correo electrónico

Medio Bajo

Alto

CARACTERÍSTICAS QUE NO SE VAN A PROBAR

No se realizarán pruebas exhaustivas, ni validación de atributos de clases en librerías y complementos que serán usados en los módulos de la plataforma, esto debido a que son desarrollos de libre uso cubiertos bajo licencia y garantía de ejecución. Estos son algunos: 

Librerías de exportación a Excel, para la generación de reportes.



Librerías de representación gráfica de informes estadísticos del movimiento de productos.



Librerías para el envío de correos electrónicos, requerida para la gestión de comunicación con los usuarios.



Complementos para el mejoramiento de la interfaz.



Librerías para la ejecución de tareas programadas de copia de seguridad.

2.5.

ENFOQUE (ESTRATEGIA)

EL plan de pruebas para el sistema de gestión de inventarios para empresas comerciales de ventas al por menor en Cundinamarca, COBESoft, busca identificar la totalidad de los casos de uso planteados para el sistema y los requerimientos vinculados a estos para que se cumplan de manera satisfactoria, para cumplir este objetivo se plantea el desarrollo de las siguientes pruebas funcionales del sistema.

Pruebas unitarias, que se centran en cada componente del sistema (módulo), son implementadas en el código fuente. 

Autenticación



registro de productos



ordenes de compra



facturas de venta



registro de proveedores



conteo de productos

Pruebas de integración, que se enfocan en la construcción y diseño del software. Pruebas de validación, prueba todos los requerimientos como funcionales y cómo se comportan, también requerimientos de rendimiento son validados a medida que se realiza la construcción del software. Pruebas de sistema, se realiza la confirmación del rendimiento del sistema de información.

3.

CRITERIOS DE TRANSICIÓN

A continuación se describen los criterios requeridos para las pruebas para poder pasar de un estado a otro.

3.1.

CRITERIOS DE ENTRADA



Los resultados de las pruebas unitarias que han sido ejecutadas.



Resultados documentados y aprobados, determinando que no hay bugs bloqueantes o de alta prioridad que invaliden las pruebas de software desde el comienzo.



Entorno de pruebas listo y estable



Herramientas e información necesaria para la puesta en marcha de las pruebas que se encuentran instaladas y funcionando correctamente.



Todos los documentos de casos de prueba que se encuentran actualizados y aprobados



Equipo de trabajo para ejecutar las pruebas asignado y listo para ejecutarlas.

3.2.

CRITERIOS DE SALIDA



Se espera que todos los casos de prueba diseñados hayan sido ejecutados en forma exitosa o cancelados.



Se debe haber realizado pruebas de regresión, asegurando que los casos de prueba que han sido ejecutados y fueron exitosos permanezcan así.



Pruebas de aceptación se deben haber ejecutado sin errores, en forma exitosa y cuentan con la aprobación correspondiente.



No deben existir bugs bloqueantes.



Todos lo documentos de pruebas actualizados, revisados y aprobados.

3.3.

CRITERIOS DE SUSPENSIÓN

Teniendo en cuenta la cantidad de fallas que se puedan presentar en la ejecución de las pruebas, se validará si es necesario proceder a la suspensión de estas, realizar los cambios necesarios y nuevamente ejecutar las pruebas para reducir la cantidad de errores.

3.4.

CRITERIOS DE REANUDACIÓN

Se tendrá en cuenta si se han probado nuevamente los procesos fallidos y que funcione correctamente la mayoría para dar paso al proceso de reanudación.

3.5.

CRITERIOS DE ÉXITO Y FALLO

Teniendo en cuenta fallas en los módulos, acceso a las bases de datos, links de acceso al enlace web, cómo también la validación de los requerimientos determinarán criterios de fallo. De acuerdo a las funciones criticas a probar y sus características dependerá si el resultado exitoso de la prueba se hace efectivo.

4.

ESTRATEGIA DE PRUEBAS

El plan de pruebas de software se diseña, construye y ejecuta con el objetivo de seleccionar los componentes que se van a probar, de esta forma se busca validar y verificar que los requerimientos funcionales y no funcionales de la herramienta Sistema de Gestión de inventarios COBESoft se cumplan. Igualmente, el documento de pruebas permite continuar el proceso de trazabilidad de los documentos, de esta forma dar una correcta ejecución al proceso de ingeniería de requerimientos. Al ejecutar el plan de pruebas, es posible recopilar información sobre los posibles errores, defecto o fallas que se presenten en el prototipo de software, de esa forma es posible aplicar las correcciones pertinentes al prototipo, buscando asegurar la calidad del producto y el correcto cumplimiento de los requerimientos de la aplicación. Las pruebas para el Sistema de Gestión de inventarios COBESoft, buscan verificar que la totalidad de los Casos de Uso planteados para el sistema y los requerimientos vinculados a estos se cumplan de manera satisfactoria, para cumplir este objetivo se planteó el desarrollo de las siguientes pruebas funcionales del sistema:

4.1.

PRUEBAS UNITARIAS

Con el desarrollo de estas pruebas se busca garantizar el cumplimiento y correcto funcionamiento de cada uno de los componentes del sistema, estas pruebas se aplicarán sobre cada uno de los módulos del sistema de gestión de inventarios, y sobre cada uno de los módulos se validará que los requerimientos relacionados se cumplan de forma correcta.

4.1.1.

Plan de pruebas unitarias

Tomando como base el documento “Plan de Construcción del Sistema de Información”, donde se relacionan cada uno de los módulos de la vista de desarrollo y el documento “Informe de especificación de requerimientos” requeridos para el proyecto COBESoft. Se desarrollará la plantilla denominada Plantilla_Caso_Pruebas.xlsx, en la cual se procede a diligenciar y ejecutar para cada uno de los requerimientos del sistema COBESoft. El resultado de las pruebas unitarias realizadas se podrá verificar en el documento plantilla_casos_de_pruebas.doc. Para verificar que todos los componentes del sistema se encuentran operativos y han superado las pruebas realizadas, se procede a validar que todos los Requerimientos

vinculados a cada componente se cumplan, para de esta forma poder aprobar el proceso de desarrollo del componente. A continuación, se relaciona el modelo de la tabla resumen de aprobación de los diferentes componentes, esta tabla se construirá con base en los resultados de las pruebas unitarias:

Resumen Pruebas Unitarias Nombre Componente

Registrar Registrar Registrar Registrar Conteo Autenticación Producto Orden Factura Proveedor Productos Perfil Usuario Compra Venta

#Req. Involucrados #Req. Probados %Req. Aprobados Componente Aprobado

Una vez finalizadas las pruebas unitarias se continuará con el desarrollo de pruebas de integración para comprobar que todos los elementos unitarios que componen el software, funcionan juntos correctamente probándolos en conjunto.

4.2.

PRUEBAS DE COMPATIBILIDAD

Teniendo en cuenta la naturaleza del sistema, es decir una plataforma cliente servidor, se ejecutarán los casos de uso descritos para la aplicación en tres navegadores diferentes, verificando de esta manera que el desarrollo del sistema funcione de manera correcta en diferentes plataformas y dispositivos. Este tipo de pruebas permitirá verificar todos los módulos del sistema y garantizar su estabilidad y funcionamiento en diferentes navegadores web. Para lograr la verificación de las pruebas de compatibilidad, se ejecutará cada uno de los Casos de Uso del Sistema de Gestión de Inventarios COBESoft siguiendo el flujo normal del Caso de Uso. Para cada caso de uso se realizo el proceso completo en tres navegadores distintos, las especificaciones se encuentran a continuación:

Para realizar las pruebas se procederá a evaluar cada Caso de Uso dando una calificación de 1 a 10, donde 10 es el valor más alto, luego se procederá a promediar las puntuaciones y para los Casos de Uso que obtengan un puntaje superior a 8 se considerará aprobada la prueba.

Navegadores Utilizados Caso de Uso

Descripción

UC-01 Registro y actualización de Productos UC-02 Registro y actualización de Proveedores UC-03 Registro y gestión de Compras UC-04 Registro y Gestión de Ventas UC-05 Control Conteo de productos UC-06 Registro y Gestión de Usuarios

Google Mozilla Opera Chrome Firefox Browser Android

Total

4.3.

PRUEBAS DE ACEPTACIÓN

Las pruebas de aceptación buscan validar con el usuario del sistema que la totalidad de los casos de uso, se ejecutarán y completarán en el prototipo de la aplicación, para lograr este objetivo, se diseña el formato de seguimiento de Casos de Uso, este será diligenciado por el personal designado por las Empresas Comerciales de los municipio de Cundinamarca y evaluará si el comportamiento del sistema es el deseado. Se deberá verificar el documento de Aceptación del sistema, firmado por el representante de la empresa comercial, los resultados de esta prueba se debe plasmar en la siguiente tabla: (La escala para la calificación otorgada y para la aprobación va de 1 a 10)

Caso de Uso

Descripción

UC-01

Registro y actualización de Productos

UC-02

Registro y actualización de Proveedores

UC-03

Registro y gestión de Compras

UC-04

Registro y Gestión de Ventas

UC-05

Control Conteo de productos

UC-06

Registro y Gestión de Usuarios

Calificación otorgada por el actor principal del Caso de Uso

Aprobado

5.

PLANIFICACIÓN Y RECURSOS

5.1.

PLANIFICACIÓN

Esta sección debería incluir una lista de hitos clave en las pruebas. Puede incluir: Aprobación del plan de pruebas Se establecen las condiciones que la aplicación de software debe satisfacer para ser aceptado por el cliente, se definen los estándares y comportamiento que el software debe asumir bajo escenarios particulares establecidos por el cliente. Desarrollos de la lista de casos de pruebas En esta sección se listarán todas las características que serán probadas, para ello es importante que se realice con los interesados del proyecto, los cuales nos permitirán determinar qué características se van aprobar en este plan, algunas de estas características que se pueden hablar en esta sección serían las siguientes: característica de funcionalidad, interfaz gráfica, seguridad, etc. Desarrollo de los casos de pruebas Para el desarrollo del plan de pruebas se realizará una manifestación de los alcances, los responsables y todo lo que implique el manejo de riesgos de un proceso de pruebas. Se puede realizar un plan en el cual se integren los distintos tipos de pruebas, por ejemplo, las pruebas de verificación, integración e integración. El objetivo del plan de pruebas es asegurar que el software cumpla con las especificaciones requeridas y eliminar los posibles defectos que este pudiere tener. Desarrollo de scripts de pruebas El sistema consta de tres fases generales principales: La fase de validación de parámetros, la fase de carga del script de prueba y la fase de generación de script de ejecución. A continuación, se muestran las diferentes fases: Fase 1: Validar parámetros. El funcionamiento del sistema inicia con el despliegue de la interfaz, permitiendo al usuario manipular los campos asignados tales como la Ruta de Script donde se ingresará o se seleccionará la ruta del archivo el cual posee en palabras naturales, acciones o funciones a desarrollar (Script de prueba). De igual forma se debe especificar la ruta que almacenará los log de resultados, archivo que contendrá el registro de las acciones realizadas durante la generación del script de ejecución.

Fase 2: Cargar script de prueba. Esta fase se inicia al momento que el usuario da clic en el botón “Confirmar”. Posteriormente se valida la estructura general del script de prueba mediante el cargado de este y llevando a cabo un recorrido que identifique unas características predeterminadas propias del esquema. Fase 3: Generación script de prueba. En esta fase se inicia la lectura por filas de cada paso en el script de prueba de forma que se identifique las palabras reservadas y genere el código de la acción. La anterior tarea podrá tardar dependiendo del volumen de información en cada paso, del volumen de pasos incluidos y de la complejidad de los mismos. Durante el proceso, toda actividad se registrará en el log, con el objetivo de que estos sirvan como seguimiento del control de errores del script de ejecución. Preparación del entorno de pruebas Objetivo de la prueba Asegurar la funcionalidad apropiada del objeto de prueba, incluyendo la navegación, entrada de datos, proceso y recuperación. Técnica Ejecutar los casos de uso usando datos válidos y no válidos, para verificar lo siguiente: •Se obtienen los resultados esperados cuando se usan datos válidos. •Cuando se usan datos no válidos se despliegan los mensajes de error o advertencia apropiados. •Se aplica apropiadamente cada regla del negocio. Criterio de aceptación Todas las pruebas planificadas se realizaron. Todos los defectos encontrados han sido debidamente identificados. Consideraciones especiales Dentro de lo posible se intentará realizar tests cases que sean automáticos, de manera de poder reproducirlos para realizar los tests de regresión. Esto no es fácil dado que se cuenta con una interfaz web que correrá sobre varios browsers de internet y el armado de tests cases automatizados es más complejo que el manual.

Fechas de ejecución de pruebas Documentar el plazo en el cual la interfaz web se va a probar estará disponible para pruebas y el tiempo estimado para ejecutar los casos de prueba.

5.2. 5.2.1.

RECURSOS Hardware

5.2.2.

Software

Se hará uso del entorno integrado de desarrollo (IDE) Eclipse con los plugins que soportaránadecuadamente los lenguajes para desarrollo web de lado tanto del cliente (JavaScript), como del servidor (PHP), junto a los lenguajes de marcado HTML y de presentación CSS y el framework Laravel para PHP. La base de datos se creará en haciendo uso de sistema de gestión de bases de datos MySQL Herramientas Se pueden escribir las propias pruebas, pero al convertirse en un procesos tedioso y que consume mucho tiempo al necesitarse realizar muchas tareas repetitivas, las pruebas se pueden automatizar, de este modo se utilizará mejor el tiempo en la creación de la lógica para las pruebas. Se utilizará el framework PHPUnit para las pruebas unitarias, en las que se tomarán pequeñas porciones del código y se probarán una por una, permitiendo un desarrollo guiado por pruebas de software. Para las pruebas funcionales y de aceptación se integrará al framework de desarrollo Laravel, la herramienta Codeception, que permite un desarrollo guiado por el comportamiento, en el que se presentarán las pruebas en lenguaje no técnico (evitando presentar directamente el código PHP), siendo de este modo más legible por el usuario.

5.2.3.

Dotación de personal

Responsabilidades Líder de pruebas: 

Define las actividades de pruebas al resto del equipo.



Tiene a cargo todas las responsabilidades de la planeación de pruebas.



Verifica que el equipo cuente con todos los recursos necesarios para ejecutar las actividades de pruebas.



Verifica que las pruebas vayan al ritmo del desarrollo del desarrollo del software en todas las fases.



Prepara el reporte de estado de las actividades de prueba.



Se relaciona directamente con los clientes.

Ingenieros de pruebas (Asegurador de la calidad de pruebas) 

Lee todos los documentos y entiende lo que necesita ser probado y cómo se deben realizar las pruebas.



Informa al líder de todos los recursos que pueda requerir para llevar a cabo las pruebas.



Desarrolla los casos de prueba, y da prioridad a las actividades de prueba.



Ejecuta todos los casos de prueba y reporta defectos, definiendo severidad y prioridad de cada defecto.



Lleva a cabo pruebas de regresión cada vez que los cambios son hechos en el código para arreglar los defectos.

Verificador externo 

Representante que provee la empresa comercial para dar dar calificación en las pruebas de aceptación.



Comunica los detalles que percibe en la ejecución del prototipo para proceder inmediatamente en la corrección de defectos o implementar mejoras.

6.

REVISIÓN DEL PLAN DE PRUEBAS

Las revisiones permiten la detección y corrección temprana de posibles defectos así como la reducción de tiempo y dinero invertido en el desarrollo y pruebas de software. Los defectos típicos que se pueden encontrar en las revisiones son: → Defectos de requisitos. → Desviaciones de los estándares. → Defectos de diseño. → Especificaciones de interfaz incorrectas. Dependiendo del grado de formalidad se tiene los siguientes tipos de revisiones: Revisión informal, en la que los revisores carecen de instrucciones escritas, los resultados de las mismas no tienen porque estar documentados y el objetivo principal es obtener defectos de forma barata. Normalmente este tipo de revisiones se llevan a cabo por parte del líder técnico de los diseños y el código. Revisión guiada, Estas revisiones pueden variar desde muy formales a bastante informales. Son llevadas acabo por el autor de un documento del proyecto y el objetivo principal es encontrar defectos y establecer un entendimiento común. Revisión técnica, pueden variar desde muy formal hasta muy informal. Los objetivos de estas revisiones son debatir, tomar decisiones, evaluar alternativas, resolver problemas técnicos, comprobar la conformidad con las especificaciones, estándares y normativas y se centrarán en alcanzar un consenso. Es un proceso documentado donde se realizará un informe de revisión. Inspección, es la técnica de revisión más formal. Se basa en el examen visual de documentos para detectar defectos como puede ser el no cumplimiento de estándares de desarrollo. Es un proceso documentado e incluye recopilación de métricas y un informe con una lista de conclusiones. Todas las revisiones tendrán objetivos claros y contarán con las personas adecuadas para cada una de ellas. Existen tres tipos diferentes de personas involucradas en las revisiones: 

Revisor: Persona involucrada en la revisión, anomalías del producto o proceso bajo revisión.

identificando

las posibles



Escriba: Persona que registrará en un acta cada defecto y sugerencia para la mejora durante revisión.



Moderador: Principal persona responsable de una inspección u otro proceso de revisión que mediará entre los distintos punto de vista.

7.

BIBLIOGRAFÍA

Dinesh Thakur. (2012). Software Testing Strategies - Types of Software Testing Strategies. Recuperado 10 Abril 2019, de E Computer Notes Sitio web: http://ecomputernotes.com/software-engineering/software-testing-strategies. STC Admin. (2015). Difference between Acceptance Criteria Vs Acceptance Tests. Recuperado 10 Abril 2019, de softwaretestingclass.com Sitio web: https://www.softwaretestingclass.com/difference-between-acceptance-criteria-vsacceptance-tests/ Huddle Group S.A.. (2010). Proceso Fundamental de las Pruebas de Software. Recuperado 11 Abril 2019, de Huddle Group S.A. Sitio web: https://issuu.com/ojo_critico/docs/procesotesting Fernando Ch. Ga.. (2017). Plan de Pruebas de Software. Recuperado 12 Abril 2019, de mundotesting.com Sitio web: https://mundotesting.com/plan-de-pruebas-de-software/#Criterios_de_suspension_y_reanud acion pmoinformatica.com. (2016). Pruebas de software: 10 pasos para elaborar el plan de pruebas. Recuperado 12 Abril 2019, de pmoinformatica.com Sitio web: http://www.pmoinformatica.com/2016/01/elaborar-plan-pruebas-software.html