P. 1
Un Plan de Pruebas Exitoso

Un Plan de Pruebas Exitoso

|Views: 176|Likes:

More info:

Published by: Victor Jose Ortiz Madalengoitia on May 05, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

05/05/2011

pdf

text

original

Un plan de Pruebas Exitoso Enviado el Miércoles, 4 de Septiembre del 2002 a las 17:02:25 porCGonzalez

Un Plan de Pruebas ?xitoso....

Introducción
La construcción de un buen Plan de Pruebas es la piedra angular y en consecuencia el principal factor crítico de éxito para la puesta en práctica de un proceso de pruebas que permita entregar un software de mejor nivel. No obstante que cada esfuerzo o proc eso de pruebas puede ser diferente y específico, la mayor parte de los proyectos informáticos, sean de nuevos desarrollos o de mantenimiento de aplicaciones, tienen un marco común para la realización de las pruebas. Este documento presenta los componentes que estructuran este marco y sirve como una guía para la preparación de cualquier Plan de Pruebas. Veamos cuales son estos componentes: 1. Descripción de Aspectos Generales. Esta sección establece el alcance y el objetivo del Plan de Pruebas. Es aquí dond se e describen los aspectos fundamentales del esfuerzo que se hará para probar una aplicación computacional, independiente las características y tama?o que ésta pueda tener. ? Objetivo - Describe por qué el Plan de Pruebas fue desarrollado - cuales son sus objetivos. Esto puede incluir requerimientos de documentación, definición de estrategias de prueba, identificación de recursos, estimación de plazos y proyección de entregables. ? Entorno o Marco - Explica los eventos que dan origen al Plan de Pruebas. Es puede incluir la realización de procesos to mejorados, o la adición de nuevos ambientes, equipamientos, funcionalidades. ? Arquitectura Técnica ? Diagramación de las partes que componen el sistema bajo prueba. Incluye el almacenamiento de datos y las conexiones para su transferencia y describe el objetivo de cada componente, inclusive la forma de su actualización. Se debe documentar tanto las capas, como la presentación / interfaz del usuario, la base de datos, los emisores de informes, etc. Un diagrama de alto nivel que muestre como el sistema en prueba se inserta en un contexto de automatización mayor también puede ser agregado, si el mismo está disponible. ? Especificaciones del SW y HW ? Corresponde a una lista individualizada de todo el hardware y el oftware que utiliza la s aplicación, incluyendo proveedores y versiones. ? Alcance - Describe brevemente los recursos que el plan requiere, las áreas de responsabilidad, las etapas y los riesgos potenciales. ? Información del proyecto ? Identifica toda la información que está disponible en relación con el proyecto. La documentación del usuario, el plan de proyecto, las especificaciones del producto, los materiales para entrenamiento y las revisiones ejecutivas, son algunos ejemplos de in formación del proyecto. 2. Descripción de Requerimientos. Esta sección del Plan de Pruebas contiene una lista de todos los requerimientos que serán probados. Cualquier requerimiento no incluido en esta lista estará fuera del alcance de las pruebas. El día que usted sea imputado de responsabilidad por un error liberado en un área del sistema que no fue probada, estará feliz de tener un documento escrito y firmado que muestra qué estaba dentro y fuera del alcance de la prueba, cuando ésta fue definida y realizada. ? Requerimientos Funcionales - todas las funciones que deben ser probadas, como por ejemplo la creación, la corrección y supresión de registros, son puestas en esta lista. Puede incluirse la lista completa en esta sección o bien hacerse referenci a a otro documento que contenga la información. ? Requerimientos de Dise?o - Las pruebas de la interfaz de usuario, las estructuras de menú u otros elementos de dise?o también deberían ser puestas en una lista o referenciados hacia otro documento. ? Requerimientos de Integración ? Los requerimientos para probar el flujo de datos desde un componente a otro deben ser incluidos si ellos harán parte del Plan de Pruebas. ? Otros Requerimientos ? Cualesquiera otras exigencias que tenga la aplicación y que necesi ser probadas. ten 3. Definición de la Estrategia de Pruebas. Use esta sección para describir como los objetivos de la prueba serán alcanzados para cada uno de los tipos de pruebas que hacen parte del plan:

la ? erramientas versi n y el número de la esa de Ayuda para pedir el apoyo. ocumentar el plazo en el cual la aplicaci n a probar estará disponible para pruebas y el tiempo estimado para ejecutar los casos de prueba. o cuando un cambio en un área de la aplicaci n causa un problema en otra parte. frecuencias. . ecursos Pruebas. de ejemplo. ocumente el instrumento y el proceso usado para registrar y rastrear los defectos. Identificar los roles y las responsabilidades que serán requeridas para la ejecuci n del Plan de  # ? asos de prueba ? en práctica el plan. ocumentar los instrumentos o herramientas que serán empleados para las pruebas. Ponga en una lista cualquier entregable asociado con el esfuerzo de pruebas y donde las copias de estos entregables o documentos pueden ser localizados. las ? condiciones de ambiente u otros aspectos ue se requi eren para establecer un estado conocido estable para las pruebas. l í il f .  .P l . casos de prueba y el plan de proyecto. ? Supuestos escribir cualquier otro proyecto externo o asuntos que pueden impactar en la eficacia o la oportunidad del esfuerzo de prueba. l t t l . Esto incluye el Plan de Pruebas en sí mismo. mecanismos de entrega y ejemplos. . tareas y recursos. . . t ll j l i i t : i t . para priorizar o calificar defectos: ? rítico denota una funci n inutilizable que causa un t rmino anormal o una falla general. i t l i i . o cuando se espera que los componentes del sistema est n listos para pruebas. equeridos. li t t t i t l l .? ? ? ? ? ? ? ? P ? ? i i E i l ? fi i l ?set ? el sistema. sobre una base regular durante el ciclo de prueba. Seguimiento y eporte de efectos. efinici n de los Entregables. egistrar los criterios que serán usados para determinar la aprobaci n o rechazo de pruebas ? riterios de ermino acci n que debe ser tomada con base en los resultados de la prueba. esarrollar un plan de proyecto mostrando a las fases. a ntenga siempre al día el pla n de proyecto para reflejar acontecimientos tales como cambios de plazos (de fechas límites) o recursos disponibles. si fuera necesario. t j ti . . Las siguien tes son categorías. . ?E ifi l ll t . i j t El j ti l l l t i t t t l i l . l s at s ecesari s tras ependencias de la prueba. escriba cualesquiera calificaci n. 6. categoría o clasificaci n que se usará para identificar o priorizar defectos. Plan de proyecto. i i t f i l t l t . Ponga en una lista todos los informes que serán generados incluyendo repositorios. o un objeto de interfaz no trabaja co mo se muestra. alendario y Plazos. itar al proveedor. escenarios para prueba. 8. ll j i l . ¤¢©¦£ © ¤¨#£©¦ ¤© ¤ £ ¨ ¤ ¡ § £©¦§ ¡' § © ¤ § § ¡© ¤¢¢# ©£ £©¤ ¡©© ¤¢©¦£ ¤¢ ¤ ¦ ¢ ©£¢ §© ¤¨¢¤¦ ¡%£©¤ ©¦ ¤¨ ¢ ¤¨  ¤¨¨ ¦§©¨© ¡¨£©¨ ¤¨ © ¢ ¨§ ¨¤¨¢£¨¡¨¨¡© £©¤ ¡©©¦¢©¡¨ % ¤ § ¢ ¨  ¤¨ £¢¡©§¢ ¢ ¢£¢ ¨¢¤¦ ¢ ¡© ¢££©& ¨ ¨ ¡©¦£ ¤¡ © ¤¨¢ ¨££¢¤© ¡%£©¤ ¢©¦£ © ¤¨¤¢§ ¤¨ ¨¨§ ¢§ §©¤ ¢§ ¡§$  ¡©¦§¨ ©¦ £ ¦§  ¤ ¨ ¤ ¤¨ © £¨ ¢ ¤ £ © ¨¨ © ¨¨§  © ¢£© ¤© ¨¢ ¨¤©© ¢ ©©¦©£¢¡£¦ ¨§ ¡©©© © © ¢¡¨©§¡¦#¡¨§¡© © ©©¦ ©£©¤¨£ ¤© ¨¤© ¦  © ¡ §¢¢©§© ¢¡¦ £©¤ © ©¦ ¨ ¨ ¤© ¢ © ¤ ¢ £ ¢ ¢£¢ ¨  £¨ ¤£¢ ¢ ¢   ¢  ¢ ¢ © ¢¨  ¨ ¨ " ¨ ! acer una lista detallada o una referencia a los casos reales de prueba que serán utili a dos para poner (   1  © ¡© ¦ ¤ ¨ ©¤£¢ ¢ © ©© ¨ £¢¤©§©¡ ¨¨§ ¨ ¡ © ¨ ¨ £©¦ ©£ ¨ ¡¦ ¡¨§¦¤ ¢¢§ ¢£¢ ¨¦ ¨  ¡ ¨  ¨     ¦ © £ ¡ © ¤© ¢ §©¤ ¤©¡¨ §¢£© ¤¡¨(  ¡ §¢ ¢ ¤¡ © ¨ ¡ §¢£¦ ¡¨§ ©    1 0"  )   " 0 ©§¡¢£¨ £© © ¡ §¢£© ¡ © " $ 0 ¤© ¢¡¨ §¡¦¥ i l i t i ¡©¦ ¨ © ¢© ¤ ¤ © ¤£ ¤© ©   ¤¢ £¢ ¡  it i i t l t f fi j ti i li . fi i i . . Identifique los recursos involucrados en el proceso de seguimiento. " "   02 ( 4 ( ( ) ( la  3 . Especifique si se proporcionará partes construidas. . ? Severo una funci n no actúa como fue requerido o dise?ado.

... o no se ajusta a las normas y convenciones. uando el es fuerzo de prueba esté terminado....... es comprobadamente el método más eficaz para obtener la aprobaci n del Plan de Pruebas.......... mensajes de error vagos o confusos o advertencias.. ocumentaci n de los esultados... Nota: Ver artículo completo ....... el jefe del proyecto y el gerente de desarrollo.... 9... documente los resultados y mediciones....... pero no tan rápidamente como esperado.. El Plan de Pruebas debe ser revisado por todos las partes responsables de su ejecuci n y aprobado por el equipo de prueba.. na reuni n final de verificaci n con todas las partes involucradas.....Escríbanos a Contacto 6 6 8 7 6 C 6 6 5 5 6 6 6 B A@ 7 9 . Identifique cualquier discrepancia entre el plan y la puesta en práctica real y describa adecuadamente como aquellas discrepancias fueron manejadas.... . ? osmético no crítico para el funcionamiento de sistema: palabras con mala ortografía.? Advertencia la funci n trabaja.. formateo incorrecto.. Aprobaci n del Plan.. btenga las firma s de aprobaci n en todas las páginas del mismo...

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->