PLAN DE GARANTÍA DE CALIDAD

DEL SOFTWARE

Versión 1.0

Nombre del Profesional

QA

2021
 HISTORIAL DE REVISIONES

Fecha Descripción Autor

24-09-2021 Crear documento SQA QA

SQA: conjunto de actividades planificadas y sistemática, cuyo objetivo es evaluar la

calidad y la adherencia de los productos de software a los estándares, procesos y
procedimientos.

2
 INDICE

HISTORIAL DE REVISIONES ...................................................................................... 2

INDICE ............................................................................................................................. 3

PROPOSITO ................................................................................................................ 5

SECCIÓN DE DOCUMENTO DE REFERENCIA .................................................... 6

SECCIÓN DE GESTIÓN............................................................................................. 7

SECCIÓN DE DOCUMENTACIÓN .......................................................................... 8

SECCIÓN DE ESTÁNDARES, PRÁCTICAS, CONVENCIONES Y MÉTRICAS . 9

SECCIÓN DE REVISIONES E INSPECCIONES .................................................... 10

SECCIÓN DE GESTIÓN DE LA CONFIGURACIÓN DE SOFTWARE ............... 11

SECCIÓN DE NOTIFICACIÓN DE PROBLEMAS Y ACCIONES

CORRECTIVAS ........................................................................................................ 12

SECCIÓN DE HERRAMIENTAS, TÉCNICAS Y METODOLOGÍAS .................. 13

SECCIÓN DE CONTROL DE CÓDIGO .................................................................. 14

SECCIÓN DE CONTROL DE MEDIOS .................................................................. 15

SECCIÓN DE CONTROL DE PROVEEDORES ..................................................... 16

SECCIÓN DE RECOPILACIÓN, MANTENIMIENTO Y RETENCIÓN DE

REGISTROS .............................................................................................................. 17

METODOLOGÍA DE PRUEBA ............................................................................... 18

ANEXOS ........................................................................................................................ 19

Lista de verificación de revisión de arquitectura ........................................................ 19

Lista de verificación de revisión de ambigüedad ....................................................... 21

Lista de verificación de documentos del proyecto ..................................................... 24

Lista de verificación de revisión del diseño de datos ................................................. 27

3
Lista de verificación del entorno ................................................................................ 30

Lista de verificación de revisión de especificaciones funcionales ............................. 32

Lista de verificación de finalización del proyecto ...................................................... 35

Lista de verificación de revisión de prototipos ........................................................... 37

Lista de verificación de revisión de cambios de requisitos ........................................ 39

Lista de verificación de revisión de riesgos ............................................................... 41

Lista de verificación de revisión de diseño técnico .................................................... 43

Lista de comprobación para la revisión de la preparación del caso de prueba ........... 47

Lista de comprobación para la revisión de la preparación del caso de prueba ........... 49

Lista de verificación de revisión del programa de pruebas ........................................ 51

Lista de comprobación de pruebas unitarias............................................................... 52

Lista de verificación de revisión de casos de uso ....................................................... 55

4
PROPOSITO

Esta sección delinea el propósito específico y el alcance del plan SQA en particular. Eso
enumera los nombres de los elementos de software cubiertos por el plan SQA y el uso del
software. Indica la parte del ciclo de vida del software cubierta por el plan SQA para cada
elemento de software especificado.

5
SECCIÓN DE DOCUMENTO DE REFERENCIA

Esta sección proporciona una lista completa de los documentos a los que se hace
referencia en otras partes del texto de la Plan SQA.

6
SECCIÓN DE GESTIÓN

Esta sección describe la estructura organizativa, las tareas y las responsabilidades del
proyecto.

7
SECCIÓN DE DOCUMENTACIÓN

Esta sección identifica la documentación que rige el desarrollo, verificación y validación,

uso y mantenimiento del software. También establece cómo se deben comprobar su
idoneidad. Esto incluye los criterios y la identificación de la revisión o Auditoría mediante
la cual se confirmará la adecuación de cada documento.

8
SECCIÓN DE ESTÁNDARES, PRÁCTICAS, CONVENCIONES Y MÉTRICAS

Esta sección identifica los estándares, prácticas, convenciones y métricas que se

aplicarán, y también establece cómo se debe monitorear y asegurar el cumplimiento de
estos elementos.

Categoría métrica (por ejemplo, defectos, estado de entrega, etc.).

Punto métrico (por ejemplo, distribución de causas de defectos, número de defectos por
causa a lo largo del tiempo.
Objetivo métrico (definir el motivo para realizar las mediciones).
Derivación (método de recopilación o presentación de la métrica).

Id Métrica Categoría Métrica Punto Métrico Objetivo Métrico Derivación

9
SECCIÓN DE REVISIONES E INSPECCIONES

Esta sección define las revisiones, recorridos e inspecciones técnicas y de gestión. Para
ser conducido. También establece cómo se deben realizar las revisiones, los tutoriales y
las inspecciones. logrado, incluidas las actividades de seguimiento y las aprobaciones.

10
SECCIÓN DE GESTIÓN DE LA CONFIGURACIÓN DE SOFTWARE

Esta sección se aborda en detalle en la gestión de la configuración del software del

proyecto.

11
SECCIÓN DE NOTIFICACIÓN DE PROBLEMAS Y ACCIONES
CORRECTIVAS

Esta sección se aborda en detalle en la gestión de la configuración del software del

proyecto.

12
SECCIÓN DE HERRAMIENTAS, TÉCNICAS Y METODOLOGÍAS

Esta sección identifica las herramientas, técnicas y metodologías de software especiales

que apoyan SQA, declara sus propósitos y describe su uso.

13
SECCIÓN DE CONTROL DE CÓDIGO

Esta sección define los métodos e instalaciones utilizados para mantener, almacenar,
asegurar y documentar las versiones controladas del software identificado durante todas
las fases de desarrollo. Esto puede implementarse junto con una biblioteca de programas
de computadora. y / o puede proporcionarse como parte del plan de gestión de la
configuración del software.

14
SECCIÓN DE CONTROL DE MEDIOS

Esta sección establece los métodos e instalaciones que se utilizarán para identificar los
medios para cada producto informático y la documentación necesaria para almacenar los
medios, incluida la copia, restaurar el proceso, y protege los medios físicos del programa
informático de acceso no autorizado o daño o degradación inadvertidos durante todas las
fases de desarrollo. Esto puede ser proporcionado por el plan de gestión de la
configuración del software.

15
SECCIÓN DE CONTROL DE PROVEEDORES

Esta sección establece las disposiciones para garantizar que el software proporcionado
por los proveedores cumpla Requisitos establecidos. Además, debe indicar los métodos
que se utilizarán para asegurarse de que el proveedor de software reciba los requisitos
adecuados y completos.

En esta sección indicará los métodos que se utilizarán para asegurar la idoneidad del
producto para su uso con los elementos de software cubiertos por el plan SQA.

Esta sección también indicará los métodos utilizados para asegurar que los
desarrolladores cumplan con los requisitos de esta norma.

16
SECCIÓN DE RECOPILACIÓN, MANTENIMIENTO Y RETENCIÓN DE
REGISTROS

Esta sección identifica la documentación de SQA que se debe conservar. Dirá los métodos
y Instalaciones para ensamblar, salvaguardar y mantener esta documentación, y designará
el periodo de retención. La implementación del plan SQA implica las aprobaciones
necesarias tanto para el plan como para el desarrollo de un plan de ejecución. La
evaluación posterior de el plan SQA se realizará como resultado de su ejecución.

17
METODOLOGÍA DE PRUEBA

Esta sección define el enfoque de prueba, las técnicas y las herramientas automatizadas
que serán usadas.

18
 ANEXOS

LISTA DE VERIFICACIÓN DE REVISIÓN DE ARQUITECTURA

Revise la arquitectura para ver si está completa y clara. Para todas las
Propósito de la respuestas negativas, el facilitador evaluará el impacto y elevará como
lista de un problema a las partes interesadas para su resolución. Esto se puede
verificación lograr a través de informes de estado semanales y / o correo
electrónico.

AREA ITEM
SI NO COMENTARIOS
¿Se ha documentado
una descripción general
del sistema?
¿Se ha definido la
arquitectura de 2 o 3
niveles?
¿Se ha definido la base
de datos y el acceso?
¿Se han definido los
servidores?
¿Se han definido los
protocolos, ej. HTTP,
JSP,…
¿El proveedor es
interno o externo?
¿Se ha definido el
punto de contacto para
resolver problemas de
arquitectura técnica?
¿Se ha definido la
plataforma?

19
¿Existe un diagrama de
red?
¿Se ha definido el
equipo de prueba?
¿Se ha definido el
equilibrio de carga?
¿Se han definido los
procesos de negocio?
¿Hay tareas comunes
que se realizan con más
frecuencia que otras
que se han definido?
¿Se han definido los
volúmenes máximos?
¿Se han identificado los
servidores web?

20
LISTA DE VERIFICACIÓN DE REVISIÓN DE AMBIGÜEDAD

Revise una especificación funcional en busca de ambigüedad estructural

Propósito de la (no debe confundirse con revisiones de contenido). Para todas las
lista de respuestas negativas, el facilitador evaluará el impacto y elevará como
verificación un problema a las partes interesadas para su resolución. Esto se puede
lograr a través de informes de estado semanales y / o correo electrónico.

AREA ITEM
SI NO COMENTARIOS
Complejidad ¿Son los requisitos
demasiado complejos?
Colgando más ¿Hay casos en los que
falta la parte else de una
afección?
Ambigüedad de ¿Hay casos en los que
referenciado hay referencias que no
están claramente
definidas?
Alcance de la acción ¿Hay casos en los que el
alcance de la acción
para una condición no
está claramente
definido?
Omisiones ¿Hay causas sin
efectos?
¿Faltan efectos?
¿Hay efectos sin
causas?
¿Existe un uso
compuesto de "y", "o"
que están calificados
entre paréntesis?

21
Operadores lógicos ¿Se utiliza
ambiguos correctamente el uso de
"o"?
¿Hay casos de negación
del alcance?
¿Hay casos de negación
innecesaria?
Negación ¿Hay casos de doble
negación?
¿Hay casos de verbos
ambiguos?
¿Hay casos de
adverbios ambiguos?
Declaraciones ¿Hay casos de adjetivos
ambiguas ambiguos?
¿Hay casos de variables
ambiguas?
¿Hay casos de alias?
Organización aleatoria ¿Hay casos de causas y
efectos mixtos?
¿Hay casos de
secuencias de casos
aleatorias?
Supuestos ¿Hay casos de
incorporados conocimiento del
dominio funcional
(SME) que no se
mencionan
explícitamente?
Supuestos ¿Hay casos en los que
incorporados las secuencias de
Relaciones de eventos no están claras?
precedencia ambiguas

22
Casos implícitos
Etc.
ES DECIR. Versus
E.G.
Ambigüedad temporal
Ambigüedad de los
límites
Casos implícitos ¿Hay casos implícitos?
Etc ¿Hay ejemplos de Etc.?
Ambigüedad temporal ¿Hay casos de
ambigüedades
temporales?
Ambigüedad de los ¿Hay ambigüedades en
límites los límites?

23
LISTA DE VERIFICACIÓN DE DOCUMENTOS DEL PROYECTO

Verifique el archivo correcto de los documentos del proyecto. Para todas

Propósito de la las respuestas negativas, el facilitador evaluará el impacto y elevará
lista de como un problema a las partes interesadas para su resolución. Esto se
verificación puede lograr a través de informes de estado semanales y / o correo
electrónico.

ITEM ITEM
SI NO COMENTARIOS
1 ¿Se archiva el
documento de requisitos
comerciales?
2 ¿Se archiva el
documento de
especificación
funcional?
3 ¿Se archiva el
documento de diseño
lógico?
4 ¿Está archivado el
documento prototipo?
5 ¿Se archivan los correos
electrónicos y la
correspondencia
relacionados con el
proyecto?
6 ¿Se archivan las actas
de todas las reuniones?
7 ¿Está archivado el
documento de estrategia
de prueba?

24
8 ¿Está archivado el
documento de estrategia
de automatización /
rendimiento?
9 ¿Está archivado el
documento del plan de
prueba?
10 ¿Se archivan los
documentos que
contienen los casos de
prueba y las
condiciones?
11 ¿Están archivados los
scripts de
automatización?
12 ¿Se archivan las
Directrices de datos de
prueba / el documento
de datos de prueba?
13 ¿Está archivado el
documento Run Plan?
14 ¿Se archiva el
documento de la Matriz
de trazabilidad?
15 ¿Se archivan los
documentos diarios de
registros de defectos
(capturas de pantalla)
consolidados?
16 ¿Se archivan los
documentos del informe
de defectos
consolidados / diarios?

25
18 ¿Está archivado el
documento de
seguimiento de
ejecución del proyecto?
19 ¿Se archiva el
documento de registro
de tiempo de
inactividad?
20 ¿Se archivan los
resúmenes consolidados
de todas las
aprobaciones de los
documentos de prueba?
21 ¿Se archiva la
funcionalidad del
documento no probado?
22 ¿Se archiva el
documento de métricas
de defectos?
23 ¿Se archiva el
documento de métricas
del proyecto de control
de calidad?
24 ¿Se archiva el
documento del informe
de cierre del proyecto?

26
LISTA DE VERIFICACIÓN DE REVISIÓN DEL DISEÑO DE DATOS

Revise el diseño lógico y físico para mayor claridad e integridad. Para

Propósito de la todas las respuestas negativas, el facilitador evaluará el impacto y
lista de elevará como un problema a las partes interesadas para su resolución.
verificación Esto se puede lograr a través de informes de estado semanales y / o
correo electrónico.

CONTEXTO ITEM
SI NO COMENTARIOS
Diseño lógico ¿Se han definido
adecuadamente los
datos?
¿Están completas las
definiciones de las
entidades de datos?
¿Están las
cardinalidades
definidas
correctamente?
¿Están los atributos
definidos
adecuadamente?
¿Están los datos
normalizados (al menos
la tercera forma
normal)?
¿Están las claves
primarias definidas
correctamente?
¿Están las claves
externas definidas
correctamente?

27
¿Están las claves
compuestas definidas
correctamente?
¿Están definidos
correctamente los
subtipos de entidad?
¿Están completos los
procesos principales?
¿Están completos los
procesos secundarios?
¿Están completas las
interacciones de las
entradas y salidas del
proceso con las
entidades?
¿Están las entidades
elementales definidas
correctamente?
¿Hay un enlace paralelo
definido
correctamente?
¿Los procesos
desencadenantes de
eventos están diseñados
correctamente?
¿Están correctamente
definidas las
asociaciones entidad /
proceso?
¿Están correctamente
definidas las
asociaciones de lectura
de entidad / proceso?

28
¿Están correctamente
definidas las
asociaciones de
actualización de la
entidad / proceso?
¿Están correctamente
definidas las
asociaciones de
eliminación de
entidades / procesos?

29
LISTA DE VERIFICACIÓN DEL ENTORNO

Verifique la preparación del entorno para la prueba antes de comenzar la

Propósito de la ejecución de la prueba. Para todas las respuestas negativas, el facilitador
lista de evaluará el impacto y elevará como un problema a las partes interesadas
verificación para su resolución. Esto se puede lograr a través de informes de estado
semanales y / o correo electrónico.

CONTEXTO ITEM
SI NO COMENTARIOS
Estrategia ¿El cliente ha aprobado
la estrategia de prueba?
¿El modelo de
interacción
(planificación del
proyecto) está definido
y establecido como se
documenta en la
estrategia de prueba?
¿Se definen y
establecen los criterios
de entrada según el
plan de estrategia del
proyecto?
Infraestructura ¿Está listo el entorno de
prueba?
• Hardware
<Ingresar cada uno
Componente>
•Software
o <Ingresar cada uno
Componente>

30
 ¿Se crea el banco de
pruebas?
¿El equipo de pruebas
está disponible y listo
para comenzar a
realizar pruebas?
¿Está completa la
configuración del
laboratorio de pruebas?
Test de datos ¿Están los datos
disponibles según el
formato esperado
(Directrices sobre datos
de prueba -
Planificación)?
¿Se rellenan los datos?
¿Se completó la
transferencia del
software y se cargó la
versión inicial?
Acceso ¿Se han configurado
los ID de usuario y las
contraseñas para
acceder al entorno
desde el Cliente /
Desarrolladores?
Gestión de defectos ¿Conoce el cliente el
proceso de gestión de
defectos definido en la
estrategia?

31
LISTA DE VERIFICACIÓN DE REVISIÓN DE ESPECIFICACIONES
FUNCIONALES

Revise una especificación funcional para ver si el contenido está

completo y claro (no debe confundirse con revisiones de ambigüedad).
Propósito de la
Para todas las respuestas negativas, el facilitador evaluará el impacto y
lista de
elevará como un problema a las partes interesadas para su resolución.
verificación
Esto se puede lograr a través de informes de estado semanales y / o
correo electrónico.

CONTEXTO ITEM
SI NO COMENTARIOS
Introducción
¿Están
documentados el
propósito, el alcance
y la organización de
la especificación
funcional?

Descripción general ¿Se documenta una

del software descripción de alto
nivel de la aplicación?
Descripción del ¿Existe una descripción
producto de por qué se está
desarrollando el
producto y una lista de
las características y
capacidades
importantes?
Producto Funcional ¿Existe una lista de las
Capacidades funciones que deberá
realizar el software?

32
 Para varias capacidades
funcionales, ¿existe
una tabla (o algún otro
formato) para ilustrar
las relaciones entre las
capacidades
funcionales? Nota: esto
puede ser una
actualización de la
documentación de
requisitos
Usuario ¿Se describe al usuario
previsto del software
en términos de función
laboral, conocimiento
especializado o niveles
de habilidad?
Características ¿Existe una descripción
de cómo los usuarios
utilizarán normalmente
el software y las tareas
que realizarán con
frecuencia?
Usuario ¿Se describen las
Operaciones y limitaciones del
Practicas algoritmo, las
limitaciones de la
Restricciones interfaz de usuario y las
generales limitaciones de los
datos?
Supuestos ¿Se describen todos los
supuestos?

33
Otros software ¿Existe una descripción
de cómo el sistema
interactúa con otro
software descrito?
Descripciones
funcionales específicas
Descripción ¿Se describe el papel
de cada función?
Entradas ¿Están todas las fuentes
de entrada
especificadas?
¿Se especifican todos
los requisitos de
precisión de entrada?
¿Están especificados
todos los valores del
rango de entrada?
¿Están todas las
frecuencias de entrada
especificadas?
¿Se especifican todos
los formatos de
entrada?
¿Se incluyen las
definiciones de la base
de datos?

34
LISTA DE VERIFICACIÓN DE FINALIZACIÓN DEL PROYECTO

Confirma que se han completado todas las actividades de cierre de

Propósito de la claves requeridas. Para todas las respuestas negativas requeridas, el
lista de facilitador evaluará el impacto y escalará como un problema a las partes
verificación interesadas para su resolución. Esto se puede lograr a través de informes
de estado semanales y / o correo electrónico.

ESTADO DEL REQUERIMIENTO

CONTEXTO ITEM SI NO REQUERIDO/ COMENTARIOS
OPCIONAL
¿Se ejecutan todos los
casos de prueba?
¿Todos los defectos
están cerrados?
¿Todas las solicitudes
de cambio están
cerradas?
¿Se ha completado la
formación del usuario?
¿Se entregan los
entregables al cliente?
¿Se obtiene la
aprobación del proyecto
del cliente?
¿El directorio de
proyectos contiene la
última versión de los
documentos?
¿Todos los documentos
se archivan y se
guardan en un almacén
de datos?
¿Se han enviado
formularios de

35
comentarios del cliente
al cliente?
¿El material
suministrado por el
cliente ha sido devuelto
o entregado a otros
proyectos y lo mismo
se ha comunicado al
cliente?
¿Se ha comunicado el
cierre formal del
proyecto? (Cliente,
Gerente Senior, Equipo
in situ, Equipo de
Calidad, Intergrupos y
Equipo de Proyecto)?
¿Se ha realizado una
copia de seguridad de
los directorios del
proyecto?
¿Se ha retirado el
directorio de proyectos
del servidor?
¿El proyecto ha sido
marcado como cerrado
en la base de datos del
proyecto?
¿Se ha completado toda
la recopilación de datos
métricos?
¿Se ha actualizado la
base de datos de
habilidades?

36
LISTA DE VERIFICACIÓN DE REVISIÓN DE PROTOTIPOS

Revise un prototipo para ver si el contenido está completo y claro. Para

Propósito de la todas las respuestas negativas, el facilitador evaluará el impacto y
lista de elevará como un problema a las partes interesadas para su resolución.
verificación Esto se puede lograr a través de informes de estado semanales y / o
correo electrónico.

CONTEXTO ITEM
SI NO COMENTARIOS
¿El prototipo refleja los
requisitos iniciales del
cliente?
¿El diseño del prototipo
refleja los requisitos
iniciales?
¿Se ha creado una
interfaz de usuario
interactiva / visual
detallada?
¿Existe una conexión
sencilla de los
componentes de la
interfaz de usuario con
el comportamiento
funcional subyacente?
¿La herramienta de
creación de prototipos
proporciona un
lenguaje fácil de
aprender?
¿Es fácil realizar la
modificación del

37
lenguaje de la
herramienta de creación
de prototipos
resultante?
Simplicidad: ¿La
interfaz de usuario
proporciona un medio
apropiado para permitir
que un cliente evalúe el
comportamiento
funcional subyacente
como se describe en los
requisitos iniciales?
¿Es el prototipo fácil de
usar?
¿El prototipo contiene
un modelo de datos que
define las estructuras de
datos para la aplicación
en sí?
¿El prototipo se adapta
a nuevos requisitos?

38
LISTA DE VERIFICACIÓN DE REVISIÓN DE CAMBIOS DE REQUISITOS

Verifique que los requisitos del proyecto de prueba no hayan cambiado

Propósito de la sustancialmente. Para todas las respuestas negativas, el facilitador
lista de evaluará el impacto y elevará como un problema a las partes interesadas
verificación para su resolución. Esto se puede lograr a través de informes de estado
semanales y / o correo electrónico.

CONTEXTO ITEM
SI NO COMENTARIOS
Cambios en los
requisitos
¿Se han actualizado y
documentado todos los
cambios?
¿Cuál es el efecto si
NO se realiza un
cambio?
¿Se han estimado los
cambios en los
requisitos?
¿Han sido aprobados
los cambios por las
partes interesadas?
¿Se han revisado los
cambios en los
requisitos para verificar
la capacidad de
prueba?
¿Existe una estrategia
de prueba para los
cambios?

39
¿Hay recursos de
prueba disponibles para
respaldar los cambios?
¿Se realizarán pruebas
de unidad / integración
adecuadas para los
cambios?
¿Se ha programado una
prueba de humo para
los cambios?
¿Existe un plan de
prueba de regresión
para probar los
cambios?
¿Se utilizará la
automatización para
probar los cambios?
¿Existe un proceso de
control de cambios?

40
LISTA DE VERIFICACIÓN DE REVISIÓN DE RIESGOS

Revise los riesgos que pueden afectar los proyectos. Esto se puede
lograr a través de informes de estado semanales o correo electrónico.
Propósito de la
Para todas las respuestas negativas, el facilitador evaluará el impacto y
lista de
elevará como un problema a las partes interesadas para su resolución.
verificación
Esto se puede lograr a través de informes de estado semanales y / o
correo electrónico.

CONTEXTO ITEM
SI NO COMENTARIOS
¿Se han definido los
riesgos para la
organización?
¿Se ha definido un
proceso de seguimiento
de la revisión de
riesgos?
¿Se han definido
riesgos para el
proyecto?
¿Se han definido las
limitaciones de riesgo?
¿Se han definido las
métricas para
monitorear los riesgos?
¿La gestión de riesgos
está incorporada en el
plan del proyecto?
¿Se han definido
herramientas de gestión
de riesgos?
¿Se han definido los
resultados de la

41
identificación de
riesgos?
¿Se han definido
técnicas de
identificación de
riesgos?
¿Se ha definido una
estrategia de mitigación
de riesgos?
¿Se ha definido una
política de riesgos?
¿Se han priorizado los
riesgos?
¿Se han identificado
amenazas?
¿Se ha definido la
vulnerabilidad?

42
LISTA DE VERIFICACIÓN DE REVISIÓN DE DISEÑO TÉCNICO

Revise el diseño técnico para mayor claridad e integridad. Para todas las
Propósito de la
respuestas negativas, el facilitador evaluará el impacto y elevará como
lista de
un problema a las partes interesadas para su resolución. Esto se puede
verificación
lograr a través de informes de estado semanales y / o correo electrónico.

CONTEXTO ITEM
SI NO COMENTARIOS
Diseño técnico
¿La secuencia lógica es
errónea?
¿El procedimiento
maneja incorrectamente
los parámetros de
entrada o salida?
¿Los procedimientos no
aceptan todos los datos
dentro de los rangos
permitidos?
¿Se realizan
verificaciones de
límites y validez en los
datos de entrada?
¿Hay procedimientos
de recuperación no
implementados o
inadecuados?
¿Falta la lógica
requerida o es
inadecuada?
¿Los valores son
erróneos o ambiguos?

43
¿El almacenamiento de
datos es incorrecto o
inadecuado?
¿Falta la variable o no
se declara
correctamente?
¿La base de datos no es
compatible con el
entorno de datos?
¿La estructura modular
refleja una alta
dependencia inter-
modular?
¿Hay algoritmos que no
se evalúen en cuanto a
precisión o velocidad?
¿La estructura de
control no es
ampliable?
¿Las estructuras de
control ignoran las
prioridades de
procesamiento?
¿Se utilizan
incorrectamente los
protocolos de interfaz?
¿Los datos no se
convierten de acuerdo
con el formato
correcto?
¿Hay bucles infinitos?
¿Se violan las reglas de
la base de datos?

44
¿Hay casos especiales
no cubiertos?
¿El manejo de errores
es deficiente?
¿Se descuidan las
consideraciones de
tiempo?
¿Se malinterpretan o
implementan
incorrectamente las
especificaciones de la
interfaz?
¿La funcionalidad del
sistema es correcta pero
no cumple con los
requisitos de
rendimiento?
¿Los algoritmos
proporcionan una
precisión insuficiente o
resultados erróneos
para ciertos valores de
la entrada?
¿Hay errores en la
lógica detallada
desarrollada para
resolver un problema
en particular?
¿Los valores de entrada
singulares o críticos
producen resultados
inesperados que no se
contabilizan

45
adecuadamente en el
código?
¿Hay algoritmos que
son incorrectos o
producen la solución
incorrecta?

46
LISTA DE COMPROBACIÓN PARA LA REVISIÓN DE LA PREPARACIÓN
DEL CASO DE PRUEBA

Asegúrese de que los casos de prueba se hayan preparado según las

Propósito de la especificaciones. Para todas las respuestas negativas, el facilitador
lista de evaluará el impacto y elevará como un problema a las partes interesadas
verificación para su resolución. Esto se puede lograr a través de informes de estado
semanales y / o correo electrónico.

CONTEXTO ITEM
SI NO COMENTARIOS
¿Está disponible el plan
de prueba aprobado?
¿Se identifican los
recursos para
implementar el plan de
prueba?
¿Están disponibles los
documentos de línea
base?
¿Se imparte el
conocimiento del
dominio a los
miembros del equipo
para trabajar con la
aplicación?
¿Se ha completado el
documento de
condición de prueba?
¿Se han desarrollado
casos de prueba para
todos los requisitos?

47
¿Se han cubierto todos
los flujos básicos en
casos de uso?
¿Se ha verificado la
trazabilidad?
¿Se han cubierto
completamente los
requisitos modificados?
¿Se han escrito los
casos de prueba para el
flujo de datos a través
de interfaces?
¿Se han escrito los
casos de prueba para
todos los tipos de
pruebas definidas en el
plan del proyecto?
¿Se han escrito casos
de prueba para
requisitos no
funcionales?
¿Se han escrito casos
de prueba para pruebas
de interfaz gráfica de
usuario / hipervínculos
en aplicaciones web?
¿Se han escrito casos
de prueba para probar
la integridad de la
fecha?

48
LISTA DE COMPROBACIÓN PARA LA REVISIÓN DE LA PREPARACIÓN
DEL CASO DE PRUEBA

Sirve es la base de la aprobación de casos de prueba. Garantiza que los

casos de prueba se hayan preparado para cubrir los requisitos de las
Propósito de la
especificaciones de requisitos. Para todas las respuestas negativas, el
lista de
facilitador evaluará el impacto y elevará como un problema a las partes
verificación
interesadas para su resolución. Esto se puede lograr a través de informes
de estado semanales y / o correo electrónico.

CONTEXTO ITEM
SI NO COMENTARIOS
¿Cada caso de prueba tiene un
identificador único?
¿Cada caso de prueba tiene una
descripción?
¿Cada caso tiene un objetivo de
prueba?
¿Cada caso de prueba tiene un
guión de prueba (pasos)?
¿Cada caso de prueba tiene
resultados esperados?
¿Cada caso de prueba tiene
resultados reales documentados?
¿Se ha creado al menos un caso de
prueba de caja negra para cada
función del sistema?
¿Se han probado todos los valores
de entrada predeterminados?
¿Se ha rastreado cada caso de
prueba hasta los requisitos?
¿Se han probado todas las
condiciones de error?

49
¿Se han proporcionado datos de
prueba de forma inequívoca en
cada caso de prueba?
¿Se han establecido todo el
entorno de prueba y las
herramientas necesarias para
ejecutar la prueba de software?
¿Se han identificado todas las
configuraciones de software
necesarias para implementar los
casos de prueba diseñados?

50
LISTA DE VERIFICACIÓN DE REVISIÓN DEL PROGRAMA DE PRUEBAS

Revise el programa de pruebas. Para todas las respuestas negativas, el

Propósito de la
facilitador evaluará el impacto y elevará como un problema a las partes
lista de
interesadas para su resolución. Esto se puede lograr a través de informes
verificación
de estado semanales y / o correo electrónico.

CONTEXTO ITEM
SI NO COMENTARIOS
Calendario
de pruebas
¿Es necesario modificar el
programa de planificación de la
prueba?
¿Es necesario modificar el
cronograma de desarrollo de
casos de prueba?
¿Es necesario modificar el
programa de revisión de la
prueba?
¿Es necesario modificar el
cronograma de ejecución de la
prueba del sistema?
¿Es necesario modificar el
cronograma de ejecución de la
prueba de aceptación?
¿Es necesario modificar el
cronograma de informes de
pruebas?
¿Es necesario ajustar los
principales hitos de la prueba?

51
LISTA DE COMPROBACIÓN DE PRUEBAS UNITARIAS

Acciones de Prueba esperadas Completadas Comentarios /

Explicación
Yes No N/A

¿Se verificaron todos los campos

para permitir que solo se
ingresen datos con el formato
correcto [ej. numérico (firmado /
sin firmar), alfabético,
alfanumérico (caracteres
especiales), fecha, válido e
inválido]; ¿Verifique los
mensajes de error en busca de
datos no válidos?
¿Se verificaron todos los campos
para permitir que solo se
ingresen datos de valores
permitidos (por ejemplo, tablas,
rangos, mínimo, máximo);
¿Verifique los mensajes de error
en busca de datos no válidos?
¿Se probaron todos los mensajes
de error?
¿Se verificó que todos los
campos manejen todos los
valores no válidos?
¿Se revisaron las
especificaciones para asegurar
que se hayan probado las
condiciones?

52
¿Se inicializaron correctamente
todos los campos?
¿Se validaron todos los campos
que están protegidos?
¿Se verificaron todos los
cálculos para proporcionar
resultados correctos en todos los
rangos de elementos de datos
involucrados según las reglas
comerciales?
¿Se verificaron todos los valores
de salida y su formato?
¿Se verificaron todos los
requisitos de seguridad
requeridos, como se especifica
en la especificación de diseño?
¿Se capturaron todas las
condiciones de error y se
manejaron de acuerdo con los
estándares del entorno en el que
se ejecutará el elemento de
software (por ejemplo, códigos
de error, mensajes de error)?
¿Se verificó que todos los
mensajes fueran claros y
comprensibles por los usuarios
finales típicos del elemento de
software?
¿Los usuarios habituales de las
instrucciones verificaron que
todas las instrucciones fueran
concisas y comprensibles?

53
¿Todas las pestañas, botones,
hipervínculos y tabulaciones de
campo funcionan de manera
lógica de acuerdo con los
estándares en los que se
ejecutará el elemento de
software?
¿Se verificaron todas las
iteraciones de bucle indefinido?
¿Se cumplieron todos los
estándares de programación?
¿Se verificaron los formatos de
fecha no válidos?

Comentarios

Completado por: Aceptado por:

___________________________ ____________________
Fecha________________ Fecha___________
Desarrollador Gerente de Desarrollo

54
LISTA DE VERIFICACIÓN DE REVISIÓN DE CASOS DE USO

Revise los casos de uso para mayor claridad e integridad. Para todas las
Propósito de la
respuestas negativas, el facilitador evaluará el impacto y elevará como
lista de
un problema a las partes interesadas para su resolución. Esto se puede
verificación
lograr a través de informes de estado semanales y / o correo electrónico.

CONTEXTO ITEM
SI NO COMENTARIOS
¿Se identifican las
acciones del usuario
final?
¿El resultado de la
prueba del usuario del
sistema está
relacionado con
acciones específicas?
¿El usuario final
comprende
correctamente los
informes y las pantallas
de salida?
¿El usuario final
comprende el tipo de
lógica y cálculo
realizado para producir
la salida?
¿Puede el usuario final
identificar la
contribución que hace
el resultado a las
acciones tomadas?

55
¿Puede el usuario final
identificar si las
acciones tomadas son
correctas?
¿Se ha identificado
correctamente a los
actores?
¿Se han definido las
condiciones previas y
posteriores?
¿Se ha abordado la
herencia?
¿Se han definido todas
las interfaces?

56