Manual de Metodología de Pruebas de Software PDF

MANUAL
DE METODOLOGÍA DE PRUEBAS DE SOFTWARE
Pertenece al procedimiento: Gestionar pruebas de software Fecha

09-Jun-2015
Clasificación: Uso Interno Versión: 7.21 Código: AE3.12-M02
CONTENIDO
1. ESTRATEGIA DEL SERVICIO ......................................................................... 5

1.1. Misión .......................................................................................................................... 5
1.2. Visión ........................................................................................................................... 5
1.3. Objetivos ..................................................................................................................... 5
1.4. Equipo de Trabajo ...................................................................................................... 6

1.4.1. Comunicación del equipo de trabajo ......................................................................................... 7
1.4.2. Roles del proceso ......................................................................................................................... 8
1.4.2.1. Coordinador Claro: ................................................................................................................ 8
1.4.2.2. Ejecutivo de Cuenta Outsourcing: ...................................................................................... 8
1.4.2.3. Líder Proyectos de Pruebas Claro/Outsourcing: .............................................................. 8
1.4.2.4. Analista/Líder de pruebas Claro/ Outsourcing: ................................................................. 8
1.4.2.5. Líder de Servicios Claro/Outsourcing:................................................................................ 8
1.4.2.6. Líder de Desarrollo Claro: .................................................................................................... 8
1.4.3. Matriz de Asignación de Responsabilidades ............................................................................ 8
1.5. Portafolio Del Servicio De Pruebas ......................................................................... 9

1.6. Diagrama De Cubrimiento De Testing ................................................................... 10
1.7. Frentes De Trabajo .................................................................................................. 11
2. PROCESO DE PRUEBAS .............................................................................. 12

2.1. Diagrama General Del Proceso De Pruebas ......................................................... 12
2.2. Etapas Del Proceso De Pruebas ............................................................................ 13
2.2.1. Entregables por etapa ................................................................................................................ 14
2.3. Flujo Del Proceso De Pruebas................................................................................ 15
2.4. Estados De Las Pruebas ......................................................................................... 16

2.4.1. Descripción De Los Estados ..................................................................................................... 16
2.4.2. Diagrama de transición de estados de las pruebas .............................................................. 17
2.5. Comunicaciones Internas Y Externas Del Proceso ............................................. 18
RESPONSABLE: Coordinador Calidad Software APROBÓ: Gerente Calidad Software

APOYO CALIDAD Y MEJORAMIENTO: Pág. 1 de 57
Se prohíbe la reproducción parcial o total de este documento, así como su impresión o digitalización sin permiso previo de la Gerencia de la Calidad y
Mejoramiento, favor consultar en el portal del Sistema Integral de Gestión la versión vigente. Cualquier copia del documento se considera copia no
controlada.
MANUAL

09-Jun-2015
2.6. Gestión De Hallazgos .............................................................................................. 18

2.6.1. Diagrama de estado de hallazgos ............................................................................................ 18
2.6.2. Descripción de estado de hallazgos ........................................................................................ 19
2.6.3. Características al reportar hallazgos ....................................................................................... 20
2.6.4. Características de los hallazgos ............................................................................................... 22
2.6.5. Service Level Agreement - SLA Para Solución De Hallazgos Por Impacto Alto .............. 23
2.7. Herramientas De Apoyo Al Proceso ...................................................................... 23

2.7.1. ALM -HP:...................................................................................................................................... 23
2.7.1.1. Transacciones en la herramienta ALM: ........................................................................... 24
2.7.1.2. Dashboard: ........................................................................................................................... 24
2.7.1.3. Registro Y Actualización De La Información En La Aplicación De Gestión De
Pruebas ............................................................................................................................................... 25
2.7.2. Portal de pruebas: ...................................................................................................................... 25
2.7.3. Mentor Extracción de Datos: ..................................................................................................... 25
2.7.4. Repositorio de Pruebas: ............................................................................................................ 26
2.7.4.1. Estructura Repositorio Pruebas ........................................................................................ 26
2.7.5. Carta de pruebas: ....................................................................................................................... 27
2.7.6. Mapa General de Procesos de Negocio y Sistemas: ............................................................ 27
2.7.7. Load Automatización Data (LAD): ............................................................................................ 28
2.7.8. Racional Robot, Rational Functional Tester IBM: .................................................................. 28
2.8. Soportes De Las Pruebas En El Repositorio ALM ............................................... 28
3. PRUEBAS FUNCIONALES ............................................................................ 29

3.1. ¿Cómo Solicitar Una Prueba Funcional?.............................................................. 29
3.1.1. Validar la solicitud ....................................................................................................................... 29
3.1.2. Asignar ......................................................................................................................................... 30
3.1.3. Planear ......................................................................................................................................... 31
3.1.4. Diseñar ......................................................................................................................................... 32
3.1.5. Ejecutar ........................................................................................................................................ 32
3.1.6. Gestionar hallazgos .................................................................................................................... 33
3.1.7. Finalizar ........................................................................................................................................ 33
3.1.8. Cerrar............................................................................................................................................ 33
3.1.9. Seguimiento en producción ....................................................................................................... 34

controlada.
MANUAL

09-Jun-2015
3.1.10. Gestión control y monitoreo .................................................................................................... 35
4. PRUEBAS NO FORMALES – ADELANTAR PLANEACIÓN Y DISEÑO. ... 38

4.1. ¿Cómo Iniciar Una Prueba No Formal? ................................................................ 38
4.1.1. Asignar ......................................................................................................................................... 38
4.1.2. Planear ......................................................................................................................................... 39
4.1.3. Diseñar ......................................................................................................................................... 39
4.1.4. Gestión control y monitoreo ...................................................................................................... 39
5. PRUEBAS EN REQUERIMIENTOS ............................................................... 40

5.1. ¿Cómo Se Solicita Una Prueba En Requerimientos?....................................... 41
5.1.2. Asignar ......................................................................................................................................... 41
5.1.3. Planear ......................................................................................................................................... 41
5.1.4. Ejecutar - Revisar ....................................................................................................................... 42
5.1.5. Finalizar y Cerrar ........................................................................................................................ 42
6. VALIDACIÓN DE CDR DE VOZ .......................................................................... 43

6.1. ¿Como Solicitar Una Prueba Cdr?......................................................................... 43
6.1.2. Asignar ......................................................................................................................................... 44
6.1.3. Planear - Diseñar- Ejecutar ....................................................................................................... 44
6.1.4. Finalizar y Cerrar ........................................................................................................................ 44
6.2. Tabla De Validación De Cdr’s Para Infracel ......................................................... 45
7. ASPECTOS IMPORTANTES DEL PROCESO ................................................... 47

7.1. Casos Especiales Cancelación, Congelamiento, Devolución ............................ 47
7.2. Causales De Eventos Congelamiento-Devolución-Encolamiento ..................... 47
7.3. Requisitos De Las Pruebas De Desarrollo............................................................ 49
7.4. Causales Del Desfase .............................................................................................. 50

controlada.
MANUAL

09-Jun-2015
7.4.1. Desfases en costos .................................................................................................................... 50

7.4.2. Horas invertidas de más o de menos ...................................................................................... 50
7.4.3. Desfases en cronograma .......................................................................................................... 50
7.5. Estimación De Tiempos .......................................................................................... 50
7.6. Estándar Para Asunto De Los Mails Y Plantillas ................................................. 51
7.7. Adopción De Nuevos Sistemas A Probar ............................................................. 52
7.8. Lecciones Aprendidas............................................................................................. 53

7.9 Estándares De Seguridad ........................................................................................ 53
7.10. Pruebas Compartidas Entre Front Y Back End .................................................. 54
8. GLOSARIO E INFORMACIÓN RELACIONADA SOBRE TESTING ................. 55

9. CONTROL DE CAMBIOS ................................................................................... 56

controlada.
MANUAL

09-Jun-2015
1. ESTRATEGIA DEL SERVICIO
1.1. Misión
Asegurar que los productos de software creados desde la Vicepresidencia de Informática tengan la
funcionalidad, utilidad y calidad requerida para alinearse a los objetivos estratégicos de la
organización destinando los recursos necesarios para optimizar los procesos, metodologías y la
mejora continua de las estrategias de testing.
1.2. Visión
Para el año 2016 consolidarse como el área que presta el servicio de pruebas a los proyectos del
grupo América Móvil, participando desde su nacimiento hasta su puesta en marcha apoyados en
las buenas prácticas de Ingeniería de Software a nivel mundial.
1.3. Objetivos
Los objetivos del servicio de pruebas son:
 Medir la calidad del producto de software.

 Minimizar el riesgo de errores en producción.
 Obtener mayor eficiencia en el servicio de pruebas.
 Reaccionar de manera ágil y oportuna de acuerdo al dinamismo de la compañía.
 Generar confianza en los productos que usan el servicio de pruebas.
 Crecer el potencial, habilidades, conocimiento y competencias de las personas
pertenecientes al grupo de Testing.
 Mejorar continuamente el proceso de pruebas, basados en los estándares internacionales,
mejores prácticas y la experiencia adquirida.

controlada.
MANUAL

09-Jun-2015
1.4. Equipo de Trabajo

controlada.
MANUAL

09-Jun-2015
1.4.1. Comunicación del equipo de trabajo
En este diagrama se visualiza el esquema de comunicación entre el equipo de Claro QA y QA

Outsourcing y estos a su vez con el equipo de Claro Desarrollo y Desarrollo Outsourcing, haciendo
énfasis en la comunicación entre los integrantes del grupo de trabajo y los niveles (estratégico,
táctico y operativo)
Ejemplo: en el nivel operativo el coordinador de QA tiene comunicación directa con el líder de

CLARO de calidad y a su vez el líder de desarrollo se comunica directamente con el líder de claro
para desarrollo, pero para la toma de decisiones entre el líder de desarrollo y el coordinador de QA
debe intervenir los líderes de claro.

controlada.
MANUAL

09-Jun-2015
1.4.2. Roles del proceso
1.4.2.1. Coordinador Claro:

Responsable de gestionar, diseñar, mantener y mejorar el servicio de pruebas de Claro.
1.4.2.2. Ejecutivo de Cuenta Outsourcing:

Responsable de gestionar, mantener y mejorar el servicio de pruebas prestado a Claro.
1.4.2.3. Líder Proyectos de Pruebas Claro/Outsourcing:

Responsable de gestionar, mantener y mejorar el/los proyectos asignados.
1.4.2.4. Analista/Líder de pruebas Claro/ Outsourcing:

Responsable de la planeación, diseño, ejecución y gestión de un proyecto de pruebas específico.
1.4.2.5. Líder de Servicios Claro/Outsourcing:

Responsable de ser único punto de contacto en la gestión de servicios internos (herramientas,
accesos, infraestructura, ambientes, etc.) necesarios para la ejecución de las pruebas.
1.4.2.6. Líder de Desarrollo Claro:

Responsable de realizar las solicitudes de pruebas y de dar solución a los hallazgos.
1.4.3. Matriz de Asignación de Responsabilidades
Ver Matriz de Asignación de Responsabilidades

controlada.
MANUAL

09-Jun-2015
1.5. Portafolio Del Servicio De Pruebas
CLASIFICACIÓN DE
SERVICIO DESCRIPCIÓN
PRUEBAS
Validan que la aplicación de software cumpla con
las especificaciones funcionales que el usuario
Prueba Funcional
solicitó en los requerimientos del sistema. Pueden
ser manuales o automáticos
Pruebas Dinámicas
(Ejecutan el Programa) Prueba Validación Planes Valida la configuración de los planes estén de
Hot Rating acuerdo a la solicitud del área comercial
Basado en los requerimientos del sistema se

Prueba No Formal adelanta la planeación y diseño de las pruebas
antes que el software sea entregado a QA.
Apoyan el modelamiento de los requerimientos
Prueba de
verificando su concisión, ambigüedad,
Requerimientos
contraposición y completitud
Valida que la información (Nro A. Nro B, Fecha,

duración) que llega al DWH después de ser
Validación de Cdrs procesada por mediación está acorde con los
Pruebas Estáticas (No datos de los llamados realizados por el área
ejecutan el programa) técnica
Optimización de Valida la sentencias de bases de datos para la

Sentencias SQL optimización de los aplicativos desarrollados

controlada.
MANUAL

09-Jun-2015
1.6. Diagrama De Cubrimiento De Testing

controlada.
MANUAL

09-Jun-2015
1.7. Frentes De Trabajo
FRENTES GERENCIAS SISTEMAS CLARO INFRACEL

AC/Screen View, Intranet/Portales Autoservicio,
G CRM&O Poliedro/Plus/Anexos, Poliedro Enterprise, Administrador
de Turnos, Poliedro Mobile, PQR.
Front End
GISAF Portal Comercial.
GGCS ALM
Tarificación, Facturación, Aprovisionamiento, Cambios de

GFPostpago
Servicio/Procesos Batch, Financiera
Operación
Día a Día Recargas- Sistemas de Cobro, Mensajeria - Portal, OTA-
GNT & SVA
SAT, Portales, IMEI Comcel.
Back End GFPREPAGO Desarrollo Core - IN, Middleware- ITEL, Procesos Inhouse
IVRs, GUIs, Hotrating y HotKit, Roaming Internacional,

GC&M Mediadores de Voz, Fraudex, SVA y Tarificadores de Voz,
GPRS, RAC, MEDPCS, STLDI, SINx
GOI Autosys, Operadores Fijos

-Nuevos Sistemas (Callidus, Intec, One Amx)
Proyectos Variable -Modificación y/o reingenieria a sistemas existentes
(Postabilidad, VPN, Sms Triger)

controlada.
MANUAL

09-Jun-2015
2. PROCESO DE PRUEBAS
A continuación se describe el proceso de pruebas tomando como base el modelo de pruebas
funcionales.
2.1. Diagrama General Del Proceso De Pruebas
1. FSP, requerimiento, Change request, mail,

acta, información a validar, manuales.
5. Informe final de
2. Formato de Solicitud de Pruebas. pruebas.
3. Informe de pruebas de desarrollo + 6. Soporte de pruebas.

pantallas.
4. Software instalado y configurado en

ambiente de pruebas.

controlada.
MANUAL

09-Jun-2015
2.2. Etapas Del Proceso De Pruebas

Las etapas generales del proceso de pruebas son:

controlada.
MANUAL

09-Jun-2015
2.2.1. Entregables por etapa

ETAPA ENTRADAS ACTIVIDADES SALIDAS
- Mail solicitud de pruebas.
-Validar que la solicitud de pruebas este completa y
- Formato de solicitud de
correcta.
Validar pruebas. Notificación de la devolución
-Si la solciitud no es valida se realiza la devolución
- FSP, casos de uso y
indicando la causa.
pruebas unitarias
- FSP, casos de uso y
Asignar -Asignación al respectivo lider de la prueba Notificación de asignación
pruebas unitarias
- Elaboración/Afinamiento del alcance, estrategia

plan de pruebas. - Plan y estrategia de pruebas.
- Especificación de la
- Estimación de tiempos. - Fechas estimadas.
funcionalidad/requerimiento.
Planear - Ejecución del smoke test y devolución si falta. - Notificación de la devolución si
-FSP, casos de uso y pruebas
- Notificación y aprobación de desarrollo del plan de falta el Smoke Test.
unitarias.
pruebas(maximo 3 dias para dar respuesta de lo - Notificación de aprobación.
contrario se dará como aprobado)
- Diseño de escenarios, casos de prueba y

- Especificación de la resultados esperados
funcionalidad/Requerimiento. - Inicio de preparación de datos de pruebas hasta - Diseño de escenarios y casos.
Diseñar - FSP, casos de uso y donde sea eficiente y posible. - Data inicial de pruebas.
pruebas unitarias. - Notificación y aprobación de casos de pruebas - Notificación de aprobación.
- Plan de pruebas. (maximo 3 dias para dar respuesta de lo contrario se
dara como aprobado).
- Softw are instalado en
ambiente de pruebas - Completar preparación de datos de prueba, si se
configurado y listo para requiere. - Registro en el Bucktracker.
Ejecutar ejecución. - Ejecución de casos de prueba y reporte de - Ejecución de casos de prueba
- Diseño de escenarios y hallazgos a desarrollo para solución. OK.
casos - Re-test despues de la corrección de un defecto
- Data de pruebas
- Hallazgos que no cumplen
- Generar acuerdos de solución a los hallazgos que - Hallazgos solucionados y/o en un
Gestionar Hallazgos con ANS establecidos o no
se encuentran pendientes estado terminal
tienen acuerdo de solución
Casos pruebas planeadas en - Notificación de finalización
- Envio de notificación de aprobación de pruebas por
Finalizar estado OK y hallazgos pendiente de documentación (Si
parte de QA.
cerrados aplica)
- Elaboración y generación del informe final de - Notificación de finalización y

- Casos pruebas planeadas
pruebas. cierre e informe final de pruebas a
Cierre en estado OK y hallazgos
- Incluir los soportes y evidencias de la prueba en la los interesados y al grupo
cerrados
herramienta de gestión GDI_QAINFOFINAL
Seguimiento en - Notificación y detalle de - Gestión de hallazgos presentados en producción. - Retes de las pruebas.
Producción hallazgos en producción - Busqueda de acciones de mejora. - Plan de mejora
- Reuniones de seguimiento y solución de
Gestionar, Controlar y Eventos e hitos durante las - Informe de Avance.
inconvenientes.
Monitorear pruebas. - Actas, Indicadores, Metricas
- Generación de informes.

controlada.
MANUAL

09-Jun-2015
2.3. Flujo Del Proceso De Pruebas

controlada.
MANUAL

09-Jun-2015
2.4. Estados De Las Pruebas
2.4.1. Descripción De Los Estados

Las pruebas tienen la característica de tener los siguientes estados en algún momento del tiempo:
ETAPA DE PRUEBAS
ESTADO DESCRIPCION
PERMITIDA
Pruebas que anuncian las gerencias de desarrollo para entregar.
QUE VIENE: NINGUNA
Cuando se requiera eliminar un proyecto de prueba se pasa a

este estado. Solo el administrador de la herramienta de gestión NINGUNA, PLANEACIÓN,DISEÑO,
ELIMINADA EJECUCIÓN,
puede pasarla a este estado. Aplica únicamente desde los
estados que viene, no formal.
Pruebas a las cuales actualmente se está realizando planeación
y Diseño con el objetivo de adelantar actividades de pruebas
NO FORMAL: PLANEACIÓN, DISEÑO,EJECUCIÓN
antes de ser entregadas por desarrollo a pruebas. Puede tener
eventos de congelamiento .
Pruebas que se están realizando en este momento. PLANEACIÓN,DISEÑO,
EN CURSO: EJECUCIÓN, FINALIZAR Y CERRAR
Pruebas iniciadas que son canceladas por algún motivo (estaba
en curso y el desarrollo ya no es válido o se cancela, no es
eficiente seguir con este proyecto para su gestión, lleva
NINGUNA, VALIDACIÓN-
demasiado tiempo congelada, por depuración, fue anunciada en
CANCELADA: ASIGNACIÓN,
que viene y no fue entregada, cuando los requerimientos o PLANEACIÓN,DISEÑO, EJECUCIÓN
alcance de la prueba cambia también se debe Cancelar la prueba
e iniciar una nueva solicitud con el nuevo alcance).
Se debe indicar la causa de la cancelación.
Una prueba se congela cuando no se puede adelantar ninguna
actividad de pruebas. Una vez se soluciona el evento que causa
NINGUNA, VALIDACIÓN-
el congelamiento se retoma. Ver causales de eventos de
CONGELADA: ASIGNACIÓN,
congelamiento encolamiento, devolución . PLANEACIÓN,DISEÑO, EJECUCIÓN
Después de 3 meses en este estado, se cancelará la prueba
acordándolo y comunicándolo al área de desarrollo.
A partir del envió de la documentación final de la prueba y su
respectivo cierre, se entra a monitorear si se presentan errores
en ambiente de producción no detectados. El periodo de
FINALIZADA: SEGUIMIENTO EN PRODUCCION
seguimiento es de 3 meses a partir de la finalización de la
prueba. Una vez finalizada no se puede modificar la información
del proyecto de prueba.

controlada.
MANUAL

09-Jun-2015
2.4.2. Diagrama de transición de estados de las pruebas

A continuación se describe la transición de estados de las pruebas:
ELIMINADA
QUE VIENE
Aplica desde estados Que viene, ,No Formal
Eventos
ENCOAMIENTO
CONGELAMIENTO
DEVOLUCIÓN
REGISTRAR
INICIO CONGELADA EN CURSO FINALIZADA
PRUEBAS
CANCELADA
QUE VIENE
NO FORMAL
Administrador Herramienta
Líder Proyectos de Pruebas
Líder Analista de pruebas FIN
ESTADOS NO ESTADOS
Líder de Proyectos o TERMINALES TERMINALES
Líder Analista de pruebas
Cuando se llega a estados terminales no se debe permitir modificar la información de la prueba al

líder analista, en caso de que se requiera, estas solicitudes de ajuste pasan por aprobación de los
coordinadores y posteriormente se realizan en ALM.

controlada.
MANUAL

09-Jun-2015
2.5. Comunicaciones Internas Y Externas Del Proceso

En la siguiente link encontrarán el modelo de comunicaciones interno y hacia nuestros clientes.
PS_ModeloDeComunicacionesProcesodePruebas
2.6. Gestión De Hallazgos

A continuación se presenta el diagrama de estado de los hallazgos.
2.6.1. Diagrama de estado de hallazgos

controlada.
MANUAL

09-Jun-2015
2.6.2. Descripción de estado de hallazgos
ESTADO DEL
HALLAZGO DESCRIPCIÓN
Es el estado inicial al ingresar un hallazgo en ALM. Este estado indica que no se ha tomado
ninguna decisión sobre el hallazgo. Cuando se abre o se digita el hallazgo, se asigna al Comité de
Cambios. Este estado, también significa que el hallazgo está pendiente de ser asignado por parte
Nuevo de la persona encargada de los recursos del cliente para su correspondiente solución.
Este estado significa que el hallazgo está asignado a una persona del equipo para que lo solucione.
Asignado
En Proceso
Significa que la persona encargada de solucionar el hallazgo está trabajando en él.
Se llega a este estado cuando la persona encargada de solucionar un hallazgo indica que está listo.
Solucionado
Después de solucionado, el hallazgo fue verificado por el Analista de pruebas, quedando pendiente
para realizar la prueba de regresión.
Verificado
Si un hallazgo fue notificado como solucionado y el comportamiento reportado se vuelve a
presentar, el hallazgo se reabre (pasa a estado reabierto). Este caso se puede presentar
posiblemente por las siguientes razones; el hallazgo no se corrigió correctamente, existió algún
problema con el control de versiones generando problemas con los artefactos. Se diferencia del
Reabierto estado “Para Analizar” en que el “Reabierto” ha implicado que el hallazgo ha tenido una notificación
de solución. Un hallazgo reabierto implica un incremento unitario del contador de reapertura.
Este estado implica que el hallazgo tiene que volver a Comité para un análisis posterior porque se
ha presentado una eventualidad en la solución que puede implicar impacto en tiempo. Este estado
Para Analizar
NO implica un incremento del contador de reapertura.
Significa que el hallazgo no aplica, generalmente son hallazgos que se realizaron por una errada
comprensión del aplicativo o falta de claridad en donde es natural que se generen este tipo de
hallazgos, en caso de presentarse un alto número, podría implicar que existe un problema en:
No es error -El diseño de la prueba
-El entendimiento de la prueba por parte del equipo de pruebas
El Comité de Cambios decide que la solución del hallazgo no es necesaria, no es posible o es muy
costosa. Este estado se debe usar OCASIONALMENTE en un proyecto. Si existe un alto número
de hallazgos en este estado (analizar proporción con respecto a los otros estados, debe ser
Así Viene/Deja máximo el 2%) puede indicar que existe un problema en el diseño del aplicativo o en el manejo de
la prueba.
Para Próxima Versión El Comité de Cambios decide que el hallazgo se deja como está, para solucionarlo en una próxima
versión.

controlada.
MANUAL

09-Jun-2015
Es un estado utilizado por el Analista de pruebas para indicar que el hallazgo se había ingresado
Duplicado
previamente en ALM. Es ideal que no se presenten frecuentemente.
Se utiliza este estado cuando:

-El hallazgo fue solucionado, verificado y cuando se hizo la prueba de regresión de un solo tipo de
Cerrado producto o los productos dentro de la misma prueba, en cuyo caso sería un estado terminal.
Estado que indica que el hallazgo no pudo ser replicado por el analista / desarrollador.
No Replicable
Estado que indica que la funcionalidad o solución del hallazgo no hacen parte del alcance de la
prueba. Puede ser necesario pasar por algún camino el cual genera el hallazgo.
Fuera del Alcance
Estado que indica que la prueba en la cual se identificó el hallazgo fue cancelada, o el hallazgo dejo
Cancelado de tener validez.
2.6.3. Características al reportar hallazgos

Cada uno de los hallazgos que son reportados durante el proceso de pruebas, aparte de ser claros
y precisos (Mostrar la información necesaria para la adecuada comprensión del mismo), deben
cumplir con las siguientes características y premisas:
Un hallazgo debe contener la descripción de un solo reporte en ALM, es decir, no incluir dos o más
errores, sugerencias, consideraciones y/o Finding en un solo hallazgo, porque:
• Ingresar dos o más bugs en un mismo hallazgo complica en extremo el

seguimiento, ya que cada uno puede requerir decisiones independientes sobre el
cambio.
• Puede prestarse para confusiones por parte del desarrollador, ya que no es claro
para éste en qué hallazgo concentrase, o simplemente podría dejar pasar por alto
un hallazgo por no tenerlo independiente.
Un hallazgo debe ser objetivo: el hallazgo debe ser siempre ingresado con la mayor objetividad
posible. Se debe recordar que el hecho de detectar un error es molesto para el equipo de
ingeniería, por lo tanto no se deben incluir insinuaciones, para no crear roces innecesarios. Utilice
un lenguaje adecuado para no incomodar al desarrollador ante los inconvenientes detectados.
Un hallazgo debe ser reproducible: debe ser claro en cuanto a los pasos que deben ejecutarse
para regenerar el mismo, esto con el objetivo que la persona encargada de revisar o corregir el
error pueda replicarlo con facilidad e independencia.

controlada.
MANUAL

09-Jun-2015
Una redacción adecuada es fundamental a la hora de documentar y reportarle al desarrollador el

hallazgo en ALM, ya que ésta permite:
• Generar independencia entre el equipo de desarrollo y el equipo de pruebas.

• Dar claridad para el proyecto (Desarrollo y Pruebas).
• La eficiencia porque se puede reproducir rápidamente el problema.
• Evitar reproceso en las actividades planeadas.
• Ahorrar tiempo y dinero a todo el equipo de trabajo.
Teniendo en cuenta la importancia y beneficios anteriormente mencionados, a continuación se

indica la estructura para redactar los hallazgos de manera articulada:
1. Breve Introducción: El hallazgo siempre debe contener una corta relación que describe el
comportamiento del incidente. Debe escribirse en lenguaje claro y conciso.
a. Pasos para replicar Hallazgo: Dada la importancia de replicar un error, con el fin de
crear independencia entre el equipo de ingeniería y el de pruebas, es necesario que se
detalle cada uno de los pasos que conllevan a replicarlo. Se debe tener en cuenta:
1. Deben estar enumerados.
2. Cada paso SÓLO debe expresar una acción.
3. El último paso debe llevar a mostrar el comportamiento no deseado.
Es muy útil que cada vez que se digita un hallazgo que tenga pasos, al terminar, se
replique el hallazgo siguiendo los pasos descritos en el mismo, esto permite verificar que
no falte ninguno y que estos estén bien expresados. Esta práctica aumenta la confiabilidad
de los hallazgos.
2. Conclusión del hallazgo: El reporte en ALM, debe estar soportado con una explicación
del resultado esperado, de tal manera que se justifique el efecto negativo que genera el
hallazgo sobre el aplicativo.

controlada.
MANUAL

09-Jun-2015
2.6.4. Características de los hallazgos
 La información y campos que manejan los hallazgos se indica en la sección descripción

campos de ALM
 Deben registrarse como hallazgos Los eventos que afectan la prueba tales como:
 No se realizó la entrega completa del objeto de la prueba.
 No está lista la Configuración necesaria.
 No se instaló correctamente.
 No está correctamente construido - Error Código - Error definición
 Al registrar hallazgos se debe tener presente los campos Naturaleza, Responsable de la

inyección, Empresa Inyección, Causal del hallazgo, con el fin de tener una adecuada
clasificación de la información sobre la calidad del proceso de desarrollo.
 Al momento de cancelar una prueba, el líder de la prueba debe asegurarse previamente de

que los hallazgos abiertos pasen a un estado “Cancelado” y los que están “Verificados”
pasen a “Cerrado”.
 Solo el analista cierra los hallazgos después de que desarrollo notifica su respuesta en
ALM
 Los hallazgos asociados a ambiente que claramente no son responsabilidad del

desarrollador, deben ser asignados a una persona de claro responsable de la gestión para
posteriormente de la solución ser cerrados por el líder de la prueba de QA.
 No se entrega el Vo.Bo. de pruebas hasta que los hallazgos en la herramienta de ALM se

encuentren en cualquiera de los siguientes estados: Cerrado, Cancelado, Para Próxima
Versión, Así viene/Deja, , Duplicado, Fuera De Alcance, No es Error
 Los hallazgos de tipo consideración, no deben ser registrados en ALM, hasta tanto no se
compruebe que el responsable de la inyección es desarrollo. Esto se hace con el fin de no
afectar a la fábrica de desarrollo en la evaluación que le aplican, con base en los hallazgos
reportados.

controlada.
MANUAL

09-Jun-2015
2.6.5. Service Level Agreement - SLA Para Solución De Hallazgos Por Impacto
Alto
Los tiempos requeridos para la solución de hallazgos son:
TIPO DE HALLAZGO TIEMPO MÁXIMO DE TIEMPO MÁXIMO DE

ANALISIS CUANDO SE SOLUCIÓN
SOLUCIONA
Severo 0.5 Hora 45 minutos
Alto 1 Hora 4 Horas
Medio 2 Horas 8 Horas
Bajo 3 Horas 16 Horas
En el tiempo máximo de análisis, desarrollo indica cuanto tiempo le toma implementar la solución.
En caso de no cumplir el acuerdo la prueba será congelada.
Para activar los SLA estamos pendientes de reunión con la Dirección de Desarrollo.
2.7. Herramientas De Apoyo Al Proceso
A continuación se presentan las herramientas sobre las cuales se apoya el proceso de pruebas.
Puede dar clic en el link para visualizarlas.
2.7.1. ALM -HP:
Aplicación WEB para la gestión y ejecución de pruebas, en donde se registra y administra

toda la información del proyecto de pruebas a realizar. La información se almacena en una
BD ORACLE. Ver la Guía de Instalación, Guía de Manejo y Manual de Usuario en ALM.
Con el objetivo de soportar el proceso de pruebas en la sección descripción de campos de

ALM, se detalla cada uno de los campos e información que utiliza la herramienta.
Dar click aquí para ver ALM

controlada.
MANUAL

09-Jun-2015
2.7.1.1. Transacciones en la herramienta ALM:
-
- Solo el administrador puede crear/eliminar nuevos registros en las listas, con
previa autorización del coordinador del servicio de pruebas.
- El rol desarrollador no puede agregar hallazgos.
- Ningún rol puede eliminar hallazgos.
- Solo el administrador y los líderes de proyectos de pruebas pueden crear reportes.
- Directrices para el uso de ALM con el proceso de pruebas (ver archivo

..\Directrices ALM.xlsx)
- Para la creación de usuarios en los proyectos Claro Dia – Dia, Comcel Dia – Dia y
D_ONE_AMX Legados y Convivencia se debe diligenciar Formato Inscripción
Usuarios Comcel.
- Para la creación de usuarios en AMDOCS se debe diligenciar el Formato

Inscripcion De Usuarios Proyecto Amdocs En Alm V 1.1
- Para solicitar un cambio en los campos de ALM se diligencia el Formato Ajuste

Información Pruebas Alm.
2.7.1.2. Dashboard:
Herramienta de indicadores y estadísticas que monitorea el proceso de pruebas sobre

aspectos cómo: planeación de pruebas, cantidad de pruebas recibidas y finalizadas, estado
de las pruebas, cantidad de errores, desfase en horas y fechas, pruebas finalizadas,
pruebas por proyecto entre otros.
Dar click aquí para ver Dashboard

controlada.
MANUAL

09-Jun-2015
2.7.1.3. Registro Y Actualización De La Información En La Aplicación De Gestión

De Pruebas
PERIODICIDAD INFORMACIÓN
% Avance Planeado, % Avance Real.
Horas invertidas en el mes, Horas Invertidas totales, Efectivas, Planeadas a la fecha,
Estimadas en el día, invertidas en el día.
Casos Ejecutados ok, Ejecutados No Ok, por ejecutar.
Diaria Información correspondiente a los hallazgos, por tipo, por estado, por naturaleza,
reaperturas, generados por otro, devoluciones. Pendientes por desarrollo, pendientes por
QA, Efectivos y no Efectivos.
Causales y Cantidad de horas de Desfases, congelamientos, encolamiento y devoluciones si

los hay
Por Cada situación o cambio que se presente durante la prueba, debe ser registrado en ALM, ya
Demanda sea mediante los campos destinados para ello o en el campo Observaciones.
2.7.2. Portal de pruebas:
Portal web donde puede encontrar toda la información sobre el servicio de pruebas de
software. Artefactos, documentos, encuestas, etc.
Dar click aquí para ver Portal de pruebas
2.7.3. Mentor Extracción de Datos:
Guía que muestra la mejor forma de extraer información común en los diferentes sistemas
de información.
Dar click aquí para ver Mentor Extracción de Datos

controlada.
MANUAL

09-Jun-2015
2.7.4. Repositorio de Pruebas:
Directorio de apoyo donde reside información básica para la gestión de las pruebas. Ej.
Estimaciones, indicadores, TestWare, plantillas, documentación, soportes de las pruebas
cerradas, otras herramientas para ejecución, datos de infraestructura de pruebas,
procedimientos.
Dar click aquí para ver Repositorio de Pruebas
2.7.4.1. Estructura Repositorio Pruebas
Esta herramienta permite compartir información entre el grupo de pruebas, manejar

estandarización y reutilización de artefactos. El repositorio de pruebas se encuentra
ubicado en \\wfile01\QA102007 a continuación la estructura del repositorio
CARPETA / SUBCARPETA DESCRIPCIÓN

Realizar planeación, control y seguimiento, dar retroalimentación sobre los
1. Gestión y Control resultados de las pruebas, mantener métricas e indicadores.
Estimaciones de pruebas Guarda los documentos con la estimación de tiempos de pruebas solicitadas
Indicadores Indicadores de gestión de pruebas
Planeación Actividades de planeación para la Coordinación.
Artefactos generados y utilizados durante el proceso de pruebas para la
2. TestWare-Eficiencia planeación, diseño y ejecución de futuras pruebas.
Contiene la información que es reutilizable y relevante con el fin de optimizar
los tiempos de pruebas. Esta información se clasifica por línea de pruebas
(BackEnd, FrontEnd, Proyectos), luego por compañía y finalmente por
aplicativo. Si el nombre de la carpeta contiene el texto “en ALM” es porque la
información ya ha sido migrada y debe consultarse y/o actualizarse en la
1. Testing Suite herramienta de gestión.
Contiene el documento estándar que permite identificar el alcance, estrategia

y/o supuestos de una forma global para un aplicativo, incluye documentos que
1. Planeación describan la funcionalidad (Ej.: Manuales de usuario, técnicos)
Contiene el TestStandar con la descripción, diagrama de flujo, escenarios,
casos y pasos para validar la funcionalidad, así como los scripts y datos de
2. Diseño prueba que se puedan reutilizar.
Almacena las herramientas que permitan validar, verificar y automatizar la
3. Ejecución funcionalidad del aplicativo (Ej.: Consultas, Scripts)
Contiene la información relevante e importante que se debe tener en cuenta
4. Fin y Cierre siempre que finaliza la prueba.
2. Plantillas Modelos y plantillas a tener en cuenta durante el proceso de pruebas.

controlada.
MANUAL

09-Jun-2015
En esta carpeta se almacena toda la información correspondiente a las

pruebas en estado terminal (canceladas y finalizadas antes del 1ro. de mayo
de 2012), documentación SOX y demás soportes asociados con la prueba. Se
clasifica por línea de pruebas (BackEnd,FrontEnd ,Proyectos), año, compañía
y aplicativo. Los soportes de las pruebas finalizadas después del 1ro de mayo
3. Soportes de Pruebas de 2012, reposan en la herramienta de gestión de pruebas HP-ALM.
Documentación de proyectos, del proceso de pruebas y de artefactos
4. Documentación utilizadas para su desarrollo.
Herramientas necesarias y utilizadas frecuentemente durante el proceso de
5. Tools pruebas.
3. Gestión de Recursos Maneja la información de los recursos que apoyan el proceso de pruebas.
Físico Inventario de computadores y servidores para pruebas.
Humano Inventario y ubicación de usuarios.
Espacio para almacenamiento e intercambio temporal de archivos. Atención,
4. Temporal tener en cuenta se elimina al finalizar cada semana.
Los soportes de las pruebas cerradas antes del 1 de Mayo 2012 se encuentran en este
repositorio. Las pruebas cerradas después de esta fecha tienen sus respectivos soportes
como anexos en ALM.
2.7.5. Carta de pruebas:
Guía del esfuerzo necesario para la realización de algunas pruebas. Se debe revisar con
detalle pues los tiempos pueden cambiar dependiendo de la solicitud de pruebas.
Dar click aquí para ver Carta de pruebas
2.7.6. Mapa General de Procesos de Negocio y Sistemas:
Visualización gráfica de los procesos de negocio y los sistemas que lo soportan con sus
respectivas relaciones.
Dar click aquí para ver Mapa General de Procesos de Negocio y Sistemas

controlada.
MANUAL

09-Jun-2015
2.7.7. Load Automatización Data (LAD):
Herramienta utilizada para extracción de datos y armar los casos de pruebas en las
pruebas automatizadas.
2.7.8. Racional Robot, Rational Functional Tester IBM:
Apoya la ejecución de pruebas automatizadas. (Ej.: AC).
2.8. Soportes De Las Pruebas En El Repositorio ALM

En ALM se almacenarán los soportes de la prueba en paquetes, tal como se explica en el manual
del PROCESO FACTURACIÓN POR ENTREGABLES.
Para continuar cumpliendo con el punto de control SOx que aplica a esta metodología, se deben
archivar en el primer paquete de soportes en ALM, el correo original de la solicitud de pruebas, con
sus respectivos anexos (los anexos no deben ser rutas o hipervínculos, deben ser archivos
adjuntos del correo de solicitud).
Las imágenes deben ser guardadas con un formato liviano como: JPG, PNG, etc. (No usar .BMP).
Para las pruebas en estado CANCELADA se debe guardar en ALM la información que se tenga
hasta el momento de la cancelación.
Las pruebas de años anteriores al 1 de mayo de 2012 se encuentran en la ruta:

\\wfile01\PruebasQA1, \\wfile01\PruebasQA3 \\wfile01\PruebasQA2.

controlada.
MANUAL

09-Jun-2015
3. PRUEBAS FUNCIONALES
Las pruebas funcionales validan que la aplicación de software cumpla con las especificaciones
funcionales que el usuario solicitó en los requerimientos del sistema.
3.1. ¿Cómo Solicitar Una Prueba Funcional?

Los pasos necesarios para realizar una solicitud formal de pruebas son:
1. El cliente envía un mail dirigido al grupo GDI_QAINICIOPRUEBAS, indicando en

el asunto de correo:
Compañía -Nombre De La Prueba – Nro Cambio
Ejemplo:
Para: GDI_QAINICIOPRUEBAS
CC:
Asunto: Claro - Reintentos Recargas Portal Comercial – BRIEF 0604-0605-0607-
C3966
2. En el correo anterior anexar :

 FSP, Requerimiento, Change Req, Caso Uso, mail, acta, Información a validar.
 Formato de solicitud de pruebas, diligenciado completo y correctamente, en
este formato se debe indicar si es necesario realizar pruebas de optimización
de sentencias SQL.
 Informe de Pruebas de Desarrollo + Captura Pantallas.
 Documentos varios: (Documento Arquitectura, Diagramas, manual de usuario,
manual técnico, y demás documentos que se crean pueden servir para una
mejor ejecución de la prueba).
3. Tener el ambiente con software configurado, instalado y listo para iniciar pruebas.
Ver: Ejemplo Solicitud de pruebas Funcionales
3.1.1. Validar la solicitud

1. Una vez recibida la solicitud el líder de pruebas debe validar que la información de la
solicitud este completa y correcta. Si no lo está realiza la devolución de la solicitud al
originador especificando la razón y usando la plantilla de devolución. , los destinatarios
del mensaje, son los mismos que utilizó el desarrollador en la solicitud.

controlada.
MANUAL

09-Jun-2015
2. Revisar si a la solicitud se adjuntó la documentación necesaria para dar inicio a las

pruebas (casos de uso, FSP, especificaciones suplementarias, manuales, pruebas de
desarrollo, url o ejecutable del aplicativo a probar).
3. Verificar los requisitos de las pruebas de desarrollo.
4. Verificar si en la solicitud se especifica la necesidad de hacer pruebas de optimización

de sentencias SQL. Ver: Procedimiento - Optimización de Sentencias SQL
5. Si todos los requisitos anteriores son cumplidos por la solicitud, el Líder Proyectos de
pruebas Claro, procede a realizar la asignación de la fábrica de pruebas de software,
mediante la plantilla de asignación formal de fábrica de pruebas.
3.1.2. Asignar
1. Revisar que otras pruebas están relacionadas a la solicitud, para buscar su posible
integración, comunicación y complemento.
2. Validar si existe una prueba en estado congelado o no_formal para retomarla y

aprovechar los adelantos realizados en planeación y diseño.
3. Se deben completar/actualizar los datos para la asignación de una prueba formal en el

aplicativo de gestión de pruebas: Fecha solicitud, Fechas planeadas desarrollo, Fechas
reales desarrollo, Líder proyecto, Desarrollador, Analista de pruebas, etc.
4. Sobre el mismo e-mail de la solicitud se envía la asignación utilizando la plantilla de

asignación sin adjuntar ningún tipo de archivo, eliminando el grupo
GDI_QAINICIOPRUEBAS e informando a:
Para: Usuario Final, Desarrollador, Líder de la prueba
CC: Coordinador de Desarrollo, Coordinador de Pruebas, Coordinador de

Outsourcing, Otros Analista de pruebas (que estén probando algún tema
relacionado) y Otras personas que sean importantes estén enterados o puedan
aportar al proyecto.
Los destinatarios del mensaje, son los mismos que utilizó el desarrollador en la solicitud,
además de los indicados en el mensaje de la etapa de asignación.
5. Enviar el mail original con sus anexos al líder de la prueba asignado. Se registra o
actualiza la prueba en la herramienta de gestión de pruebas.
6. En caso de ser necesario realizar pruebas de optimización de sentencias SQL, enviar esta
solicitud al líder de pruebas asignado.

controlada.
MANUAL

09-Jun-2015
3.1.3. Planear
1. Como primer paso en la etapa de planeación se debe verificar todo el Testing Suite
(documentación, scripts, test estándar, consultas, etc) en el repositorio, con el objetivo de
optimizar los tiempos invertidos en la prueba reutilizando la información existente, también
tener en cuenta en la carpeta “Fin y Cierre” del Testing Suite, si existen reportes Next
Version para validar con el área de desarrollo la viabilidad de incluirlos dentro del alcance
de la nueva prueba.
2. Identificar si la prueba se debe realizar integral o no.
3. Incluir casos de optimización de sentencias SQL en el plan de pruebas (Este paso aplica
solo si se solicitó este tipo de pruebas).
4. Se realiza la definición del alcance, estrategia y estimación de recursos necesarios

(tiempo, analistas de pruebas y fechas estimadas).
5. Realizar el Smoke Test lo más pronto posible para determinar si se debe devolver la
prueba a desarrollo. Se busca la mayor oportunidad en este punto.
6. Sobre el mismo e-mail de la asignación se envía utilizando la plantilla de planeación, los

destinatarios del mensaje, son los mismos que utilizó el desarrollador en la solicitud,
además de los indicados en el mensaje de la etapa de asignación.
7. El Líder de Desarrollo Claro y el Usuario Final, deben dar su aprobación y/o comentarios
sobre el plan de pruebas, antes de que inicie la ejecución de la prueba, de lo contrario la
planeación se dará como aprobada. Estos son los beneficios de dicha aprobación:
7.1. Identificar puntos clave de éxito, que no estén contemplados en el plan o los
escenarios de pruebas.
7.2. Asegurar la completitud del alcance.
7.3. Ahorrar en tiempo, costo y esfuerzo de los equipos de trabajo.
7.4. Minimizar el riesgo de errores en producción por omitir escenarios de importancia

para el negocio. En este ítem, el apoyo principal es el del usuario.
7.5. Sincronizar expectativas entre los equipos de trabajo.
8. Con el fin de fortalecer el conocimiento obtenido sobre los sistemas probados y la

documentación de los mismos en ALM, para las capacitaciones recibidas en esta o
cualquier etapa de la prueba, se debe usar la guía para los manuales de los aplicativos.
NOTA: Si en este momento ya tiene el diseño de casos de prueba usar la plantilla de

planeación y diseño.

controlada.
MANUAL

09-Jun-2015
3.1.4. Diseñar
1. Antes de iniciar la etapa de diseño se debe verificar la existencia del Testing Suite en el
repositorio, con el objetivo de optimizar los tiempos invertidos en la prueba reutilizando la
información existente, también tener en cuenta el Testing Suite para validar que elementos
se pueden reutilizar en la prueba existente (Datos, Scripts, Consultas… etc.)
2. Se realiza el diseño detallado de la prueba con sus escenarios, casos de prueba.
3. Se inicia la búsqueda y preparación de los datos de prueba. Los datos con complejidad
baja y media pueden ser generados por el analista, en el caso de que los datos sean con
complejidad alta, se procede a tramitar la solicitud con el equipo de extracción de data.
Ver: Proceso de extracción de data
4. Sobre el mismo e-mail de la planeación se envía el diseño utilizando la plantilla de diseño

de casos, los destinatarios del mensaje, son los mismos que utilizó el desarrollador en la
solicitud, además de los indicados en el mensaje de la etapa de asignación.
5. Desarrollo debe dar su aprobación y/o cometarios del diseño en un tiempo máximo de 3
días después de haber recibido el correo. Si pasado este tiempo el analista/líder no recibe
respuesta, el diseño se dará como aprobado.
3.1.5. Ejecutar
1. Verificar el Testing Suite del repositorio para validar que elementos se pueden reutilizar en
la prueba existente (Scripts, test maestro, Consultas… etc.)
2. Revisión y validación de ambientes para pruebas.
3. Completar la data necesaria para la prueba.
4. Ejecutar de los escenarios y casos de prueba.
5. Reportar hallazgos (si existen) en ALM.
6. Ejecutar pruebas de regresión siempre, independiente de si se encuentran defectos o no.
6.1. Las pruebas de regresión, se deben diseñar y ejecutar en la herramienta de gestión

de pruebas.
6.2. Deben ser independientes de la verificación de los hallazgos (re-test) y se deben

extender al flujo crítico de toda la prueba, no solo del caso donde se encontraron
defectos.

controlada.
MANUAL

09-Jun-2015
6.3. Los casos diseñados para la regresión, pueden ser reutilizados en regresiones
futuras como parte del test estándar.
6.4. El registro del set de pruebas de regresión, en la herramienta de gestión de pruebas,

debe ser independiente del set de pruebas inicial.
3.1.6. Gestionar hallazgos

1. Realizar seguimiento a los hallazgos reportados en ALM.
2. Realizar pruebas de confirmación después de que desarrollo notifica solución de los
hallazgos.
3. Cambiar estado de los hallazgos según la respuesta obtenida en la prueba de
confirmación.
Para más detalle acerca de la gestión de hallazgos consultar la sección GESTIÓN DE
HALLAZGOS
3.1.7. Finalizar
1. Cuando el tiempo que le toma al analista entre finalizar y cerrar el proyecto es menor a 2
horas debe saltar el paso 2 de esta sección. Es decir no se envía el mail de fin pendiente
documentación.
2. Se envía sobre el mail de diseño de casos de prueba la notificación de la finalización de la

prueba, indicando que la documentación será enviada lo más pronto posible. Se debe usar
la plantilla Finalización pendiente documentación. , los destinatarios del mensaje, son los
mismos que utilizó el desarrollador en la solicitud, además de los indicados en el mensaje
de la etapa de asignación.
3.1.8. Cerrar
1. Se construye el informe final de pruebas basado en el formato: Informe final de pruebas.
Dentro del documento del informe final, si se presentaron hallazgos durante la prueba, se debe
adjuntar la matriz de hallazgos. Este archivo debe insertarse como tipo objeto y no como
hipervínculo o ruta de ubicación.
2. Se envía el informe final de pruebas sobre el mismo e-mail del último diseño de casos de
prueba. Se incluye el correo en el campo CC al grupo de correo GDI_QAINFOFINAL y se

controlada.
MANUAL

09-Jun-2015
copia a las personas involucradas durante la prueba o puedan estar interesadas en

conocer su cierre. Se debe usar la plantilla Finalización y cierre. Si requiere enviar
información adicional, esta se empaqueta en un archivo comprimido para minimizar
tamaño del mail. NOTA: los destinatarios del mensaje, son los mismos que utilizó el
desarrollador en la solicitud, además de los indicados en el mensaje de la etapa de
asignación.
3. Solo para las pruebas de las Gerencias de Mediación, Configuración y Facturación

PosPago se debe copiar el informe final también al grupo GDI_QATEST_PREBILLING.
4. El líder de la prueba registra la finalización de la prueba en la aplicación de gestión de

pruebas con toda la información que se requiera como por ejemplo cambio de Estado,
Fecha Final de Pruebas Real, Casos de Prueba Reales, Horas Reales del Mes, Duración
Prueba, Complejidad , Causales del desfase y Observaciones (si aplica), etc.
5. Toda la información actualizada de la prueba debe quedar en ALM, aplica para las pruebas
en estado terminal como son: FINALIZADA /CANCELADA.
3.1.9. Seguimiento en producción

Se debe enviar un correo con la Plantilla Seguimiento en producción a los 5 días hábiles siguientes
de culminar la prueba y hacer seguimiento hasta obtener una respuesta válida. La respuesta a
este mensaje de seguimiento, o el conjunto de mensajes que evidencian el seguimiento, deben ser
comprimidos en un solo archivo llamado “Seg_prod.zip” y debe ser cargado en ALM, en la etiqueta
Attachments, del módulo de requerimientos, en la prueba respectiva.
En la reunión de seguimiento con cada área de desarrollo se solicita se envíen los detalles de los
hallazgos en producción atribuibles a fallas en los temas de pruebas durante la semana anterior.
Incluir en el acta semanal comentarios sobre lo mencionado al respecto.
Independientemente si se lleva a cabo o no reunión, se debe realizar este seguimiento y no solo

orientado a la identificación de hallazgos en producción, sino también a calificar la satisfacción del
servicio prestado en general y llevar una trazabilidad del producto.
Basados en el acta semanal del comité de cambios, para cambios no exitosos atribuibles a QA por
las pruebas, se debe solicitar el detalle de los hallazgos presentados en producción al área
correspondiente.
El líder de proyecto de pruebas de acuerdo a la información sobre el error registra y realiza el

análisis de lo sucedido apoyándose con el grupo desarrollo investiga la causa y solución del
inconveniente.

controlada.
MANUAL

09-Jun-2015
Si reportan algún error en producción no detectado en las pruebas se debe registrar en la

aplicación de gestión de hallazgos (usando la opción ambiente producción) la siguiente
información:
“Cómo se identificó/Fecha Notificación/Fecha del reporte en producción/Persona que

Reporta/Descripción del caso/Impacto/Causa Raiz/Solución/LecciónAprendida/Imputable
a/Información adicional/.
El Líder de Pruebas Claro, es quien registra el hallazgo en HP-ALM y se lo asigna al Coordinador

de la fábrica de pruebas, mediante el campo Desarrollador.
En caso de que el responsable de la inyección sea pruebas, se debe registrar en HP-ALM en el

campo Responsable de Inyección y en el de Empresa de Inyección, el nombre de la fábrica de
pruebas respectiva.
Sumamente Importante: Como resultado del punto anterior se debe registrar la lección aprendida
que permita mejorar para futuros casos.
3.1.10. Gestión control y monitoreo

 Informe de Avance por prueba
Frecuencia: DIARIO (Al finalizar la jornada, máximo hasta la 6pm)
1. Con el objetivo de comunicar los eventos más importantes de las pruebas junto con sus
avances y hallazgos el analista líder la prueba realiza el envío diario del informe de avance
usando la plantilla de informe de avance. los destinatarios del mensaje, son los mismos
indicados en el mensaje de la etapa de la asignación.
2. El informe debe ser copiado a:
Para: Usuario (si aplica), Desarrollador, Líder pruebas Claro
CC:Coordinador de Desarrollo, Coordinador de Pruebas, Coordinador de Outsourcing,

Otros Analista de pruebas (que estén probando algún tema relacionado) y Otras
personas que sea importante vincularlas al proyecto.
Casos Especiales para pruebas de Poliedro, AC-Portales.
No se notifica al usuario en los siguientes casos:
 Informe de avance.
 Devoluciones.

controlada.
MANUAL

09-Jun-2015
 Congelamiento.
 Informe de Avance por proyecto
Frecuencia: SEMANAL (Todos los Viernes 4 pm).
Un proyecto agrupa varias pruebas por lo tanto es necesario dar un visión general de los aspectos
más importantes a través de un informe de avance para su adecuado seguimiento.
1. Sobre el mail del informe semanal anterior se envía el siguiente informe de proyecto para
mantener la historia.
2. Con el objetivo de comunicar los eventos más importantes del proyecto el líder del proyecto
de pruebas realiza el envío del informe de avance de proyecto usando la plantilla de informe
de avance de proyecto. Ver ejemplo plantilla de informe de avance de proyecto. los
destinatarios del mensaje, son los mismos indicados en el mensaje de la etapa de
asignación.
3. El informe debe ser copiado a:
Para: Gerentes de desarrollo, Coordinadores de desarrollo, Usuario (si aplica),

Desarrollador, Líder proyecto de pruebas Claro.
CC:Gerente de QA, Coordinador de Pruebas, Coordinador de Outsourcing, Otros

Analista de pruebas (que estén probando algún tema relacionado) y Otras personas
que sea importante esté informada sobre el proyecto.
Asunto: Nombre del Proyecto – SubProyecto - Informe de avance a ddMMMyy -

Compañia
Ejemplo Asunto: PROYECTO ONEAMX – LEGADOS - Informe de avance a

10Ene12 - CCO
El sub proyecto se usa sólo cuando es un proyecto demasiado grande.
 Reuniones periódicas de seguimiento con desarrollo
Según se defina la periodicidad con cada área de desarrollo se realizan reuniones de seguimiento
en donde se revisa:
a) Panorama de pruebas no formales y congeladas.

controlada.
MANUAL

09-Jun-2015
b) Pruebas que serán entregadas en las siguientes semanas.
c) Pruebas en curso que requieran atención.
d) Comentarios, sugerencias de mejora del ciclo de desarrollo y pruebas.
Una vez finalizada la reunión se envía un acta usando la plantilla de seguimiento de

pruebas. Sobre el mail de acta semanal anterior se envía la siguiente acta para mantener
la historia.
IMPORTANTE: Se deben preguntar y tramitar de manera proactiva todos los accesos, usuarios y
ambientes para ser más eficientes al momento de recibir la prueba.

controlada.
MANUAL

09-Jun-2015
4. PRUEBAS NO FORMALES – ADELANTAR PLANEACIÓN Y DISEÑO.
Buscando oportunidad en el proceso de pruebas, cuando sea viable y eficiente se adelantan las
labores de planeación*, diseño de las pruebas e incluso preparación inicial de datos (si aplica). La
meta es preparar todos los elementos de la prueba de tal forma que en el momento en que
desarrollo tenga listo el software, se inicie con mayor oportunidad la ejecución de la prueba.
Basados en un documento de requerimientos y avance del proyecto de desarrollo se adelanta al

máximo posible las etapas mencionadas de pruebas. Nota: En el momento que no es posible
avanzar más en la planeación se cambia de estado la prueba a CONGELADA.
* En esta etapa no se generaría la estimación de tiempos final ya que cuando se asigne a formal
pueden existir cambios de alcance.
4.1. ¿Cómo Iniciar Una Prueba No Formal?
El líder de pruebas de Claro valida con el grupo de desarrollo la certeza de la entrega del
desarrollo a pruebas y solicita el documento de especificación funcional o FSP al área de
desarrollo o a través del comité de requerimientos semanal.
Dicho insumo detalla las características funcionales que sirven como base del producto a probar.
Si todos los requisitos anteriores son cumplidos por la solicitud, se procede a realizar la asignación
de la fábrica de pruebas de software, mediante la plantilla de asignación no formal de fábrica.
4.1.1. Asignar
Ver sección de Asignar prueba funcional
La única diferencia es que en el punto 3 cambia la plantilla de asignación y las personas a quienes
se copia la asignación.
 Sobre el mismo e-mail de la solicitud se envía la asignación utilizando la plantilla de

asignación NF sin adjuntar ningún tipo de archivo e informando a:
Para: Líder de proyecto de prueba Claro.

controlada.
MANUAL

09-Jun-2015
CC: Coordinador de Pruebas, Coordinador de Outsourcing, Otros Analistas de

pruebas (que estén probando algún tema relacionado) y Otras personas que sea
importante vincularlas al proyecto.
4.1.2. Planear
Se debe seguir el mismo procedimiento de la sección planear pruebas funcionales, teniendo en
cuenta que los campos fechas de la plantilla de planeación no se diligencian.
A diferencia de las pruebas funcionales aquí no existe ambiente para ejecutar.
4.1.3. Diseñar
Ver sección de diseñar pruebas funcionales
Si no es posible avanzar más en algún momento en la prueba, se debe pasar a estado

NO_FORMAL_CONGELADA.
Si es conveniente por el estado del proyecto de pruebas/desarrollo se comparte con desarrollo el

plan y diseño de casos para obtener retroalimentación oportuna y ajustarlo en caso de ser
necesario.

Se debe seguir el mismo procedimiento de la sección Pruebas funcionales Gestión, Control y
monitoreo.

controlada.
MANUAL

09-Jun-2015
5. PRUEBAS EN REQUERIMIENTOS
Las pruebas en requerimientos buscan involucrarse desde las etapas tempranas del ciclo de
desarrollo con el objetivo de minimizar los costos al detectar errores. Este tipo de pruebas están
diseñadas para ser ejecutadas en paralelo a la etapa de requerimientos del proceso desarrollo de
software y el objetivo es apoyar la modelación (requerimientos) de las ideas.
Importancia: Gran cantidad de los errores que se presentan en un software son debido a
definiciones incompletas del requisito o ambigüedades en la interpretación del mismo.
Alcance: El objetivo es apoyar en la modelación de los requerimientos desde el punto de vista

conceptual en la etapa de requerimientos, más no garantizar que cubra las necesidades de
negocio.
Se verifican las siguientes características:
 Conciso: Breve descripción que expresa una única idea, clara y a criterio del analista de
pruebas entendible.
 No ambiguo: Tiene una única interpretación posible.
 Contraposición: El requerimiento no se contrapone con otro propuesto para la versión o

release o funcionalidad existente.
 Completitud: Validar que todos los casos de uso estén asociados al requerimiento
original.
Beneficios:
 Disminución de tiempos requeridos para la solución de inquietudes entre desarrollo y el

negocio.
 Disminución de gastos generados por la solución de errores en los aplicativos que son
generados por una débil documentación.
 Detección oportuna de incoherencias o problemas, que pueden derivar en errores del
aplicativo.
 Oportunidad – Eficiencia.
Proceso:

controlada.
MANUAL

09-Jun-2015
5.1. ¿Cómo Se Solicita Una Prueba En Requerimientos?
Los pasos necesarios para realizar una solicitud de pruebas son:
1. El cliente envía un mail con copia al grupo GDI_QAINICIOPRUEBAS, indicando en el

asunto de correo:
Compañía -Nombre – Nro.Brief – Nro Cambio
Ejemplo:
CC:
Asunto:Com- Reintentos Recargas Portal Comercial - Brief 0591
2. En el correo anterior anexar :
 Formato de solicitud de pruebas, diligenciado completo y correctamente.

 FSP, Caso de Uso, Requerimiento, Change Request, mail, acta,
Información a validar, manuales.
La prueba es asignada por el coordinador de pruebas de acuerdo a la solicitud.

Ver sección de Validar la solicitud en pruebas funcionales.
5.1.2. Asignar
Ver sección de Asignar prueba funcional.
5.1.3. Planear
Ver sección de planear de pruebas funcionales.
Aquí no existe ambiente por ser prueba en requerimientos, por lo tanto obviar el punto 3.

controlada.
MANUAL

09-Jun-2015
5.1.4. Ejecutar - Revisar

1. Verificar el Testing Suite del repositorio para validar que elementos se pueden reutilizar en
la prueba existente (Scripts, test maestro, Consultas… etc.)
2. Revisión, validación y realización de comentarios sobre el documento.
3. Sobre el mismo e-mail de planeación se envían los comentarios usando la plantilla

comentarios.
4. Reporte de hallazgos (si existen) en ALM o matriz de hallazgos.
5. Validar los ajustes realizados por desarrollo o usuario.
6. Verificar los requisitos de las pruebas de desarrollo.
5.1.5. Finalizar y Cerrar

Ver sección Finalizar y Cerrar las Pruebas Funcionales
En casos de cancelación y congelamiento aplica el mismo procedimiento que en pruebas

funcionales.
Con el objetivo de comunicar los eventos más importantes de las pruebas junto con sus avances y
hallazgos se realiza él envió del informe de avance usando la plantilla de informe de avance. Los
destinatarios del mensaje, son los mismos que utilizó el desarrollador en la solicitud, además de los
indicados en el mensaje de la etapa de asignación.

Ver sección Pruebas funcionales Gestión, Control y monitoreo.

controlada.
MANUAL

09-Jun-2015
6. VALIDACIÓN DE CDR DE VOZ

Una vez realizadas llamadas de prueba estas cursan por el sistema de mediación y son registradas
en el repositorio DWH, allí se realiza la validación de CDR cuyo objetivo es verificar la estructura de
los CDR registrados.
Tiempo máximo de atención de la solicitud 3 días hábiles. Hasta 40 cdrs. Para más de 40 cdrs el
tiempo aumenta.
 Cuando la solicitud es para nuevas centrales la validación se hace contra los archivos
generados por el mediador de pruebas. El tiempo depende de la cantidad de escenarios
solicitados.
 Cuando la solicitud es para validación de actualización de elementos de la central se hace

contra los archivos generados por el mediador de producción. El tiempo depende de la
programación acordada.
 Cuando la solicitud es de validación de Infracel se debe tener en cuenta la Tabla de

Infracel.
6.1. ¿Como Solicitar Una Prueba Cdr?

Los pasos necesarios para realizar una solicitud formal de pruebas son:
1. El cliente envía un mail con copia al grupo GDI_QAINICIOPRUEBAS, indicando en el
asunto de correo:
Compañía –Nombre Xxxxxx (XXXX hace referencia a detalles como ruta, conexión, o
algún tipo de especificación de la prueba.)
Ejemplo:
CC:
Asunto: Com- Llamadas Centrales Nuevas – Nueva Interconexión Aranda01
2. En el correo anterior debe anexar:
 Formato de solicitud de pruebas, diligenciado completo y correctamente.

 Archivo en formato Excel con la información de los cdrs a validar.
 Número A (Calling Number)
 Número B (Called Number )
 Fecha/hora llamada
 Duración de la llamada

controlada.
MANUAL

09-Jun-2015
**Si el caso es una nueva central la solicitud debe incluir los datos de la central.(IP
Chu,Cantidad Chu,Switch, EXCHANGE _ID)
3. Tener el ambiente con software configurado, instalado y listo para iniciar pruebas.
Responsabilidad de la gerencia de mediación y configuración.
Ver Ejemplo Solicitud de Pruebas
Verificar los requisitos de las pruebas de desarrollo.
Ver sección de Validar la solicitud en pruebas funcionales.
6.1.2. Asignar
Ver sección de Asignar pruebas funcionales.
6.1.3. Planear - Diseñar- Ejecutar

Ver sección de planear pruebas funcionales.
Revisión, validación y reporte de errores en caso de existir.
6.1.4. Finalizar y Cerrar

Ver sección Finalizar y Cerrar las Pruebas Funcionales.

Cuando la prueba dura más de 2 días, sólo a partir del tercer día debe enviarse el informe de
avance diario. Ver sección Pruebas funcionales Gestión, Control y monitoreo.

controlada.
MANUAL

09-Jun-2015
6.2. Tabla De Validación De Cdr’s Para Infracel

Para las validaciones de cdr’s de Infracel se debe tener en cuenta:
TIEMPO DE PRUEBAS EN DÍAS

Caso Descripción ALCANCE
HABILES
Una vez realizadas las llamadas de prueba

estas cursan por el sistema de mediación y son
incluidas en los cubos de DWH, allí se realiza
Tráfico LDI Infracel desde un la validación de CDRs cuyo objetivo es verificar
operador fijo o móvil nacional algunos* campos de los CDRs registrados.
marcando 00444 a través de
1 una nueva ruta entre Claro y
otro operador fijo o móvil En Claro se valida que sean excluidas (STF o
nacional o una ruta existente Mediador GSM).
sin tarifas configuradas.
En Infracel se valida que sean entregadas por

Inframed al STLD. 5 días.

la validación de CDRs cuyo objetivo es verificar
algunos campos de los CDRs registrados*.
Tráfico LDI Infracel desde un

operador fijo o móvil nacional En Claro se valida que sean excluidas (STF o
marcando 00444 a través de Mediador GSM).
2 una nueva ruta entre Claro y
otro operador fijo o móvil
nacional o una ruta existente
con tarifas configuradas. En Infracel se valida que sean entregadas por
Inframed al STLD.
En STLD se valida la tarificación de las

llamadas. 7 días

Nuevas rutas entre Infracel y la validación de CDRs cuyo objetivo es verificar
3 carrier internacional - llamadas algunos campos de los CDRs registrados*.
entrantes
Se valida que sean excluidas por parte del

mediador de Infracel 4 días.

controlada.
MANUAL

09-Jun-2015

la validación de CDRs cuyo objetivo es verificar
algunos campos de los CDRs registrados*.
Nuevas rutas entre Infracel y
4 carrier internacional - llamadas
En Claro se valida que sean excluidas (STF o
salientes
Mediador GSM).
En Infracel se valida que sean entregadas por

Inframed al STLD. 5 días.
Cambio realizados sobre la Una vez realizadas las llamadas de prueba se

5
central de Infracel toman los archivos generados por el mediador Durante la ventana de realización de la
de Infracel y se validan las llamadas. actividad
NOTA:
1. Los tiempos arriba mencionados dependen de la cantidad de llamadas solicitadas a validar.
2. Para salidas a producción en fechas específicas es necesario tener el panorama de planeación

con anticipación a la solicitud de pruebas, para programar los recursos de pruebas y cumplir los
tiempos mencionados.
3. * Los campos incluidos en la validación son Número A, B, Fecha, Hora, Duración.

controlada.
MANUAL

09-Jun-2015
7. ASPECTOS IMPORTANTES DEL PROCESO
7.1. Casos Especiales Cancelación, Congelamiento, Devolución

 Antes enviar el correo se debe comunicar al líder de proyectos pruebas de Claro y Líder de
desarrollo para que todos estén enterados del evento.
 El correo de la cancelación o congelamiento de la prueba se hace sobre el mail de diseño

de casos, plan de prueba o asignación. (según la etapa máxima alcanzada en la prueba).
 Para enviar el mail se debe usar la plantilla adecuada según el evento. Es muy importante
dar claridad de motivo de la cancelación, congelamiento y devolución.
 Si es cancelación tener en cuenta el adecuado cierre de los hallazgos.
7.2. Causales De Eventos Congelamiento-Devolución-Encolamiento
Las indicaciones a seguir para los siguientes eventos son:
CONGELAMIENTO / DEVOLUCIÓN / ENCOLAMIENTO: (No se puede adelantar nada de la

prueba)
Para crear estos tipos de eventos se requiere:
1. Cambiar el estado a congelado de la prueba.
2. Crear el evento con la respectiva información, fecha inicial del evento y
adjuntar el correo que contiene el detalle del evento. El objetivo es dejar
claro el contexto y escenario del evento.
Para cerrar el evento anterior se debe:
3. Editar el evento respectivo y llenar la información y fecha final del evento.
4. Cambiar el estado de la prueba a en curso/NoFormal/cancelada según
corresponda.
5. Asegurar que la cantidad de eventos creados, coincida con la cantidad de
eventos calculada de manera automática en el requerimiento.
6. Para cerrar el evento de congelamiento en el informe de avance diario se
informara el tiempo que duro congelada la prueba, cuál era la fecha que se
tenía planeada y cuál es la nueva fecha. Se correrán los tiempos que se
tienen planeados en esos días, para continuar desde el día que se
descongela la prueba, Ejemplo: si la prueba duro congelada 5 días y como
fecha de entrega estaba el día 20 de agosto la nueva fecha será el 25 de
Agosto.

controlada.
MANUAL

09-Jun-2015
Se realiza la devolución o congelamiento de acuerdo a la siguiente tabla:
EVENTOS RESPONSABLE
ANTIGUO
ESTADO
ETAPA DE ESTADO
TIPO EVENTO CAUSAL DEL EVENTO NATURALEZA QA DESARROLLO QUEDA
PRUEBAS VERSIONES
PRUEBA
ANTERIORES
VALIDACIÓN DEVOLUCIÓN Completitud: solicitud de pruebas CALIDAD x CONGELADA NUEVO
incompletas
VALIDACIÓN DEVOLUCIÓN Contenido: Documentación incosistente CALIDAD x CONGELADA NUEVO
VALIDACIÓN DEVOLUCIÓN Contenido: Entrega del objeto de la CALIDAD x CONGELADA NUEVO
prueba incompleto
VALIDACIÓN DEVOLUCIÓN Contenido: Pruebas de desarrollo CALIDAD x CONGELADA NUEVO
incompletas o débiles
ASIGNACIÓN ENCOLAMIENTO Prueba no planeada - No hay analisis PLANEACIÓN x CONGELADA COLA
disponibles
ASIGNACIÓN ENCOLAMIENTO Prueba planeada- No hay analisis PLANEACIÓN x CONGELADA COLA
disponible
ASIGNACIÓN ENCOLAMIENTO Ausencia de elementos o PLANEACIÓN x CONGELADA COLA
prerrequisitos para iniciar la prueba
PLANEACIÓN DEVOLUCIÓN No supero el smoke test CALIDAD x CONGELADA
PLANEACIÓN CONGELAMIENTO NoFormal. No es posible adelantar o ya PROACTIVA CONGELADA NOFORMAL CONG
DISEÑO finalizó planeación y diseño
PLANEACIÓN ENCOLAMIENTO NoFormal. No hay analistas disponibles PROACTIVA CONGELADA NOFORMAL CONG
DISEÑO
PLANEACIÓN CONGELAMIENTO Ausencia de elementos o PLANEACIÓN x CONGELADA
DISEÑO prerrequisitos para continuar la prueba
PLANEACIÓN CONGELAMIENTO Cambio de alcance - Modificación de PLANEACIÓN x CONGELADA

DISEÑO los requerimientos.
PLANEACIÓN CONGELAMIENTO Cambio de prioridades negociadas con PLANEACIÓN x CONGELADA
DISEÑO desarrollo
EJECUCIÓN DEVOLUCIÓN Por cantidad de errores encontrados CALIDAD x CONGELADA
impacto alto
EJECUCIÓN DEVOLUCIÓN Ausencia de elementos o PLANEACIÓN x CONGELADA
prerrequisitos para continuar la prueba
EJECUCIÓN CONGELAMIENTO Cambio de prioridades negociadas con CONGELADA

desarrollo PLANEACIÓN x
Algunas aclaraciones son:
Momento: ¿Al validar Completitud de la solicitud. Vienen todos los insumos?
o Solicitud de pruebas incompleta (Sin FSP, Sin Prueba de Desarrollo, sin software,
sin formato solicitud).
Momento: ¿Al validar el contenido de la solicitud. El contenido es correcto?
o Documentación inconsistente e incompleta.

o Validación del Check List Pruebas de Desarrollo.

controlada.
MANUAL

09-Jun-2015
o Entrega del objeto de la prueba incompleto. (software, CU, Requerimiento).
Momento: Al ejecutar el Smoke Test.
o No supera escenarios básicos de la aplicación del Smoke Test.
Momento: Al ejecutar los escenarios de prueba.
o Devolución por Cantidad de Errores Impacto Alto. Cuando por la cantidad

recurrente de errores se evidencia la inestabilidad del aplicativo. No Aplica para
pruebas en requerimientos.
Cuando definitivamente no se puede o no es eficiente avanzar en la prueba se congela con el

evento devolución.
7.3. Requisitos De Las Pruebas De Desarrollo
Las pruebas de desarrollo deben cumplir con las siguientes características:
1. Usar la plantilla: F0-02 PRUEBAS_DE_DESARROLLO_V4_E.DOCX
2. En Ambiente de pruebas, Pantallas completas de la ejecución de escenarios de pruebas

asociados al cambio o nueva funcionalidad, mostrando el paso a paso de la transacción de
inicio a fin.
3. Tomar pantallas de las validaciones realizadas en las BDs para garantizar que a nivel de
tablas se refleje el cambio y que la funcionalidad es correcta (Ej.: Que las Activaciones
fluyan a BSCS, ACTIVA, Validación Ticklers).
4. Especificar datos de prueba usados como entradas y log de las transacciones si se

generan.
5. El líder de desarrollo que solicita una prueba, debe ser el responsable de incluir los
soportes de las pruebas unitarias de todos los sistemas afectados por el desarrollo.
Algunos ejemplos de Transacciones son:
· POLIEDRO: Activación/Reposición/Cambio Servicio/Planillado/Otros.

· AC: Creación-Modificación de Clientes, productos y servicios /Desactivaciones,
· BACK END: Control/ Aprovisionamiento /Tarificación /Facturación / Mediación / Pagos.

controlada.
MANUAL

09-Jun-2015
7.4. Causales Del Desfase

Para el manejo de los desfases e informes del estado del proyecto el proceso de pruebas se apoya
en el EVM, Método del Valor Ganado del PMBOk.
Las causales y sus responsables se pueden ver en Causales de Desfase
7.4.1. Desfases en costos

Cuando existe diferencia entre las horas efectivas y las horas invertidas totales se presentan
desfases los cuales tienen unas causales por las cuales se originaron y un responsable como tal.
A través de la herramienta de gestión de pruebas es responsabilidad del analista de pruebas

registrar a diario la cantidad de horas de desfase asociando su respectiva casual y responsable.
Con el nuevo esquema un desfase negativo impacta negativamente el proyecto.
7.4.2. Horas invertidas de más o de menos

Cuando por alguna situación se invierte más o menos horas en una prueba debe justificar con su
respectiva causa.
7.4.3. Desfases en cronograma

Cuando existe diferencia entre las horas efectivas y las horas planeadas a la fecha se presentan
desfases en cronograma los cuales tienen unas causales por las cuales se originaron y un
responsable como tal.
También se puede obtener el desfase total en cronograma total así:
DESFASE EN CRONOGRAMA = DESFASE EN COSTOS + HORAS INVERTIDAS DE MAS O

DE MENOS.
7.5. Estimación De Tiempos

1. La estimación de tiempos se realiza sobre pruebas que posiblemente van a ser entregadas
y se hace de manera general con el fin de obtener un panorama de tiempo y esfuerzo.
2. Se registran los tiempos invertidos en estimación mensualmente en la herramienta ALM,

bajo una prueba genérica creada para tal fin.

controlada.
MANUAL

09-Jun-2015
3. La estimación de tiempos debe de tener una aprobación y dicha aprobación es la que debe
ir registrada en ALM.
4. La estimación de tiempos debe considerar las siguientes actividades:
a. Planeación y Diseño (incluye construcción del set de datos).
b. Ejecución.
c. Documentación y Cierre (incluye tiempos de actualización de la herramienta de gestión

de pruebas).
7.6. Estándar Para Asunto De Los Mails Y Plantillas

Al emitir los correos durante el proceso de pruebas se debe tener en cuenta los siguientes
estándares y plantillas de correo.
Formato del Asunto Correo: ID_PRUEBA – Tipo de e-mail - COMPAÑÍA - TIPO PRUEBA –
Sistema-Nombre – BRIEF – ID-CAMBIO
Ejemplo:
CCO-DD-2732 - Diseños de Casos - CCO - FN - ITEL - HOT KIT - Reingeniería Hot-Kit Prepago
‘ *Obligatorio
Para ver la plantilla dar clic en cada Tipo de E-mail.
 *CCO-DD-XXXX( EmpresaPais-Proyecto-nro): número consecutivo de prueba
asignado por la herramienta de gestión
 *PROYECTO: Nombre del proyecto de pruebas que puede agrupar varias pruebas.
 *Tipo E -mail:
 Asignación
 Asignación No Formal
 Avance ddMMMYY
 Comentarios
 Plan de Pruebas
 Diseño de Casos
 Plan y Diseño de Casos
 Cancelación
 Congelamiento
 Devolución
 Cierre
 Finalización Pendiente Doc

controlada.
MANUAL

09-Jun-2015
 *Compañía:
 CCO (Claro Colombia)
 CPA (Claro Panamá)
 INF (Infracel)
 *Tipo de prueba:
 FN: Funcional
 RQ: Requerimientos
 *Sistema: Indica el sistema principal sobre el cual se van a realizar las pruebas.
 *Nombre de la prueba: Nombre asignado por el líder que envía mail de asignación de
prueba. Debe tener un buen nivel de descripción. Usar el mismo que se registra en la
herramienta de gestión.
 Brief : generado del PRB
 Cambio: Relacionado generado por el registro del cambio en la herramienta: CZZZZZ
7.7. Adopción De Nuevos Sistemas A Probar

Cuando se adopta un nuevo sistema para probar, se maneja la siguiente estrategia:
a. Se validan los ambientes de pruebas disponibles con sus respectivos accesos (se deben
tramitar dichos accesos), la capacidad de recursos de desarrollo como una de las variables
para estimar la capacidad de pruebas.
b. Se inicia con capacitaciones generales por parte del área de desarrollo y el área actual de
pruebas en cuanto a negocio y métodos utilizados.
c. Se exige la entrega por parte de desarrollo de un documento que especifique la

funcionalidad.
d. Se debe elaborar por parte de QA un documento inicial que describa la actividades

principales a realizar en las pruebas, indicando: actividades, roles, tiempos y entregables.
Este documento será validado con nuestro cliente.
e. Se realiza un acompañamiento inicial por parte de QA donde el alcance es planeación y

diseño (QA no realiza ejecución de la prueba).
f. Para registrar los tiempos de la prueba se asigna como una prueba formal en ALM y en el
repositorio debe quedar la información que se tenga sobre la prueba en la estructura de
carpetas correspondiente.
g. Se inicia con una segunda prueba en donde QA realiza todo el proceso y se recibe
acompañamiento por parte del área de desarrollo y el área actual de pruebas.

controlada.
MANUAL

09-Jun-2015
h. Se recibe la tercera prueba, donde QA adopta formalmente las pruebas (aplica proceso
formal de pruebas.
i. Si durante la ejecución de los 2 primeros meses de las pruebas no se recibe el soporte
necesario y cumplimiento en la planeación de pruebas, se reevaluará con los gerentes la
continuidad del apoyo en la prestación del servicio de pruebas.
7.8. Lecciones Aprendidas

 Cuando el producto no pase la prueba de Smoke Test, realizar la respectiva devolución
para no caer a futuro en pérdida de tiempo en aplicaciones que no están listas para
pruebas.
 Es necesario dejar como evidencia de las pruebas realizadas impresión de las pantallas.
Usar formatos donde puedan apreciarse los procesos llevados a cabo de manera
secuencial, siguiendo los procesos de prueba diseñados.
 Dejar evidencia de las reuniones y decisiones tomadas por medio de acta o correo.
 No suponer.
 Si durante el proceso de pruebas cambia la planeación y se disminuye el alcance,
entonces debe quedar documentado el motivo del cambio.
 Si tenemos argumentos válidos, se pueden objetar observaciones de desarrollo y las
conclusiones de estas documentarlas.
 Se debe tener en cuenta la integración entre pruebas relacionadas que se estén realizando
para verlas como un solo producto final al usuario. Es responsabilidad de los líderes de
proyectos de pruebas una buena comunicación respecto a este punto.
7.9 Estándares De Seguridad

Para realizar las conexiones remotas a los servidores siempre usar SSH. No usar Telnet. Con ello
la información que viaje entre el usuario y el servidor irá encriptado. Por Ejemplo las claves. Una
herramienta que pueden utilizar es el Putty (Repositorio: TestWare-Eficiencia\5. Tools\emuladores).

controlada.
MANUAL

09-Jun-2015
7.10. Pruebas Compartidas Entre Front Y Back End

Cuando llegan pruebas con temas muy relacionadas de los 2 frentes se debe manejar un solo
proyecto de pruebas o en su defecto 2 pruebas pero cada una con su respectiva información de
proyecto evitando duplicidad de información.

controlada.
MANUAL

09-Jun-2015
8. GLOSARIO E INFORMACIÓN RELACIONADA SOBRE TESTING
 Fundamentos de pruebas: La ISTQB consolida en un solo documento los

fundamentos de pruebas de software (Syllabus).
 ISTQB: Grupo internacional especializado en buscar estandarizar temas de

pruebas de software (http://istqb.org/display/ISTQB/Home).
 Pruebas de regresión: Las pruebas de regresión son la prueba reiterada de un

programa ya probado, después de haber sido modificado, con vistas a localizar
defectos surgidos o no descubiertos como resultados del cambio o de los cambios.
Estos defectos pueden estar en el software objeto de las pruebas, o en cualquier
otro componente de software asociado o no asociado. Se realizan cuando el
software, o su entorno, sufren modificaciones. El alcance de las pruebas de
regresión depende del riesgo de no encontrar defectos en el software que antes
funcionaba.
 Verificación de los hallazgos (Pruebas de confirmación o Re-test): Repetición

de una prueba que ha fallado anteriormente con vistas a confirmar su corrección.

controlada.
MANUAL

09-Jun-2015
9. CONTROL DE CAMBIOS
Versión Fecha Elaboró Comentarios
7.21 09-Jun-15 Mauricio Navarro  Se actualiza el organigrama de la gerencia.

 Se actualiza el procedimiento de facturación por entregables.
7.20 05-Jun-15 Mauricio Navarro  Se elimina la matriz de reporte de hallazgos en producción.

 Se adiciona el procedimiento de asignación de hallazgos en producción.
7.19 26-May-15 Mauricio Navarro  Se actualiza el formato de solicitud de pruebas.
7.18 25-May-15 Mauricio Navarro  Se actualizan condiciones y características de las pruebas de regresión.
 Se declaran los conceptos de pruebas de regresión y verificación de hallazgos.
7.17 19-May-15 Mauricio Navarro  Se declaran los beneficios de la aprobación del plan de pruebas.
7.16 15-May-15 Mauricio Navarro  Se modifica la actividad de aprobación de planes de pruebas.
7.15 12-May-15 Mauricio Navarro  Se adiciona el rol del Líder de Desarrollo Claro.
 Se adicionan responsabilidades al rol del Líder de Desarrollo Claro.
 Se ratifica que el usuario final debe ser incluido en los destinatarios de la
asignación y demás plantillas de correo a excepción de los informes de avance.
7.13 20-Mar-15 Mauricio Navarro  Se aclara la forma en que se deben archivar los soportes del correo de solicitud de
pruebas.
 Se vinculan los nuevos formatos de asignación formal y no formal de fábrica de
pruebas.
7.12 18-Mar-15 Mauricio Navarro  Se incluye nueva condición para el registro de consideraciones en ALM.
 Se aclara la forma en que debe ser archivado el seguimiento en producción en
ALM.
7.11 13-Feb-15 Mauricio Navarro  Se vincula la guía para los manuales de los aplicativos.
 Se modifica el objetivo y el alcance del mensaje del plan de pruebas.
 Se modifica el objetivo del mensaje de planeación y diseño.
 Se modifica el objetivo del mensaje de diseño de casos.
7.10 12-Feb-15 Mauricio Navarro  Se vincula la Guía de Instalación de ALM, la Guía de Manejo y el manual de
usuario.
 Se actualiza el archivo de Directrices ALM en la transacción “Crea Requerimientos
de Prueba…” con respecto del campo No. de Servicio.
 Se resalta que en las pruebas no formales, se debe enviar plan de pruebas.
 Se especifica la hora de envío de los informes de avance.
7.8 10-Feb-15 Diego Espitia  Se vincula el proceso de Gestión control y monitoreo para las pruebas no
formales.
 Se realiza la aclaración en el proceso de seguimiento en producción
 Se crea la plantilla de seguimiento en producción y se especifica cuando se debe
enviar.
Histórico de Cambios

controlada.
MANUAL

09-Jun-2015

controlada.

Manual de Metodología de Pruebas de Software PDF

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual de Metodología de Pruebas de Software PDF

Cargado por

Copyright:

Formatos disponibles

MANUAL

DE METODOLOGÍA DE PRUEBAS DE SOFTWARE

Pertenece al procedimiento: Gestionar pruebas de software Fecha

Clasificación: Uso Interno Versión: 7.21 Código: AE3.12-M02

1. ESTRATEGIA DEL SERVICIO ......................................................................... 5

1.2. Visión ........................................................................................................................... 5

1.3. Objetivos ..................................................................................................................... 5

1.4. Equipo de Trabajo ...................................................................................................... 6

1.5. Portafolio Del Servicio De Pruebas ......................................................................... 9

1.7. Frentes De Trabajo .................................................................................................. 11

2. PROCESO DE PRUEBAS .............................................................................. 12

2.3. Flujo Del Proceso De Pruebas................................................................................ 15

2.4. Estados De Las Pruebas ......................................................................................... 16

2.5. Comunicaciones Internas Y Externas Del Proceso ............................................. 18

RESPONSABLE: Coordinador Calidad Software APROBÓ: Gerente Calidad Software

Pertenece al procedimiento: Gestionar pruebas de software Fecha

Clasificación: Uso Interno Versión: 7.21 Código: AE3.12-M02

2.6. Gestión De Hallazgos .............................................................................................. 18

2.7. Herramientas De Apoyo Al Proceso ...................................................................... 23

2.8. Soportes De Las Pruebas En El Repositorio ALM ............................................... 28

3. PRUEBAS FUNCIONALES ............................................................................ 29

RESPONSABLE: Coordinador Calidad Software APROBÓ: Gerente Calidad Software

Pertenece al procedimiento: Gestionar pruebas de software Fecha

Clasificación: Uso Interno Versión: 7.21 Código: AE3.12-M02

3.1.10. Gestión control y monitoreo .................................................................................................... 35

4. PRUEBAS NO FORMALES – ADELANTAR PLANEACIÓN Y DISEÑO. ... 38

5. PRUEBAS EN REQUERIMIENTOS ............................................................... 40

6. VALIDACIÓN DE CDR DE VOZ .......................................................................... 43

6.2. Tabla De Validación De Cdr’s Para Infracel ......................................................... 45

7. ASPECTOS IMPORTANTES DEL PROCESO ................................................... 47

7.2. Causales De Eventos Congelamiento-Devolución-Encolamiento ..................... 47

7.3. Requisitos De Las Pruebas De Desarrollo............................................................ 49

7.4. Causales Del Desfase .............................................................................................. 50

RESPONSABLE: Coordinador Calidad Software APROBÓ: Gerente Calidad Software

Pertenece al procedimiento: Gestionar pruebas de software Fecha

Clasificación: Uso Interno Versión: 7.21 Código: AE3.12-M02

7.4.1. Desfases en costos .................................................................................................................... 50

7.5. Estimación De Tiempos .......................................................................................... 50

7.6. Estándar Para Asunto De Los Mails Y Plantillas ................................................. 51

7.7. Adopción De Nuevos Sistemas A Probar ............................................................. 52

7.8. Lecciones Aprendidas............................................................................................. 53

7.10. Pruebas Compartidas Entre Front Y Back End .................................................. 54

8. GLOSARIO E INFORMACIÓN RELACIONADA SOBRE TESTING ................. 55

RESPONSABLE: Coordinador Calidad Software APROBÓ: Gerente Calidad Software

Pertenece al procedimiento: Gestionar pruebas de software Fecha

Clasificación: Uso Interno Versión: 7.21 Código: AE3.12-M02

1. ESTRATEGIA DEL SERVICIO

 Medir la calidad del producto de software.

RESPONSABLE: Coordinador Calidad Software APROBÓ: Gerente Calidad Software

Pertenece al procedimiento: Gestionar pruebas de software Fecha

Clasificación: Uso Interno Versión: 7.21 Código: AE3.12-M02

1.4. Equipo de Trabajo

RESPONSABLE: Coordinador Calidad Software APROBÓ: Gerente Calidad Software

Pertenece al procedimiento: Gestionar pruebas de software Fecha

Clasificación: Uso Interno Versión: 7.21 Código: AE3.12-M02

1.4.1. Comunicación del equipo de trabajo

En este diagrama se visualiza el esquema de comunicación entre el equipo de Claro QA y QA

Ejemplo: en el nivel operativo el coordinador de QA tiene comunicación directa con el líder de

RESPONSABLE: Coordinador Calidad Software APROBÓ: Gerente Calidad Software

Pertenece al procedimiento: Gestionar pruebas de software Fecha

Clasificación: Uso Interno Versión: 7.21 Código: AE3.12-M02

1.4.2. Roles del proceso