Documento Pruebas

8/17/2019 Documento Pruebas

1/35

2016

BATERIA DE PRUEBAS SISTEMA DE GESTIONDE INCIDENCIAS


2/35


3/35

BATERIA DE PRUEBAS

GLOSARIO DE TERMINOSTESTING: Es el proceso orientado a demostrar que un programa no tiene errores

TESTING: Es la tarea de demostrar que un programa realiza funciones para las cuales fue construidoTESTING: Es la ejecución de programas de software con el objetivo de detectar defectos y fallas

TEST EXITOSO: Aquel que detecta errores

TEST NO EXITOSO: Aquel que no los detecta

ERROR: Una equivocación de una persona al desarrollar alguna actividad de desarrollo de software

DEFECTO: Se produce cuando una persona comete un error

FALLA: Es en desvió respecto del comportamiento esperado del sistema, puede producirse en cualquier etapa

TOP-DOWN: Técnica que empieza con los módulos de nivel superior, y se verifica que los módulos de nivel superior llaman a los de nivel inferior de manera

correcta con los parámetros correctos.

DOWN- TOP: Técnica que comienza con los módulos de nivel inferior, y se verifica que los módulos de nivel inferior llaman a los de nivel superior de

manera correcta, con los parámetros correctos

CAJA NEGRA: Esto es verificar el sistema (y sus procesos internos), la integración con las aplicaciones que lo usan y analizar las salidas o resultados

CAJA BLANCA: El testeador escoge distintos valores de entrada para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se

devuelven los valores de salida adecuados.

HUMO: Una prueba de humo o smoke test, es un testing rápido que se realiza sobre aspectos funcionales no tanto para encontrar bugs sino para

asegurarse que la funcionalidad básica del software o de una parte del software se encuentre estable y responda al comportamiento esperado

STRESS: Se escala la cantidad de carga con el tiempo hasta que se encuentren los límites del sistema


4/35

INTRODUCCIONEl documento que a continuación se presenta está dirigido al equipo de soporte técnico conformado por: L.I. Edgar Leonardo Flores Esteban y el Ing. Jayro

Flores Tapia.

El objetivo de este documento es facilitar la información y datos necesarios para que el equipo de soporte realice las pruebas de calidad del sistema de

gestión de incidencias.

El presente documento se basa en varios niveles de pruebas, y estos a su vez integran diferentes métodos para validar la entrada de datos, procesamiento y

obtención de resultados, basados en el documento de especificación de requerimientos.

NIVELES DE PRUEBAS Test unitarios

Test de componentes / Test de integración

Test de funcionalidad

Test de aceptación

Niveles de prueba

Test Objetivo Participantes Ambiente MétodoUnitario Detectar errores en los datos, lógica y algoritmos Programadores Desarrollo Caja blanca

Integración Detectar errores de interfaces y relaciones entrecomponentes

Programadores Desarrollo Caja blanca, Top Down,Down-top

Funcional Detectar errores y fallas en la implementación de losrequerimientos

Testers y analistas Desarrollo FuncionalCaja negraHumoStressSeguridad

Aceptación Detectar fallas en la implementación del sistema Testers, analistas y cliente Productivo Funcional


5/35

DESCRIPCION DETALLADA DE LOS NIVELES DE PRUEBA

Prueba Objetivo DescripciónUnitario Se enfoca en ejecutar cada módulo (O unidad

mínima a ser probada, ejemplo: una clase) loque provee un mejor modo de manejar laintegración de las unidades en componentesmayores.Busca asegurar que el código funciona deacuerdo con las especificaciones y que elmodulo lógico es válido.

Particional los módulos en pruebas en unidades lógicas fáciles de probar. Por cada unidad hay que definir los casos de prueba (Pruebas de caja blanca) Para esto los casos de prueba se deben diseñar de forma tal que se recorran todos

los caminos de ejecución posibles dentro del código bajo prueba; por lo tanto eldiseñador debe construirlos con acceso al código fuente a probar.

Los aspectos a considerar son los siguientes:o Rutinas de excepcióno Rutinas de erroro Manejo de parámetroso Validacioneso Valores validoso Valores limiteso Rangoso Mensajes posibles

Comparar el resultado esperado con el resultado obtenido Si existen errores reportarlos

Integración Identificar errores introducidos por lacombinación de programas probadosunitariamente.Determina como la base de datos será cargada.

Verificar que las interfaces entre las entidadesexternas (usuarios) y las aplicaciones funcionancorrectamente.Verificar que las especificaciones de diseño seanalcanzadas.Determina el enfoque para avanzar desde unnivel de integración de los componentes alsiguiente

Describe como verificar que las interfaces entre los componentes de softwarefuncionan correctamente

Determina como la base de datos será cargada Determina el enfoque para avanzar desde un nivel de integración de componentes

al siguiente Decide qué acciones tomar cuando se descubren problemas Por cada caso de prueba ejecutado

o Comparar el resultado esperado con el resultado obtenido.o Utilizar la técnica top-down.o Utilizar la técnica down-top.


6/35

Funcional Se asegura el trabajo apropiado de los requisitosfuncionales, entrada de datos, procesamiento yobtención de resultados

Las pruebas funcionales deben enfocarse en los requisitos funcionales, las pruebaspueden estar basadas directamente en los casos de uso (o funciones de negocio), y lasreglas del negocio.Las metas de estas pruebas son:

Verificar la apropiada aceptación de datos Verificar el procesamiento y recuperación

Este tipo de pruebas está basado en caja negra. Determina que pruebas del sistema (usabilidad, volumen y desempeño, etc.)aseguran que la aplicación alcanzara sus objetivos

Aceptación Determinación, por parte del cliente de laaceptación de la aceptación o rechazo delsistema desarrollado

La prueba de aceptación es ejecutada antes de que la aplicación sea instalada dentro deun ambiente de producción. La prueba de aceptación es generalmente desarrollada yejecutada por el cliente o especialista de la aplicación y es conducida a determinar comoel sistema satisface sus criterios de aceptación validando los requisitos que han sidolevantados para el desarrollo, incluyendo la documentación y diagramas de proceso.Los casos de prueba de aceptación han de ser planificados, organizados y formalizadosde manera que se determine el cumplimiento de los requisitos del sistema.Para la realización de estas pruebas se necesita disponer de los siguientes documentos:

Especificación de requisitos del sistema


7/35

TIPOS Y MODELO DE PRUEBAS

Testdefacilidad

Testdevolumen

Testdestress

Testdeusabilidad

Testdeseguridad

Testdeconfiguración

Testdefiabilidad

Testderecuperación

Testdedocumentación

Testdemantenibilidad


8/35

PROCESOS INTERNOS MÁS IMPORTANTES

• Registro de incidencias

• Asignar incidencias

• Solucionar incidencias

• Validar incidencias• Aprobar incidencias

• Registro del problema

• Asignar problema

• Solucionar problema

• Validar problema

• Aprobar problema

• Generar reportes y graficas

• Registro de usuarios

•

Asignación de roles• Asignación de permisos a usuarios para sistemas en especifico


9/35

Partición de módulos

CATÁLOGOS

Caso de uso:


10/35

Caminos de ejecución:


11/35

Datos de pruebas:

Pruebas del módulo catálogos

Id Sub modulo Descripción del sub modulo Pre- requisitos Datos requeridos Resultado esperado Usuarios Role

1 Estados El usuario puede registrar diferentesestados de la república mexicana consus respectivos municipios

Ninguno • Estado• Municipio

El estado numero X fuecreado

JayroEdgar

TesterJefe de soporte técnico

2 Clientes Se registran los clientes que tengancontrato de soporte técnico ogarantía

Tener registros enel catálogo deestados

• Cliente

• Email• Estado

• Municipio

• Calle

• Núm. Interior• Núm. Exterior

• Colonia

• Código postal

• Teléfono• Sitio web

El cliente fue creadosatisfactoriamente

JayroEdgar


3 Sistemas Se registraran los sistemas que esténdisponibles, ya sea en ejecución o endesarrollo

Ninguno • Sistema

• Versión

• Descripción

• Categorías

• Funcionalidades

El sistema fue creadosatisfactoriamente

GabrielEsaú

Líder técnico de proyectosProgramadores

5 Clientes ySistemas

Se hace una relación entre los datosdel módulo cliente y los datos desistema. El cliente puede tener Nnúmero sistemas y cada sistemapuede tener N número de clientes

Tener registros enel catálogo declientes y en el desistemas

• Cliente Id

• Cliente nombre• Sistema id

• Sistema nombre

• Versión

• Fecha de garantía ofecha de contrato desoporte

La relación del cliente ysistema fue creadasatisfactoriamente

JayroEdgar



12/35

Sub modulo estados

Estados Id

Autoincremento)

Estados Nombre Municipio Id

Autoincremento)

Municipio Nombre

1 Morelos 1 Tlaltizapan

2 Temixco3 Cuernavaca

4 Jiutepec

5 Xochitepec

2 Guerrero 1 Acapulco de Juárez

2 Iguala

3 Taxco

Sub modulo clientes

Id Cliente Email Estado Municipio Calle Núm.

Int

Núm.

Ext

Col. C.P. Tel. Sitio web

1 Acapulco Acapulco. Juá[email protected] Guerrero Acapulco deJuárez La costa 14 12 Aguasblancas 39589 735689251 acapulco.gob.mx

2 Iguala Acapulco. Juá[email protected]

Guerrero Iguala 20 denoviembre

01 AdolfoLópezmateos

39470 735689241 iguala.gob.mx

3 Taxco Acapulco. Juá[email protected]

Guerrero Taxco Turquesa 32 21 Altos demarques

39898 7352966478 taxco.gob.mx

4 Tlaltizapan [email protected]

Morelos Tlaltizapan FranciscoVilla

14 EmilianoZapata

62776 7343436854 morelos.gob.mx/?q=tlaltizapan

5 Temixco [email protected]

Morelos Temixco Reforma 05 AltaPalmira

62583 7772589631 morelos.gob.mx/?q=temixco

6 Cuernavaca [email protected]

Morelos Cuernavaca Guayabosagrios

24 14 Buganvilias

62587 7776984238 morelos.gob.mx/?q=cuernavaca

7 Jiutepec [email protected]

Morelos Jiutepec Caminosagua fría

22 01 Agua Fría 62555 7775689125 morelos.gob.mx/?q=jiutepec

8 Xochitepec [email protected]

Morelos Xochitepec 3 de mayo 09 41 BenitoJuárez

63981 7776592147 morelos.gob.mx/?q=xochitepec

http://www.heraldo.com.mx/guerrero/acapulco-de-juarez/39589/http://www.heraldo.com.mx/guerrero/acapulco-de-juarez/39470/http://www.heraldo.com.mx/guerrero/acapulco-de-juarez/39898/mailto:[email protected]:[email protected]://www.heraldo.com.mx/morelos/temixco/62583/mailto:[email protected]:[email protected]://www.heraldo.com.mx/morelos/temixco/62587/mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]://www.heraldo.com.mx/morelos/temixco/62587/mailto:[email protected]:[email protected]://www.heraldo.com.mx/morelos/temixco/62583/mailto:[email protected]:[email protected]://www.heraldo.com.mx/guerrero/acapulco-de-juarez/39898/http://www.heraldo.com.mx/guerrero/acapulco-de-juarez/39470/http://www.heraldo.com.mx/guerrero/acapulco-de-juarez/39589/


13/35

Sub modulo sistemas

Id

Sistema

Sistema Versión Descripción Id

categorías

Categorías Id funcionalidad Funcionalidad

1 SGI 1.1 Sistema para la gestión de incidenciasversión 1.1 para pruebas delaboratorio

1 Incidencias 1 Registrar

2 Asignar

3 Asignar no aprobadas

4 Solucionar

5 Validar2 Problemas 1 Registrar

2 Asignar

4 Solucionar

5 Validar

3 Reportes 1 Reportes para el área de soportetécnico

2 Reporte de sistemas específicos

3 Reportes área de desarrollo

2 SGI 1.0 Sistema para la gestión de incidenciasv 1.0 para las pruebas de sistemas por

liberar

1 Incidencias 1 Registrar

2 Asignar

3 Asignar no aprobadas4 Solucionar

5 Validar

2 Problemas 1 Registrar

2 Asignar

4 Solucionar

5 Validar

3 Web Pred 1.0 Sistema para el pago de predial, enlenguaje C, con función del cálculo depago

1Pago en ventanilla 1

Procesar pagos línea de captura

4 Web Pred 1.1 Sistema para el pago de predial, enlenguaje Java con funciones de cálculo,descuentos, pago Online, generarrecibos. Administraciones 2016.

1 Pago en ventanilla 1 Procesar pagos línea de captura

2 Pagos en línea 1 Pagos efectuados

2 Intentos de pago

3 Comentario

Configuración 1 Parámetros generales

2 Bancos

3 Factura electrónica

4 Pantalla principal

5 1.0 1 Ajustes 1 Histórico


14/35

Autorizaciónde valorescatastrales

Sistema para la autorización de valorescatastrales

2 Información digital

3 Consulta datos

2 Avalúos 1 Administración de usuario

2 Configuración de la aplicación

3 Reportes 1 Valor catastral

2 Incremento valor catastral

Sub modulo sistemas y clientes

SistemaYClienteId Cliente Id Cliente Sistema id Sistema Versión Fecha inicio

garantía

Fecha fin de

garantía

Fecha inicio

contrato de

soporte

Fecha fin contrato de

soporte

1 1 Acapulco 1 SGI 1.0

2 1 Acapulco 2 SGI 1.1 05/05/2016 05/06/2016

3 2 Iguala 3 Web Pred 1.0 06/05/2016 06/05/2016

4 3 Taxco 3 Web Pred 1.0 04/04/2016 04/05/2016

5 4 Tlaltizapan 3 Web Pred 1.1 08/06/2016 08/07/2016

6 4 Tlaltizapan 4 Web Pred 1.1 01/05/2016 01/06/20167 5 Temixco 4 Web Pred 1.1 10/05/2016 10/06/2016

8 6 Cuernavaca 5 Autorizaciónde valorescatastrales

1.0

9 6 Cuernavaca 2 SGI 1.1 20/05/2016 20/06/2016

10 7 Jiutepec 4 Web Pred 1.1 28/04/2016 28/05/2016

12 8 Xochitepec 1 SGI 1.1 30/04/2016 30/05/2016

Sub modulo ciclo

id Fecha inicial Fecha final Sistema id Nombre Cliente Versión Descripción

1 Se genera el díaque se crea unnuevo ciclo

05/06/2016 1 SGI Acapulco 1.0 Pruebas de la etapa unodel SGI


08/07/2016 1 SGI Acapulco 1.0 Pruebas de la etapa dosdel SGI


15/35


05/06/2016 5 Autorización devalores catastrales

Cuernavaca 1.0 Pruebas de la etapa unoautorización de valorescatastrales


09/07/2016 5 Autorización devalores catastrales

Cuernavaca 1.0 Pruebas de la etapa dosautorización de valorescatastrales

5 Se genera el día

que se crea unnuevo ciclo

10/07/2016 5 Autorización de

valores catastrales

Cuernavaca 1.0 Pruebas de la etapa tres

autorización de valorescatastrales


16/35

SEGURIDAD

Caso de uso:


17/35

Caminos de ejecución


18/35


19/35

Sub Modulo Usuarios

Nombre E-mail Apellido Paterno Apellido Materno Contraseña Confirmar

contraseña

Fecha de

Nacimiento

Genero

edgar Nota el correo debe estar activopara recibir las notificaciones

Flores Esteban eflorese eflorese 27/04/1986 Masculino

esau Nota el correo debe estar activo

para recibir las notificaciones Farías

Bahena efariasb efariasb 28/04/1992 Masculino

gabriel Nota el correo debe estar activo

para recibir las notificaciones

Mancilla Mondragon gmancillam gmancillam 28/04/1980 Masculino

jayro

Nota el correo debe estar activo

para recibir las notificaciones

Flores Tapia Jflorest Jflorest 28/04/1991 Masculino

Yohana [email protected] Garcia Sandoval Ygarcias Ygarcias 18/03/1993 Femenino

Guadalupe [email protected] De Jesus De Jesus Gdejesusd Gdejesusd 12/01/1993 Femenino

Sub Modulo Roles

Usuario Role

edgar Jefe de Soporte Técnico

jayro Tester

Yohana Usuario de Sistemas

Guadalupe Usuario de Sistemas


20/35

Sub Modulo Asignar Permisos

Usuario

Sistemas

edgar Acapulco SGI 1.0

edgar Acapulco SGI 1.1

edgar Iguala Web Pred 1.0

edgar Taxco Web Pred 1.0edgar Tlaltizapan Web Pred 1.1

edgar Tlaltizapan Web Pred 1.1

edgar Temixco Web Pred 1.1

edgar Cuernavaca Autorización de valores catastrales 1.0

edgar Cuernavaca SGI 1.1

edgar Jiutepec Web Pred 1.1

edgar Xochitepec SGI 1.1

jayro Acapulco SGI 1.0

jayro Acapulco SGI 1.1

jayro Iguala Web Pred 1.0

jayro Taxco Web Pred 1.0 jayro Tlaltizapan Web Pred 1.1

jayro Tlaltizapan Web Pred 1.1

jayro Temixco Web Pred 1.1

jayro Cuernavaca Autorización de valores catastrales 1.0

jayro Cuernavaca SGI 1.1

jayro Jiutepec Web Pred 1.1

jayro Xochitepec SGI 1.1

yohana Acapulco SGI 1.1

yohana Iguala Web Pred 1.0

yohana Taxco Web Pred1.0

guadalupe Tlaltizapan Web Pred 1.1guadalupe Temixco Web Pred 1.1


21/35

INCIDENCIAS

Casos de uso:


22/35



23/35


24/35


25/35

Datos de pruebas:

Caminos de pruebas del módulo Incidencias

Id Sub

modulo

Descripción del sub

modulo

Pre- requisitos Datos requeridos Resultado esperado Usuarios Role

1 Registro deuna nuevaincidencia

Registro de unanueva incidencia de:LaboratorioGarantíaContrato de soporteTécnico

Para los tres tipos deincidencia se debe tenerdatos en los catálogos de:Sistemas y ClientesSistemasUsuarios con permisos desistemas para el registrode incidenciasPara Incidencias de tipolaboratorio se debetener:

Registro de ciclos activos

• Fecha de Registro

• Usuario que registra

• Sistema

• Sistema Nombre

• Cliente Nombre

• Menú Id

• Menú nombre

• Funcionalidad Id

• FuncionalidadNombre

•

Tipo de Incidencia• Medio de Reporte

• Ciclo Id

• Usuario Id

• Usuario NombreCompleto

• Usuario Email

• URL

• Fecha Solución

• Descripción

• Adjuntar Archivos

Generación de un nuevoregistro con un ticket deacuerdo al tipo de incidenciaG= GarantíaD= DesarrolloC=Contrato de

Soporte técnicoIncidencias de Garantía yContrato de Soporte TécnicoSe genera un comprobante delregistro de su incidencia conlos siguientes campos N° Ticket Cliente Nombre del Sistema Prioridad Fecha de registro

Fecha de ProbableSolución

Descripción Menú FuncionalidadEl cual será enviadoautomáticamente a su correoelectrónico

LaboratorioEdgarJayro

Garantía yContrato deSoporteTécnicoEdgarJayro

CarlosAnellIsmaelYohana

LaboratorioJefe de soportetécnicoTester

Garantía y Contratode Soporte TécnicoJefe de soportetécnicoTesterJefe de Gestión de

ProyectosContabilidadUsuario deSistemas


26/35

2 AsignarIncidencia

La asignación deIncidencias serealizara por:Técnico de SoporteLíder Técnico deProyecto

Incidencias registradasTener registradosusuarios con Roles de:TesterLíder técnicoProgramadores

Seleccionar unaincidencia para asignar(Ticket)Seleccionar unTester, Líder Técnico oProgramador según seael casoFecha de asignaciónDatos opcionales

Seleccionar una nuevaprioridad si se requiereAdjuntar archivos

La incidencia cambiara suStatus a asignado al personalcorrespondiente a la selecciónen la asignación.Se le enviara una notificaciónal personal que se le asigno laincidenciaCon la siguiente información. Ticket Nombre del Sistema Prioridad Fecha de registro Fecha de Probable

Solución Descripción Menú

FuncionalidadY un URL para acceder al SGIpara solucionar la incidencia

Asignarincidencias enel Área deSoporteTécnicoEdgar

Asignarincidencias enel Área deDesarrolloGabriel

Asignar incidenciasen el Área deSoporte TécnicoJefe de soportetécnico

Asignar incidenciasen el Área deDesarrolloLíder Técnico deproyecto

3 SolucionarIncidencia

Al inicio de sesión delusuario se mostraráuna tabla con susincidencias asignadas

Se debe tener incidenciasasignados

Seleccionar de la tablauna Incidencia paraobtenerTicketSistemaPosteriormente redactarla soluciónNombre de quien

solucionaFecha de soluciónDatos que se puedenrequerirSi en el proceso desolución de la incidenciaes necesario una nuevaversión se debe marcar

La incidencia cambiara deStatus a Solucionado

EdgarJayroGabrielEsaú

Jefe de soportetécnicoTesterLíder Técnico deproyectoProgramador

el campo de nueva


27/35

el campo de nuevaversiónEl cual mostrara unaventana para agregar lanueva versión delsistema el cual a su veznotificara al Jefe deSoporte Técnico de lanueva versión que se diode alta

4 ValidarIncidencia En el menú deIncidencias Validar semostrara una tablaactualizada de lasincidencias que ya sesolucionaron paraproceder a validarlas

Tener IncidenciasSolucionadas Seleccionar de la tablauna incidencia paravalidar que obtendrá losdatos de:TicketEl usuario que realice lavalidación debe Ingresarla siguiente informaciónde la validaciónTipo de Prueba querealizoTipo de Bug

Quien validoFecha de ValidaciónInformación opcionalAdjuntar archivosrequeridos

Puede generar dos resultadosValidar o No validar laIncidenciaValidarSi se realiza la validación laIncidencia cambia su status haTerminadoY actualiza la base de datoscon los datos requeridosanteriormente.Se envía una notificación a losusuarios externos para que

realicen la aprobación de laincidencia esto si es incidenciade tipo garantía o contrato desoporte técnicoEl correo contendrá los datossiguientes:N° TicketClienteNombre del SistemaPrioridadFecha de registro

Fecha de Probable SoluciónDescripciónMenúFuncionalidadFecha de SoluciónTécnico que resolvióSoluciónFecha Validación

EdgarJayro Jefe de soportetécnicoTester

Esto para indicarle que su


28/35

Esto para indicarle que suincidencia se ha validado y quetiene un tiempo máximo de 3días para aprobarlo o noaprobarlo, en caso de vencer eltiempo esta incidencia pasaraa un Status de FinalizadoautomáticamenteNo ValidarCambia el Status de la

Incidencia ha Asignado y seregresa la incidencia al usuarioasignado de resolverla paraque realice la solucióncorrespondiente

5 AprobarIncidencia

Al Iniciar sesión semostrara una tablacon las incidenciaspendientes poraprobar en su tiempode espera derespuesta

correspondiente

Tener incidenciasvalidadas del usuarioexterno

Se debe seleccionar unaincidencia de la tabla

Información opcionalcomentario respecto a laaprobaciónInformación Requerida

Descripción de por quéno se aprobó laincidencia

Puede generar 2 resultadosaprobar o no aprobar laincidencia

Aprobar la IncidenciaActualiza la base de datos conStatus aprobado y guarda la

fecha de aprobaciónOpcionalAgregar algún comentario dela aprobación de la incidenciaNo AprobadaCambia el Status de laIncidencia a No Aprobada paravolver a solucionarla

Obligatorio:Agregar la información de por

qué no se aprobó para volver arealizar la investigación ydiagnóstico de la incidencia

Yohana Usuario deSistemas


29/35


30/35

T1000DM003-1ER162_Z4Y6FC71XXXXZ4Y6FC71

El día en que

se haga elregistro

jayro 8

Autorizacion de

valorescatastrales

Cuernavaca 1 Ajustes 2 InformacionDigital Desarrollo Laboratorio 3

http://www.yoursearching.com/?type=sc&ts=1455384884&z=057ddc7e372

701020cc4008g3zf w9wec5b1z0bbbdc&from=face&uid=ST1000DM003-1ER162_Z4Y6FC71XXXXZ4Y6FC72

08/05/2016

No genera el

comprobantede los valorescatastrales

no

El día en quese haga elregistro

jayro 8

Autorizacion devalorescatastrales

Cuernavaca

1 Ajustes 3Consulta dedatos

Desarrollo Laboratorio 3

http://www.yoursearching.com/?type=sc&ts=1455384884&z=057ddc7e372701020cc4008g3zf w9wec5b1z0bbbdc&from=face&uid=ST1000DM003-1ER162_Z4Y6FC71XXXXZ4Y6FC73

09/05/2016Se generandatos vacios

si


jayro 8


Cuernavaca

2 Avalúos 1Administracionde usuarios



13/05/2016

No permiteasignarpermisos a losusuarios denuevo ingreso

no


jayro 8


Cuernavaca

2 Avalúos 2Configuraciónde la aplicación



09/05/2016

La aplicaciónno funciona enla red delservidor 30

no


31/35


jayro 8


Cuernavaca

3 Reportes 1 Valor Catastral Desarrollo Laboratorio 5


16/05/2016

No genera losvalores delperiodo que sele solicita

si


jayro 8


Cuernavaca

3 Reportes 2Incremento delvalor catastral



30/05/2016

Los valores deincrementoexceden ellimiteaprovado

no


32/35

PROBLEMAS

Casos de uso:


33/35



34/35

Dados de Pruebas:

Caminos de pruebas del módulo Problemas

Id Sub

modulo

Descripción del

sub modulo

Pre- requisitos Datos requeridos Resultado esperado Usuarios Role

1 Registro deuna nuevoproblema

Registro de unnuevo problema,los problemas sonorigen deincidencias quepasan variosciclos de solucióny validación sinconseguirsolucionarse.

Para llevar a cabo elregistro delproblema debetener datos en loscatálogos de:Sistemas y ClientesSistemas

• Fecha de Registro

• Usuario que registra

• Sistema

• Sistema Nombre

• Sistema versión

• Menú Id

• Menú nombre

• Funcionalidad Id

• Funcionalidad Nombre

• URL

• Descripción

• Adjuntar Archivos

Generación de unnuevo registro con unticket de acuerdo altipo que es problemaG= Problema

EdgarJayro

Jefe de soporte técnicoTester

2 Asignarproblema

La asignación deproblemas serealizara por:Técnico deSoporteLíder Técnico deProyecto, paraque el tester oprogramador alque se las asigna,

proceda con lasolución.

Datos deIncidenciasregistradasTener registradosusuarios con Rolesde:TesterLíder técnicoProgramadoresJefe de soporte

técnico

Seleccionar una problema para asignar(Ticket)Seleccionar a quien asignarlo, en caso deque el que asigna es el Jefe de soportetécnico, se le mostraran los usuarios quecumplan con el rol de tester, Jefe desoporte técnico, Líder técnico de proyectoEn caso de ser el Líder técnico el queasigna se le mostraran los usuarios quecumplan con el rol de programador, jefe

de soporte técnico y líder técnico deproyectoFecha de asignaciónSeleccionar prioridadDatos opcionales

Adjuntar archivos

El problema cambiarasu Status a asignado.

EdgarGabriel

Jefe de soporte técnicoLíder Técnico deproyecto


35/35

3 Solucionarproblemas

Los usuarios a losque se lesasignaronproblemaspuedensolucionarlas

Tener incidenciasasignadas

Seleccionar de la tabla una problemas paraobtenerTicketSistemaPosteriormente redactar la soluciónNombre de quien solucionaFecha de solución

El problema cambia deStatus ha

Terminado

EdgarJayroGabrielEsaú

Jefe de soporte técnicoTesterLíder Técnico deproyectoProgramador

4 ValidarIncidencia

Se validan losproblemas que yacambiaron sustatus haterminado

Que algúnproblema estéterminado

Seleccionar de la tabla una problema paravalidar que obtendrá los datos de:TicketDatos para la validación:

Tipo de Prueba que realizoTipo de BugDatos de la sesión:

Fecha de ValidaciónQuien validaInformación opcional:

Adjuntar archivos requeridos

Puede generar dosresultados Validar o NovalidarSi se realiza lavalidación el problemacambia su status haValidado

EdgarJayro

Jefe de soporte técnicoTester

Documents

Documento Pruebas