SlideShare una empresa de Scribd logo
1 de 6
Descargar para leer sin conexión
DISEÑO DE CASO DE PRUEBAS
1. REQUERIMIENTOS DEL SISTEMA
Para la realización de las pruebas de nuestro sistema, realizamos una lista con los
requerimientos funcionales y no funcionales solicitados para el correcto desarrollo de nuestro
proyecto.
1.1. Requerimientos Funcionales
Un requerimiento funcional define una función del sistema de software o sus
componentes. Una función es descrita como un conjunto de entradas, comportamientos y
salidas. Los requerimientos funcionales pueden ser:
CÁLCULOS,
DETALLES TÉCNICOS,
MANIPULACIÓN DE DATOS Y
OTRAS FUNCIONALIDADES ESPECÍFICAS QUE SE SUPONE, UN SISTEMA DEBE
CUMPLIR (REGISTRAR, MODIFICAR, ELIMINAR, GENERAR REPORTES, ENTRE
OTRAS).
Como se define en la ingeniería de requerimientos, los requerimientos funcionales
establecen los comportamientos del sistema.
1.2. Requerimientos No funcionales
Un requerimiento no funcional o atributo de calidad es, en la ingeniería de sistemas y
la ingeniería de software, un requerimiento que especifica criterios que pueden usarse para
juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos
corresponden a los requerimientos funcionales. Por tanto, se refieren a todos los
requerimientos que ni describen información a guardar, ni funciones a realizar.
Algunos ejemplos de requisitos no funcionales típicos son los siguientes:
 Rendimiento
 Disponibilidad
 Seguridad
 Accesibilidad
 Usabilidad
 Estabilidad
 Portabilidad
 Costo
 Operatividad
 Interoperabilidad
 Escalabilidad
 Concurrencia
 Mantenibilidad
 Interfaz
2. SELECCIÓN DE MÓDULOS A PROBAR
Una vez teniendo en cuenta el listado de los requerimientos procedemos a especificar
cuales módulos vamos a evaluar lo hacemos de acuerdo a los requerimientos solicitados y le
agregamos un identificador a cada unidad a probar. Por ejemplo, basándonos en los
requerimientos:
Unidad de Prueba Identificador
Acceso MOD1
Contenido MOD2
Interfaz
Navegación
Seguridad
Validación
Base de Datos
Configuración
Comportamiento General
NOTA: El ID puede ser cualquier termino que se decida para designar a la unidad a probar.
3. PRUEBA DE LAS FUNCIONES POR MÓDULOS
Una vez identificados las unidades o módulos del sistema a probar hacemos una tabla
en la que colocamos el identificador del módulo con las funciones que debería cumplir el
sistema. Este es un ejemplo
Modulo Registrar Eliminar Modificar Calcular Reportes Funcion6
Mod1 SI NA NA NA NA NA
Mod2 SI SI SI SI SI SI
Mod3 SI NO SI NA NA SI
Mod4 SI SI SI NA NA SI
Mod5 NA NA NO NO NA SI
Mod6 NA NA NA NA NA SI
PARA AFIRMACIÓN DE LA FUNCIÓN SE COLOCA (SI), (NO) O (N/A)= NO
APLICA
O EN SU DEFECTO UNA X O UN VIÑETE DE AFIRMACIÓN
Recuerden que las funciones pueden ser Cálculos, detalles técnicos y funciones
básicas que debe cumplir el sistema, como de la misma manera se pueden estar evaluando
los requemamientos no funciones como: interfaz, acceso, seguridad, usabilidad, entre otras.
4. VEREDICTO DE LAS PRUEBAS
Una vez realizada la prueba se hace la descripción para el veredicto y/o resultado
generado por la prueba.
ID Módulo Probado Resultado
obtenido
Veredicto observaciones
Mod1 Acceso a la interfaz principal Esperado Funcional
Mod2 Validación de formularios Esperado Funcional
Mod3 Registro de los usuarios Esperado Funcional
Mod4 Seguridad de acceso Esperado Funcional
Mod5 Conexión con la base de
datos
Esperado Funcional
Mod6 Genera el reporte solicitado Esperado Funcional
- El resultado puede ser Esperado o sin resultado (el modulo esta en construcción), o fallido.
- Veredicto puede ser Funcional o No Funcional.
- Observaciones se coloca cualquier eventualidad presentada durante la prueba.
5. DOCUMENTACIÓN DE LA PRUEBA
Por último se realiza una ficha la cual contendrá ciertos datos indispensables de la
realización de prueba la cual es la que el PROBADOR certificara y hará constar de la
ejecución de la misma.
Documentación de la Prueba
INSTITUCIÓN RESPONSABLE FECHA
NOMBRE DE LA INSTITUCIÓN
TITULO DEL PST II
DOCUMENTOS DE REFERENCIA
Identificador Título
Mod1 Acceso a la interfaz principal
Fecha de realización:
22-06-2013
Duración de la prueba: 1 hora
Requerimientos
de la prueba
LAPTOP, PENDRIVE...
Objetivo Encontrar el mayor numero de errores posibles, para la mejora
del sistema.
Resultado Esperado
Resultado Obtenido Prueba Exitosa SI(X ) NO( )
Estado del Caso de No iniciado En curso Terminado
prueba X
Personal Requerido Cargo Nombre Firma
Profesor/Ingeniero FULANITO
Comentarios En este modulo, se encontró una falla de seguridad, no esta
cifrada la contraseña.
Realizado por: Firma Fecha
NOMBRE TUTOR
TECNICO
00/00/201X
Aprobado por: Firma Fecha
TUTOR(A) ACADEMIC@ 00/00/201X

Más contenido relacionado

La actualidad más candente

Introducción a las Pruebas Software
Introducción a las Pruebas SoftwareIntroducción a las Pruebas Software
Introducción a las Pruebas SoftwareMicael Gallego
 
Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionalesRequisitos funcionales y no funcionales
Requisitos funcionales y no funcionalesRene Guaman-Quinche
 
Requerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No FuncionalesRequerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No FuncionalesCarlos Macallums
 
Diagramas de caso de uso
Diagramas de caso de usoDiagramas de caso de uso
Diagramas de caso de usoTensor
 
Normas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de SoftwareNormas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de SoftwareEvelinBermeo
 
Casos de prueba de caja blanca (WhiteBox)
Casos de prueba de caja blanca (WhiteBox)Casos de prueba de caja blanca (WhiteBox)
Casos de prueba de caja blanca (WhiteBox)Jesús Navarro
 
Plantilla para realizar un manual de usuario de software
Plantilla para realizar un manual de usuario de software Plantilla para realizar un manual de usuario de software
Plantilla para realizar un manual de usuario de software Yaskelly Yedra
 
Analisis De Software
Analisis De SoftwareAnalisis De Software
Analisis De SoftwareWily Sánchez
 
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de usoPrimeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de usoJuan Pablo Bustos Thames
 
POE Unidad 2: Diseño y construcción de programas visuales y orientados a eventos
POE Unidad 2: Diseño y construcción de programas visuales y orientados a eventosPOE Unidad 2: Diseño y construcción de programas visuales y orientados a eventos
POE Unidad 2: Diseño y construcción de programas visuales y orientados a eventosFranklin Parrales Bravo
 
METODOLOGÍA UWE (UML-BASED WEB ENGINEERING)
METODOLOGÍA UWE (UML-BASED WEB ENGINEERING) METODOLOGÍA UWE (UML-BASED WEB ENGINEERING)
METODOLOGÍA UWE (UML-BASED WEB ENGINEERING) Germán Sánchez
 
REDES NEURONALES Algoritmos de Aprendizaje
REDES NEURONALES Algoritmos  de AprendizajeREDES NEURONALES Algoritmos  de Aprendizaje
REDES NEURONALES Algoritmos de AprendizajeESCOM
 
Requerimientos de Usabilidad
Requerimientos de  UsabilidadRequerimientos de  Usabilidad
Requerimientos de Usabilidadgcaicedo
 
diagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistemadiagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistemaUniversidad Tecnológica
 
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMASIMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMASAlcoverify
 

La actualidad más candente (20)

Introducción a las Pruebas Software
Introducción a las Pruebas SoftwareIntroducción a las Pruebas Software
Introducción a las Pruebas Software
 
Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionalesRequisitos funcionales y no funcionales
Requisitos funcionales y no funcionales
 
Sistema De Gestion De Notas De Post Grado
Sistema De Gestion De Notas De Post GradoSistema De Gestion De Notas De Post Grado
Sistema De Gestion De Notas De Post Grado
 
Requerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No FuncionalesRequerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No Funcionales
 
Diagramas de caso de uso
Diagramas de caso de usoDiagramas de caso de uso
Diagramas de caso de uso
 
Casos De Uso
Casos De UsoCasos De Uso
Casos De Uso
 
Ejemplo iconix
Ejemplo iconixEjemplo iconix
Ejemplo iconix
 
Normas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de SoftwareNormas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de Software
 
Casos de prueba de caja blanca (WhiteBox)
Casos de prueba de caja blanca (WhiteBox)Casos de prueba de caja blanca (WhiteBox)
Casos de prueba de caja blanca (WhiteBox)
 
Plantilla para realizar un manual de usuario de software
Plantilla para realizar un manual de usuario de software Plantilla para realizar un manual de usuario de software
Plantilla para realizar un manual de usuario de software
 
Analisis De Software
Analisis De SoftwareAnalisis De Software
Analisis De Software
 
Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionales Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionales
 
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de usoPrimeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
 
Pruebas unitarias
Pruebas unitariasPruebas unitarias
Pruebas unitarias
 
POE Unidad 2: Diseño y construcción de programas visuales y orientados a eventos
POE Unidad 2: Diseño y construcción de programas visuales y orientados a eventosPOE Unidad 2: Diseño y construcción de programas visuales y orientados a eventos
POE Unidad 2: Diseño y construcción de programas visuales y orientados a eventos
 
METODOLOGÍA UWE (UML-BASED WEB ENGINEERING)
METODOLOGÍA UWE (UML-BASED WEB ENGINEERING) METODOLOGÍA UWE (UML-BASED WEB ENGINEERING)
METODOLOGÍA UWE (UML-BASED WEB ENGINEERING)
 
REDES NEURONALES Algoritmos de Aprendizaje
REDES NEURONALES Algoritmos  de AprendizajeREDES NEURONALES Algoritmos  de Aprendizaje
REDES NEURONALES Algoritmos de Aprendizaje
 
Requerimientos de Usabilidad
Requerimientos de  UsabilidadRequerimientos de  Usabilidad
Requerimientos de Usabilidad
 
diagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistemadiagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistema
 
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMASIMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
 

Similar a Como uso el formato de pruebas

Diseños de planes de pruebas de software1
Diseños de planes de pruebas de software1Diseños de planes de pruebas de software1
Diseños de planes de pruebas de software1Vanessa Toral Yépez
 
Unidad # 8 diseño de planes de prueba
Unidad # 8 diseño de planes de pruebaUnidad # 8 diseño de planes de prueba
Unidad # 8 diseño de planes de pruebaDarleneperalta
 
Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1naviwz
 
Ciclo de vida del desarrollo de software
Ciclo de vida del desarrollo de softwareCiclo de vida del desarrollo de software
Ciclo de vida del desarrollo de softwareDulce Arenas Garzon
 
Tipos de modelos de procesos
Tipos de modelos de procesosTipos de modelos de procesos
Tipos de modelos de procesosEIYSC
 
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...Gustavo Palomo Ureña
 
Segunda web conferencia
Segunda web conferenciaSegunda web conferencia
Segunda web conferencialeidymedina28
 
Analisis y Diseño de Sistemas
Analisis y Diseño de SistemasAnalisis y Diseño de Sistemas
Analisis y Diseño de Sistemascardan2007i
 
Trabajo 2 exposicion
Trabajo 2 exposicionTrabajo 2 exposicion
Trabajo 2 exposicionEvelin Oña
 
Testing de software en instrumentos de pesar de funcionamiento no automatico ...
Testing de software en instrumentos de pesar de funcionamiento no automatico ...Testing de software en instrumentos de pesar de funcionamiento no automatico ...
Testing de software en instrumentos de pesar de funcionamiento no automatico ...Rodrigo Almeida
 
Auditoria de la seguridad informatica
Auditoria de la seguridad informaticaAuditoria de la seguridad informatica
Auditoria de la seguridad informaticaestudiante
 
Estándar IEEE 830-1998 - Especificacón de requisitos de Software
Estándar IEEE 830-1998 - Especificacón de requisitos de SoftwareEstándar IEEE 830-1998 - Especificacón de requisitos de Software
Estándar IEEE 830-1998 - Especificacón de requisitos de SoftwareDaniel Guaycha
 

Similar a Como uso el formato de pruebas (20)

Diseños de planes de pruebas de software1
Diseños de planes de pruebas de software1Diseños de planes de pruebas de software1
Diseños de planes de pruebas de software1
 
Unidad # 8 diseño de planes de prueba
Unidad # 8 diseño de planes de pruebaUnidad # 8 diseño de planes de prueba
Unidad # 8 diseño de planes de prueba
 
Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1
 
Ciclo de vida del desarrollo de software
Ciclo de vida del desarrollo de softwareCiclo de vida del desarrollo de software
Ciclo de vida del desarrollo de software
 
Ciclo de vida
Ciclo de vidaCiclo de vida
Ciclo de vida
 
Casos de pruebas
Casos de pruebasCasos de pruebas
Casos de pruebas
 
Tipos de modelos de procesos
Tipos de modelos de procesosTipos de modelos de procesos
Tipos de modelos de procesos
 
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...
 
Segunda web conferencia
Segunda web conferenciaSegunda web conferencia
Segunda web conferencia
 
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseñoConceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
 
Temario ceneval yo
Temario ceneval yoTemario ceneval yo
Temario ceneval yo
 
Analisis y Diseño de Sistemas
Analisis y Diseño de SistemasAnalisis y Diseño de Sistemas
Analisis y Diseño de Sistemas
 
Trabajo 2 exposicion
Trabajo 2 exposicionTrabajo 2 exposicion
Trabajo 2 exposicion
 
Prueba a los programas
Prueba a los programasPrueba a los programas
Prueba a los programas
 
Prueba a los programas
Prueba a los programasPrueba a los programas
Prueba a los programas
 
Prueba a los programas
Prueba a los programasPrueba a los programas
Prueba a los programas
 
Testing de software en instrumentos de pesar de funcionamiento no automatico ...
Testing de software en instrumentos de pesar de funcionamiento no automatico ...Testing de software en instrumentos de pesar de funcionamiento no automatico ...
Testing de software en instrumentos de pesar de funcionamiento no automatico ...
 
Auditoria de la seguridad informatica
Auditoria de la seguridad informaticaAuditoria de la seguridad informatica
Auditoria de la seguridad informatica
 
Estándar IEEE 830-1998 - Especificacón de requisitos de Software
Estándar IEEE 830-1998 - Especificacón de requisitos de SoftwareEstándar IEEE 830-1998 - Especificacón de requisitos de Software
Estándar IEEE 830-1998 - Especificacón de requisitos de Software
 
Manual de sistema
Manual de sistemaManual de sistema
Manual de sistema
 

Más de Yesika Rodriguez

Lineamientos generales del_conocimiento_cientifico
Lineamientos generales del_conocimiento_cientificoLineamientos generales del_conocimiento_cientifico
Lineamientos generales del_conocimiento_cientificoYesika Rodriguez
 
Sistema control-recepcion-custodia-y-salida-repuestos-almacen-edelca
Sistema control-recepcion-custodia-y-salida-repuestos-almacen-edelcaSistema control-recepcion-custodia-y-salida-repuestos-almacen-edelca
Sistema control-recepcion-custodia-y-salida-repuestos-almacen-edelcaYesika Rodriguez
 
Declaracion conocimiento condiciones_tdc_final
Declaracion conocimiento condiciones_tdc_finalDeclaracion conocimiento condiciones_tdc_final
Declaracion conocimiento condiciones_tdc_finalYesika Rodriguez
 

Más de Yesika Rodriguez (8)

Sistemas informacion
Sistemas informacionSistemas informacion
Sistemas informacion
 
Servicios yesika
Servicios   yesikaServicios   yesika
Servicios yesika
 
Lineamientos generales del_conocimiento_cientifico
Lineamientos generales del_conocimiento_cientificoLineamientos generales del_conocimiento_cientifico
Lineamientos generales del_conocimiento_cientifico
 
Uml 2004 para impresion
Uml 2004 para impresionUml 2004 para impresion
Uml 2004 para impresion
 
Seguridad defensa
Seguridad   defensaSeguridad   defensa
Seguridad defensa
 
Curso de project
Curso de projectCurso de project
Curso de project
 
Sistema control-recepcion-custodia-y-salida-repuestos-almacen-edelca
Sistema control-recepcion-custodia-y-salida-repuestos-almacen-edelcaSistema control-recepcion-custodia-y-salida-repuestos-almacen-edelca
Sistema control-recepcion-custodia-y-salida-repuestos-almacen-edelca
 
Declaracion conocimiento condiciones_tdc_final
Declaracion conocimiento condiciones_tdc_finalDeclaracion conocimiento condiciones_tdc_final
Declaracion conocimiento condiciones_tdc_final
 

Como uso el formato de pruebas

  • 1. DISEÑO DE CASO DE PRUEBAS 1. REQUERIMIENTOS DEL SISTEMA Para la realización de las pruebas de nuestro sistema, realizamos una lista con los requerimientos funcionales y no funcionales solicitados para el correcto desarrollo de nuestro proyecto. 1.1. Requerimientos Funcionales Un requerimiento funcional define una función del sistema de software o sus componentes. Una función es descrita como un conjunto de entradas, comportamientos y salidas. Los requerimientos funcionales pueden ser: CÁLCULOS, DETALLES TÉCNICOS, MANIPULACIÓN DE DATOS Y OTRAS FUNCIONALIDADES ESPECÍFICAS QUE SE SUPONE, UN SISTEMA DEBE CUMPLIR (REGISTRAR, MODIFICAR, ELIMINAR, GENERAR REPORTES, ENTRE OTRAS). Como se define en la ingeniería de requerimientos, los requerimientos funcionales establecen los comportamientos del sistema. 1.2. Requerimientos No funcionales Un requerimiento no funcional o atributo de calidad es, en la ingeniería de sistemas y la ingeniería de software, un requerimiento que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requerimientos funcionales. Por tanto, se refieren a todos los requerimientos que ni describen información a guardar, ni funciones a realizar.
  • 2. Algunos ejemplos de requisitos no funcionales típicos son los siguientes:  Rendimiento  Disponibilidad  Seguridad  Accesibilidad  Usabilidad  Estabilidad  Portabilidad  Costo  Operatividad  Interoperabilidad  Escalabilidad  Concurrencia  Mantenibilidad  Interfaz 2. SELECCIÓN DE MÓDULOS A PROBAR Una vez teniendo en cuenta el listado de los requerimientos procedemos a especificar cuales módulos vamos a evaluar lo hacemos de acuerdo a los requerimientos solicitados y le agregamos un identificador a cada unidad a probar. Por ejemplo, basándonos en los requerimientos:
  • 3. Unidad de Prueba Identificador Acceso MOD1 Contenido MOD2 Interfaz Navegación Seguridad Validación Base de Datos Configuración Comportamiento General NOTA: El ID puede ser cualquier termino que se decida para designar a la unidad a probar. 3. PRUEBA DE LAS FUNCIONES POR MÓDULOS Una vez identificados las unidades o módulos del sistema a probar hacemos una tabla en la que colocamos el identificador del módulo con las funciones que debería cumplir el sistema. Este es un ejemplo Modulo Registrar Eliminar Modificar Calcular Reportes Funcion6 Mod1 SI NA NA NA NA NA Mod2 SI SI SI SI SI SI Mod3 SI NO SI NA NA SI Mod4 SI SI SI NA NA SI Mod5 NA NA NO NO NA SI Mod6 NA NA NA NA NA SI PARA AFIRMACIÓN DE LA FUNCIÓN SE COLOCA (SI), (NO) O (N/A)= NO
  • 4. APLICA O EN SU DEFECTO UNA X O UN VIÑETE DE AFIRMACIÓN Recuerden que las funciones pueden ser Cálculos, detalles técnicos y funciones básicas que debe cumplir el sistema, como de la misma manera se pueden estar evaluando los requemamientos no funciones como: interfaz, acceso, seguridad, usabilidad, entre otras. 4. VEREDICTO DE LAS PRUEBAS Una vez realizada la prueba se hace la descripción para el veredicto y/o resultado generado por la prueba. ID Módulo Probado Resultado obtenido Veredicto observaciones Mod1 Acceso a la interfaz principal Esperado Funcional Mod2 Validación de formularios Esperado Funcional Mod3 Registro de los usuarios Esperado Funcional Mod4 Seguridad de acceso Esperado Funcional Mod5 Conexión con la base de datos Esperado Funcional Mod6 Genera el reporte solicitado Esperado Funcional - El resultado puede ser Esperado o sin resultado (el modulo esta en construcción), o fallido. - Veredicto puede ser Funcional o No Funcional. - Observaciones se coloca cualquier eventualidad presentada durante la prueba. 5. DOCUMENTACIÓN DE LA PRUEBA Por último se realiza una ficha la cual contendrá ciertos datos indispensables de la realización de prueba la cual es la que el PROBADOR certificara y hará constar de la ejecución de la misma.
  • 5. Documentación de la Prueba INSTITUCIÓN RESPONSABLE FECHA NOMBRE DE LA INSTITUCIÓN TITULO DEL PST II DOCUMENTOS DE REFERENCIA Identificador Título Mod1 Acceso a la interfaz principal Fecha de realización: 22-06-2013 Duración de la prueba: 1 hora Requerimientos de la prueba LAPTOP, PENDRIVE... Objetivo Encontrar el mayor numero de errores posibles, para la mejora del sistema. Resultado Esperado Resultado Obtenido Prueba Exitosa SI(X ) NO( ) Estado del Caso de No iniciado En curso Terminado
  • 6. prueba X Personal Requerido Cargo Nombre Firma Profesor/Ingeniero FULANITO Comentarios En este modulo, se encontró una falla de seguridad, no esta cifrada la contraseña. Realizado por: Firma Fecha NOMBRE TUTOR TECNICO 00/00/201X Aprobado por: Firma Fecha TUTOR(A) ACADEMIC@ 00/00/201X