Número Acción Fecha acción Resumen Responsable

Aprobado por Distribuido a

versión C,M,D,A (1) (2) cambios de la acción

Se C
1.0 C 02/10/2022 VBG VBG Equipo
Documento

C=Creación, M=Modificación, D=Distribución, A=Aprobación (Excluyentes)

El contenido de la columna Fecha Acción (AAAA-MM-DD) es requerido y se diligencia de la

siguiente manera: Escribir para las acciones de Creación y Modificación del documento la
fecha de iniciación de la acción, para la de Aprobación la fecha de su finalización y para
Distribución la fecha de envío del documento.

Metodología Básica V1

1. Introducción

La metodología de pruebas de software es un conjunto de procesos y actividades que se

utilizan para evaluar la calidad de un producto de software. El objetivo de las pruebas es
identificar y corregir los errores y defectos en el software antes de que se ponga en
producción.

La metodología básica V1 es una metodología de pruebas de software ágil que se utiliza en

el Area. La metodología se basa en los siguientes principios:

 Inclusión: Todas las partes interesadas, incluidos los desarrolladores, los usuarios y
los testers, participan en el proceso de pruebas.
 Iteración: Las pruebas se realizan de forma iterativa, lo que permite identificar y
corregir los errores de forma rápida y eficiente.
 Automatización: Las pruebas automatizadas se utilizan para reducir el tiempo y el
esfuerzo necesarios para realizar las pruebas.

Proceso de pruebas
El proceso de pruebas de la metodología básica V1 se divide en las siguientes etapas:

 Planificación: En esta etapa, se define el alcance de las pruebas, se identifican los

riesgos y se crea un plan de pruebas.
 Diseño: En esta etapa, se diseñan los casos de prueba que se utilizarán para evaluar
el software.
 Ejecución: En esta etapa, se ejecutan los casos de prueba y se registran los
resultados.
 Análisis: En esta etapa, se analizan los resultados de las pruebas para identificar los
errores y defectos.
 Corrección: En esta etapa, se corrigen los errores y defectos identificados.

Texto revisado

Pasos básicos que debemos tener en el proceso de ejecución de las pruebas en ICETEX:

1. Solicitud de la prueba

 Evidencia de la solicitud: Debe existir evidencia de la solicitud desde el cliente, como

un correo electrónico, un enlace a la HU o un elemento del backlog en Azure.
 Tipos de solicitudes: Las solicitudes pueden ser por planificación, por requerimiento
específico o por Fastrack.
 Checlist inicio de prueba.docx , Aplicación del CHECK LIST de Inicio de Prueba

2. Recibir documentación o explicación del negocio y/o desarrollo

 Documentación: La documentación debe estar disponible para los probadores y

debe estar guardada en un repo físico o en Azure.
 Validación de la documentación: La documentación debe ser validada por un
probador para garantizar que permita comprender el requerimiento.
 Generación de los criterios de aceptación: Los criterios de aceptación deben ser
generados durante la reunión de planificación, con la participación de los
probadores, el negocio y el desarrollo.
 Reunión de contextualización y refinamiento de HU: Se debe realizar una reunión de
contextualización y refinamiento de HU para asegurar que todos los involucrados
tengan un entendimiento común del requerimiento.
3. Estimación: Cuando donde y como estimar. Guillermo. Estimar horas de la prueba y que
sea aprobado en el formato.

 Punteo de las pruebas: El punteo de las pruebas debe realizarse en horas.

 Recomendación: Las horas deben ser mínimo el 50% de lo que se demore desarrollo.
 Estimación de pruebas automatizadas: La estimación de las pruebas automatizadas
debe realizarse teniendo en cuenta los puntos de control y las implicaciones
técnicas.

4. Construir el plan de pruebas

- El plan de pruebas es un documento que describe el alcance, los objetivos,

los riesgos, la estrategia y la ejecución de las pruebas. Debe ser elaborado por
los probadores, con la participación del negocio y el desarrollo.
- En Azure DevOps, construir el plan de pruebas para cada prueba a realizar:
- Alcance:
- Definir lo que se probará y lo que no se probará.
- Considerar los requisitos funcionales, no funcionales y de seguridad.
- Identificar los casos de uso y escenarios de prueba.
- Riesgos:
- Identificar los riesgos potenciales que podrían afectar a las pruebas.
- Desarrollar estrategias para mitigar los riesgos.
- Precondiciones de ejecución:
- Definir los requisitos previos para ejecutar las pruebas.
- Garantizar que los recursos necesarios estén disponibles.
- Estrategia de prueba:
- Desarrollar una estrategia para probar los casos de uso y escenarios identificados.
- Considerar los métodos de prueba manuales y automatizados.
- Calidad de la documentación para la prueba:
- Asegurar que la documentación de las pruebas sea clara, concisa y fácil de seguir.
- Utilizar un lenguaje y una terminología que sean comprensibles para todos los
involucrados.
- El plan de pruebas se debe compartir con el cliente y/o Célula. (Antes de
iniciar Diseño):
- Enviar el plan de pruebas al cliente y/o Célula para su revisión y aprobación.
- Recibir comentarios del cliente y/o Célula y realizar las modificaciones necesarias.
- Obtener la aprobación formal del plan de pruebas. Si es posible correo del
funcional y/o pm o líder.
- Plan de Pruebas Automatizadas:
- Definir los objetivos de las pruebas automatizadas.
- ¿Cuáles son los objetivos específicos de las pruebas automatizadas?
- ¿Qué se espera lograr con las pruebas automatizadas?
- Definir las herramientas de automatización.
 - ¿Qué herramientas se utilizarán para automatizar las pruebas?
- ¿Cuáles son las capacidades y limitaciones de estas herramientas?
- Definir los puntos de control de las pruebas automatizadas.
- ¿Qué se probará con las pruebas automatizadas?
- ¿Cuáles son los criterios de aceptación para las pruebas automatizadas?
- Crear Diagramas de Flujo de Pruebas a Automatizar.
- ¿Cómo se ejecutarán las pruebas automatizadas?
- ¿Qué pasos se realizarán?
- Plan de Pruebas Performance:

5. Diseño

El diseño de pruebas es el proceso de planificación y creación de un conjunto de pruebas

para verificar que un sistema cumple con sus requisitos. Debe ser realizado por los
probadores, con la participación del negocio y el desarrollo.

Con la aprobación del plan de pruebas verificada y guardada en el repositorio físico y en la

matriz de trazabilidad el link correspondiente iniciar con el diseño:

 Aprobación del plan de pruebas: Por cliente formal. Si es posible Funcional y PM

 El plan de pruebas debe ser aprobado por el cliente y/o Célula.
 La aprobación debe ser formal y por escrito.
 El plan de pruebas debe guardarse en el repositorio físico y en la matriz de
trazabilidad.

El diseño se realizará en la plantilla básica para exportar en Azure devops.

 Plantilla de diseño:
 Se utilizará una plantilla básica para el diseño de pruebas.
 La plantilla debe ser exportable a Azure DevOps.

El diseño en Excel debe quedar en el repo físico y al ser aprobado se sube al Azure devops.
(Requerimos capacitación para saber cómo subirlo al igual que el equipo ICETEx)

 Subida del diseño a Azure DevOps:

 El diseño debe ser subido a Azure DevOps una vez sea aprobado.
 Se requiere capacitación para subir el diseño a Azure DevOps.

Al terminar el Diseño este debe ser enviado al analista del negocio para su aprobación.
  Aprobación del diseño:
 El diseño debe ser aprobado por el analista del negocio.
 La aprobación debe ser formal y por escrito.
 El diseño debe guardarse en el repositorio físico y en la matriz de trazabilidad.

La aprobación se debe dar por mail Formalmente por parte del cliente PM y Negocío o
funcional. Manos ICETEX

 Aprobación formal:
 La aprobación debe ser formal y por escrito.
 El correo electrónico debe indicar que el diseño ha sido aprobado.

Esta debe quedar en el repo Físico y el link en la matriz de trazabilidad visual que el link de
los diseños en Azure.

 Documentación del diseño:

 El diseño debe documentarse de manera clara y concisa.
 La documentación debe guardarse en el repositorio físico y en la matriz de
trazabilidad.

El mail de aprobación debe salir con la nota de si no se aprueba en 36 horas se considerará

aprobado, y se debe poner como riesgo si esto sucede y reportar que esto afecto el proceso
de ejecución, porque se retrasó justificando el inconveniente.

 Procedimiento de aprobación:
 Si el diseño no es aprobado en 36 horas, se considerará aprobado.
 Este retraso debe ser considerado como un riesgo y reportado.

Diseño de pruebas automatizadas:

 Selección de casos de prueba:

 Se deben identificar los casos de prueba más críticos y relevantes para la
funcionalidad que se está probando.
 No es necesario automatizar todas las pruebas.
 Pruebas de regresión:
 Se deben identificar y automatizar las pruebas que se deben ejecutar de manera
continua para garantizar que las nuevas actualizaciones no rompan la funcionalidad
existente.
 Validación de resultados:
 Se deben establecer criterios claros para validar los resultados esperados durante la
ejecución de las pruebas.
6. Ejecución: Pedir dentro del Sprint UAT con el usuario final , en se defecto usuario
funcional o de negocio que asuma el rol y o DEMO(termino ICETEX) F80 con la firma de
ese usuario. Mas la nuestre (ICETEX)

- La ejecución de pruebas es el proceso de realizar las pruebas diseñadas para verificar

que un sistema cumple con sus requisitos. Debe ser realizado por los probadores,
con la participación del negocio y el desarrollo.
- Ejecución de pruebas manuales:
- Soportes:
- Se deben tomar soportes de absolutamente todo.
- La forma de tomar los soportes será con un print completo de pantalla.
- Se deben marcar los casos de prueba pasados o fallidos en el Azure devops.
- Los soportes se deben dejar en repo físico y en la matriz de trazabilidad el link
correspondiente.
- Regresión y UAT:
- Debe estar el usuario Funcional o de negocio.
- Debe quedar conformidad del usuario de negocio sea mediante la verificación de los
soportes o UAT en vivo.
- Debemos generar carta de aceptación y enviarla al cliente para su aprobación.
- Sin carta de aceptación aprobada debemos levantar la mano para que no se pase a
producción.
- Ejecución de pruebas automatizadas:
- Antes de ejecutar cualquier automatización, es necesario verificar el funcionamiento
del entorno y asegurarse de que la funcionalidad ya haya sido validada por un
analista de pruebas de manera manual.
- Verificar que los datos de prueba estén disponibles y sean consistentes con los casos
de prueba automatizados.
- 7. Reportes de Issues
- Los Issues son los defectos o errores encontrados durante la ejecución de pruebas.
Se deben reportar en el Azure devops del cliente en un tablero específico y se deben
asociar a los casos de prueba y testplan.
- Soportes del error:
- Los soportes del error deben quedar en el repo físico.
- Gestión de Issues:
- Se debe gestionar con desarrollo los posibles tiempos de solución, para tener
claridad la afectación del sprint o tiempos ociosos.
- En la matriz de trazabilidad se debe dejar el link del error del azure y el link de los
soportes del error.
- La prueba se considera cerrada solo si los Issues están en un estado termina.
- 8. Cierre de Prueba
 - El cierre de prueba es el proceso de finalizar las pruebas y documentar los
resultados.
- Informe de cierre:
- Se debe generar un informe de cierre con los resultados de las pruebas.
- El informe debe incluir información sobre los errores encontrados, su impacto y las
acciones tomadas para corregirlos.
- El informe debe ser aprobado por el cliente y/o Célula.
- Explicación de los cambios realizados:
- Ejecución de pruebas manuales:
- Se ha añadido una oración para aclarar que los soportes deben ser completos.
- Se ha añadido una oración para indicar que los casos de prueba deben marcarse
como pasados o fallidos en Azure DevOps.
- Se ha añadido una oración para indicar que los soportes deben guardarse en el repo
físico y en la matriz de trazabilidad.
- Se ha añadido una oración para indicar que la UAT debe contar con la conformidad
del usuario de negocio.
- Se ha añadido una oración para indicar que la carta de aceptación debe ser enviada
al cliente para su aprobación.
- Se ha añadido una oración para indicar que la carta de aceptación debe ser aprobada
antes de pasar a producción.
- Se ha añadido una oración para indicar que las pruebas automatizadas deben
ejecutarse después de que la funcionalidad haya sido validada de manera manual.
- Reportes de Issues:
- Se ha añadido una oración para indicar que los soportes del error deben guardarse
en el repo físico.
- Se ha añadido una oración para indicar que se debe gestionar con desarrollo los
posibles tiempos de solución de los Issues.
- Se ha añadido una oración para indicar que la prueba se considera cerrada solo si los
Issues están en un estado termina.
- Cierre de Prueba:
- Se ha añadido una oración para indicar que el informe de cierre debe incluir
información sobre los errores encontrados, su impacto y las acciones tomadas para
corregirlos.
- Se ha añadido una oración para indicar que el informe debe ser aprobado por el
cliente y/o Célula.
-
Etapa Peso por Etapa
Planeación 10,0%
Diseño 20,0%
Ejecución 40,0%
Regresión 0,0%
Aceptación 0,0%
Documentación / Gestion Certificacion 5,0%
Total Certificación 75,0%
 Etapa Horas Estimadas
Planeación 40,0
Diseño 60,0
Ejecución 125,0
Regresión 0,0
Aceptación 0,0
Documentación / Gestion Certificacion 40,0
Total Certificación 265,0

Nombres Estándar de Documentos y Mails. DEVOPS.

Documento Nombre / Asunto Tag

Plan de Pruebas PP_NOMBREPROYECTO
IA mail Informe de Avance/Status -
Proyecto - Sprint xx -
dd/mm/aaaa
Estimación ET_NOMBREPROYECTO
Issues CCD
HU Plan de Pruebas CCD, PLANPRUEBAS
Diseños casos de Prueba: Se CCD “Si aplica”
crea es en un Test Plan

- Carta de Cierre o F80 CC_Proeyecto_SPRINT_ddmm

aaaa

- Informes de DEfinido po rMAnuela

Performance:

- Informes que se DEfinido por Juan Carlos

generar desde el
Serenity:

Subtareas CCD

Estos son pendientes de definición.

 - El reporte de tiempos debe ser homologado con la matriz de trazabilidad para poder
fusionarlos a nivel de requerimientos.
- Facturación:
- El reporte de tiempos homologado es el insumo de la facturación.
- Matriz de trazabilidad:
- El Cliente mapeará la matriz de trazabilidad en Azure como proceso.
- Ejecución:
- El equipo de trabajo deberá realizar un esfuerzo extra para generar la matriz de
trazabilidad, ya que es una información requerida para la facturación. 0,50 30
minutos por 10 horas por proyecto de IA 20 horas en el mes
- (Marco quier más numeros en el IA) posiblemente inventarnos entrega de data
detallda.
- La facturación desde la Coordinación del Proyecto requiere esfuerzo extra debido a
no contar con aplicativos de gestión de proyectos y de pruebas.

Tabla de Documentos de Lectura

Documento Descripción Link

2_._ANEXO_1_ESPECIFICACIONES_TÉCNIC El presente documento establece Transición - Fabrica
AS - 23 (MOD Testers) (1) las especificaciones técnicas para Testing - OneDrive
la licitación cuyo objeto es (sharepoint.com)
“Contratar los servicios por medio
del esquema de fábrica de
pruebas funcionales, no
funcionales y de automatización
que permitan garantizar la calidad
de los desarrollos de software
implementados por ICETEX.”
ESPECIFICIDAD PRUEBAS FUNCIONALES ESPECIFICIDAD PARA PRUEBAS Modelo VBG -
CONSTRUCCION V1 (1) FUNCIONALES EN LA ETAPA DE OneDrive
CONSTRUCCIÓN (sharepoint.com)
ESPECIFICIDAD PRUEBAS PERFORMANCE Especificidad Pruebas Preventivas Modelo VBG -
V1 (1) - Requerimiento Funcionales y OneDrive
básicos no funcionales (sharepoint.com)
ESPECIFICIDAD PRUEBAS EN REQUISITOS ESPECIFICIDAD PARA PRUEBAS Modelo VBG -
V1 BORRADOR (1) PERFORMANCE OneDrive
EN LA ETAPA DE CONSTRUCCIÓN (sharepoint.com)
Diagrama servicio de Consultoría para Diagrama, plan de trabajo / Modelo VBG -
Procesos (1) proyecto - Asesoría y consultoría OneDrive
(sharepoint.com)
ANS pruebas ANS pruebas Transición - Fabrica
Testing - OneDrive
(sharepoint.com)
Lista de Chequeo Pruebas Proyecto CheckList Pruebas Transición - Fabrica
Testing - OneDrive
 (sharepoint.com)
Checlist inicio de prueba Mediante este documento se Transición - Fabrica
pretende dar una guía al Analista Testing - OneDrive
de Pruebas indicándole los puntos (sharepoint.com)
fundamentales que debe tener en
cuenta para iniciar la Planeación
de una Prueba.
Banco de Pruebas Casos de prueba genéricos Documentos Base
Test - OneDrive
(sharepoint.com)
Diseño ICETEX_Accesibilidad Diseño de casos de prueba Documentos
genéricos basados en la Accesibilidad -
RESOLUCIÓN N° 001519 DE 24 DE OneDrive
AGOSTO DE 2020 (sharepoint.com)
MINISTERIO DE TECNOLOGÍAS DE
LA INFORMACIÓN
Y LAS COMUNICACIONES
Diseño Validaciones para la ejecución de Diseño de casos de prueba Documentos Base
pruebas funcionales genéricos, validaciones para la Test - OneDrive
ejecución de pruebas funcionales (sharepoint.com)
INSTRUCTIVO PARA EL MANEJO DE Indicar las características de Modelo VBG -
REPORTES DE ISSUES V1 26112022 seguimiento y buen manejo de OneDrive
los reportes de Issues y permitir al (sharepoint.com)
equipo encargado del proyecto
de pruebas la correcta utilización
del bugtracker.
Matriz de Trazabilidad. MONITOREO Y CONTROL DEL Transición - Fabrica
SERVICIO - MONITOREO EQUIPO Testing - OneDrive
(sharepoint.com)
IA - Cliente_Proyecto_Funcionalidad Informe Diario de Proyecto / Modelo VBG -
ddmmaaaa - V3-1 Prueba OneDrive
(sharepoint.com)
PlantillaIA Informe Diario de Proyecto / Modelo VBG -
Prueba OneDrive
(sharepoint.com)
Resultados de Ejecución Pruebas RESULTADO DE LA EJECUCIÓN DE Transición - Fabrica
LAS PRUEBAS FUNCIONALES - Testing - OneDrive
Formato (sharepoint.com)
ARBOL NOMBRE FECHA INICIO_v3 Estructura de Carpetas para el Modelo VBG -
almacenamiento de información OneDrive
(sharepoint.com)
Planificar la transición de un servicio de Planificar la transición de un Transición - Fabrica
software testing servicio de software testing de Testing - OneDrive
una compañía a otra requiere una (sharepoint.com)
estrategia bien estructurada para
garantizar una transición fluida y
 sin problemas
Riesgos Genericos de Proyecto:
ANS Descripción del Riesgo
Cumplimiento y Riesgo de que las personas
Participación en asignadas no participen
Eventos y Reuniones activamente en reuniones y
eventos definidos en la
metodología de desarrollo del
ICETEX o en otras relevantes para
el proyecto.
Reporte de Actividades Riesgo de que las personas no
en la Herramienta de reporten sus actividades de
Gestión de acuerdo con los lineamientos de la
Requerimientos metodología en la herramienta de
gestión de requerimientos (Azure
DevOps).
Cumplimiento en Riesgo de que no se genere la
Documentación documentación requerida,
incluyendo plan de pruebas,
diseños y aceptación, de acuerdo
con los compromisos adquiridos
para el proyecto.
Cumplimiento y Riesgo de que el equipo de trabajo
Calidad de los no genere los artefactos
Entregables necesarios, no cumpla con los
estándares de calidad o no
entregue los artefactos en los
formatos de ICETEX.
Rotación de Personal Riesgo de que la rotación de
personal en el equipo afecte la
continuidad y calidad del
proyecto.
Calidad de los Riesgo de que los entregables
Entregables Liberados liberados a producción contengan
a Producción defectos que afecten el
funcionamiento de las
funcionalidades desarrolladas.
Ausentismo Riesgo de que el ausentismo de los
miembros del equipo afecte la
productividad y cumplimiento de
plazos del proyecto.
Medidas de Mitigación
- Establecer un calendario de reuniones
y eventos claros. - Comunicar la
importancia de la participación activa. -
Realizar seguimiento regular y reportar
ausencias justificadas.
- Capacitar al personal en el uso de la
herramienta. - Establecer un proceso de
revisión y validación de los reportes. -
Fomentar la cultura de registro y
seguimiento de actividades.
- Definir claramente los documentos
requeridos para cada fase del proyecto. -
Establecer revisiones y plazos para la
documentación. - Asignar
responsabilidades específicas para la
documentación.
- Establecer estándares de calidad y
formatos de entrega claros. - Realizar
revisiones de calidad de los artefactos. -
Identificar y abordar factores técnicos o
de recursos que afecten la entrega.
- Realizar una gestión proactiva de la
retención de personal. - Tener planes de
contingencia para la rotación inesperada.
- Evaluar el impacto de la rotación en el
proyecto y tomar medidas adecuadas.
- Establecer un proceso de revisión y
pruebas riguroso antes de la liberación. -
Realizar pruebas exhaustivas en
ambientes de producción simulados. -
Tener un plan de respuesta rápida ante
incidentes en producción.
- Tener un plan de contingencia para
reemplazos temporales. - Establecer
políticas claras sobre ausencias
justificadas y no justificadas. -
Monitorear el ausentismo y tomar
medidas para abordar patrones
 preocupantes.

Conclusiones

La metodología básica V1 es una metodología de pruebas de software eficaz que ayuda a

garantizar la calidad de los productos de software del Area. La metodología es ágil, lo que
permite identificar y corregir los errores de forma rápida y eficiente. Además, la
metodología utiliza la automatización para reducir el tiempo y el esfuerzo necesarios para
realizar las pruebas.