PLAN DE PRUEBAS
Objetivo del documento
Señalar el enfoque, los recursos y el esquema de actividades de prueba, así como los elementos a probar, las características, las actividades de prueba, el personal responsable y los riesgos asociados
Estructura fijada en el estándar
1. Identificador único del documento
2. Introducción y resumen de elementos y características a probar
3. Elementos software a probar
4. Características a probar
5. Características que no se probarán
6. Enfoque general de la prueba
7. Criterios de paso/fallo para cada elemento
8. Criterios de suspensión y requisitos de reanudación
9. Documentos a entregar
10. Actividades de preparación y ejecución de pruebas
11. Necesidades de entorno
12. Responsabilidades en la organización y realización de las pruebas
13. Necesidades de personal y formación
14. Esquema de tiempos
15. Riesgos asumidos por el plan y planes de contingencias
16. Aprobaciones y firmas con nombre y puesto desempeñado
ESPECIFICACION DEL DISEÑO DE PRUEBAS
Objetivo del documento
Especificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e identificar las características que se deben probar con este diseño de pruebas
ESPECIFICACION DEL DISEÑO DE PRUEBAS
Estructura fijada en el estándar
* Identificador único para la especificación. Proporcionar también una referencia del plan asociado (si existe)
* Características a probar de los elementos software (y combinaciones de características)
* Detalles sobre el plan de pruebas del que surge este diseño, incluyendo las técnicas de prueba específica y los métodos de análisis de resultados
ESPECIFICACION DE CASO DE PRUEBA
Objetivo del documento
Definir uno de los casos de prueba identificado por una especificación del diseño de las pruebas
ESPECIFICACION DE CASO DE PRUEBA
Estructura fijada en el estándar
Elementos software (por ejemplo, módulos) que se van a probar: definir dichos elementos y las características que ejercitará este caso
* Especificaciones de cada entrada requerida para ejecutar el caso (incluyendo las relaciones entre las diversas entradas; por ejemplo, la sincronización de las mismas)
* Especificaciones de todas las salidas y las características requeridas (por ejemplo, el tiempo respuesta) para los elementos que se van a probar
* Necesidades de entorno (hardware, software y otras como, por ejemplo, el personal)
ESPECIFICACION DE PROCEDIMIENTO DE PRUEBA
Objetivo del documento
Especificar los pasos para la ejecución de un conjunto de casos de prueba o, más generalmente, los pasos utilizados para analizar un elemento software con el propósito de evaluar un conjunto de características del mismo
Estructura fijada en el estándar
Identificador único de la especificación y referencia a la correspondiente especificación de diseño de prueba
* Objetivo del procedimiento y lista de casos que se ejecutan con él
* Requisitos especiales para la ejecución (por ejemplo, entorno especial o personal especial)
* Pasos en el procedimiento. Además de la manera de registrar los resultados y los incidentes de la ejecución, se debe especificar:
* La secuencia necesaria de acciones para preparar la ejecución
* Acciones necesarias para empezar la ejecución
* Acciones necesarias durante la ejecución
* Cómo se realizarán las medidas ( por ejemplo, el tiempo de respuesta)
* Acciones necesarias para suspender la prueba (cuando los acontecimientos no previstos lo obliguen)
* Puntos para reinicio de la ejecución y acciones necesarias para el reinicio en estos puntos
* Acciones necesarias para detener ordenadamente la ejecución
* Acciones necesarias para restaurar el entorno y dejarlo en la situación existente antes de las pruebas
* Acciones necesarias para tratar los acontecimientos anómalos.
La prueba de software es un forma de verificar las,tecnicas y métodos que hacen un buen desempeño de un programa, determinando si los requistos han sido cubiertos satisfactoriamente.
ResponderEliminarSi el programa carece de documentacion puede presentarse alguna falla o error devido a que los requisitos no fueron bien captados por el desarrollador del programa.
Para esto exite la verificacion y la validacion los cuales te permiten detectar que todos los requisitos han sido satisfactorios para el usuario previniendo retrasos en en su desarrollo.
Existen tres enfoques principales para el diseño de casos o pruebas:
1.- De caja blanca: analiza los caminos de ejecución.
2.- De caja negra. Se centra en las entradas y salidas.
3.- El enfoque aleatorio: consiste en utilizar modelos estadísticos para crear a partir de ellos los casos de prueba.
La documentacion del diseño de las pruebas se realiza con la finalidad de que los objetivos, de desarrollar el software con los requerimientos que el usuario requiere siguiendo reglas para su elaboracion, asignando responsabilidades y programando las actividades que se van a realizar para su desarrollo.
Tratando de prevenir o en su caso detener la elaboracion del programa por acontecimientos anomalos o inesperados por el desarrollador, los cuales no tengan o cumplan con lo esperado por el usuario.
Conclusion: Javier.
Sin lugar a dudas realizar pruebas al software desarrollado implica mucho más que depuraciones, parte de estas pruebas se pueden realizar desde diagramas de UML que nos muestren los procesos por los que pasa el sistema y en donde puede fallar cada uno de ellos.
ResponderEliminarDiferenciar adecuadamente los síntomas del sistema (error, defecto y falla) determina la adecuada ejecución del caso de prueba el cual puede ser aplicado por ambas partes involucradas en el desarrollo del software, es decir, una relación cliente-desarrollador.
Verificar el sistema permite determinar si los procesos que este realiza satisface completamente los objetivos planteados esto no implica que esté libre de fallas o errores, sin embargo para eso se utiliza la validación de los componentes del sistema que al inicio, durante y al final del desarrollo del software determinan si cumplirá al 100% el funcionamiento por el cual fue realizado.
Las pruebas de verificación pueden ser de caja blanca revisando la estructura interna del sistema o de caja negra que implica validar funciones, entradas, métodos, variables, constructores que ayuden en cada modulo del programa.
Sin embargo las pruebas al igual que el funcionamiento se debe documentar para el adecuado rendimiento y revisión del programa en un futuro, el documento debe contener cada una de las acciones a revisar, elementos que se probarán, características de componentes y de módulos, así como las personas que implica el desarrollo, es decir, las personas a cargo de cada parte de codificación del sistema y los riesgos presentados durante el ciclo de vida del mismo desde el análisis hasta implementación.
Conclusion por Dulce
Para mi lo mas importante para hacer un buen software es desde un inicio hacer un buen plan de trabajo, buen diseño de base de datos, si es que se necesita una, de tal forma que sea optimo para su funcionamiento, y hacer un buen diseño de software que permita facilidad en su uso, buen entendimiento pero a la vez muy funcional.
ResponderEliminarEsto conlleva a tener menos fallas, errores, defectos, etc., en el mismo; pero no por ello no hay que verificar todo el sistema, al contrario con ello nos proporciona un software mas robusto, con mas funcionalidad y menos errores, defectos, o fallas.
Para realizar todo ello se dispone de varios métodos que son útiles para detectar cualquier desperfecto, como son las pruebas de caja blanca y negra, asi como tambien software estadistico que nos indique en que puede fallar el mismo.
En cuanto a la documentación si lo veo algo extenso, pero sobre la marcha se va construyendo y anexando a la documentación del proyecto, como se mencionó en el tema, el tener bien documentado nuestro proyecto (analisis de requisitos, diccionario de datos, diagramas, etc) nos ayuda mas a realizar las pruebas de software sin andar divagando tanto.
alguien de ustedes sabe sobre el tema
ResponderEliminarDiseño y aplicación de pruebas
que me pueda contestar estas preguntas para saber en si sobre este tema, muchas gracias espero y pudan ayudarme :) saludos
-Que es el proceso de documentación de pruebas de software
-Para que se desarrolla la documentación de pruebas de software o cuáles son sus objetivos
-Cuál es el proceso de documentación de pruebas del software
-Ejemplo de documentación de pruebas de software
compa karim ando buscando lo mismo pero no lo he encontrado
ResponderEliminar