Anexos Aplicación de Inspecciones y Pruebas de Software

SERVICIO NACIONAL DE APRENDIZAJE SENA
CENTRO TECNOLÓGICO DE GESTIÓN INDUSTRIAL

TECNOLOGIA EN ANÁLISIS Y DESARROLLO DE SISTEMAS DE
INFORMACIÓN
Anexo No. 1
MIPS-001 FORMATO HISTORIA DE ERROR DETECTADO EN INSPECCIÓN
Sección No. 1: Información Diligenciada en la fase de Revisión Individual

Revisión Individual Realizada por Scrum Master
Carmelo Valencia
Identificador del Ítem Inspeccionado: Acceso al sistema de información.
<identificador único del documento o - Acceso 1.1 Validación de usuario
código fuente sometido a inspección> - Acceso 1.2 Recuperación de
contraseña
Localización del Error: <listar todas
las ocurrencias>
Descripción del Error:
Este tipos de error se soluciona…..
Sección No. 2: Información Diligenciada en la fase de Reunión de

Inspección
No. de Error: <consecutivo Fecha
Asignado por el administrador>
Decisión Tomada: Gravedad Categoría
Requiere corrección/ Fatal Omisión
justificación del Autor
Equivocación
Duplicado de Error No. Serio Redundancia
No es error Menor Mal entendido
Sugerencia
Tipo Origen
Lógica Requisitos
Interface Diseño Arquitectónico
Definición de Datos Diseño Detallado
Documentación Código
Otro Corrección error Número
¿Cuál?
INFORMACIÓN
Sección No. 3: Información Diligenciada en la fase de Corrección de

Errores
Corregido Si No
Tratamiento dado al Error
En caso de no haber
sido corregido,
justifíquelo:
Sí el Error fue Corregido, diligencie las siguientes casillas:
Sección No.
Descripción 4: corrección:
de la Información Diligenciada en la fase de Verificación de
Correcciones
(Aprobación de la Corrección o de la justificación de la no corrección)
Aprobada Rechazada Requiere
reinspección
Horas
Observaciones: Fecha de Cambio Número de
invertidas del ítem que Versión del
incorpora la Producto
Corrección que
Incorpora la
Firma del Administrador: Fecha:
Corrección
Otros Ítems Cambiados en la Corrección: <listar otros ítems diferentes al ítem
inspeccionado, que fueron modificados al hacer la corrección>
INFORMACIÓN
Anexo No. 2
MIPS-002 FORMATO DEL REPORTE DE REVISIÓN INDIVIDUAL
Id. Ítem Inspeccionado: <identificador único del Fecha

documento ó código fuente sometido a inspección>
Nombre de quien hace la inspección
Rol desempeñado en la inspección
Administra Inspector compañero de proyecto Inspector
dor del autor
miembro de otro
proyecto
Número de Errores/Problemas Horas invertidas
Reportados
INFORMACIÓN
Anexo No. 3
MIPS-003 FORMATO DEL REPORTE FINAL DE INSPECCIÓN
Sección No. 1: Información del ítem Inspeccionado

Id. Ítem Inspeccionado: <identificador
único del documento ó código fuente
sometido a inspección>
Nombre Ítem Inspeccionado: <nombre
del documento o código fuente sometido
a inspección>
Tamaño: <número de líneas de código
(LDC) o páginas del ítem
inspeccionado>
Autor
Proyecto al que pertenece
Sección No. 2: Información Consolidada de la Inspección

Fecha de la Administrado
inspección r
Inspector No. 1
Inspector No. 2
Tipo de Inspección Horas-Hombre Consumidas
Sí hubo reinspección, las horas-hombre
respectivas se distribuyen entre las fases
aquí mencionadas
Requisitos Preparación de Inspección
Diseño Arquitectónico Revisión Individual
Diseño Detallado Reunión de Inspección
Código Corrección de Errores
Errores Verificación de Correcciones
Total errores detectados Análisis Causal de Errores
Total errores corregidos Total
Sección No. 3: Propuesta para Prevenir los mismos Errores en el Futuro

Descripción de Acciones Propuestas:
INFORMACIÓN
Anexo No. 4
MIPS-004 LISTA DE CHEQUEO PARA EL DOCUMENTO DE

ESPECIFICACIÓN DE REQUISITOS
Revisado por Cargo o rol

Fecha Sitio
Nombre del
proyecto
Descripción:
REVISIÓN DEL CONTENIDO GENERAL DEL DOCUMENTO

ASPECTO O ELEMENTO A VERIFICAR SI NO NO OBSERVACIONE
APLIC S
A
1. Introducción
1.1. Propósito
1.2. Ámbito o alcance
1.3. Definiciones, siglas y abreviaturas
1.4. Referencias
1.5. Apreciación Global del documento
2. Descripción general
2.1. Perspectiva del producto
2.2. Funciones del producto
2.3. Características de los usuarios
2.4. Restricciones
2.5. Suposiciones y dependencias
2.6. Requisitos futuros
3. Requisitos Específicos
3.1. Interfaces Externas
3.1.1 Interfaces del Sistema
3.1.2 Interfaces del Usuario
3.1.3 Interfaces del Hardware
3.1.4. Interfaces del Software
3.1.5. Interfaces de Comunicaciones
3.2. Funciones
3.3. Requisitos de rendimiento
3.4. Requisitos de datos
3.5 Restricciones de diseño
3.6. Atributos del sistema
3.6.1. Funcionalidad
3.6.1.1. Adecuación
3.6.1.2. Exactitud
INFORMACIÓN
3.6.1.3. Interoperabilidad
3.6.1.4. Seguridad de acceso
3.6.1.5. Cumplimiento funcional
3.6.2. Fiabilidad
3.6.2.1. Madurez
3.6.2.2. Tolerancia a fallos
3.6.2.3. Capacidad de recuperación
3.6.2.4. Cumplimiento de la fiabilidad
3.6.3. Usabilidad
3.6.3.1. Capacidad para ser entendido
3.6.3.2. Capacidad para ser aprendido
3.6.3.3. Capacidad para ser operado
3.6.3.4. Capacidad de atracción
3.6.3.5. Cumplimiento de la usabilidad
3.6.4. Eficiencia
3.6.4.1. Comportamiento temporal
3.6.4.2. Utilización de recursos
3.6.4.3. Cumplimiento de la eficiencia
3.6.5. Mantenibilidad
3.6.5.1. Capacidad de ser analizado
3.6.5.2. Capacidad de ser cambiado
3.6.5.3. Estabilidad
3.6.5.4. Capacidad de ser probado
3.6.5.5 Cumplimiento de la mantenibilidad
3.6.6. Portabilidad
3.6.6.1. Adaptabilidad
3.6.6.2. Instalabilidad
3.6.6.3. Coexistencia
3.6.6.4. Capacidad para reemplazar
3.6.6.5. Cumplimiento de la portabilidad
3.6.7. Calidad de uso
3.6.7.1. Efectividad
3.6.7.2. Productividad
3.6.7.3. Seguridad Física
3.6.7.4 Satisfacción
3.7. Otros requisitos
4. Apéndices
INFORMACIÓN
Observaciones Generales:
FIRMA DEL REVISOR :

INFORMACIÓN
Anexo No. 5
MIPS-005 LISTA DE CHEQUEO DE CADA REQUISITO

Fecha Sitio
Nombre del
proyecto
Nombre del
Requisito
Descripción del requisito:
REVISIÓN DEL REQUISITO

APLIC S
A
1. El requisito esta formulado de forma
clara, concisa y no ambigua.
2. El requisito tiene “dueño”.
3. El requisito está cuantificado
4. El requisito es verificable
5. El requisito es consistente o no tiene
conflictos con otros requisitos.
6. Volatilidad del requisito
6.1. Puede cambiar el requisito
6.2. Puede generalizarse para incluir
posibles cambios futuros
7. Documentación del requisito
7.1. Casos de usos
7.2. Diagramas de secuencia
7.3. Especificación de casos de uso
7.4. Otros documentos
INFORMACIÓN
FIRMA DEL REVISOR :

INFORMACIÓN
Anexo No. 6
MIPS-006 FORMATO DE EVALUACIÓN GLOBAL DEL

DOCUMENTO DE ESPECIFICACIÓN DE REQUISITOS

Fecha Sitio
Nombre del
proyecto
Descripción:
EVALUACIÓN GENERAL
Apreciación general sobre el documento de especificación de requisitos,
respecto a los siguientes aspectos
Correcto
Inequívoco
Completo
Consistente
Comprobable
Modificable
Identificable
INFORMACIÓN
Observaciones Finales
FIRMA DEL REVISOR :

INFORMACIÓN
Anexo No. 7

PLANEACIÓN DE PRUEBAS

Fecha Sitio
Nombre del
proyecto
Descripción:
REVISIÓN DEL CONTENIDO GENERAL DEL DOCUMENTO

APLIC S
A
1. Estrategia de pruebas
1.1. Definición de la estrategia de pruebas y
de sus fases correspondientes.
1.2. Definición técnicas de diseño de
pruebas
1.3. Definición de personal y experiencia de
pruebas requerido
1.4. Definición de la cobertura de las
pruebas
2. Cronograma
2.1. Definición detallada del Cronograma
2.2. Priorización de las pruebas y criterios
utilizados
2.3. Restricciones consideradas de tiempo,
personal y presupuesto
3. Adquisición de datos de prueba

3.1. Diccionario de Datos de pruebas
3.2. Técnicas a utilizar para definir datos de
pruebas (Cobertura de flujo de datos,
Pruebas de condición límite o frontera)
3.4. Definición de la Base de Datos de
prueba, que incluye los aspectos de
profundidad, variedad, alcance e integridad
de los datos.
4. Ambiente de Pruebas
4.1. Definición del Software requerido para
las pruebas
4.2. Definición del Hardware requerido para
INFORMACIÓN
las pruebas
4.3. Determinación del recurso humano
requerido para las pruebas
4.4. Definición de otros recursos requeridos
para las pruebas
4.5. Definición de mecanismos de respaldo
(Back-up) para resultados de pruebas
4.6. Presupuesto de pruebas estimado
5. Manejo de Problemas que se puedan

presentar
5.1. Manejo de productos beta o pre-
versiones
5.2. Manejo de parches o paquetes de
servicio
FIRMA DEL REVISOR :

INFORMACIÓN
Anexo No. 8
MIPS-008 LISTA DE CHEQUEO PARA PLANEACIÓN DE CADA

PRUEBA

Fecha Sitio
Nombre del
proyecto
Nombre de la
prueba
REVISIÓN DE LA PRUEBA
APLIC S
A
1. Información general de la prueba
1.2. Técnica de prueba (Caja blanca, caja
negra)
1.3. Estrategia de prueba
1.4. Tipo de prueba (Unidad, integración,
sistema, validación)
1.3. Localización de la prueba (donde se
hará)
1.4. Fecha y hora de la prueba
1.5. Responsable(s) de la aplicación de la
prueba
2. Descripción de la prueba
2.1. Datos de entrada
2.2. Datos de salida o resultados esperados
2.3. Procedimiento para realizar la prueba
Observaciones Generales :
FIRMA DEL REVISOR :

INFORMACIÓN
Anexo No. 9
MIPS-009 FORMATO DE CASOS DE PRUEBA
CASOS DE PRUEBA
Identificación del
ítem probado
Preparado por
Tipo de prueba: Unidad Integración Sistema Aceptación
Técnica de prueba: Caja blanca Caja negra
CASO No. 1
Propósito de Funcionalidad Robustez Frontera Tolerancia
la prueba: a Fallas
Objetivo de la prueba
Pasos de la prueba
<paso 1>
<paso 2>
<paso n>
Criterios de aceptación Si / No
<Criterio 1> Si o No cumple
<Criterio 2>
<Criterio 3>
<Criterio n>
Observaciones: (Escriba el detalle de las fallas que se presentaron en la
ejecución de la prueba)
CASO No. 2
Propósito de Funcionalidad Robustez Frontera Tolerancia
la prueba: a Fallas
Pasos de la prueba
<paso 1>
<paso 2>
<paso n>
<Criterio 1> Si o No cumple
<Criterio 2>
<Criterio 3>
<Criterio n>
INFORMACIÓN
CASO No. 3
RobustezFronteraTolerancia a FallasPropósito de la prueba:

Objetivo de la
pruebaFuncio
nalidad
Pasos de la prueba
<paso 1>
<paso 2>
<paso n>
Criterios de aceptación
Si / No<Criterio 1> Si o No cumple
<Criterio 2>
<Criterio 3>
<Criterio n>
Observaciones: (Escriba el detalle de las fallas que se
presentaron en la ejecución de la prueba)
INFORMACIÓN
Anexo No. 10
EJEMPLO DE CASOS DE PRUEBA DE ACEPTACIÓN Y DEL

SISTEMA
En este ejemplo se muestran cinco casos de prueba para el

requisito de “Asignar nota a estudiante”. Cada uno tiene su propósito y
su objetivo.
CASOS DE PRUEBA
Identificación SC-008 Asignar nota a Estudiante
ítem probado
Preparado por Pedro Pérez
Tipo de prueba: Unidad Integración Sistema X Aceptación
Técnica de Caja blanca Caja negra X
prueba:
CASO No. 1
Propósito de Funcionalidad X Robustez Frontera Tolerancia
la prueba: a Fallas
Probar la funcionalidad de la aplicación al ingresar una nota válida a un estudiante
Pasos de la prueba
- Ejecute la aplicación de cursos
- En el menú principal seleccione la opción de inscribir estudiante en un curso
- Cuando el sistema solicite el período académico, ingrese 200520
Ingrese los siguientes datos
- Código del estudiante: 2
- Curso a inscribir: matemáticas
- Guarde los cambios
- En el menú principal seleccione la opción ingresar nota definitiva
- Nota definitiva: 3.0
- Guarde los datos ingresados
- En el menú principal seleccione consultar notas de un estudiante
- Observe si los datos que acabó de ingresar están en la consulta
¿El estudiante con los datos de período académico, cursos
inscritos y nota definitiva que se ingresaron aparece en la
consulta?
INFORMACIÓN
¿Se presentó alguna falla en la ejecución de esta prueba?

CASO No. 2
la prueba: a Fallas
Probar la funcionalidad del método ingresar nota de un estudiante cuando no se ha
inscrito en el curso
Pasos de la prueba
¿Salió algún mensaje de error al tratar de ingresar la nota a este
estudiante?
¿En la consulta se pudieron observar los datos ingresados?
INFORMACIÓN
CASO No. 3
Propósito de Funcionalidad Robustez X Frontera Tolerancia X
la prueba: a Fallas
Probar el método ingresar nota de un estudiante cuando la nota es inválida en
cuanto al rango inferior
Pasos de la prueba
- Nota definitiva: -1
inscritos y nota definitiva que se ingresaron aparece en la
consulta?
¿El sistema mostró un mensaje de rango de nota inválida?
¿El sistema le permitió corregir la nota?
¿Se presentó otra falla en la ejecución de esta prueba?

INFORMACIÓN
CASO No. 4
la prueba: a Fallas
cuanto al rango superior
Pasos de la prueba
- Nota definitiva: 6
inscritos y nota definitiva que se ingresaron apareció en la
consulta?
¿El sistema mostró un mensaje de rango de nota inválida?

INFORMACIÓN
CASO No. 5
la prueba: a Fallas
cuanto a tipo de dato
Pasos de la prueba
- Nota definitiva: as
consulta?
¿El sistema mostró un mensaje de nota inválida?

INFORMACIÓN
Anexo No. 11
MIPS-010 LISTA DE CHEQUEO PARA INSPECCIONAR LOS

CASOS DE PRUEBA DE ACEPTACIÓN Y DEL SISTEMA

Fecha Sitio
Nombre del
proyecto
Identificación del
caso de prueba
Descripción del
caso de prueba
REVISIÓN DEL CASO DE PRUEBA

APLIC S
A
1. Encabezado del caso de prueba
1.1. El documento tiene una clara
identificación del ítem probado.
1.2. Se especifica el nombre de quien
preparó el caso de prueba.
1.3. Se especifica que el caso de prueba
pertenece al tipo de pruebas del Sistema y/o
Aceptación
1.4. Se especifica la técnica de prueba a
aplicar como caja negra.
2. Propósitos y objetivos del caso de prueba
2.1. El propósito de la prueba está
claramente definido.
2.2. El objetivo de la prueba está claramente
definido.
3. Pasos de la prueba
3.1. Los pasos de la prueba se especificaron
claramente.
3.2. Los pasos de la prueba corresponden a
pruebas de aceptación y del sistema. Es
decir, sirven para comprobar que se cumple
el requisito a probar.
3.3. Los pasos de la prueba corresponden
con el propósito del caso de prueba.
con el objetivo del caso de prueba.
INFORMACIÓN
4. Criterios de aceptación
4.1. Los criterios de aceptación del caso de
prueba son claros.
prueba corresponden con el propósito de la
prueba.
prueba corresponden con el objetivo de la
prueba.
FIRMA DEL REVISOR :

INFORMACIÓN
Anexo No. 12

DISEÑO ARQUITECTÓNICO

Fecha Sitio
Nombre del
proyecto
Descripción del proyecto:
REVISIÓN DEL DOCUMENTO

APLIC S
A
1. El documento de diseño arquitectónico
está completo y ha sido desarrollado de
acuerdo al estándar preestablecido
2. El diseño arquitectónico cubre todos los
requisitos.
3. Las interfaces entre componentes
arquitectónicos están especificadas de forma
suficientemente precisa.
4. Se describen los conectores
arquitectónicos o mecanismos de
interconexión usados para comunicar los
componentes arquitectónicos.
5. El diseño arquitectónico está descrito de
forma suficientemente precisa y libre de
ambigüedades, de manera que pueda ser
construido exactamente como está descrito,
sin mal interpretarlo.
6. El diseño arquitectónico tiene el nivel de
detalle suficiente como para usarlo de base
para desarrollar casos de prueba de
integración.
7. Consideración de las características no funcionales
7.1. Eficiencia en la comunicación /
interacción entre componentes
arquitectónicos
7.2. Seguridad: autenticación, control de
acceso
7.3. Escalabilidad: limitaciones volumétricas
INFORMACIÓN
7.4. Alta Disponibilidad: componentes

redundantes para tolerancia a fallas
7.5. Confiabilidad: componentes
redundantes para detección de errores en el
software
7.6. Modificabilidad: uso apropiado de los
principios de diseño arquitectónico para
facilitar cambios futuros, tales como
ocultamiento de información, separación de
responsabilidades, abstracción.
7.7. Extensibilidad: facilidad para adicionar
nuevos componentes en el futuro.
7.8. Portabilidad:
aislamiento/encapsulamiento de
dependencias de plataforma.
7.9. Reutilizabilidad: componentes
débilmente acoplados, de forma que puedan
ser reutilizados individualmente en otros
sistemas.
7.10. Interoperabilidad: interfaces con otros
sistemas existentes o futuros.
7.11. Integrabilidad: posibilidad de construir
el sistema incrementalmente.
7.12. Pruebabilidad: facilidad para detectar,
aislar y diagnosticar errores en pruebas de
integración y pruebas del sistema.
FIRMA DEL REVISOR :

INFORMACIÓN
Anexo No. 13
EJEMPLO DE CASOS DE PRUEBA DE INTEGRACIÓN
FORMATO DE CASOS DE PRUEBA

Identificación Asignar nota a Estudiante (SC-008 ) integrado con inscripción
ítem probado de curso (SC-007)
Tipo de prueba: Unidad Integración X Sistema Aceptación
Técnica de Caja blanca Caja negra X
prueba:
CASO No. 1
la prueba: a Fallas
Probar la funcionalidad del método ingresar nota de un estudiante integrado con
inscripción de curso, ya que para poder ingresar la nota de un estudiante, éste debe
estar inscrito en un curso.
Pasos de la prueba
- Curso a inscribir: redes
consulta?
INFORMACIÓN
CASO No. 2
la prueba: a Fallas
Probar la funcionalidad del método ingresar nota de un estudiante integrado con
inscripción de curso, cuando no se ha inscrito un estudiante en un curso
Pasos de la prueba
¿Salió algún mensaje de error al tratar de ingresar la nota a este
estudiante?
¿En la consulta se pudieron observar los datos ingresados?
INFORMACIÓN
Anexo No. 14
CASOS DE PRUEBAS DE INTEGRACIÓN

Fecha Sitio
Nombre del
proyecto
Identificación del
caso de prueba
Descripción del
caso de prueba

APLIC S
A
1.1. El documento tiene una clara
identificación del ítem probado.
pertenece al tipo de pruebas de Integración.
aplicar como caja negra.
2.1. El propósito de la prueba está
2.2. El objetivo de la prueba está claramente
definido.
3.1. Los pasos de la prueba se especificaron
claramente.
3.2. ¿Los pasos de la prueba corresponden a
pruebas de integración? Es decir, sirven
para comprobar que el sistema funciona
adecuadamente al integrar los módulos que
los componen.
con el propósito del caso de prueba.
con el objetivo del caso de prueba.
prueba son claros.
INFORMACIÓN

prueba.
prueba.
FIRMA DEL REVISOR :

INFORMACIÓN
Anexo No. 15
MIPS-013 LISTA DE CHEQUEO DEL DOCUMENTO DE DISEÑO

DETALLADO

Fecha Sitio
Nombre del
proyecto
Descripción del proyecto:

APLIC S
A
1. ¿El documento de diseño detallado está
completo y ha sido desarrollado de acuerdo
al estándar definido?
2. ¿El diseño detallado es suficientemente
preciso como para ser codificado
correctamente?
3. ¿El diseño detallado es suficientemente
preciso como para usarlo de base para
desarrollar casos de prueba de unidad?
4. Para cada función, rutina o procedimiento especificado en el diseño detallado
verificar lo siguiente:
4.1 ¿La función tiene un único proceso?
4.2 ¿La función es legible/entendible en el
punto de llamada?
4.3 ¿Los códigos de error retornados o
excepciones generadas están
completamente especificados?
4.4 ¿La lógica de procesamiento está
especificada sin ambigüedad?
4.5 ¿Las precondiciones y post-condiciones
están completas y claramente
especificadas?
4.6 ¿La descripción de los parámetros es
suficientemente clara para los que van a
llamar la función?
4.7 ¿Los tipos o significados de los
parámetros y valores retornados no
propician el cometer errores al llamar la
función?
INFORMACIÓN
FIRMA DEL REVISOR:
Anexo No. 16
EJEMPLO CASOS DE PRUEBA DE UNIDAD
FORMATO DE CASOS DE PRUEBA

Identificación SC-001 Ingresar Estudiante
ítem probado
Tipo de prueba: Unidad X Integración Sistema Aceptación
Técnica de Caja blanca X Caja negra
prueba:
CASO No. 1
la prueba: a Fallas
Probar la funcionalidad del método ingresar un estudiante cuando todos los datos
de entrada son correctos
Pasos de la prueba
- Marque un “Break” en la línea que inicia el método de ingresar un estudiante
- Ejecute la aplicación de cursos en modo DEBUG
- Active la ventana de datos de DEBUG
- Cuando el DEBUG detenga la ejecución de la aplicación, presione F7 por cada
línea de código que se ejecuta y compruebe en la ventana de datos de variables que
se van leyendo almacenen correctamente los valores digitados.
- Cuando el sistema solicite el código del estudiante digite 1
- Nombre: Jorge
- Apellido : Suárez
- Fecha de nacimiento: 27/02/1970
INFORMACIÓN
- Ejecute nuevamente la aplicación pero en modo normal, no DEBUG

- Elija opción de consultar estudiantes
¿Los datos que se ingresaron del estudiante aparecen en la
consulta?
¿Los datos ingresados aparecieron en la ventana de datos
asignados correctamente en las variables que debían asignarse?
¿Se presentó alguna falla en la ejecución del método ingresar
estudiante?
CASO No. 2
la prueba: a Fallas
Probar la funcionalidad del método ingresar un estudiante cuando ya existe un
estudiante con el código a ingresar
Pasos de la prueba
- Nombre: Marta
- Apellido : Luna
consulta?
¿Se lanzó la excepción de que ya existía un estudiante creado con
ese código?
¿Se presentó otra falla en la ejecución del método ingresar
estudiante?
INFORMACIÓN
CASO No. 3
Propósito de Funcionalidad Robustez X Frontera Tolerancia
la prueba: a Fallas
Probar el método ingresar un estudiante cuando la fecha tiene un dato inválido
Pasos de la prueba
- Nombre: Luis
- Apellido : Mesa
consulta?
¿Se lanzó la excepción de fecha inválida?
¿Se presentó otra falla en la ejecución del método ingresar
estudiante?
INFORMACIÓN
INFORMACIÓN
Anexo No. 17

CASOS DE PRUEBAS DE UNIDAD

Fecha Sitio
Nombre del
proyecto
Identificación del
caso de prueba
Descripción del
caso de prueba
APLIC S
A
1.1. El documento identifica claramente el
ítem probado.
pertenece al tipo de pruebas de Integración.
aplicar
2.1. El propósito de la prueba esta
2.2. El objetivo de la prueba esta claramente
definido.
3.1 Los pasos de la prueba se especificaron
claramente.
3.2 ¿Los pasos de la prueba corresponden a
pruebas de unidad? Es decir, sirven para
comprobar que las unidades del software
funcionan correctamente.
3.3 Los pasos de la prueba corresponden con
el propósito del caso de prueba.
3.4 Los pasos de la prueba corresponden con
el objetivo del caso de prueba.
INFORMACIÓN

prueba son claros.
prueba.
prueba.
FIRMA DEL REVISOR

INFORMACIÓN
Anexo No. 18
MIPS-015 LISTAS DE CHEQUEO DE ESTÁNDARES DE

PRESENTACIÓN Y FUNCIONALIDAD DE LA APLICACIÓN
PARA FORMAS

Fecha Sitio
Nombre del
proyecto
Nombre de la
Forma
Descripción de la forma:
REVISIÓN DE ESTÁNDARES DE PRESENTACIÓN

ASPECTO O ELEMENTO A REVISAR SI NO NO OBSERVACION
APLIC ES
A
1. ¿Están claramente definidos los bloques o
módulos de información?
Hace referencia a sí es posible visualizar de
manera clara los módulos o partes en los que
está dividida la aplicación y sí se puede ver
la función que cumplen.
2. ¿Son correctos los títulos y los
encabezados de la aplicación?
Verificar que los títulos y los encabezados
identifican realmente la forma, recordando
las normas de programación y la
mnemotecnia (hace referencia a lo que
contienen o van a contener)
3. ¿Las etiquetas de los campos son claras y
representativas?
Los nombres de las etiquetas deben ser
claros, acordes y representativos de cada
campo.
4. ¿Los campos de despliegue requeridos
están habilitados y con el color adecuado?
En cada caso deben habilitarse los campos
requeridos y deben identificarse con
claridad que están habilitados.
5. ¿Los campos de solo despliegue están
claramente identificados?
Verificar que tengan la identificación de un
INFORMACIÓN
campo de despliegue: flecha que indica la

existencia de una lista de valores o
elementos.
6. ¿Posee los colores estándar y/o los
acordados? Revisar que los colores utilizados
en cada forma sean los representativos de la
empresa, de la aplicación o lo pactado con el
cliente y/o grupo de desarrollo.
7. ¿Los campos fecha poseen el formato
dd/mm/aaaa?
Los campos fecha deben estar listos para
escribir la fecha y deben estar validados
para impedir el ingreso de una fecha
incorrecta o sin sentido.
8. ¿La forma tiene la dimensión correcta?
Visualizar la forma para poder ver su
tamaño, correspondiente a tamaño mediano
o al 100%, según sea requerido.
9. ¿La forma tiene la ubicación correcta?
La forma debe estar ubicada centrada para
facilitar su utilización, control y
visualización. De ninguna manera debe
aparecer en los extremos.
10. ¿Los campos están distribuidos de
manera lógica?
Verificar que todos los campos tengan una
distribución adecuada de acuerdo con la
periodicidad o con la frecuencia de uso,
comprobar que su distribución permita
visualizar claramente los campos de mayor
uso y mayor relevancia.
11. ¿Contiene los campos que se necesitan?
Verificar que se encuentren todos los
campos requeridos de acuerdo con lo que
cada forma deba contemplar.
12. ¿Los campos están alineados en forma
correcta?
La forma debe estar organizada y alineada
estéticamente y para facilitar su utilización.
13. ¿Las barras de Scroll tienen el ancho
adecuado?
Los scroll deben ser tamaño estándar a
menos que la forma o parte de ella donde
estén localizados sea muy pequeña, en cuyo
caso pueden ser de menor tamaño.
14. ¿Están los botones habilitados
adecuadamente para cumplir con su
función?
Verificar que cumplan con el propósito para
el cual fueron creados y que en todos los
casos cumplan la misma función.
INFORMACIÓN
15. ¿Cumplen los botones con los estándares

de toda la aplicación?
Todos los botones de la aplicación cumplen
con la forma, el color, el tamaño y demás
atributos de toda la aplicación o del
software.
REVISIÓN DE FUNCIONALIDAD
16. ¿La forma realiza la función requerida?
17. ¿Los datos de la forma cambian de
manera sincronizada?
18. ¿El manejo de la forma es fácil y rápido?
19. Cuándo se cambia el valor de un campo
de entrada ¿También se modifica el campo
de despliegue?
20. ¿El tiempo de respuesta es adecuado?
21. ¿El orden de navegación de los campos
es el correcto?
22. ¿Los mensajes de retroalimentación son
manejados adecuadamente?
23. ¿Está la forma bien documentada?
FIRMA DEL REVISOR :
Anexo No. 19
MIPS-016 LISTA DE CHEQUEO DE ESTÁNDARES DE

PRESENTACIÓN Y FUNCIONALIDAD DE LA APLICACIÓN PARA
REPORTES

Fecha Sitio
Nombre del proyecto
Nombre del Reporte
INFORMACIÓN
Descripción del Reporte:
REVISIÓN DE ESTÁNDARES DE PRESENTACIÓN

ACTIVIDAD O ELEMENTO A REVISAR SI NO NO OBSERVACION
APLIC ES
A
1. ¿El reporte tiene el nombre correcto del
sistema?
Es indispensable que en el reporte aparezca
el nombre del sistema.
2. ¿El reporte tiene los encabezados del
título y el nombre de la aplicación correcta?
3. ¿El reporte permite imprimir su fecha de
generación, sí se necesita?
4. ¿El reporte tiene el número actual, parcial
y total de páginas?
Es necesario saber cuántas páginas genera
cada documento o cada salida impresa.
5. ¿Están claramente definidos los bloques
de información?
El formato debe permitir la diferenciación de
cada bloque de información y de su
contenido.
6. ¿El reporte posee los estándares
obligatorios?
El reporte debe incluir: nombre de la
empresa o entidad, logotipo y/o logo
símbolo, NIT o número de registro o de
licencia de funcionamiento, dirección,
teléfono(s), nombre del reporte,
encabezados de cada columna y los que sean
necesarios según el tipo de documento
emitido.
7. ¿Las etiquetas de los campos son claras y
representativas?
Verificar que se cumpla y que se entienda
claramente lo enunciado en cada parte del
reporte.
8. ¿El reporte tiene los colores estándares de
la empresa o entidad?
El original debe contener los colores de la
empresa y el cliente decidirá sí se imprimen
en colores o no.
9. ¿Los campos fecha tienen el formato
dd/mm/aaaa?
Verificar que sólo tengan que digitarse los
números cuando se pida la fecha para
generar el reporte y cuando éste sea
generado.
10. ¿Se validan los campos de la fecha?
INFORMACIÓN
Evaluar que no acepte fechas incorrectas y

sin sentido cuando se pida la fecha para
generar el reporte y cuando éste sea
generado.
11. ¿Los campos están alineados en forma
correcta?
La distribución de los campos del reporte
debe ser entendida y responder a óptimos
parámetros estéticos y de presentación. Por
esta razón también deben estar alineados y
ordenados.
12. ¿Se ha utilizado la sectorización de los
campos en los reportes para incrementar su
legibilidad?
13. ¿El reporte tiene enumeradas las filas?
Para mayor seguimiento y visualización de la
información se sugiere que se enumeren. No
es obligatoria la norma.
14. ¿El reporte posee los encabezados y
logos solicitados y/o requeridos por los
estándares del software?
Verificar que se incluye: nombre de la
empresa, NIT o registro o licencia de
funcionamiento, dirección, teléfono(s), otros
que sean necesarios según el tipo de
documento.
15. ¿El reporte ha sido aprobado por
usuario?
Los reportes deben ser generados de
acuerdo con las diferentes necesidades del
cliente.
FIRMA DEL REVISOR :

INFORMACIÓN
Anexo No. 20
MIPS-017 LISTAS DE CHEQUEO DE ESTÁNDARES DE TABLAS

Fecha Sitio
Nombre del proyecto
Nombre de la tabla
Descripción de la tabla:
REVISIÓN DE ESTÁNDARES DE LAS TABLAS

APLIC ES
A
1. ¿El nombre de las tablas es correcto
según los estándares?
Verificar que cumpla con los siguientes
estándares: nombre de la tabla escrito en
singular, nombre relacionado con el
contenido.
2. ¿Cada columna está descrita en la base de
datos?
Verificar si cada columna incluye la
documentación respectiva en la base de
datos.
3. ¿Posee las llaves e índices adecuados?
Es necesario verificar que los campos
INFORMACIÓN
utilizados como llaves primarias o foráneas

son las adecuadas.
4. ¿La creación de la tabla ha tenido en
cuenta su periodicidad de uso? Se debe
evaluar con el fin de ver la rapidez en su
acceso.
FIRMA DEL REVISOR :
Anexo No. 21

FUNCIONES Y PROCEDIMIENTOS

Fecha Sitio
Nombre del proyecto
Nombre de la función o procedimiento:
Descripción:
REVISIÓN DE FUNCIONES Y PROCEDIMIENTOS

APLIC ES
A
INFORMACIÓN
1. ¿El nombre cumple con los estándares?

El nombre debe ser mnemotécnico, no
poseer más de 8 caracteres, comenzar por
letra, ¿otros?
2. ¿El código cumple con los estándares?
El código debe cumplir con los estándares
de programación como modularidad,
interrelación entre módulos, secuencia
lógica, etc.
3. ¿Está la función/ procedimiento
documentada?
Cada función, procedimiento, objeto o en
general módulo debe especificar que hace y
cuál es su función dentro de la aplicación.
4. ¿Se ha realizado el proceso de
afinamiento de las búsquedas?
Las búsquedas deben ser las necesarias,
deben cumplir con su objetivo: deben
encontrar lo buscado y deben generar la
información requerida.
5. ¿Se usan todas las variables, constantes y
parámetros? Todo lo creado debe ser
utilizado, lo que sobre debe ser eliminado.
6. ¿La asignación de valores a las variables,
constantes y parámetros tienen un
propósito?
Verificar que los procesos sean rápidos,
correctos, funcionales y con un alto
rendimiento.
7. ¿Son correctas las validaciones de
condiciones? (ciclos infinitos, división por
cero, verificación de rangos, etc.)
Revisar todos los ciclos en el límite, dentro
del límite y fuera de este, verificar que no
existan divisiones por cero y que los valores
tengan una magnitud aceptada por el tipo de
dato definido.
8. ¿Faltan validaciones?
Verificar cuales validaciones hacen falta:
condicionales, estructuras compuestas,
procedimientos, funciones…
9. ¿Se tienen en cuenta todas las
excepciones posibles?
Dentro de cada proceso o procedimiento es
necesario preguntarse qué pasaría si
ocurriera un caso diferente y verificar si la
aplicación está en capacidad de asumir
dicho caso sin descontrolarse.
10. ¿Las variables que guardan datos de
columnas de tablas se han definido de
acuerdo con ellas?
INFORMACIÓN
Para identificar cada variable y su función,

esta debe ser apropiadamente nombrada,
para ser fácilmente identificada.
11. Si se llaman otras funciones y/o
procedimientos, ¿tienen el número de
parámetros y el tipo de datos adecuado?
El número y la clase de parámetros deben
ser compatibles para no crear errores o
conflictos dentro de la aplicación.
FIRMA DEL REVISOR :

INFORMACIÓN
Anexo No. 22

PROGRAMACIÓN - CÓDIGO

Fecha Sitio
Nombre del proyecto
Descripción:
REVISIÓN DE LA PROGRAMACIÓN – CÓDIGO

APLIC ES
A
1. Código en general
1.1 ¿Está el código con los espacios
establecidos?
Verificar que el código se entienda, que esté
bien dividido, que en cada módulo o
estructura se pueda reconocer fácilmente en
el comienzo y en la terminación.
1.2 ¿Están ordenadas alfabéticamente las
constantes, las variables y los cursores?
En la documentación es importante que las
constantes y las variables estén ordenadas
alfabéticamente.
1.3 ¿Están alineados a la izquierda la
definición del tipo de dato de las
constantes y de las variables?
Este es un estándar de programación que
debe cumplirse.
2. Documentación
2.1 ¿Está toda la documentación en una
línea diferente al código que se está
documentando?
Verificar este aspecto en todo el código.
2.2 ¿Comprende la documentación de
funciones/procedimientos tres partes: una
descripción general de los que hace la
función o procedimiento (módulo), la
INFORMACIÓN
descripción de los parámetros de entrada y

la descripción de los posibles valores y/o
parámetros de salida?
3. Parámetros
3.1 ¿El nombre de los parámetros es
significativo?
Debe ser representativo y fácilmente
identificable
4. Constantes
4.1 ¿El nombre de las constantes es
significativo?
Debe ser representativo y cumplir con los
estándares de programación.
5. Variables
5.1 ¿El nombre de las variables es
significativo?
Debe ser representativo y cumplir con los
estándares de programación.
5.2 ¿Están los nombres de las constantes y
de las variables alineados a la izquierda
junto a la definición del tipo?
FIRMA DEL REVISOR:

INFORMACIÓN
Anexo No. 23
MIPS-020 LISTA DE CHEQUEO DE ESTÁNDARES DE

PRESENTACIÓN-FORMAS O VENTANAS

Fecha Sitio
Nombre del proyecto
Nombre de la forma
Descripción:
REVISIÓN DE ESTÁNDARES DE PRESENTACIÓN FORMAS

APLIC ES
A
1. Forma
¿La descripción y el título de la forma
concuerdan con los estándares?
Verificar cuáles son los estándares para las
formas.
¿La dimensión de la forma es correcta?
Esto significa que la forma o ventana debe
adaptarse a las dimensiones del monitor y
contiene de manera ordenada todo cuanto se
necesite, con los espacios suficientes.
2. Título de la forma
2.1 ¿Está el título escrito con mayúscula
inicial?
2.2 Si la forma corresponde a un solo
registro, ¿está su título escrito en singular?
2.3 Si la forma es multirregistro ¿está su
título en plural?
2.4 ¿Está localizado el título en la parte
superior izquierda de la forma?
3. Campos
INFORMACIÓN
3.1 ¿Tiene el contenido del campo la

alineación adecuada de acuerdo con su tipo
de dato?
3.2 Si existen varios campos organizados
verticalmente, ¿están alineados todos a la
izquierda?
4. Etiquetas
4.1 ¿Si la organización no es tabular, ¿están
las etiquetas situadas a la izquierda del
campo al que pertenecen?
4.2 Si la organización es tabular, ¿están
todas las etiquetas situadas en la parte
superior del campo al que pertenecen?
4.3 Si la organización es tabular, ¿están las
etiquetas centradas?
4.4 ¿Están las etiquetas escritas en
mayúscula inicial?
4.5 ¿Están las etiquetas escritas sin los dos
puntos al final?
4.6 Si existen varios campos organizados
verticalmente, ¿Están alineadas todas las
etiquetas a la derecha?
4.7 ¿Están las etiquetas formadas de manera
que no utilicen abreviaturas ni expresiones
de solicitud?
5. Listas de valores
5.1 ¿Están los descriptores alineados a la
izquierda en forma de columna?
5.2 ¿Están organizados los descriptores en
orden alfabético o numérico, según sea el
caso?
5.3 ¿Están los descriptores en mayúscula
inicial?
5.4 ¿Tienen las listas valores de posición, de
forma que no requieren ser movidas?
6. Botones
6.1 Si están ubicados horizontalmente,
¿están en la parte inferior de la pantalla?
6.2 Si están ubicados verticalmente, ¿están a
la derecha de la pantalla?
6.3 Los botones organizados verticalmente,
INFORMACIÓN
¿tienen la misma altura?

6.4 ¿Está localizada la posición más
frecuente en la izquierda?
6.5 ¿Usan los descriptores mayúscula
inicial?
6.6 ¿El ancho es suficiente para evitar el uso
de scroll horizontal.
6.7 ¿Tienen las listas de valores la posición
adecuada, de forma que no requieran ser
movidas?
6.8 ¿Incluyen puntos suspensivos si la acción
despliega otra ventana?
7. Scroll
7.1 ¿Están las barras de scroll vertical
ubicadas a la derecha?
7.2 ¿Están las barras de scroll vertical
iguales a la altura de sus campos asociados?
7.3 ¿Están las barras de scroll horizontal
ubicadas en la parte inferior?
7.4 ¿Están las barras de scroll horizontal
iguales al ancho de sus campos asociados?
7. ¿El color de las barras de scroll es el
adecuado?
8. Botones
8.1 Si están ubicados horizontalmente,
¿están en la parte inferior de la pantalla?
8.2 Si están ubicados verticalmente, ¿están a
la derecha de la pantalla?
8.3 Los botones organizados
horizontalmente, ¿tienen la misma altura?
8.4 Los botones organizados verticalmente,
¿tienen el mismo ancho?
8.5 ¿Está colocada la opción más frecuente a
la izquierda o arriba según corresponda?
8.6 ¿Usan los botones mayúscula inicial?
8.7 ¿Incluyen puntos suspensivos si la acción
despliega otra ventana?
INFORMACIÓN
FIRMA DEL REVISOR :
Anexo No. 24
MIPS-021 LISTAS DE CHEQUEO DE PROGRAMACIÓN – FORMAS

O VENTANAS

Fecha Sitio
Nombre del proyecto
Titulo de la Forma o Ventana
Descripción:
INFORMACIÓN
REVISIÓN DE ESTÁNDARES DE PROGRAMACIÓN– FORMAS

ELEMENTO A REVISAR SI NO NO OBSERVACION
Verificar que los objetos o módulos APLIC ES
cumplen con los estándares. A
1. Alertas
2. Bloques
3. Forma o reporte
4. Funciones y/o procedimientos
5. Gráficos
6. Librerías
7. Lista de valores
8. Parámetros
9. Relación
10. Variables
11. Atributos visuales
12. Ventanas
FIRMA DEL REVISOR :

INFORMACIÓN
Anexo No. 25
MIPS-022 LISTA DE CHEQUEO DE INSPECCIÓN DE CÓDIGO

PARA EL LENGUAJE DE PROGRAMACIÓN

Fecha Sitio
Nombre del proyecto
Nombre de la función o procedimiento
Descripción:
REVISIÓN DE IMPLEMENTACIÓN DEL LENGUAJE DE PROGRAMACIÓN

APLIC ES
A
1. ¿El código está escrito siguiendo el
estándar de codificación definido para el
lenguaje usado?
2. El código implementa completa y correctamente el diseño detallado correspondiente
2.1 ¿Hay funciones/procedimientos
faltantes?
2.2 ¿El código de cada
función/procedimiento es consistente con
su especificación de diseño detallado?
3. ¿Se tiene en cuenta condiciones de
frontera (valores nulos o negativos)?
4. ¿Se tienen en cuenta todas las posibles
condiciones de error?
5. Los procedimientos para cada invocación a función/procedimiento son correctos
5.1 ¿Los parámetros de entrada contienen
los valores correctos?
5.2 ¿Los parámetros de salida tienen el
tamaño y tipo correcto?
6. ¿Cada sentencia de selección es válida
(¿la cláusula “else” está asociada a la
sentencia “if” correcta?)
7. Para cada sentencia de selección múltiple (“switch” , “case of” o una sentencia con
el mismo propósito)
7.1 ¿Los casos considerados están
completos?
7.2 ¿El caso “default” se considera y se
INFORMACIÓN
utiliza correctamente?
8. Para cada ciclo (while, for, repeat o similares)
8.1 ¿El ciclo ejecuta el número correcto de
iteraciones?
8.2 ¿El ciclo no se queda en “loop” infinito?
8.3 ¿La lógica de la última iteración del ciclo
está completa y correcta?
8.4 ¿Hay algún error en la condición que
haga que se ejecute una vez más o una vez
menos de lo debido?
9. Para cada expresión matemática o booleana:
9.1 ¿La precedencia de operadores y de
paréntesis son utilizados correctamente?
9.2 ¿Las conversiones no causan pérdida de
información?
10. Todos los arreglos y cadenas:
10.1 ¿Tienen el tamaño correcto?
10.2 ¿Están inicializados correctamente?
11. Todos los apuntadores usados:
11.1 ¿Son inicializados antes de hacer
referencia a lo apuntado por ellos?
11.2 ¿Apuntan a memoria ya liberada?
12. ¿Todos los archivos abiertos son
cerrados?
13. ¿Todos los objetos creados en memoria
dinámica son liberados?
FIRMA DEL REVISOR:

INFORMACIÓN
Anexo No. 26
MIPS-023 FORMATO DE REGISTRO DE ERRORES

ENCONTRADOS EN INSPECCIÓN DE CÓDIGO
Elaborado por Cargo o rol

Fecha Sitio
Nombre del proyecto
Descripción:
Código de Localización Descripción del Error Encontrado

Error *
INFORMACIÓN
OBSERVACIONES GENERALES:
FIRMA DEL EJECUTOR DE LAS PRUEBAS:
* Códigos de Errores
Códi Nombre Descripción
go
DOC- Documentación Comentarios, mensajes, aclaraciones
SIN- Sintaxis Ortografía de los comandos, puntuación, errores de tecleo,
formato de las instrucciones
MVR Manejo de Manejo de cambios, librerías, control de versiones
- versiones
ASG- Asignación Declaraciones, identificadores duplicados, alcance y límites
de los mismos
INT- Interfaces Llamadas y referencias a procedimientos, I/O, interfaz de
usuario
VAL- Validación Mensajes de error, validaciones incorrectas.
DAT- Datos Estructuras, contenidos, inicializaciones
FUN- Funciones Defectos de lógica, puntero, ciclos, recursividad, cálculo y
funcionamiento
SIS Sistema Configuración, memoria, tiempo de respuesta
ENT- Entorno Problemas de diseño, compilación, pruebas del ambiente de
desarrollo.
INFORMACIÓN
Anexo No. 27
MIPS-024 HISTORIA DE ERROR DETECTADO EN PRUEBAS
Sección No. 1: Información Diligenciada al detectar error en las pruebas

Prueba realizada por
Identificador ítem Probado:
<identificador único del módulo,
función, procedimiento, componente,
subsistema o sistema probado>
No. del caso de prueba que detectó el
error <identificador único del caso de
prueba o casos de prueba que
permitieron detectar el error>
Descripción del Error:
Forma de reproducir el error <si no hay caso de prueba asociado, se debe especificar la
secuencia de pasos a seguir para reproducir el problema encontrado>:
Descripción de información anexa <describir los anexos incluidos con este reporte de
error, tales como archivos de log generados, print-Screens y otros tipos de información
obtenidos durante la prueba que ayudaron a diagnosticar el error>:
Sección No. 2: Información Diligenciada al hacer el diagnóstico del error

No. de Error: <consecutivo Fecha
Asignado por el equipo de pruebas>
Decisión Tomada: Gravedad Categoría
Requiere corrección/ Fatal Omisión
justificación del Autor
Equivocación
Duplicado de Error No. Serio Redundancia
No es error Menor Mal entendido
Sugerencia
Tipo Origen
Lógica Requisitos
Interface Diseño Arquitectónico

INFORMACIÓN
Definición de Datos Diseño Detallado
Documentación Código
Otro Corrección error Número
¿Cuál?
Causa del error:
Localización del error en el código y/o documentación asociada:
Sección No. 3: Información Diligenciada en la fase de Corrección de Errores

Corregido Si No
Tratamiento dado al Error
En caso de no corrección,
justifíquelo:
Si el Error fue Corregido, diligencie las siguientes casillas:
Descripción de la corrección:
Horas invertidas Fecha de Cambio Número de

del ítem que Versión del
Incorpora la Producto
Corrección que
Incorpora la
Corrección
Sección No. 4: Información Diligenciada en la fase de Verificación de

Correcciones
(Aprobación de la Corrección o de la justificación de no corrección)
Aprobada Rechazada Requiere pruebas
de regresión
Observaciones:
Firma del Probador: Fecha:
Otros ítems cambiados en la corrección:

INFORMACIÓN

Anexos Aplicación de Inspecciones y Pruebas de Software

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Anexos Aplicación de Inspecciones y Pruebas de Software

Încărcat de

Drepturi de autor:

Formate disponibile

SERVICIO NACIONAL DE APRENDIZAJE SENA

CENTRO TECNOLÓGICO DE GESTIÓN INDUSTRIAL

MIPS-001 FORMATO HISTORIA DE ERROR DETECTADO EN INSPECCIÓN

Sección No. 1: Información Diligenciada en la fase de Revisión Individual

Sección No. 2: Información Diligenciada en la fase de Reunión de

Interface Diseño Arquitectónico

Definición de Datos Diseño Detallado

Otro Corrección error Número

Sección No. 3: Información Diligenciada en la fase de Corrección de

MIPS-002 FORMATO DEL REPORTE DE REVISIÓN INDIVIDUAL

Id. Ítem Inspeccionado: <identificador único del Fecha

MIPS-003 FORMATO DEL REPORTE FINAL DE INSPECCIÓN

Sección No. 1: Información del ítem Inspeccionado

Sección No. 2: Información Consolidada de la Inspección

Sección No. 3: Propuesta para Prevenir los mismos Errores en el Futuro

MIPS-004 LISTA DE CHEQUEO PARA EL DOCUMENTO DE

Revisado por Cargo o rol

REVISIÓN DEL CONTENIDO GENERAL DEL DOCUMENTO

FIRMA DEL REVISOR :

MIPS-005 LISTA DE CHEQUEO DE CADA REQUISITO

Revisado por Cargo o rol

REVISIÓN DEL REQUISITO

FIRMA DEL REVISOR :

MIPS-006 FORMATO DE EVALUACIÓN GLOBAL DEL

Revisado por Cargo o rol

FIRMA DEL REVISOR :

MIPS-007 LISTA DE CHEQUEO PARA EL DOCUMENTO DE

Revisado por Cargo o rol

REVISIÓN DEL CONTENIDO GENERAL DEL DOCUMENTO

3. Adquisición de datos de prueba

5. Manejo de Problemas que se puedan

FIRMA DEL REVISOR :

MIPS-008 LISTA DE CHEQUEO PARA PLANEACIÓN DE CADA

Revisado por Cargo o rol

FIRMA DEL REVISOR :

MIPS-009 FORMATO DE CASOS DE PRUEBA

RobustezFronteraTolerancia a FallasPropósito de la prueba:

EJEMPLO DE CASOS DE PRUEBA DE ACEPTACIÓN Y DEL

En este ejemplo se muestran cinco casos de prueba para el

¿Se presentó alguna falla en la ejecución de esta prueba?

Observaciones: (Escriba el detalle de las fallas que se presentaron en la

Observaciones: (Escriba el detalle de las fallas que se presentaron en la

Observaciones: (Escriba el detalle de las fallas que se presentaron en la

MIPS-010 LISTA DE CHEQUEO PARA INSPECCIONAR LOS

Revisado por Cargo o rol

REVISIÓN DEL CASO DE PRUEBA

FIRMA DEL REVISOR :

MIPS-011 LISTA DE CHEQUEO PARA EL DOCUMENTO DE

Revisado por Cargo o rol

REVISIÓN DEL DOCUMENTO

7.4. Alta Disponibilidad: componentes

FIRMA DEL REVISOR :

EJEMPLO DE CASOS DE PRUEBA DE INTEGRACIÓN

FORMATO DE CASOS DE PRUEBA

Revisado por Cargo o rol

REVISIÓN DEL DOCUMENTO

prueba corresponden con el propósito de la

FIRMA DEL REVISOR :

MIPS-013 LISTA DE CHEQUEO DEL DOCUMENTO DE DISEÑO

Revisado por Cargo o rol

REVISIÓN DEL DOCUMENTO

FIRMA DEL REVISOR:

EJEMPLO CASOS DE PRUEBA DE UNIDAD

FORMATO DE CASOS DE PRUEBA