PLAN DE PRUEBAS

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

Abril 2019
HISTÓRICO DE CAMBIOS

Fecha Versión Descripción Autor

11/04/2019 1.0 Plan de Pruebas de Omar Augusto Bautista Mora
software para el proyecto Edward Stiven Martinez Castiblanco
de formación. Cristian Orlando Rincon Bonilla
Brayan Alexis Jimenez Lopez
Índice
1.1. Objetivos y tareas 4
1.1.1. Objetivos 4
1.1.2. Tareas 4
1.2. Audiencia prevista 4
1.3. Referencias 5
2.1. Ítems a probar (funciones) 6
2.2. Cuestiones de riesgo 6
2.3. Características a probar 7
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 9
3.4. Criterios de reanudación 10
3.5. Criterios de éxito y fallo 10
4.1. Estrategia de pruebas 12

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 16
5.2. Recursos 18
5.2.1. Hardware 18
5.2.2. Software 19
5.2.2.1. Herramientas 19
5.2.3. 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. OBJETIVOS Y TAREAS

1.1.1. 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 Grupo GAES 13 1.0 https://

requerimientos drive.google.com/
funcionales y no open?
funcionales del id=129d3zBfgTLIAa1
Proyecto. dJGOwtaqPtfH3EPK
Ss

Informe de Grupo GAES 13 1.0 https://

especificación de drive.google.com/
requerimientos open?
id=1WFvU6s7sg3gzZ
IrPXtu9FtsuOYMl4wb
_

Informe de Análisis Grupo GAES 13 1.0 https://

del Sistema de drive.google.com/
Información open?
id=1LOUBZCG_TkW
Ci7QPHQwg9G1F1jU
8Rkcm

Plan de Grupo GAES 13 1.0 https://

Construcción del drive.google.com/file/
Sistema de d/
Información 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 Nivel de riesgo

Validar productos existentes y no Alto Medio Bajo

existentes.

Validar campos establecidos como Alto Medio Bajo

registrarProducto()
numéricos y dentro de los rangos.

Validar existencia mínima > 0 Alto Medio Bajo

Validar existencia máxima > 0 y Alto Medio Bajo

> existencia mínima

Validar que el producto esté en el rango Alto Medio Bajo

mínimo y máximo de existencia.
registrarOrdenCompra()
Verificar proveedor registrado Alto Medio Bajo

Validar valor total de la orden Alto Medio Bajo

Validar que el producto esté en el rango Alto Medio Bajo

mínimo y máximo de existencia.
registrarFacturaVenta()
Verificar cliente registrado. Alto Medio Bajo

Validar valor total de la factura Alto Medio Bajo

Validar proveedor existente y no Alto Medio Bajo

existente.
registrarProveedor()
Validar campos establecidos como Alto Medio Bajo
numéricos y dentro de los rangos.

Validar formato de correo electrónico Alto Medio Bajo

 Validar que el producto esté en el rango Alto Medio Bajo
mínimo y máximo de existencia.
conteoProductos()
Validar solamente productos activos Alto Medio Bajo

Validar usuario y contraseña existentes Alto Medio Bajo

y activos

Validar permisos a los módulos y Alto Medio Bajo

perfilUsuario()
acciones permitidas a su respectivo rol

Validar campos establecidos como Alto Medio Bajo

numéricos y dentro de los rangos.

Validar formato de correo electrónico Alto Medio Bajo

2.4. 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 Registrar Registrar Registrar Registrar Conteo

Autenticación
Componente 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
Descripción Google Total
de Uso Mozilla Opera
Chrome -
Firefox Browser
Android

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

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)

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

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

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. RECURSOS

5.2.1. 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, identificando las posibles

anomalías del producto o proceso bajo revisión.

 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-vs-
acceptance-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