quicksoft6.files.wordpress.com€¦ · Web viewLa necesidad de comprobar el correcto...
Transcript of quicksoft6.files.wordpress.com€¦ · Web viewLa necesidad de comprobar el correcto...
Documento de Pruebas
Revision: 3
Ultimo cambio: 14/11/2009
Autores: Andrés Mauricio tapias/Julián David Romero / Wilson Andrés Arguello/ David Toca Ávila/Ricardo Silva Gómez/Pedro Antonio Moncada
Cliente: Gilberto PedrazaRespondable del
documento: Julián David Romero
Enviar comentarios a: [email protected] del Documento Documento de Prueba
Localización del Documento: http: www.quicksoftcol.tk
Plan de Diseño de software QuickSoft
TABLA DE CONTENIDO
1. PROPÓSITO
2. ALCANCE
3. DETALLE DE LAS ACTIVIDADES DEL PROCEDIMIENTO
3.1 Análisis de los requerimientos del proyecto
3.2 Diseño de pruebas y sus casos de pruebas
3.3 Validación y ejecución mediante la aprobación del diseño de los casos de prueba
4. CUADRO RESUMEN DE LAS PRUEBAS
5. BASES DE DATOS DE PRUEBAS
6. EQUIPO DE PRUEBAS Y RESPONSABILIDADES
7-ANEXO
Plan de Diseño de software QuickSoft
INTRODUCCIÓN
La necesidad de comprobar el correcto funcionamiento del producto hace que sea imprescindible un plan de pruebas, con el cual se procederá a realizar una serie de ensayos que permitan obtener resultados correctos y erróneos con el fin de analizar el proceso de ejecución. Con este conjunto de pruebas seremos capaces de determinar si nuestro programa es erróneo sobre todo en casos extremos y particulares, tanto si estos fallos se producen por la una mala implementación del programa o bien por un uso especifico que realiza el usuario. El aspecto más importante para realizar la planificación de este conjunto de pruebas en abarcar con ellas todos los requisitos que debe cumplir el programa y que por tanto responda correctamente a las funcionalidades que se le solicitan inicialmente. Puesto que en el documento de especificación de requisitos software ya se ha realizado una evaluación de las funcionalidades que debe incluir el programa, tomaremos este documento de referencia para desarrollar el plan de pruebas de sistema.
OBJETIVO
La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además, esta etapa implica:
Verificar la interacción de componentes.
Verificar la integración adecuada de los componentes.
Verificar que todos los requisitos se han implementado correctamente.
Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente.
Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.
Plan de Diseño de software QuickSoft
DOCUMENTOS RELACIONADOS
Nombre Descripción
Informe de diseño El diseño que se
implementoInforme de requerimientos y casos de uso
Informe de A el informe que contiene los requisitos del programa
ESTRATEGIA DE PRUEBAS DE SOFTWARE
Una estrategia de prueba para el software debe constar de pruebas de bajo nivel, así como de pruebas de alto nivel.
Más concretamente, los objetivos de la estrategia de prueba son:
Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de unidad, integración y las pruebas de sistema. Las pruebas de unidad y de integración son necesarias dentro de la iteración, mientras que las pruebas de sistema son necesarias sólo al final de la iteración.
Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar, cómo realizar las pruebas y creando, si es posible, componentes de prueba ejecutables para automatizar las pruebas.
Realizar diferentes pruebas y manejar los resultados de cada prueba sistemáticamente. Los productos de desarrollo de software en los que se detectan defectos son probadas de nuevo y posiblemente devueltas a otra etapa, como diseño o implementación, de forma que los defectos puedan ser arreglados.
Para conseguir estos objetivos el flujo de trabajo de la etapa de Pruebas consta de las siguientes etapas:
Planificación de las pruebas.
Diseño de las pruebas.
Plan de Diseño de software QuickSoft
Implementación de las pruebas.
Ejecución de las pruebas.
Evaluación de las pruebas.
Los productos de desarrollo del software fundamentales que se desarrollan en la etapa de Pruebas son:
Plan de Pruebas.
Casos de Prueba.
Informe de evaluación de Pruebas.
Modelo de Pruebas, que incluye Clases de Prueba, Entorno de Configuración de Pruebas, Componentes de Prueba y los Datos de prueba.
1-PROPÓSITO
Garantizar el cumplimiento de los requerimientos planteados en el marco del proyecto.
Asegurar que se tengan en cuenta todos los casos de pruebas posibles para validar la solución informática a un requerimiento o solicitud de cambio, garantizando que en el momento de entregar el producto a pruebas de usuario éste cuente con un nivel de calidad apropiado.
Definir todas las actividades relacionadas con la ejecución de las pruebas unitarias, las responsabilidades individuales para cada tarea, los recursos y los prerrequisitos que deben ser considerados en el esfuerzo de pruebas.
2-ALCANCE
Plan de Diseño de software QuickSoft
Aplica para el diseño y la elaboración de los planes de pruebas unitarias que son ejecutadas por los desarrolladores antes de realizar la entrega de una versión estable del producto para que le sean aplicadas las pruebas de usuario. Estas pruebas son realizadas a nivel de capa de negocio en los productos y servicios comprendidos dentro del sistema de calidad. Su diseño y ejecución se apoyan en la herramienta JUnit.
3-DETALLE DE LAS ACTIVIDADES DEL PROCEDIMIENTO
3.1 Análisis de los requerimientos del proyecto
Nos basamos en todos los documentos que nos pueden ayudarle a definir las pruebas unitarias que se realizarán en la capa de presentación de cada uno de los componentes que se desean probar. De esta manera se garantiza la completitud de las pruebas definidas y el desarrollo de un proceso de calidad que realmente apoye la detección temprana de errores dentro del grupo de desarrollo y promueva el desarrollo de software de alta calidad.
Los documentos en los cuáles nos apoyamos son:
- Levantamiento de requerimientos - Análisis del requerimientos - Diseño (Diseño de plataforma Java, Diseño PLSQL- ORACLE)- Diseño Detallado (Diagramas de Secuencia CU, Modelo de Datos)
Plan de Diseño de software QuickSoft
3.2 Diseño de pruebas y sus casos de pruebas
Para realizar el diseño y ejecución de pruebas unitarias sobre los componentes del negocio, se utilizará la herramienta JUnit, con esta herramienta es posible diseñar y ejecutar diferentes Casos de Prueba de una manera sencilla y rápida. Estos casos de prueba pueden ser ejecutados repetidamente cuando sea necesario, optimizando el tiempo requerido para efectuar pruebas de regresión.
Las pruebas de regresión es la actividad que ayuda a asegurar que los cambios (debido a pruebas u otros motivos) no introduzcan un comportamiento no deseado o errores adicionales, por ello prueban nuevamente componentes evaluados anteriormente, asegurando que los cambios introducidos en el software no han afectado su funcionamiento.Utilizando JUnit se deben realizar las siguientes pruebas sobre cada uno de los componentes del negocio, teniendo en cuenta en cada uno de ellos condiciones de ejecuciones válidas e inválidas de acuerdo a las reglas del negocio establecidas:
- Funcionamiento adecuado del ciclo de vida- Métodos del negocio- Manejo adecuado de las reglas del negocio
Se tiene la concepción de realizar a futuro un documento de Configuración del Ambiente de Pruebas en donde describa detalladamente las configuraciones que deben efectuarse previamente para poder diseñar y ejecutar adecuadamente las pruebas unitarias. Si se van a realizar pruebas unitarias que involucren la interacción con otros sistemas presentes en el proyecto, es fundamental describir en el documento de Configuración del Ambiente de Pruebas, cómo se comunican los sistemas involucrados, la información de
Plan de Diseño de software QuickSoft
entrada y salida que se maneja, y las configuraciones previas que deben realizarse en cada uno de los sistemas para la ejecución de las pruebas unitarias.
3.3 Validación y ejecución mediante la aprobación del diseño de los casos de prueba
Es importante validar y efectuar los casos de prueba definidos, verificando que se han contemplado todas las pruebas necesarias, que no existen pruebas duplicadas o implícitas en otras y que el tiempo estimado no sobrepasa la fecha límite de ejecución.Como lo expresa nuestro cliente es necesario que la inspección de los casos de prueba la efectúe una persona diferente a quien diseño los casos de prueba inicialmente.
7. CUADRO RESUMEN DE LAS PRUEBAS
Módulos del Sistema a ser probados:
Módulos:
- Presentación
- Persistencia
- Controlador
Objetivos de las Pruebas En estos Módulos se realizarán pruebas para validar:
La visualización de los datos, ingresados o modificados.
La operación de los servicios en relación a la arquitectura para dar respuesta a los productos del sistema.
La respuesta y realización de las transacciones de cada módulo.
Que las actividades y requerimientos generados en el sistema se reflejen de acuerdo a la necesidad del usuario.
La secuencia lógica de las funcionalidades y transacciones.Detalle del orden de ejecución de los módulos
Los módulos se deben ejecutar en forma independiente, pero consecutivos en el orden siguiente:
- Persistencia
- Presentación
- Controlador
Responsabilidad de la Prueba Las pruebas son responsabilidad del Testing Operacional del equipo de proyecto en este caso el Líder de Desarrollo encabeza este trabajo, quien en conjunto con los demás Lideres de Equipo y el usuario final deben seleccionar las pruebas que
Plan de Diseño de software QuickSoft
aseguren la efectividad del sistema.
Plan de Diseño de software QuickSoft
CRITERIOS DE INICIO
Aceptación del plan de pruebas. Revisión y aceptación del documento que contiene los casos de pruebas para la certificación del proyecto.
Aceptación de paquetes. Revisión y aceptación de los paquetes de desarrollo, y que este cumpla con las condiciones de aceptación dadas por el cliente.
Aceptación de ambiente. Revisión y aceptación del ambiente de certificación, y que este cumpla con las condiciones planteadas en la arquitectura.
8. BASES DE DATOS DE PRUEBAS
Base de Datos : ORACLE
Servidor BD : Oracle
Datos : Tablas
9. CRITERIOS DE APROBACION / RECHAZO
Errores Graves: información crítica presentada erróneamente, información mal registrada en la base de datos, caídas de programas, incumplimiento de objetivos en funciones principales, etc.
Errores Medios (comunes): errores en documentos impresos que se entregan a personas ajenas a la organización, errores en presentación de datos, incumplimiento de objetivos en funciones secundarias, caídas de programas auxiliares, etc.
Errores Leves: errores en presentación de datos secundarios, no adecuación a estándares, comportamientos correctos pero diferentes en situaciones similares, dificultades de operación, etc.
Plan de Diseño de software QuickSoft
Las pruebas se llevarán a cabo de la siguiente forma:
1. Secuencias de pasos para la Configuración
Configuración de los Equipos Cliente y del Servidor de Aplicación Web (Servlet) y de Base de Datos.
2. Secuencias de pasos para la generación de datos para los módulos.
Ejecución del proceso (manual) de generación de datos, donde las tablas y campos a utilizar serán llenados manualmente.
Plan de Diseño de software QuickSoft
PRUEBA DE INTEGRACIÓN
INTRODUCCION
La necesidad de realizar las pruebas de integración viene dada por el hecho de que los módulos que forman un programa suelen fallar cuando trabajan de forma conjunta, aunque previamente se haya demostrado que funcionan correctamente de manera individual. Por ello realizamos este tipo de pruebas, asegurándonos que los módulos que están relacionados ejecuten correctamente. Con el uso de estas pruebas conseguimos ir formando el programa global a medida que se comprueba como los distintos componentes interaccionan y se comunican libres de errores.
PROPÓSITO
Garantizar el cumplimiento de los requerimientos planteados en el marco del proyecto en cuanto a la integración de aplicaciones.
Asegurar que se tengan en cuenta todos los casos de pruebas posibles para validar la solución informática a un requerimiento o solicitud de cambio, garantizando que en el momento de entregar el producto a pruebas de usuario éste cuente con un nivel de calidad apropiado.
Definir todas las actividades relacionadas con la ejecución de las pruebas de integración, las responsabilidades individuales para cada tarea, los recursos y los prerrequisitos que deben ser considerados en el esfuerzo de pruebas.
Garantizar el funcionamiento adecuado de las reglas de negocio que involucran la integración de aplicaciones.
Garantizar el buen funcionamiento de la infraestructura de integración utilizada.
ALCANCE
Aplica para el diseño y la elaboración de los planes de pruebas de integración que son ejecutadas por los desarrolladores antes de realizar la entrega de una versión estable del producto para que le sean aplicadas las pruebas de usuario. Estas pruebas son realizadas a nivel de capa de negocio en los productos y servicios comprendidos dentro del sistema de calidad. Su diseño y ejecución se apoyan en la herramienta Junit.
En este caso particular las pruebas de integración están enfocadas en verificar el correcto funcionamiento de las reglas de negocio de integración sobre la infraestructura
Plan de Diseño de software QuickSoft
DIAGRAMA DE ACTIVIDADES DEL PROCEDIMIENTO
Plan de Diseño de software QuickSoft
DIAGRAMA DE INTEGRACION DEL SISTEMA
Para realizar la integración del sistema se ha tomado la decisión de poner en práctica la integración ascendente, es decir, comenzar por los módulos más bajos hasta el programa principal. Siguiendo la especificación del diseño de alto nivel, podemos ver que solo hay dos niveles, la clase “Ejecutar operación” estará en el nivel más alto y el resto de las clases en el más bajo, puesto que es la clase Ejecutar operación la que llama al resto. Par desarrollar el diagrama supondremos que las pruebas unitarias de cada una de las clases han sido superadas correctamente y por tanto no se van a representar de forma grafica.
La prueba de integración es una técnica sistemática para construir la estructura del programa mientras al mismo tiempo, se lleva a cabo pruebas para detectar errores asociados con la interacción. El objetivo es tomar los módulos probados en unidad y estructurar un programa que esté deacuerdo con el que dicta el diseño.
Plan de Diseño de software QuickSoft
TIPOS DE INTEGRACIÓN
Integración descendente, es una estrategia de integración incremental a la construcción de la estructura de programas, en el cual se integran los módulos moviéndose en dirección hacia abajo por la jerarquía comenzando por el control principal (Programa principal). Los módulos subordinados de control principal se incorporan en la estructura en la estructura, bien, de forma primero-en-profundidad, bien primero-en-anchura.
Integración ascendente, es donde la construcción del diseño empieza desde los módulos más bajos hacia arriba (módulo principal), el procesamiento requerido de los módulos subordinados siempre esta disponible y elimina la necesidad de resguardo.La sección de una estrategia de integración depende de las características depende de las características del software y, a veces, del plan del proyecto, en algunos de los casos se puede
Plan de Diseño de software QuickSoft
Pruebas de Integración
Estas pruebas se desarrollan versus a los Casos de Uso
1. Ingresar integrante:
Caso exitoso: se ingresa el integrante
Caso de prueba: que el que ingresa no se sepa los datos del integrante.
Error Falla en la base de datos
Identificador: PR-01
Proyecto: Defect Zero
Referencias: CU –1.
Nombre: Ingresar Integrante
Responsable: David Toca
Estado: Inspeccionada
Dependencias: Ninguna
Identificador: CPR-01
Identificador de Prueba:
PR-01
Nombre: Ingresar Integrante
Usuario y Fecha de Creación:
David Mora – 9 de Noviembre de 2009
Usuario y Fecha de Última Modificación:
David Toca – 9 de noviembre de 2009
Descripción: Este caso de prueba tiene el objetivo la verificación del ingreso del integrante
Dependencias: Ninguna
Prioridad: 1
Plan de Diseño de software QuickSoft
2. Ingresar un defecto (integrante):
Caso exitoso: se ingresa el defecto
Caso de prueba: el que ingresa tiene todos los datos del defecto.
Error Falla en la base de datos
Identificador: PR-02
Proyecto: Defect Zero
Referencias: CU –2.
Nombre: Ingresarr un defecto (Integrante)
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-01
Identificador: CPR-02
Identificador de Prueba:
PR-02
Nombre: Ingresar un defecto (Integrante) y producir una respuesta
Usuario y Fecha de Creación:
Ricardo Silva – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Ricardo Silva – 12 de Nov 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema lo ingrese correctamente
Dependencias: PR-01
Prioridad: 1
Plan de Diseño de software QuickSoft
3. ingresar un defecto
(administrador):
Caso exitoso:
Caso de prueba: el que ingresa tiene todos los datos del defecto.
Error Falla en la base de datos
Identificador: PR-02
Proyecto: Defect Zero
Referencias: CU –3.
Nombre: Ingresar un defecto (Administrador)
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-02
Identificador: CPR-03
Identificador de Prueba:
PR-03
Nombre: Ingresar un defecto (Administrador) y producir una respuesta
Usuario y Fecha de Creación:
Ricardo Silva – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Ricardo Silva – 12 de Nov 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema lo ingrese correctamente por parte del administrador
Dependencias: PR-02
Prioridad: 2
Plan de Diseño de software QuickSoft
4. Crear un proyecto (administrador):
Caso exitoso: se creo el proyecto
Caso de prueba: el administrador ingresa datos validos del proyecto
Error Falla en la base de datos
Identificador: PR-04
Proyecto: Defect Zero
Referencias: CU –4
Nombre: Crear un proyecto (Administrador)
Responsable: Julián Romero
Estado: Inspeccionada
Dependencias: PR-03
Identificador: CPR-04
Identificador de Prueba:
PR-04
Nombre: Crear un proyecto (Administrador)
Usuario y Fecha de Creación:
Julián Romero – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Julián Romero – 12 de Nov 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema ingrese un proyecto correctamente administrador
Dependencias: PR-03
Prioridad: 4
Plan de Diseño de software QuickSoft
5. Iniciar sesión (integrante):
1. Caso exitoso: el integrante ingresa al Sistema
2. Caso de Prueba: usuario y contraseña de un integrante existente
Error: Falla de conexión Servidor
Identificador: PR-05
Proyecto: Defect Zero
Referencias: CU –5
Nombre: Iniciar Sesión (Integrante)
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-04
Identificador: CPR-05
Identificador de Prueba:
PR-05
Nombre: Iniciar Sesión (Integrante)
Usuario y Fecha de Creación:
Julián Romero – 11 de Noviembre
Usuario y Fecha de Última Modificación:
Julián Romero – 11 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema inicie sesión correctamente
Dependencias: PR-04
Prioridad: 5
6. iniciar sesión (administrador):
Plan de Diseño de software QuickSoft
1. Caso exitoso: el administrador ingresa al Sistema
2. Caso de Prueba: usuario y contraseña de un administrador existente
Error: Falla de conexión Servidor
Identificador: PR-06
Proyecto: Defect Zero
Referencias: CU –6
Nombre: Iniciar Sesión (Administrador)
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-05
Identificador: CPR-06
Identificador de Prueba:
PR-06
Nombre: Iniciar Sesión (Administrador)
Usuario y Fecha de Creación:
Julián Romero – 12de Noviembre
Usuario y Fecha de Última Modificación:
Julián Romero – 12 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema inicie sesión correctamente administrador
Dependencias: PR-05
Prioridad: 6
Plan de Diseño de software QuickSoft
7. modificar un integrante:
Caso exitoso: los datos del integrante han sido modificados
Caso de prueba: los datos nuevos son compatibles en los campos y son validos
Error Falla en la base de datos
Identificador: PR-07
Proyecto: Defect Zero
Referencias: CU –7
Nombre: modificar un integrante
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-04
Identificador: CPR-07
Identificador de Prueba:
PR-07
Nombre: modificar un integrante
Usuario y Fecha de Creación:
David Toca – 13de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 13 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema modifique un integrante correctamente
Dependencias: PR-06
Prioridad: 7
8. modificar un proyecto:
Caso exitoso: los datos del proyecto han sido modificados
Plan de Diseño de software QuickSoft
Caso de prueba: los datos nuevos son compatibles en los campos y son validos
Error Falla en la base de datos
Identificador: PR-08
Proyecto: Defect Zero
Referencias: CU –8
Nombre: modificar un proyecto
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-05
Identificador: CPR-08
Identificador de Prueba:
PR-08
Nombre: modificar un proyecto
Usuario y Fecha de Creación:
David Toca – 13de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 13 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema modifique un proyecto correctamente
Dependencias: PR-06
Prioridad: 7
9. eliminar un proyecto:
Caso exitoso: el proyecto es eliminado
Plan de Diseño de software QuickSoft
Caso de prueba: el proyecto no tiene ningún defecto
Identificador: PR-09
Proyecto: Defect Zero
Referencias: CU –9
Nombre: Eliminar un proyecto
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-08
Identificador: CPR-09
Identificador de Prueba:
PR-09
Nombre: Eliminar un proyecto
Usuario y Fecha de Creación:
David Toca – 13de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 13 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema elimine un proyecto correctamente
Dependencias: PR-08
Prioridad: 8
10. Eliminar un integrante:
Caso exitoso: el integrante es eliminado
Caso de prueba: el integrante no tiene ningún defecto
Plan de Diseño de software QuickSoft
Identificador: PR-10
Proyecto: Defect Zero
Referencias: CU –10
Nombre: Eliminar un integrante
Responsable: Julián Romero
Estado: Inspeccionada
Dependencias: PR-08
Identificador: CPR-09
Identificador de Prueba:
PR-09
Nombre: Eliminar un integrante
Usuario y Fecha de Creación:
Julian Romero – 14de Noviembre
Usuario y Fecha de Última Modificación:
Julian Romero – 14 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema elimine un integrante correctamente
Dependencias: PR-09
Prioridad: 9
11. cerrar sesión:
Caso exitoso: la sesión del usuario se cierra con éxito
Caso de prueba: el usuario presiona el botón cerrar sesión
Plan de Diseño de software QuickSoft
Identificador: PR-11
Proyecto: Defect Zero
Referencias: CU –11
Nombre: Cerrar sesión
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-10
Identificador: CPR-11
Identificador de Prueba:
PR-11
Nombre: Cerrar sesion
Usuario y Fecha de Creación:
David Toca – 13de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 13 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de cerrar sesión correctamente
Dependencias: PR-10
Prioridad: 9
12. ver defectos (administrador)
Caso exitoso: el administrador observa correctamente los defectos del proyecto
Caso de prueba: el administrador inicia sesión y accede a la funcionalidad ver defectos
Identificador: PR-12
Plan de Diseño de software QuickSoft
Proyecto: Defect Zero
Referencias: CU –12
Nombre: Ver defectos
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-11
Identificador: CPR-12
Identificador de Prueba:
PR-12
Nombre: Ver defectos
Usuario y Fecha de Creación:
David Toca – 13de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 13 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de ver los defectos del líder
Dependencias: PR-11
Prioridad: 10
13. ver defectos (integrante)
Caso exitoso: el integrante observa correctamente los defectos que tiene asignados
Caso de prueba: el integrante inicia sesión y accede a la funcionalidad ver defectos
Identificador: PR-13
Plan de Diseño de software QuickSoft
Proyecto: Defect Zero
Referencias: CU –13
Nombre: Ver defectos (integrante)
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-12
Identificador: CPR-13
Identificador de Prueba:
PR-13
Nombre: Ver defectos (integrante)
Usuario y Fecha de Creación:
David Toca – 13de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 13 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de ver los defectos del integrantes
Dependencias: PR-12
Prioridad: 11
14. asignar defecto
Caso exitoso: el administrador asigno correctamente un defecto a un integrante
Caso de prueba: el administrador inicia sesión y accede a la funcionalidad asignar defectos, a continuación asigna un defecto a un integrante
Identificador: PR-14
Proyecto: Defect Zero
Plan de Diseño de software QuickSoft
Referencias: CU –14
Nombre: Asignar defecto
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-13
Identificador: CPR-14
Identificador de Prueba:
PR-14
Nombre: Asignar defectos
Usuario y Fecha de Creación:
David Toca – 13de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 13 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de asignar el defecto encontrado
Dependencias: PR-13
Prioridad: 12
15. filtrar defectos por fecha ascendente
Caso exitoso: la lista de defectos fue mostrada según el orden ascendente
Caso de prueba: el integrante selección el filtro ascendente
Identificador: PR-15
Plan de Diseño de software QuickSoft
Proyecto: Defect Zero
Referencias: CU –15
Nombre: filtrar defectos por fecha ascendente
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-14
Identificador: CPR-15
Identificador de Prueba:
PR-15
Nombre: filtrar defectos por fecha ascendente
Usuario y Fecha de Creación:
David Toca – 13de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 13 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de filtrar los defectos por fecha de forma ascendente
Dependencias: PR-14
Prioridad: 13
16. filtrar defectos por fecha descendente
Caso exitoso: la lista de defectos fue mostrada según el orden descendente
Caso de prueba: el integrante selección el filtro descendente
Identificador: PR-16
Plan de Diseño de software QuickSoft
Proyecto: Defect Zero
Referencias: CU –16
Nombre: filtrar defectos por fecha descendente
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-14
Identificador: CPR-16
Identificador de Prueba:
PR-16
Nombre: filtrar defectos por fecha descendente
Usuario y Fecha de Creación:
David Toca – 13de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 13 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de filtrar los defectos por fecha de forma descendente
Dependencias: PR-15
Prioridad: 13
17. filtrar defectos sin asignar
Caso exitoso: la lista de defectos fue mostrada según el orden sin asignar
Caso de prueba: el integrante selección el filtro sin asignar
Identificador: PR-17
Proyecto: Defect Zero
Plan de Diseño de software QuickSoft
Referencias: CU –17
Nombre: filtrar defectos sin asignar
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-16
Identificador: CPR-17
Identificador de Prueba:
PR-17
Nombre: filtrar defectos sin asignar
Usuario y Fecha de Creación:
David Toca – 14 de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 14 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de filtrar los defectos no asignados
Dependencias: PR-16
Prioridad: 15
18. filtrar defectos asignados
Caso exitoso: la lista de defectos fue mostrada según el orden asignados
Caso de prueba: el integrante selección el filtro asignados
Identificador: PR-18
Proyecto: Defect Zero
Referencias: CU –18
Plan de Diseño de software QuickSoft
Nombre: filtrar defectos asignados
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-17
Identificador: CPR-18
Identificador de Prueba:
PR-18
Nombre: filtrar defectos asignados
Usuario y Fecha de Creación:
David Toca – 14 de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 14 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de filtrar los defectos asignados
Dependencias: PR-17
Prioridad: 16
19. filtrar defectos no resueltos
Caso exitoso: la lista de defectos fue mostrada según el orden no resuelto
Caso de prueba: el integrante selección el filtro no resuelto
Identificador: PR-19
Proyecto: Defect Zero
Referencias: CU –18
Plan de Diseño de software QuickSoft
Nombre: filtrar defectos no resueltos
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-18
Identificador: CPR-19
Identificador de Prueba:
PR-19
Nombre: filtrar defectos no resueltos
Usuario y Fecha de Creación:
David Toca – 14 de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 14 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de filtrar los defectos no resueltos
Dependencias: PR-18
Prioridad: 17
20. filtrar defectos resueltos
Caso exitoso: la lista de defectos fue mostrada según el orden resuelto
Caso de prueba: el integrante selección el filtro resuelto
Identificador: PR-20
Proyecto: Defect Zero
Plan de Diseño de software QuickSoft
Referencias: CU –20
Nombre: filtrar defectos resueltos
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-18
Identificador: CPR-20
Identificador de Prueba:
PR-20
Nombre: filtrar defectos resueltos
Usuario y Fecha de Creación:
David Toca – 14 de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 14 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de filtrar los defectos no resueltos
Dependencias: PR-18
Prioridad: 17
Plan de Diseño de software QuickSoft
21. Resolver defecto
Caso exitoso: el defecto fue resuelto
Caso de prueba: el integrante selección el defecto a resolver
Identificador: PR-21
Proyecto: Defect Zero
Referencias: CU –21
Nombre: Resolver defecto
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-18
Identificador: CPR-21
Identificador de Prueba:
PR-21
Nombre: Resolver defecto
Usuario y Fecha de Creación:
David Toca – 14 de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 14 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de resolver un defecto
Dependencias: PR-18
Prioridad: 10
Plan de Diseño de software QuickSoft
22. Métrica defectos solucionados
Caso exitoso: la métrica fue visualizada correctamente
Caso de prueba: el administrador trata de mirar la métrica de defectos solucionados
Identificador: PR-22
Proyecto: Defect Zero
Referencias: CU –22
Nombre: Métrica defectos solucionados
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-18
Identificador: CPR-22
Identificador de Prueba:
PR-22
Nombre: Métrica defectos solucionados
Usuario y Fecha de Creación:
David Toca – 14 de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 14 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de mirar las métricas de defecto solucionados
Dependencias: PR-18
Prioridad: 10
Plan de Diseño de software QuickSoft
23. Métrica fase inyección de defectos
Caso exitoso: la métrica fue visualizada correctamente
Caso de prueba: el administrador trata de mirar la métrica de fase inyección de defectos
Identificador: PR-23
Proyecto: Defect Zero
Referencias: CU –23
Nombre: métrica de fase inyección de defectos
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-18
Identificador: CPR-23
Identificador de Prueba:
PR-23
Nombre: métrica de fase inyección de defectos
Usuario y Fecha de Creación:
David Toca – 14 de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 14 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de mirar las métrica de fase inyección de defectos
Dependencias: PR-18
Prioridad: 10
Plan de Diseño de software QuickSoft
24. Métrica tiempo de detección de defectos
Caso exitoso: la métrica fue visualizada correctamente
Caso de prueba: el administrador trata de mirar la métrica tiempo de detección de defectos
Identificador: PR-24
Proyecto: Defect Zero
Referencias: CU –24
Nombre: métrica tiempo de detección de defectos
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-18
Identificador: CPR-24
Identificador de Prueba:
PR-24
Nombre: métrica tiempo de detección de defectos
Usuario y Fecha de Creación:
David Toca – 14 de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 14 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de mirar las métrica de tiempo de detección de defectos
Dependencias: PR-18
Prioridad: 10
Plan de Diseño de software QuickSoft
Casos de Prueba Fracaso
25. Ingresar Integrante:
Caso exitoso: Mensaje de Error
Caso de Prueba: Datos Inválidos al ingresar un Integrante
Error Falla en la base de datos
Identificador: PR Fracaso -01
Proyecto: Defect Zero
Referencias: CU –1.
Nombre: Ingresar Integrante
Responsable: David Toca
Estado: Inspeccionada
Dependencias: Ninguna
Identificador: CPR Fracaso -01
Identificador de Prueba:
PR-01
Nombre: Ingresar Integrante
Usuario y Fecha de Creación:
David Toca – 9 de Noviembre de 2009
Usuario y Fecha de Última Modificación:
David Toca – 9 de noviembre de 2009
Descripción: Este caso de prueba tiene el objetivo de que el sistema no ingrese in Integrante si los Datos son Inválidos
Dependencias: Ninguna
Prioridad: 1
Plan de Diseño de software QuickSoft
26. Ingresar un Defecto (integrante):
Caso Éxito: Mensaje de Error
Caso de prueba: El que ingresa un defecto tiene Datos Inválidos
Error Falla en la base de datos
Identificador: PR Fracaso-02
Proyecto: Defect Zero
Referencias: CU –2.
Nombre: Ingresar un defecto (Integrante)
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-01
Identificador: CPR Fracaso-02
Identificador de Prueba:
PR-02
Nombre: Ingresar un defecto (Integrante) y producir una respuesta
Usuario y Fecha de Creación:
Ricardo Silva – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Ricardo Silva – 12 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no ingrese el defecto si los Datos son Inválidos
Dependencias: PR-01
Prioridad: 2
Plan de Diseño de software QuickSoft
27. Ingresar un Defecto (administrador):
Caso exitoso: Mensaje de Error
Caso de prueba: Ingreso de un defecto (Administrador) tiene Datos Inválidos
Error Falla en la base de datos
Identificador: PR Fracaso -03
Proyecto: Defect Zero
Referencias: CU –3.
Nombre: Ingresar un defecto (Administrador)
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-02
Identificador: CPR Fracaso -03
Identificador de Prueba:
PR-03
Nombre: Ingresar un defecto (Administrador) y producir una respuesta.
Usuario y Fecha de Creación:
Ricardo Silva – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Ricardo Silva – 12 de Nov 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no ingrese correctamente un defecto por parte del administrador si los datos son inválidos
Dependencias: Ninguna
Prioridad: 2
Plan de Diseño de software QuickSoft
28.Crear un proyecto (Administrador):
Caso exitoso: Mensaje de Error No se Puede Crear un Proyecto
Caso de prueba: El Administrador ingresa datos invalidos del proyecto
Error Falla en la base de datos
Identificador: PR Fracaso -04
Proyecto: Defect Zero
Referencias: CU –4
Nombre: Crear un proyecto (Administrador)
Responsable: Julián Romero
Estado: Inspeccionada
Dependencias: PR-03
Identificador: CPR Fracaso -04
Identificador de Prueba:
PR-04
Nombre: Crear un proyecto (Administrador)
Usuario y Fecha de Creación:
Julián Romero – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Julián Romero – 12 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no permita ingresar un proyecto correctamente administrador si los datos son inválidos.
Dependencias: PR-03
Prioridad: 4
Plan de Diseño de software QuickSoft
29. Iniciar sesión (Integrante):
1. Caso exitoso: Mensaje de Error Iniciar Sesión
2. Caso de Prueba: Usuario y Contraseña de un integrante existente
Error: Falla de conexión Servidor
Identificador: PR Fracaso -05
Proyecto: Defect Zero
Referencias: CU –5
Nombre: Iniciar Sesión (Integrante)
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-04
Identificador: CPR Fracaso -05
Identificador de Prueba:
PR-05
Nombre: Iniciar Sesión (Integrante)
Usuario y Fecha de Creación:
Julián Romero – 11 de Noviembre
Usuario y Fecha de Última Modificación:
Julián Romero – 11 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no inicie sesión correctamente si los datos de usuario y contraseña don inválidos.
Dependencias: PR-04
Prioridad: 5
Plan de Diseño de software QuickSoft
30. Iniciar Sesión (Administrador):
1. Caso exitoso: Mensaje de Error Administrador no puede Ingresa al Sistema
2. Caso de Prueba: Usuario y Contraseña de un administrador existente
Error: Falla de conexión Servidor
Identificador: PR Fracaso -06
Proyecto: Defect Zero
Referencias: CU –6
Nombre: Iniciar Sesión (Administrador)
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-05
Identificador: CPR Fracaso -06
Identificador de Prueba:
PR-06
Nombre: Iniciar Sesión (Administrador)
Usuario y Fecha de Creación:
Julián Romero – 12de Noviembre
Usuario y Fecha de Última Modificación:
Julián Romero – 12 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no inicie sesión correctamente administrador si los datos de usuario y contraseña don inválidos.
Dependencias: PR-05
Prioridad: 6
Plan de Diseño de software QuickSoft
31.Modificar un Integrante:
Caso exitoso: Mensaje de Error los datos del integrante no han sido modificados
Caso de prueba: los datos nuevos son compatibles en los campos y son validos
Error Falla en la base de datos
Identificador: PR Fracaso -07
Proyecto: Defect Zero
Referencias: CU –7
Nombre: Modificar un Integrante
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-04
Identificador: CPR Fracaso -07
Identificador de Prueba:
PR-07
Nombre: Modificar un Integrante
Usuario y Fecha de Creación:
David Toca – 13de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 13 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no modifique un integrante si los campos son inválisdos.
Dependencias: PR-06
Prioridad: 7
Plan de Diseño de software QuickSoft
32. Modificar un Proyecto:
Caso exitoso: Mensaje de Error los datos del proyecto no han sido modificados
Caso de prueba: los datos nuevos son compatibles en los campos y son validos
Error Falla en la base de datos
Identificador: PR Fracaso -08
Proyecto: Defect Zero
Referencias: CU –8
Nombre: Modificar un Proyecto
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-05
Identificador: CPR Fracaso -08
Identificador de Prueba:
PR-08
Nombre: Modificar un Proyecto
Usuario y Fecha de Creación:
David Toca – 13de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 13 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no modifique un proyecto si los datos son inválidos.
Dependencias: PR-06
Prioridad: 7
Plan de Diseño de software QuickSoft
33.Eliminar un Proyecto:
Caso exitoso: Mensaje de Error el proyecto no puede ser eliminado
Caso de prueba: El proyecto no tiene ningún defecto
Identificador: PR Fracaso -09
Proyecto: Defect Zero
Referencias: CU –9
Nombre: Eliminar un proyecto
Responsable: David Toca
Estado: Inspeccionada
Dependencias: PR-08
Identificador: CPR Fracaso -09
Identificador de Prueba:
PR-09
Nombre: Eliminar un proyecto
Usuario y Fecha de Creación:
David Toca – 13de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 13 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no permita eliminar un proyecto si a el no se le han asignado defectos.
Dependencias: PR-08
Prioridad: 8
Plan de Diseño de software QuickSoft
34. Eliminar un Integrante:
Caso exitoso: Mensaje de Error el integrante no puede ser eliminado
Caso de prueba: el integrante no tiene ningún defecto
Identificador: PR Fracaso -10
Proyecto: Defect Zero
Referencias: CU –10
Nombre: Eliminar un integrante
Responsable: Julián Romero
Estado: Inspeccionada
Dependencias: PR-08
Identificador: CPR Fracaso -09
Identificador de Prueba:
PR-09
Nombre: Eliminar un integrante
Usuario y Fecha de Creación:
Julián Romero – 14de Noviembre
Usuario y Fecha de Última Modificación:
Julián Romero – 14 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no elimine un integrante a el no se le han asignado defectos.
Dependencias: PR-09
Prioridad: 9
Plan de Diseño de software QuickSoft
35. Cerrar Sesión:
Identificador: PR Fracaso-35
Proyecto: Defect Zero
Referencias: CU –35
Nombre: cerrar sesión
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-01
Identificador: CPR Fracaso-35
Identificador de Prueba:
PR-35
Nombre: cerrar sesión
Usuario y Fecha de Creación:
Ricardo Silva – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Ricardo Silva – 12 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no cierre sesión si no se cumplen ciertas condiciones
Dependencias: PR-01
Prioridad: 1
Plan de Diseño de software QuickSoft
36. Ver Defectos
(Administrador)
Identificador: PR Fracaso-36
Proyecto: Defect Zero
Referencias: CU –36
Nombre: ver defectos (administrador)
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-01
Identificador: CPR Fracaso-36
Identificador de Prueba:
PR-36
Nombre: ver defectos y producir una respuesta
Usuario y Fecha de Creación:
Ricardo Silva – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Ricardo Silva – 12 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no vea defectos (administrador) si los Datos son Inválidos
Dependencias: PR-01
Prioridad: 1
Plan de Diseño de software QuickSoft
Identificador: PR Fracaso-37
Proyecto: Defect Zero
Referencias: CU –37
Nombre: ver defectos (integrante)
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-01
Identificador: CPR Fracaso-37
Identificador de Prueba:
PR-37
Nombre: ver defectos y producir una respuesta
Usuario y Fecha de Creación:
Ricardo Silva – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Ricardo Silva – 12 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no vea defectos (integrante) si los Datos son Inválidos
Dependencias: PR-01
Prioridad: 1
Plan de Diseño de software QuickSoft
38. Asignar Defecto
Identificador: PR Fracaso-38
Proyecto: Defect Zero
Referencias: CU –238
Nombre: asignar defecto
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-01
Identificador: CPR Fracaso-38
Identificador de Prueba:
PR-38
Nombre: asignar defecto
Usuario y Fecha de Creación:
Ricardo Silva – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Ricardo Silva – 12 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no asigne un defecto si los Datos son Inválidos
Dependencias: PR-01
Prioridad: 1
Plan de Diseño de software QuickSoft
39. Filtrar defectos por fecha ascendente
Identificador: PR Fracaso-39
Proyecto: Defect Zero
Referencias: CU –39
Nombre: filtrar defectos por fecha ascendente
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-01
Identificador: CPR Fracaso-39
Identificador de Prueba:
PR-39
Nombre: filtrar defectos por fecha ascendente y producir una respuesta
Usuario y Fecha de Creación:
Ricardo Silva – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Ricardo Silva – 12 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no filtrar defectos por fecha ascendente si no existen Datos
Dependencias: PR-01
Prioridad: 1
Plan de Diseño de software QuickSoft
40. Filtrar defectos por fecha descendente
Identificador: PR Fracaso-40
Proyecto: Defect Zero
Referencias: CU –40
Nombre: filtrar defectos por fecha descendente
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-01
Identificador: CPR Fracaso-40
Identificador de Prueba:
PR-40
Nombre: filtrar defectos por fecha ascendente y producir una respuesta
Usuario y Fecha de Creación:
Ricardo Silva – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Ricardo Silva – 12 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no filtrar defectos por fecha descendente si no existen Datos
Dependencias: PR-01
Prioridad: 1
Plan de Diseño de software QuickSoft
Identificador: PR Fracaso-41
Proyecto: Defect Zero
Referencias: CU –41
Nombre: defectos sin asignar
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-01
Identificador: CPR Fracaso-41
Identificador de Prueba:
PR-41
Nombre: defectos sin asignar y producir una respuesta
Usuario y Fecha de Creación:
Ricardo Silva – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Ricardo Silva – 12 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no defectos sin asignar si no existen Datos
Dependencias: PR-01
Prioridad: 1
Plan de Diseño de software QuickSoft
Identificador: PR Fracaso-42
Proyecto: Defect Zero
Referencias: CU –2.
Nombre: defectos asignados
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-01
Identificador: CPR Fracaso-42
Identificador de Prueba:
PR-02
Nombre: defectos asignados y producir una respuesta
Usuario y Fecha de Creación:
Ricardo Silva – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Ricardo Silva – 12 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no defectos asignados si no existen Datos
Dependencias: PR-01
Prioridad: 1
Plan de Diseño de software QuickSoft
Identificador: PR Fracaso-43
Proyecto: Defect Zero
Referencias: CU –2.
Nombre: defectos no resueltos
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-01
Identificador: CPR Fracaso-43
Identificador de Prueba:
PR-02
Nombre: defectos no resueltos
Usuario y Fecha de Creación:
Ricardo Silva – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Ricardo Silva – 12 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no defectos no resueltos si no existen Datos
Dependencias: PR-01
Prioridad: 1
Plan de Diseño de software QuickSoft
Identificador: PR Fracaso-44
Proyecto: Defect Zero
Referencias: CU –2.
Nombre: defectos resueltos
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-01
Identificador: CPR Fracaso-44
Identificador de Prueba:
PR-02
Nombre: defectos resueltos
Usuario y Fecha de Creación:
Ricardo Silva – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Ricardo Silva – 12 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no defectos resueltos si no existen Datos
Dependencias: PR-01
Prioridad: 1
Plan de Diseño de software QuickSoft
Identificador: PR Fracaso-45
Proyecto: Defect Zero
Referencias: CU –2.
Nombre: Resolver defecto
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-01
Identificador: CPR Fracaso-45
Identificador de Prueba:
PR-02
Nombre: Resolver defecto
Usuario y Fecha de Creación:
Ricardo Silva – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Ricardo Silva – 12 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no resuelva defectos si no existen defectos
Dependencias: PR-01
Prioridad: 1
Plan de Diseño de software QuickSoft
Identificador: PR Fracaso-46
Proyecto: Defect Zero
Referencias: CU –2.
Nombre: Métrica defectos solucionados
Responsable: Ricardo Silva
Estado: Inspeccionada
Dependencias: PR-01
Identificador: CPR Fracaso-46
Identificador de Prueba:
PR-02
Nombre: Métrica defectos solucionados
Usuario y Fecha de Creación:
Ricardo Silva – 12 de Noviembre
Usuario y Fecha de Última Modificación:
Ricardo Silva – 12 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo de verificar que el sistema no produzca la métrica defectos solucionados si no existen defectos solucionados
Dependencias: PR-01
Prioridad: 1
Plan de Diseño de software QuickSoft
Plan de Diseño de software QuickSoft
47. Métrica Fase Inyección de Defectos
Caso exitoso: Mensaje de Error la métrica no fue visualizada correctamente
Caso de Prueba: el administrador trata de mirar la métrica de fase inyección de defectos
Identificador: PR Fracaso -23
Proyecto: Defect Zero
Referencias: CU –23
Nombre: Métrica de fase inyección de defectos
Responsable: David Toca
Estado: Inspeccionada
Dependencias: Ninguna
Identificador: CPR Fracaso -23
Identificador de Prueba:
PR-23
Nombre: Métrica de fase inyección de defectos
Usuario y Fecha de Creación:
David Toca – 14 de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 14 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo el no visualizar las métrica de fase inyección de defectos
Dependencias: Ninguna
Prioridad: 10
Plan de Diseño de software QuickSoft
48. Métrica Tiempo de Detección de Defectos
Caso exitoso: Mensaje de Error la métrica no fue visualizada correctamente
Caso de prueba: El Administrador trata de mirar la métrica tiempo de detección de defectos
Identificador: PR Fracaso -24
Proyecto: Defect Zero
Referencias: CU –24
Nombre: Métrica tiempo de detección de defectos
Responsable: David Toca
Estado: Inspeccionada
Dependencias: Ninguna
Identificador: CPR Fracaso -24
Identificador de Prueba:
PR-24
Nombre: Métrica tiempo de detección de defectos
Usuario y Fecha de Creación:
David Toca – 14 de Noviembre
Usuario y Fecha de Última Modificación:
David Toca – 14 de Noviembre 2009
Descripción: Este caso de prueba tiene el objetivo el no visualizar las métrica de tiempo de detección de defectos
Dependencias: Ninguna
Prioridad: 10
Plan de Diseño de software QuickSoft
RESULTADOS
1. ingresar integrante:Superado
2. ingresar un defecto (integrante):Superado
3. ingresar un defecto (administrador):Superado
4. crear un proyecto (administrador):Superado
5. iniciar sesión (integrante):Superado
6. iniciar sesión (administrador):Superado
7. modificar un integrante:No superado
8. modificar un proyecto:No superado
9. eliminar un proyecto:No superado
10. eliminar un integrante:No superado
11. cerrar sesión:Superado
12. ver defectos (administrador)Superado
13. ver defectos (integrante)Superado
14. asignar defectoNo superado
15. filtrar defectos por fecha ascendenteSuperado
16. filtrar defectos por fecha descendenteSuperado
17. filtrar defectos sin asignarSuperado
18. filtrar defectos asignadosSuperado
19. filtrar defectos no resueltosSuperado
20. filtrar defectos resueltosSuperado
Plan de Diseño de software QuickSoft
12- RESULTADOS
El componente de persistencia esta libre de defectos
1 Partes tienen fallos en compilación
Se presentaron fallos en la mayoría de los métodos de eliminación y modificación
Plan de Diseño de software QuickSoft
ANEXO
VERSION 1.1
CAMBIO de- pruebas de integración
Se agregaron varios casos
TIPO DE CAMBIO ADICCION
MOTIVO
Debido a los nuevos casos de uso
CAMBIO de resultados
Se agregaron varios resultados
TIPO DE CAMBIO MODIFICACION
MOTIVO
Debido a los nuevos casos de prueba, se originaron nuevos resultados
MOTIVO
No estaban especificadas anteriormente
Plan de Diseño de software QuickSoft
Plan de Diseño de software QuickSoft