EJERCICIO:

1.- Elabore de acuerdo a la metodología que conozca las actividades que considere necesarias
hasta generar los casos de prueba en base a la información dada.

2.- Liste las preguntas que realizaría a los desarrolladores y Usuarios para poder entender el
Requerimiento

3.- Elaborar las actividades de QA, en base a la información dada.

NUEVA PANTALLA DE SOLICITUD DE TARJETAS

1. Motivo:

XXXXX BANCA EC. del Ecuador con el objetivo de brindar un mejor servicio a sus clientes ha
procedido a contratar los servicios de un proveedor que se encargará del desarrollo y
administración de un frame que utilizará los servicios y transacciones que pueden ser
realizadas en línea por los socios Diners: Personas naturales, jurídicos y establecimientos.

El presente documento describe las interfaces necesarias por medio de las cuales la data de
los clientes será trasmitida desde los sistemas participantes al frame, para lo cual se proveerá
los servicios de integración que permitan a los sistemas comunicarse y consumir los datos
necesarios para garantizar una óptima operatividad de XXXXX BANCA EC

2. Objetivo

El objetivo de este requerimiento es ofertar a los clientes un listado de los productos que la
organización dispone para que pueda solicitar.

3. Alcance

Generar una consulta con todos los productos que el cliente no posea y que la organización
desee ofertar.
 Esta funcionalidad estará disponible para:
a) Clientes Personales Principales
b) Clientes Personales Adicionales
c) Persona Natural Prepago
d) Persona Jurídica - Administrativos (Cliente Administrador de la cuenta del
Establecimiento)

 Esta funcionalidad NO estará disponible para:

a) Clientes en listas Negras (CONSEP, OFAC, PEP’s), en mora o vencidas

INTEGRACIONES:
 Integrar la aprobación de pre cancelación al módulo OTP.
 Integración con Sistema de Casos, para generación de Casos de Asistencia
Automáticos
 Generar Notificaciones mediante SMS y/o mail a través del módulo de mensajería.

4. Prerrequisitos

N/A

5. Análisis Funcional
 5.1. Situación Actual

Actualmente existen procesos de Solicitud de tarjetas desde los portales WEB, los mismos que
en su operativa difieren dependiendo de la marca:
Para Diners la información que ingresa el cliente se almacena en un repositorio y posterior a
ello el oficial es quien manualmente registra la información en el sistema principal
Para Discover la información que el cliente registra en la web se registra en el sistema de casos
como una venta Potencial, y posterior a ello el agente manualmente realiza la gestión hasta
generar un Lote mismo que es enviado al sistema principal
5.2. Situación Propuesta

Se propone mantener una operativa genérica para las solicitudes, mismas que internamente
ejecutan los procesos propios de cada marca.

5.2.1.Diagrama de la situación Propuesta:

Servicios y programas Nuevos:
T0  Lista de Productos que no dispone el cliente
T1  Servicio que obtiene la información del Cliente Principal
T2  Servicio que obtiene la información del Cliente Adicional
T3  Servicio para Grabar la Solicitud de tarjeta Principal
T4  Servicio para Grabar la Solicitud de tarjeta Adicional o Convenio
T5  Validar Scoring
T6  Crear en el Sistema de Casos

Servicios y Programas a Reutilizar:

 Servicio Genérico de Casos para crear y cerrar los casos.
 Servicio de para Validar Listas Negras

5.2.2. Descripción de Procesos

5.2.2.1. Lista de Productos que no dispone el cliente (T0)

Servicio para consultar 4 listados de tarjetas que el cliente no posee y que se le desea ofertar.

Este servicio es nuevo y utiliza programas RPG y JAVA

Los listados de productos son los siguientes:

Listado de Tarjetas Principales que aún no posee el cliente.
Listado de tarjetas Adicionales relacionadas con las tarjetas principales que el cliente posee.
Listado de tarjetas Convenio relacionadas con las tarjetas principales que el cliente posee.
Listado de Tarjetas Prepago: relacionadas con las tarjetas principales que el cliente posee.

El servicio recibe como parámetros de entrada:

a) Número de Identificación
b) Tipo de Identificación
Pregunta: Cuales son las restricciones y validaciones de estos campos, en caso de no
encontrar que devuelve el sistema
El servicio responderá lo siguiente:
 1. Lista de Tipos de tarjetas a ofertar
 Código de Tipo de tarjeta
 Descripción
 Lista de Productos (Para cada uno de los tipos se tiene el siguiente listado)
 Código Marca
 Código Entidad
 Código de Producto
 Nombre del Producto
 URL Detalle
 URL Imagen
 Descripción Corta

Esta información la obtienen desde el Sistema Principal

5.2.2.2. Servicio que obtiene la información del Cliente Principal

Servicio que envía a consultar la información que se tenga para llenar el formulario de la
solicitud de Tarjetas Principales

El servicio recibe como parámetros de entrada:

a) Número de Identificación
b) Tipo de Identificación

El servicio responderá lo siguiente:

a) Una estructura con toda la información que dispone el cliente
Pregunta: La estructura en que formato y que información es la que se debe presentar
si todo o cual es la necesaria.

5.2.2.3. Servicio que obtiene la información del Cliente Adicional

Servicio que envía a consultar la información que se tenga para llenar el formulario de la
solicitud de Tarjetas Adicionales de Terceros, esta es la información que se va a presentar en
el Portal
El servicio recibe como parámetros de entrada:
a) Número de Identificación Principal
b) Tipo de Identificación Principal
c) Número de Identificación Adicional
d) Tipo de Identificación Adicional
e) Indicador de Tercero (S / N)

El servicio responderá lo siguiente:

a) El listado de la información del Cliente Adicional

Pregunta: Como se le presenta al usuario, con qué información no describen que debe
devolver el servicio

5.2.2.4. Grabar Información de la Solicitud de Tarjeta Principal (T3)

Si el producto seleccionado se encuentra en la base de Pre aprobado para el cliente, este

Servicio debe grabar la solicitud en el sistema principal, similar como lo realiza el proceso de
Afiliación que deja los registros listos para la impresión de la tarjeta

Caso contrario debe registrar la solicitud como un caso en el Sistema de Casos, adicional se
debe registrar en el Sistema Principal toda la información de la solicitud en una nueva
estructura.
El servicio recibe como parámetros:
a) Trama con la información del cliente a ser creado
El servicio responde:
a) Descripción Estado
b) Cód. Transacción (secuencial generado)
c) Fecha
d) Hora

Internamente el flujo debe valida el prescoring y si su respuesta NO es favorable se debe

registrar la información en el LOG
Si la respuesta no es favorable que alerta o notificación se recibe en el sistema

5.2.2.5. Grabar Información de la Solicitud de Tarjeta Adicional (T5)

Servicio que debe grabar la solicitud en el Sistema Principal, similar como lo realiza el proceso
de Afiliación que deja los registros listos para la impresión de la tarjeta

Caso contrario debe registrar la solicitud como una oportunidad en el sistema de Casos,
adicional se debe registrar en el CORE toda la información de la solicitud en una nueva
estructura.
El servicio recibe como parámetros:
b) Trama con la información del cliente a ser afiliado

El servicio responde:
a) Descripción Estado
b) Cód. Transacción (secuencial generado)
c) Fecha
d) Hora

Internamente el flujo debe valida el prescoring y si su respuesta NO es favorable se debe

registrar la información en el archivo de LOG FORDATP

5.2.2.6. Validar Prescoring (T5)

Servicio que valida el scoring de un cliente, en base a su respuesta el flujo determina si crear
una oportunidad o enviar al LOG.

5.2.2.7. Crear Oportunidad (T6)

Servicio que genera una oportunidad en el sistema de casos, a partir del cual el usuario puede
continuar con el proceso operativo para generar las afiliaciones, es llamado desde el flujo que
guarda la información de la solicitud.

5.2.2.8. Consulta de solicitudes ingresadas desde la WEB (AS400)

Pantalla de consulta de formularios ingresados en la web para solicitud de tarjetas principales y

adicionales, para lo cual se debe crear la Opción: CONSULTA FORMULARIOS WEB

La consulta se podrá realizar por:

 Número de Solicitud (secuencial autogenerado)
 Estado de la Solicitud
 Fecha de ingreso del Formulario

6. Identificación del Riesgo

Riesgo Síntomas Respuesta Acciones de Responsable
mitigación
Interrupción en la Se obtienen Mitigar Generar un control de IBM
comunicación entre errores en excepciones en IIB
el ambiente web y el comunicación con que permita identificar
AS400. AS400 – timeout. el error y envíe alertas
a los administradores
de servidores.
Tiempo de Alto tiempo en Mitigar Realizar pruebas de IBM
respuesta de los respuesta estrés al AS400.
distintos sistemas desde el As400
involucrados.
Solicitudes sin Crear un esquema Diners
Indisponibilidad de respuesta Activo – Pasivo.
Mitigar
IIB desde el frame Implementar Cluster
multicanal de servidores

Respuestas

1- Actividades necesarias
Definir plan de pruebas teniendo en cuenta los requerimientos definidos, describiendo
como se realizarán las pruebas establecidas durante el proceso de validación. Las
actividades que se deben seguir y los tipos de pruebas que se deben realizar.
Definir o establecer actividades tanto con los analistas como el cliente para entender
los requerimientos y plantear en caso de ser necesario inquietudes observaciones o
bien dudas al respecto.
2-
 No se definen estándares ni validaciones para campos en caso de no encontrar
resultado que debe retornar el sistema. Si la fecha de ingreso del formulario
coincide con otras como muestra las solicitudes ingresadas ¿? ¿El número de
solicitud seria único en el sistema? (ID), si es por estado igual devuelve un listado
de todas las solicitudes.
 Pregunta: Como se le presenta al usuario, con qué información no describen que
debe devolver el servicio
 Pregunta: La estructura en que formato y que información es la que se debe
presentar si todo o cual es la necesaria.
 Pregunta: Cuales son las restricciones y validaciones de estos campos, en caso de
no encontrar que devuelve el sistema
 Notificación al usuario que información recibe como es la plantilla a recibir.
 Pregunta: Todos son obligatorios, cuáles son las validaciones de debe tener cada
campo de entrada.
3-
 Como actividad principal en base a la documentación entregada se debe tener una
reunión con analistas y desarrolladores para aclarar y esclarecer los
requerimientos
 Elaborar plan de pruebas para definir que pruebas se deben realizar y cuál es la
estrategia a seguir
 Definir alcance de pruebas
 Definir escenarios de pruebas y validar su aprobación
 Definir alcance de pruebas con cliente
 Definir escenarios de pruebas con cliente para aceptación proyecto
 Diseñar casos de prueba según los requerimientos entregados
 Definir informes de QA para seguimiento
 Ejecutar pruebas.
 Registro de incidencias
 Entregar informe de pruebas según las iteraciones
 Pruebas de regresión.
 Pruebas de aceptación
 Acta de aceptación