Universidad Nacional Abierta y a Distancia

Vicerrectoría Académica y de Investigación

Guía de actividades y rúbrica de evaluación
Fase 2 - Definición del Plan de Trabajo de Pruebas de Software.

1. Descripción general del curso

Escuela o Unidad Escuela de Ciencias Básicas, Tecnología e

Académica Ingeniería
Nivel de Tecnológico
formación
Campo de Formación disciplinar
Formación
Nombre del Diplomado de profundización en pruebas de
curso software
Código del curso 204047
Tipo de curso Metodológico Habilitable Si ☐ No ☒
Número de 10
créditos

2. Descripción de la actividad

Número
Tipo de
Individual ☐ Colaborativa ☒ de 4
actividad:
semanas
Momento de
Intermedia,
la Inicial ☐ ☒ Final ☐
unidad:
evaluación:
Peso evaluativo de la Entorno de entrega de actividad:
actividad: 120 Seguimiento y evaluación
Fecha de inicio de la
Fecha de cierre de la actividad:
actividad: viernes, 6 de
jueves, 3 de octubre de 2019
septiembre de 2019

Competencia a desarrollar:

• El estudiante identifica los elementos a tener en cuenta para

elaborar un plan de pruebas de software a un producto
determinado.
Temáticas a desarrollar:

Plan de pruebas de software, pruebas a los largo del ciclo de ciclo de

vida del desarrollo del software, gestión de las pruebas de software y
sus caracteristicas, gestión de la configuración en las pruebas de
software y gestión de incidencias, diferencias entre riesgo del proyecto
y riesgo del producto, herramientas para el proceso de pruebas de
software, plan de pruebas de acuerdo a la norma IEEE 829 y 730
Pasos, fases o etapa de la estrategia de aprendizaje a
desarrollar
Fase 2 - Definición del plan de trabajo de pruebas de software.

Actividades a desarrollar

Descripción de la Actividad Individual.

Para realizar los siguientes puntos, leer cuidadosamente cada instrucción

definida para cada punto:

Leer la página del 37 al 61 del siguiente enlace:

https://repository.unad.edu.co/handle/10596/26560 - El documento
204047-ProgramaDeEstudioDeNivelBásicoISTQB_2018.pdf

1. Con base en la lectura, realizar un cuadro comparativo donde se

defina los niveles de la prueba y sus las características.

Leer la página del 88 al 103 del siguiente enlace:

https://repository.unad.edu.co/handle/10596/26560 - El documento
204047-ProgramaDeEstudioDeNivelBásicoISTQB_2018.pdf

2. Elabore un cuadro sinóptico donde defina con sus propias palabras

la gestión de la configuración en las pruebas de software y gestión
de incidencias.

3. A través de un mapa mental defina las diferencias entre riesgo del

proyecto y riesgo del producto.

4. Con base en la lectura anterior, investigue las actuales

herramientas de pruebas que existen en el mercado, sus
 características, funcionalidad y tipo de herramienta, con dicha
información cree un cuadro comparativo.

5. Seleccionar un rol líder de pruebas o probador, el cual se utilizará

en el proceso de pruebas que se desarrollará a lo largo del
diplomado.

Nota: El primer estudiante que seleccione el rol líder es quién

tendrá el rol relacionado en todos los documentos que se
construyan a lo largo del proyecto, la elección se publicará, en el
foro de la unidad 2, fase 2 del entorno de aprendizaje colaborativo,
para el proceso de pruebas se requiere un líder y uno o más
probadores, el rol es para relacionarlo en el plan de trabajo, pero
todos los estudiantes desarrollarán las funciones de estos roles en
el proceso de pruebas.

6. En la aplicación y módulo seleccionado por el grupo en la unidad

1, el estudiante desarrolla los diseños de alto nivel (mínimo 5
escenarios de pruebas, máximos los que el estudiante considere).

Los diseños de alto nivel son los objetivos de las pruebas. Para el
correcto desarrollo. “Apoyarse en el Anexo 1 relacionado al
final de la guía”

7. El estudiante recolecta los riesgos detectados del proyecto

(proceso de pruebas) y del producto (aplicación seleccionada para
practicar el proceso de pruebas). Se debe identificar por lo menos
un riesgo.

8. Para elaborar la matriz de riesgos, “Apoyarse en el Anexo 2

relacionado al final de la guía”

9. El diseño de alto nivel y la matriz de riesgos son dos artefactos que

hace parte de proceso de pruebas, los nombres de los artefactos
deben estar nombrados de acuerdo con los elementos de la gestión
en la configuración.

Así mismo cada artefacto se encuentra en una carpeta cuya

distribución tiene un orden; para la entrega se debe realizar con
 base al orden definido para el proyecto. Ver guía para el uso de
recursos educativos_204047A_Diplomado de Profundización en
pruebas de software, definido en el entorno de aprendizaje
práctico.

Por medio de pantallas evidenciar el orden de configuración

definido para el proyecto.

Ej,

1. En la aplicación seleccionada por el grupo en la unidad 1, el

estudiante desarrolla un proceso de revisión estática, el tipo de
revisión es informal. El proceso de revisión estática informal se
 realiza en el servicio de ayuda de la aplicación seleccionada.
“Apoyarse en el Anexo 4 relacionado al final de la guía”

10. En la aplicación seleccionada por el grupo en la Unidad 1, el

estudiante sustenta con sus propias palabras el tipo de prueba y
nivel de prueba que se debe realizar en la aplicación seleccionada
y establece la estimación de tiempos. “Apoyarse en el Anexo 5
relacionado al final de la guía”

La estimación de tiempos es un artefacto que hace parte de proceso de

pruebas, el nombre del artefacto se nombra de acuerdo a los elementos
de la gestión en la configuración.

Así mismo cada artefacto se encuentra en una carpeta cuya distribución

tiene un orden; para la entrega se debe realizar con base al orden
definido para el proyecto. Ver guía para el uso de recursos
educativos_204047A_Diplomado de Profundización en pruebas de
software, definido en el entorno de aprendizaje práctico.

Por medio de pantallas evidenciar el orden de configuración definido para

el proyecto.

Ej,

Descripción de la Actividad Colaborativa

1. Socializar los aportes individuales, por medio del trabajo

entregado en el entorno de aprendizaje colaborativo.

2. Consolidar en un solo trabajo los puntos del 5 al 10.

 Para la consolidación, se espera que por cada punto se observe lo
siguiente:

El rol seleccionado

Consolidar en un solo cuadro los diseños de alto nivel, por cada

módulo del sistema y el responsable, según modelo definido en el
Anexo N° 1 disponible al final de la guía.

Una matriz consolidada de riesgos, de acuerdo al modelo definido

en el anexo N° 2 disponible al final de la guía.

El nombramiento del diseño de alto nivel y la matriz de riesgos

debe estar de acuerdo lo definido en los elementos de la
configuración del proyecto, ver guía para el uso de recursos
educativos_204047A_Diplomado de Profundización en pruebas de
software, definida en el entorno de aprendizaje práctico.

Construir el plan de trabajo de pruebas de acuerdo a la norma

IEEE829 y 730. Los lineamientos para el desarrollo del plan de
pruebas, se encuentra en el anexo N° 3 disponible al final de la
guía.

11. La estimación debe presentarse por cada módulo del el cual

se encuentra en el Anexo 5 relacionado al final de la guía.

El nombramiento de la estimación, de acuerdo a lo definido en la

guía para el uso de recursos educativos_204047A_Diplomado de
Profundización en pruebas de software, definido en el entorno de
aprendizaje práctico.

Construir la matriz de trazabilidad de los casos de prueba. Los

lineamientos para el desarrollo se encuentran en el Anexo N° 6 al
final de la guía.

Construir la propuesta de pruebas de acuerdo con la norma IEEE

829 de 1998. Los lineamientos para el desarrollo del plan de
pruebas, se encuentra en el anexo N° 7 disponible al final de la
guía.
Entornos
para su Entorno de aprendizaje colaborativo
desarrollo
Individuales:
Se espera como producto de esta actividad un documento
en pdf que contenga:

Página 1: Portada.
Contiene:
- Título “Trabajo Individual”
- Nombre
- Código del estudiante
- E-mail
- Skype del estudiante
- Ciudad
- CEAD donde se encuentra el
estudiante.
- Nombre del tutor
- Nombre de la Universidad
Productos - Fecha de entrega de la tarea
a entregar
por el Página 2: Introducción (incluye objetivos).
estudiante Página 3 y siguientes: Desarrollo de los puntos 1 al 8 de
la actividad individual descrita en la columna anterior.
Página Penúltima: Conclusiones
Página Última: Bibliografía

Lugar de entrega del trabajo: El archivo debe ser

publicado por el estudiante en el entorno de aprendizaje
colaborativo.

No se aceptan entregas parciales, el documento debe

estar completo con los 8 puntos definidos.

Espacio de interacción asincrónica: Entorno de

aprendizaje colaborativo, en el foro denominado: Unidad
2 - Fase 2. Planificar, definir plan de pruebas y generar
matriz de riesgo
Espacios de interacción sincrónica: Revisar horarios de
chat y de conferencia web en el entorno de información
inicial.

Generalidades del documento:

Nombre: PrimerNombrePrimerApellidofase2.pdf.
Ejemplo: JavierAcostaFase2.pdf.

Colaborativos:
Se espera como producto de esta actividad un documento
en pdf que contenga:

Página 1: Portada.
Contiene:
- Título “Trabajo Fase 2”
- Nombres de los integrantes del grupo
- Códigos de los estudiantes
- E-mail
- Skype del estudiante
- Ciudad
- CEAD donde se encuentran los
Estudiantes.
- Nombre del tutor
- Nombre de la Universidad
- Fecha de entrega de la tarea
Página 2: Introducción (incluye objetivos).
Página 3 y siguientes: Desarrollo de los puntos 2 y 3 de
la actividad Colaborativa descrita en la columna anterior.
Página Penúltima: Conclusiones
Página Última: Bibliografía

Lugar de entrega del trabajo: El trabajo final será

entregado por el líder del grupo en el entorno de
Evaluación y seguimiento.

Espacio de interacción asincrónica: Entorno de

 aprendizaje colaborativo, en el foro denominado: Unidad
2 - Fase 2. Planificar, definir plan de pruebas y generar
matriz de riesgo.

Espacios de interacción sincrónica: Revisar horarios de

chat y de conferencia web en el entorno de información
inicial.
Generalidades del documento:

Nombre: ColaborativoN°_grupoN°.pdf. Ejemplo:

Fase2_grupo2.pdf.

Lineamientos generales del trabajo colaborativo para el

desarrollo de la actividad

Para obtener nota en este tipo de trabajos

Planeación colaborativos es obligatorio publicar un archivo como
de definitivo en el mismo foro donde se ha venido
actividades desarrollando, en caso de que el grupo no indique cual
para el es el archivo definitivo se procederá a calificar los
desarrollo aportes individuales.
del trabajo
colaborativo La participación del estudiante debe ser activa durante
todo el periodo de la actividad no al final de ella.
Roles Función
Consolidar el documento que se
constituye como el producto final del
debate, teniendo en cuenta que se
Roles a hayan incluido los aportes de todos los
desarrollar participantes y que solo se incluya a los
Compilador
por el participantes que intervinieron en el
estudiante proceso. Debe informar a la persona
dentro del encargada de las alertas para que avise
grupo a quienes no hicieron sus
colaborativo participaciones, que no se les incluirá en
el producto a entregar.
Asegurar que el escrito cumpla con las
Revisor normas de presentación de trabajos
exigidas por el docente.
 Revisa que los aportes de los integrantes
sean elaboraciones conceptuales propias
(no copias textuales o plagios) y que las
citas y referencias bibliográficas estén
completas y adecuadas a las normas
APA. Avisa a la persona de alertas para
que informe a los integrantes del equipo
en caso que haya que realizar algún
ajuste sobre estos aspectos.
Asegurar que el documento contenga los
criterios presentes en la rúbrica. Debe
comunicar a la persona encargada de las
Evaluador
alertas para que informe a los demás
integrantes del equipo en caso que haya
que realizar algún ajuste sobre el tema.
Alertar sobre los tiempos de entrega de
los productos y enviar el documento en
los tiempos estipulados, utilizando los
Entregas
recursos destinados para el envío, e
indicar a los demás compañeros que se
ha realizado la entrega.
Asegurar que se avise a los integrantes
del grupo de las novedades en el trabajo
Alertas e informar al docente mediante el foro
de trabajo y la mensajería del curso, que
se ha realizado el envío del documento.
La responsabilidad de cada estudiante dentro del grupo
Roles y
colaborativo no solo es elegir un rol a desempeñar
responsabili
dentro del grupo al inicio de la actividad si no cumplir
dades para
con ese rol elegido a lo largo de la misma.
la
producción
El rol principal para el trabajo colaborativo es el rol de
de
líder quien será la persona encargada de la entrega de
entregables
los trabajos finales en el entorno de seguimiento y
por los
evaluación ya que este constituye el resultado del
estudiantes
trabajo colaborativo.
Presentación: 2.5 cm por cada lado, letra Arial 12, y
para referenciar las fuentes consultadas puede
Uso de
navegar por el link:
referencias
http://www.cibem.org/paginas/img/apa6.pdf
 En el acuerdo 029 del 13 de diciembre de 2013,
artículo 99, se considera como faltas que atentan
contra el orden académico, entre otras, las siguientes:
literal e) “El plagiar, es decir, presentar como de su
propia autoría la totalidad o parte de una obra,
trabajo, documento o invención realizado por otra
persona. Implica también el uso de citas o referencias
faltas, o proponer citad donde no haya coincidencia
entre ella y la referencia” y liberal f) “El reproducir, o
copiar con fines de lucro, materiales educativos o
resultados de productos de investigación, que cuentan
con derechos intelectuales reservados para la
Universidad.

Las sanciones académicas a las que se enfrentará el

estudiante son las siguientes:

a) En los casos de fraude académico demostrado en el

Políticas de
trabajo académico o evaluación respectiva, la
plagio
calificación que se impondrá será de cero puntos cero
(0.0) sin perjuicio de la sanción disciplinaria
correspondiente.

b) En los casos relacionados con plagio demostrado en

el trabajo académico cualquiera sea su naturaleza, la
calificación que se impondrá será de cero puntos cero
(0.0), sin perjuicio de la sanción disciplinaria
correspondiente

Para conocer la forma como se referencian los

documentos consulte el siguiente documento: Centro
de Escritura Javeriano ( ) Normas APA. Sexta edición.
Recuperado de:
http://centrodeescritura.javerianacali.edu.co/index.ph
p?option=com_content&view=article&id=138:normas-
apa&catid=45:referencias-bibliograficas&Itemid
 4. Formato de Rubrica de evaluación

Formato rúbrica de evaluación

Tipo de Actividad Actividad
☐ ☒
actividad: individual colaborativa
Momento de la Intermedia,
Inicial ☐ ☒ Final ☐
evaluación unidad
Aspectos Niveles de desempeño de la actividad individual Puntaj
evaluados Valoración alta Valoración media Valoración baja e
El estudiante El estudiante
El estudiante no
Definición de realizo realizó
realiza la definición
niveles de satisfactoriamente parcialmente la
de niveles de
prueba y sus la definición de definición de 5
prueba y sus
característica niveles de prueba y niveles de prueba y
características.
s. sus características.. sus características.
(Hasta 5 puntos) (Hasta 3 puntos) (Hasta 0 puntos)
El estudiante El estudiante
El estudiante no
Definición de realizo realizó
presentó la
gestión de la satisfactoriamente parcialmente la
definición de
configuración la definición de definición de
gestión de la
en las gestión de la gestión de la
configuración en las 5
pruebas de configuración en las configuración en las
pruebas de
software y pruebas de pruebas de
software y gestión
gestión de software y gestión software y gestión
de incidencias .
incidencias de incidencias de incidencias.
(Hasta 5 puntos) (Hasta 3 puntos) (Hasta 0 puntos)
El estudiante El estudiante no
El estudiante
define define
Diferencias define parcialmente
satisfactoriamente satisfactoriamente
entre riesgo las diferencias
las diferencias las diferencias
del proyecto entre riesgo del 5
entre riesgo del entre riesgo del
y riesgo del proyecto y riesgo
proyecto y riesgo proyecto y riesgo
producto. del producto.
del producto. del producto.
(Hasta 5 puntos) (Hasta 3 puntos) (Hasta 0 puntos)
Definición de El estudiante define El estudiante define El estudiante no
herramientas satisfactoriamente parcialmente las define
de pruebas las herramientas de herramientas de satisfactoriamente 5
que existen pruebas que pruebas que las herramientas de
en el existen en el existen en el pruebas que
mercado, sus mercado, sus mercado, sus existen en el
característica características, características, mercado, sus
s, funcionalidad y tipo funcionalidad y tipo características,
funcionalidad de herramienta. de herramienta. funcionalidad y tipo
y tipo de de herramienta.
herramienta. (Hasta 5 puntos) (Hasta 3 puntos) (Hasta 0 puntos)
El estudiante El estudiante El estudiante no
desarrolla desarrolla desarrolla
Desarrolla los
satisfactoriamente parcialmente los satisfactoriamente
diseños de 5
los diseños de alto diseños de alto los diseños de alto
alto nivel
nivel, mínimo 5 nivel o menos de 5 nivel, mínimo 5
(Hasta 5 puntos) (Hasta 3 puntos) (Hasta 0 puntos)
El estudiante
El estudiante El estudiante no
Recolección recolecta
recolecta recolecta
de los riesgos satisfactoriamente
parcialmente los parcialmente los
detectados los riesgos
riesgos detectados riesgos detectados 5
del proyecto detectados del
del proyecto y del del proyecto y del
y del proyecto y del
producto producto
producto producto
(Hasta 5 puntos) (Hasta 3 puntos) (Hasta 0 puntos)
El estudiante
El estudiante
realizo El estudiante no
realizó
satisfactoriamente presentó la matriz
Matriz de parcialmente la
la matriz de de riesgos. 15
riesgos matriz de riesgos.
riesgos.
(Hasta 15
(Hasta 7 puntos) (Hasta 0 puntos)
puntos)
El estudiante El estudiante
realizo realizó El estudiante no
Manejo de satisfactoriamente parcialmente el presentó el manejo
elementos de el manejo de manejo de de elementos de la
la elementos de la elementos de la configuración del 10
configuración configuración del configuración del proyecto.
del proyecto. proyecto. proyecto.
(Hasta 10
(Hasta 5 puntos) (Hasta 0 puntos)
puntos)
El estudiante El estudiante El estudiante no
Desarrollo del desarrollo desarrollo desarrollo 5
proceso de satisfactoriamente parcialmente el satisfactoriamente
revisión el proceso de proceso de revisión el proceso de
estática revisión estática estática revisión estática

(Hasta 5 puntos) (Hasta 3 puntos) (Hasta 0 puntos)

El estudiante
El estudiante
determina El estudiante no
determina
satisfactoriamente determina el tipo
Tipo de parcialmente el tipo
el tipo de prueba y de prueba y nivel
prueba y de prueba y nivel
nivel de prueba que de prueba que se
nivel de de prueba que se
se debe realizar en debe realizar en la
prueba que debe realizar en la
la aplicación aplicación 5
se debe aplicación
seleccionada y seleccionada y no
realizar en la seleccionada o no
establece realiza la
aplicación establece la
adecuadamente la estimación de
seleccionada estimación de
estimación de tiempos
tiempos
tiempos
(Hasta 5 puntos) (Hasta 3 puntos) (Hasta 0 puntos)
Aspectos Niveles de desempeño de la actividad colaborativa Puntaj
evaluados Valoración alta Valoración media Valoración baja e
El estudiante El estudiante
realizo realizó El estudiante no
Socializar los
satisfactoriamente parcialmente presentó socializo
aportes
socializo los socializo los los aportes
individuales,
aportes aportes individuales, por
por medio del
individuales, por individuales, por medio del trabajo
trabajo 5
medio del trabajo medio del trabajo entregado en el
entregado en
entregado en el entregado en el entorno de
el entorno de
entorno de entorno de aprendizaje
aprendizaje
aprendizaje aprendizaje colaborativo.
colaborativo.
colaborativo. colaborativo.
(Hasta 5 puntos) (Hasta 3 puntos) (Hasta 0 puntos)
El estudiante El estudiante
realizo realizó El estudiante no
satisfactoriamente parcialmente el presentó el trabajo
Trabajo
el trabajo trabajo consolidado. 25
consolidado
consolidado. consolidado.
(Hasta 25 (Hasta 13
(Hasta 0 puntos)
puntos) puntos)
 El estudiante El estudiante
realizo realizó El estudiante no
satisfactoriamente parcialmente el presentó el plan de
Plan de
el plan de trabajo plan de trabajo de trabajo de pruebas. 25
pruebas
de pruebas. pruebas.
(Hasta 25 (Hasta 13
(Hasta 0 puntos)
puntos) puntos)
Calificación final 120
 ANEXO N ° 1 - DISEÑO DE ALTO NIVEL

El diseño de alto nivel, es un artefacto que se diligencia con el fin de

definir los objetivos de la prueba y de esta manera poder tener una
visión de las pruebas que se van a realizar en la aplicación.

A continuación, se define los criterios a tener en cuenta para el correcto

diligenciamiento del formato.

Responsable: Persona encargada de diseñar y ejecutar el caso de

prueba.
Módulo: Módulo de la aplicación para probar.
Id Caso de prueba: El id del caso de prueba se construye antecediendo
las iniciales del módulo (Son 3 letras, la primera en mayúscula, las demás
letras en minúscula), ej. Aut = Autenticación; más el consecutivo del
escenario de pruebas, ej., Cp01, Cp2 etc… Ejemplo del Id, AUT_Cp01
Nombre del Caso de Prueba: Está compuesto por el Id y el nombre del
caso de prueba, es una descripción compuesto máximo por tres palabras,
el nombre se breve, claro y conciso, con el nombre debe dar claridad de
la prueba a realizar. Ej. AUT_Cp01_AutenticaciónUsuario.
Descripción: Describir el objetivo de la prueba, por lo tanto debe iniciar
con verbo en infinitivo ir, er o ir. Ej, Verificar la interfaz gráfica de la
pantalla inicial de la aplicación web de Facebook.
Prioridad (alta, medio o baja): Se da una prioridad a cada caso de
prueba de acuerdo al impacto que este tenga en la aplicación, la prioridad
se clasifica en alta, media o baja, el criterio va de acuerdo a la importancia
en la aplicación, ej., sí el sistema de información es para comprar o vender
un artículo, el flujo de compra es clasificado como prioridad alta, pero sí
el escenario de pruebas es para verificar la estructura de un reporte de
las empresas que tiene convenio, se puede clasificar el escenario como
medio, por otro lado, sí el escenario es verificar los colores definidos para
la interfaz gráfica, este se puede clasificar como bajo; en este punto prima
la importancia del flujo a probar.
Total CP prioridad Alta: Total de casos de prueba clasificados como
alta.
Total CP prioridad Media: Total de casos de prueba clasificados como
medio.
Total CP Baja: Total de casos de prueba clasificados como bajo.
Total CP de pruebas: Total de casos de prueba definidos.

Una vez se tenga claro los puntos definidos se procede a construir el

siguiente cuadro, para la entrega se debe borrar la anterior información.

Nombre de la Aplicación a
Evaluar:
Grupo de trabajo:
Líder:
Probadores:

Objetivo de la Prueba: (Máximo 250 palabras)

íte Respon Módu Id Caso Nombre del Descripción Priori

m sable lo de prueba Caso de dad
Prueba
1
2
3
4
 Total CP prioridad
Alta:
Total CP prioridad
Media:
Total CP Baja:
Total CP de pruebas:

ANEXO N° 2 – MATRIZ DE RIESGOS

Matriz de Riesgos

Proyecto:

Fecha
inicio:

Fecha fin:

Riesgo Evaluación

Tipo de Impacto Probabilidad Respuest

Señal Autor
riesgo (A/M/B) (A/M/B) Valor Nivel a
Id. de Resultado
(1 al 9) (A/M/B)
Riesgo Origen
 Identificar
una señal
de alarma o
advertencia Especifica
de que el r la acción
riesgo que el
Describir puede Con base equipo del
el riesgo ocurrir. en el valor proyecto
Especificar
Categoriz identific Ejemplo: el de la llevará a
cuál sería el Evaluar la De acuerdo Nombre del
ación del ando la proveedor Evaluar el columna cabo para
efecto en probabilid con la responsable
No. de riesgo causa. no impacto en el anterior, eliminar,
caso de que ad de que matriz de del equipo del
identificació (Técnico, Ejemplo proporciona proyecto en se transferir
el riesgo el riesgo probabilidad proyecto que
n del riesgo, cronogra : una caso de que establece o mitigar
ocurra. ocurra. e impacto llevará a cabo
numeración ma, Si no se respuesta el riesgo el nivel la
Ejemplo: (Alta, que se la acción de
consecutiva experienci recibe a concreta, ocurra. (Alto, del amenaza
entonces se Media y muestra respuesta al
a, tiempo sólo da Medio y Bajo) riesgo: o para
retrasará el Baja) abajo riesgo.
alcance…) el largas a la alto, explotar,
proyecto.
equipo.. entrega del medio, mejorar o
. equipo. bajo compartir
Recuerda una
que no oportunid
todos los ad.
riesgos
tienen
sintomas.

Nivel
Valor
Riesgos

6a9 Alto

3y4 Medio

1y2 Bajo
Evaluación de los riesgos.

De acuerdo a los riesgos identificados y la clasificación dada a la

valoración y probabilidad, en el siguiente cuadro se ingresa la cantidad
de riesgos por probabilidad e impacto.

B M A

Anexo N° 3 - PLAN DE TRABAJO DE PRUEBAS DE SOFTWARE

1 INFORMACIÓN DEL PROYECTO

Nombre del proyecto: Pruebas de Aceptación

***Nombre de los integrantes del
Preparado por: grupo***

El plan de pruebas pretende definir de manera clara, sin ambigüedades

el alcance y objetivos específicos de las pruebas, de acuerdo con el
nivel, tipo de la prueba y de las características de calidad para probar,
las cuales son: facilidad de administración, seguridad, exactitud,
completitud, recuperación ante fallas consistencia, eficiencia, interfaz,
integridad y resistencia.

2 OBJETIVO DE LA PRUEBA

Detectar fallas no es el objetivo primordial de las pruebas, el verdadero

objetivo de las pruebas se fundamenta en los requerimientos que han
sido previamente especificados y que fueron la base para la construcción
del software que se desea probar.

Verificar la funcionalidad del sistema de información ***Nombre de la

aplicación***

***Dar alcance a los objetivos planteados en la prueba***

3 ALCANCE DE LA PRUEBA

El tipo de pruebas a realizar es a nivel funcional donde se validará la

exactitud, completitud, consistencia interfaz e integridad del sistema.

El alcance para el proceso de pruebas funcionales a abarcar el Análisis el

cual consta de la planeación, el Diseño consta del diseño de las pruebas
y la Ejecución consta de la ejecución, evaluación y cierre del proceso de
pruebas funcionales.

Se validará la funcionalidad de cada sistema y su integración con los

otros sistemas.
***Dar alcance al alcance de la prueba***
4 GRUPO DE TRABAJO Y RESPONSABILIDADES

4.1 Definición del grupo:

Líder de la prueba: ***Nombre de la persona seleccionada para

líder***
Probadores ***Nombre de los probadores***

4.2 Responsabilidades específicas:

***Dar alcance definiendo responsabilidades a cada Rol***

Rol Actividades

Probadores • Contextualización de aplicaciones

• Gestión de incidencias (reporte y solución
de incidencias)
• Estrategia de pruebas
• Informes de avance
• Gestión Casos de prueba
Líder • Reuniones de seguimiento de los analistas
• Análisis y evaluación de métricas
• Análisis y evaluación de los informes de fin
de mes

5. METODOLOGÍA

La ejecución del proyecto que cubre el presente Plan de Pruebas se

realiza en las siguientes etapas:
Estas fases son apoyadas por los procesos que se muestran en la parte
inferior de la gráfica.

***Dar alcance definiendo cada fase o etapa del proyecto***

5.1. Herramientas de apoyo en el proceso de pruebas

Se utilizaran las siguientes plantillas para el desarrollo del proyecto:

• Plan de pruebas
• Estimación de los casos de prueba
• Propuesta de pruebas
• Diseño de alto nivel
• Diseños de bajo nivel
• Gestión de los casos de prueba
• Gestión de incidencias
• Informe de evaluación del producto

5.2. Estrategia Respecto a la Gestión de defectos

Los defectos encontrados durante la ejecución de las pruebas serán

registrados en la plantilla “Gestión de incidencias”.
En la plantilla se lleva el control de las incidencias detectadas por cada
módulo y ciclo de pruebas.

***Dar alcance estrategias para gestión de defectos***

5.3. Reglas para la clasificación de defectos (incidencias y

fallos)

Todos los defectos serán registrados en una plantilla de apoyo, para

generar indicadores.

5.3.1. Naturaleza

Categoría Descripción general

Ambiente Se manifiesta en el momento que el ambiente de pruebas

este funcionando incorrectamente, o el sistema está mal
configurado o parametrizado.

Datos Se manifiesta cuando los datos existentes no están de

acuerdo a la estructura definida para el buen
funcionamiento del software.

Documen Se manifiesta cuando la documentación está mal definida

tación o existe ambigüedad.

Funcional Se manifiesta cuando el funcionamiento del software no

idad está de acuerdo con las especificaciones y requisitos del
mismo.

Hardwar Se manifiesta cuando existe algún problema en la parte

e del hardware del sistema. Fallas en los periféricos o
herramientas utilizadas para la ejecución de pruebas
Ortografí Se manifiesta cuando existe una palabra u oración mal
a escrita de acuerdo al idioma en que se está probando.

Presenta Se manifiesta cuando el software no cumple con los

ción requisitos mínimos de lineamientos gráficos.

Rendimie Se manifiesta cuando el desempeño del sistema es muy

nto bajo, de acuerdo a los requisitos no funcionales.

Segurida Se manifiesta por la gestión de la seguridad de la

d funcionalidad, no está controlada ni alineada con los
requisitos del negocio o establecidas en la documentación

Software Se manifiesta cuando existe algún problema en la parte

del software como la convivencia con otros programas.

5.3.1.1. Tipo de Incidencia

Categoría Descripción general

Defecto Corresponde a una falla detectada en el software

Consider Corresponde a una duda que se pueda presentar sobre

ación un posible comportamiento anormal.

Sugerenc Es una propuesta para mejorar alguna funcionalidad o

ia parte del producto de software por parte del Probador.

Cambio/ Es una propuesta para mejorar alguna funcionalidad o

Mejora parte del producto de software por parte del Usuario.

5.3.1.2. Severidad

Categoría Descripción general

Alto Funcionalidad inoperante, sin alternativa que permita su

operación.
 Medio Funcionalidad opera parcialmente, hay alternativa para
continuar con la operación

Bajo Incidencia menor, permite la operación de la

funcionalidad (cosmético).

5.3.1.3. Prioridad

Categoría Descripción general

Baja El defecto es superficial o cosmético y se puede proyectar

su solución para más adelante incluyendo una próxima
versión.

Normal El defecto puede esperar para la solución del problema

Alta El defecto requiere una respuesta en el menor tiempo

posible

5 CRITERIOS

***Determinar los criterios que se tomaran en cuenta en el

proyecto***

5.1 Criterios de aceptación

El proceso de pruebas funcionales se da por terminado una vez que:
• Se han ejecutado el 100% de los casos de prueba diseñados para
este proyecto y su resultado ha sido exitoso.
• El 100% de los defectos detectados en la ejecución de pruebas han
sido solucionados y se ha validado dicha solución por parte de
pruebas.
• Cuando, a pesar de no cumplirse en su totalidad el punto anterior,
el dueño del negocio, gerente manifieste que los defectos no son
críticos para salir a producción (los defectos pasarían
inmediatamente a un estado terminal de “Siguiente Versión”).
5.2 Criterios de priorización
Los casos de prueba serán priorizados según la necesidad que requiera
el proyecto, por lo cual la ejecución de los casos de prueba de cada uno
de los requerimientos a certificar será concertada con el cliente.

5.3 Técnica medición

Se cuenta con indicadores de gestión, indicadores de calidad de
software, indicadores de cumplimiento que serán implementados en el
proceso de certificación de los requerimientos.

5.4 Criterios de repetición

Se contemplan tres ciclos de ejecución
Prueba de Humo: Se realiza para garantizar que no se presenten
problemas funcionales críticos y/o de ambiente que impliquen la
devolución del aplicativo
Ciclo1: Ejecución de los casos de prueba disponibles en la primera
versión recibida.
Ciclo2: En esta actividad se revisa las correcciones realizadas sobre los
problemas o defectos en que se hayan reportado durante la ejecución
del ciclo 1.
Regresión: En esta actividad se revisa que los errores que se hayan
reportado y corregido, no hayan afectado las funcionalidades que venían
comportándose correctamente, validando que no se repliquen los
errores y todo el aplicativo funciona óptimamente.

6 Seguimiento y reporte

Mensualmente se presentará un reporte general del estado del avance

del proceso de certificación.
Estos informes y reportes serán comunicados en conjunto al equipo de
pruebas, al líder de proyecto, al equipo del proyecto que dé a lugar

6. ENTREGABLES DE PRUEBAS

Los entregables producidos durante el proceso de pruebas son:

 Nombre documento Propósito

Propuesta de Este documento describe detalles particulares

Pruebas del proceso de pruebas de cada proyecto
derivados del plan general de pruebas

Diseño de alto nivel Este documento describe los objetivos de las

pruebas

Estimación de Este documento es realizado con el fin de

Tiempos tener un estimado del tiempo que se requiere
para el desarrollo del proyecto, incluyendo las
fechas inicial y final estimadas de cada una
de las fases y del proyecto.

Diseño de Casos de Contiene diseño detallado de cada uno de los

Pruebas casos de prueba del proyecto

Informe de Avance Este informe debe mostrar cual ha sido el

avance de las pruebas en un periodo
determinado de tiempo.

Informe Final Es un documento en donde se indica como ha

(Evaluación de las sido la ejecución de las pruebas, que
pruebas) porcentaje de pruebas se han cubierto,
cuantos errores han sido generados, entre
otros.

7 SUPUESTOS PARA EL ÉXITO DE LA PRUEBA

***Determinar los supuestos para el éxito de las pruebas**

• La aplicación debe estar correctamente instalada en el ambiente de

pruebas.
• La aplicación ha sido verificada en el ambiente de pruebas por el
desarrollador, previo a su entrega al equipo de calidad.

• En caso de que el aplicativo tenga interacción con otros módulos o

aplicaciones la comunicación entre estos estará disponibles y en un
nivel óptimo siempre.

• Se cuenta con la documentación actualizada, siendo esta la última

versión y sobre la cual se llevará a cabo el proceso de pruebas.

• La entrega de los datos del ambiente de pruebas será dada por el

usuario para garantizar el desarrollo de la prueba.

8 CRONOGRAMA DE PRUEBAS

El cronograma se encuentra en la propuesta de las pruebas, el

cronograma está estimado para realizar en 4 meses.

9 HISTORIA DE CAMBIOS DEL REGISTRO

- ***Fecha de creación***
- ***Autor***

***Los datos registrados entre los asteriscos, son datos que

debe complementar el estudiante, una vez lo realice, deben
borrarlo***

Actividades a desarrollar ANEXO N° 4 - Revisión Estática

Informal
 La revisión estática informal se debe realizar en el servicio de ayuda o
manual de usuario de la aplicación. Este tipo de revisión estático se
realiza en un documento con el fin de practicar la estructura del tipo
seleccionado.

La estructura del tipo seleccionado con un revisor, quién es el estudiante

hay ausencia de un proceso formal, los resultados se documentan, por
lo tanto se requiere de las pantallas o imágenes que soporten el proceso
realizado.

El objetivo es probar estáticamente los documentos.

1. Descripción del documento: Describir como está estructurado el

servicio de ayuda o manual de usuario de la aplicación seleccionada.

2. Prueba estática: Verificar el servicio de ayuda o manual de usuario

por medio de los siguientes criterios:

Criterios de Evaluación Cumple No Cumple No

Aplica
1. El servicio de ayuda o manual de usuario es
claro, usable; el usuario interpreta como
manejar la aplicación o como solucionar las
dudas que tiene
2. El servicio de ayuda o manual de usuario tiene
buena ortografía y redacción.
3. El servicio de ayuda o manual de usuario
maneja imágenes para clarificar al usuario el
proceso mencionado.
4. Solo sí el servicio de ayuda o manual, maneja
links.
 Los links que el servicio de ayuda o manual
tiene asociado tienen funcionamiento, es decir
no están rotos.
5. El servicio de ayuda o manual, maneja links
maneja algún tipo de encuesta de satisfacción.

El servicio de ayuda o manual de usuario que tenga algún criterio

mencionado anteriormente, marcado como No Cumple, será un defecto
detectado en las pruebas estáticas.

3. Evidencias del Proceso:

- Por cada punto del anterior cuadro, se documenta por medio de

imágenes el proceso realizado, así como se hace una breve
descripción. (Máximo 3 imágenes)

ANEXO N° 5 - ESTIMACIÓN DE TIEMPOS

La técnica de estimación de tiempos es de Juicio de expertos; con la

navegación realizada en la aplicación y modulo seleccionado en la
unidad 1, el estudiante conoció la aplicación, en este sentido se realizar
una estimación para proyectar el tiempo que el probador invertirá al
diseña y ejecutar los casos de prueba.

Para realizar la estimación de tiempos se requiere el diseño de alto nivel

realizado en la unidad 2.

1. Asignación de Pesos por fases:

Se debe asignar por cada fase un peso de acuerdo al impacto del caso
de prueba.

A continuación, se hace unas recomendaciones, estos pesos pueden

cambiarlos, si así lo consideran.

• Métricas de estimación para Diseño: Se debe asignar por cada

o Impacto Alta: Peso en Minutos, (120 min)

o Impacto Media: Peso en Minutos, (90 min)
o Impacto Baja: Peso en minutos, (60 min)

• Métricas de estimación para Ejecución:

o Impacto Alta: Peso en Minutos, (100 min)

o Impacto Media: Peso en Minutos, (70 min)
o Impacto Baja: Peso en minutos, (50 min)

• Métricas de estimación para Documentación:

o Impacto Alta: Peso en Minutos, (120 min)

o Impacto Media: Peso en Minutos, (90 min)
o Impacto Baja: Peso en minutos, (60 min)

2. Generar Estimación.

De acuerdo a los casos de prueba definidos en el diseño de alto

nivel, por cada etapa e impacto asignar los casos de prueba, los
 pesos multiplicarlos por la cantidad de casos de prueba y dividirlos
por 60, de esta forma en cada etapa se determina el tiempo total.

Etapa Diseño Ejecución Documentación

Impact Alta Media Baja Alta Media Baja Alta Media Baja
o
Peso 120 90 60 100 70 50 120 90 60
Casos # de # de # de # de # de # de # de # de # de
de Casos Casos Casos Casos Casos Casos Casos Casos Casos
Prueba de de de de de de de de de
prueb prueb prueb prueb prueb prueb prueb prueb prueb
a a a a a a a a a
defini definid defini defini definid defini defini definid defini
dos os dos dos os dos dos os dos
como como como como como como como como como
impac impact impac impac impact impac impac impact impac
to o alto to to o alto to to o alto to
alto en el alto alto en el alto alto en el alto
en el diseño en el en el diseño en el en el diseño en el
diseñ de diseñ diseñ de diseñ diseñ de diseñ
o de alto o de o de alto o de o de alto o de
alto nivel alto alto nivel alto alto nivel alto
nivel nivel nivel nivel nivel nivel
Sub- =Peso =Peso =Peso =Peso =Peso =Peso =Peso =Peso =Peso
Total *# * # de * # *# * # de * # *# * # de * #
de casos de de casos de de casos de
casos de casos casos de casos casos de casos
de prueb de de prueb de de prueb de
prueb a prueb prueb a prueb prueb a prueb
a a a a a a
Total Sumar el resultado del Sumar el resultado del Sumar el resultado del
sub-total de las tres sub-total de las tres sub-total de las tres
columnas. columnas. columnas.
 3. Totalizar estimación:

Responsable Modulo Diseño Ejecución Documentación

Nombre de la Módulo de Total de Total de Total de tiempo
persona ejercicio tiempo tiempo etapa etapa
responsable práctico etapa Ejecución del Documentación del
Diseño del cuadro cuadro anterior
cuadro anterior
anterior
TOTAL

ANEXO N° 6 - MATRIZ DE TRAZABILIDAD

La matriz de trazabilidad se construye con base a los casos de prueba

construidos por el grupo y por módulo en la Unidad 2, esto se realiza para
saber la relación que existe entre los casos de prueba y los módulos de la
funcionalidad. Ej, Para un sistema de compras se requiere pasar por el
módulo de autenticación, por lo tanto, en la matriz estos casos de prueba
de autenticación afectan el módulo de compras.
La matriz de trazabilidad ayuda a identificar, que casos se debe probar,
sí un caso de prueba ha fallado, por ejemplo, en un ciclo de regresión se
acude a la matriz, para identificar los casos de prueba que afecta los casos
de prueba que fallaron y de esta manera ejecutar los casos de prueba
para poder certificar la aplicación y que esta se pueda poner en un
ambiente de producción.
 Se ha estructurado la siguiente matriz:
Respons Sistema / Nombre Nombre Nombre Nombre Nombre
able Modulo del Módulo del Módulo del Módulo del Módulo del Módulo

Funcionali Funcionali Funcionali Funcionali Funcionali

dad dad dad dad dad

Nombre del X
Caso de
Prueba
Nombre del
Caso de
Prueba

Nombre del
Caso de
Prueba

Responsable: Persona diseñadora del caso de prueba.

Nombre del Módulo: El nombre del módulo es el seleccionado y
trabajado por cada estudiante durante el proyecto.
Funcionalidad: Se describe en una o dos palabras en que consiste.
Nombre del Caso de Prueba: Por cada recuadro se asina un caso de
prueba, el nombre es el definido en el diseño de alto nivel construido en
la unidad 2.
Cada estudiante analiza los módulos existentes y casos de prueba
propuestos, con una X identifica los casos de prueba que afecta tanto el
módulo seleccionado, como a los otros módulos del sistema.

ANEXO N° 7 - PROPUESTA DE PRUEBAS

1. Datos generales de la prueba:

Nombre Proyecto : Nombre del sistema de información seleccionado

Líder: Nombre del estudiante con rol líder
Probador: Nombre del estudiante con rol probador
Probador: Nombre del estudiante con rol probador
Probador: Nombre del estudiante con rol probador
Probador: Nombre del estudiante con rol probador

2. Alcance de la Prueba:

Describir el alcance de las pruebas.

1. Cronograma

Realizar el cronograma, se debe destinar un tiempo en las actividades

realizadas hasta el momento. Sí se considera se pueden agregar más
actividades.
 El cálculo de horas del ciclo 2 es el 75% del tiempo total estimado en el
ciclo 1.
El cálculo de horas del ciclo 3 es el 85% del tiempo total estimado en el
ciclo 1.

Tiempo
Fecha
Dedicación
Actividad Descripción
Fecha Fecha
Horas
Inicio Fin

PLANEACIÓN PROYECTO

Análisis de la aplicación,
navegación del sistema

Análisis Análisis de las pruebas a

realizar

Diseño alto nivel

TOTAL HORAS DEDICADAS A ANALISIS

Se calcula
Diseño de los casos con base a la
Diseño
de prueba estimación
realizada.

TOTAL HORAS DEDICADAS A

ANALISIS/DISEÑO

Verificación Ambiente de
Pruebas / Prueba de Humo
Ejecución
Ejecución Ciclo 1 Se calcula
con base a la
 Tiempo
Fecha
Dedicación
Actividad Descripción
Fecha Fecha
Horas
Inicio Fin

PLANEACIÓN PROYECTO

estimación
realizada.

Documentación Evidencias Se calcula

con base a la
estimación
realizada.

Reunión con usuario para

verificar evidencias

Verificación Ambiente de
Pruebas / Prueba de Humo

Ejecución Ciclo 2 Se calcula

con base a la
estimación
realizada.

Documentación Evidencias Se calcula

con base a la
estimación
realizada.

Reunión con usuario para

verificar evidencias

Verificación Ambiente de
Pruebas / Prueba de Humo

Ejecución regresión Se calcula

con base a la
estimación
realizada.
 Tiempo
Fecha
Dedicación
Actividad Descripción
Fecha Fecha
Horas
Inicio Fin

PLANEACIÓN PROYECTO

Documentación Evidencias Se calcula

con base a la
estimación
realizada.

Pruebas de aceptación por

parte del usuario

TOTAL HORAS EJECUCIÓN

2. Diagrama

Realizar un diagrama GANTT con base a las fechas propuestas y

tiempos definidos.

3. Características que no serán probadas

- Áreas funcionales que se excluyan del alcance inicial

- Pruebas de interfaz con otros sistemas.
- Cualquier otra característica que no vaya a ser probada
 4. CRITERIOS GENERALES

Criterios Para Certificar el Aplicativo

• Los criterios se encuentran definidos en el plan de pruebas.

Criterios Para no Certificar el Aplicativo

• Cuando, a pesar de no cumplirse los criterios de certificación de un

aplicativo, el cliente exija la liberación del producto a pruebas, sin
ningún tipo de condicionamiento

Para la entrega del trabajo borrar la letra en rojo