ESTRUCTURA Y ELEMENTOS DE UN PLAN DE PRUEBAS (Borrador) Preparado por Adrián Anex M – Dirección de Calidad

INTRODUCCIÓN Las pruebas de software se aplican como una etapa más del proceso de desarrollo de software, su objetivo es asegurar que este cumpla con las especificaciones requeridas y eliminar los posibles defectos que este pudiera tener. Generalmente las pruebas se apoyan en metodologías generales que revisan los aspectos más fundamentales que debe considerar todo proceso de prueba. “El propósito del plan de pruebas es explicitar el alcance, enfoque, recursos requeridos, calendario, responsables y manejo de riesgos de un proceso de pruebas. Incluye identificación del plan de acción y fecha del plan, el alcance que es el Tipo de prueba y las propiedades/elementos del software a ser probado, los ítems a probar que son los elementos a probar y las condiciones mínimas que debe cumplir para comenzar a aplicarle el plan.”
Un plan de pruebas está constituido por un conjunto de pruebas. Cada prueba debe:
• • • •

Dejar claro qué tipo de propiedades se quieren probar (corrección, robustez, fiabilidad, usabilidad,...). Dejar claro cómo se mide el resultado. Especificar en qué consiste la prueba (hasta el último detalle de cómo se ejecuta). Definir cuál es el resultado que se espera (identificación, tolerancia,...) ¿Cómo se decide que el resultado es acorde con lo esperado?

Luego de culminadas las etapas de análisis, diseño y desarrollo se inicia la etapa de pruebas, en esta etapa lo recomendable es que el aplicativo se mantenga en un ambiente aislado o separado del ambiente de desarrollo o de producción, lo ideal es preparar un ambiente de pruebas lo más parecido a los ambientes que existen en producción para asegurar su correcto funcionamiento en esa futura etapa Para el analista de pruebas es muy importante y conveniente tener una definición funcional y técnica razonable antes de iniciar el proceso de prueba.

Estabilidad: Es recomendable que los cambios no interfieran en la evolución del plan de pruebas. Descomposición: Deben estar estructurado de tal forma que puedan aislarse los problemas en componentes simples (modularidad) Simplicidad: Tanto funcional. y cada versión debería contener una agenda para actualizaciones subsiguientes del plan. Probar todo es lisa y llanamente imposible. Una prueba tiene éxito si encuentra un error o defecto. Facilidad de comprensión: Cuanta mas información contenga el código o la documentación técnica adjunta mas fácilmente se desarrollaran las prueba Evolución del Plan A medida que el proyecto evolucione este documento debe ser actualizado periódicamente para reflejar las situaciones desarrolladas. Si usted no encuentra una debilidad. Observabilidad: Deben existir formas de conocer las operaciones que esta realizando el software Controlabilidad: Las salidas del software deben depender únicamente de los datos de entrada. como estructural y en el código. Las pruebas sólo pueden encontrar los errores que buscan. Así. pero jamás demostrar que no los hay. tenga por seguro que la encontrará el usuario. debe resolverse antes. . Por esto es tan importante un buen diseño de pruebas. cada versión del plan debería ser remplazada por el cambio de control. • • • • Tenga en consideración Para que un software sea adecuado a las pruebas debe cumplir los siguientes requisitos: • • • • • • • Operatividad: El fallo debido a un error no debe interferir con las pruebas posteriores.Al probar hay que tener presente las siguientes máximas: • • Que usted no encuentre debilidades no quiere decir que no existan. Las pruebas pueden encontrar fallos. no dando lugar a aleatoriedades.

1. Al corregirse los defectos.Configuración del ambiente de pruebas. Repetido. mejor.1 ESTRUCTURA DEL PLAN DE PRUEBAS Este capítulo presenta los componentes que estructuran este marco y sirve como una guía para la preparación de cualquier Plan de Pruebas Características de una buena prueba • • • • Ha de tener una alta probabilidad de encontrar un fallo. Si ya funciona. no lo probamos más.Estrategia de prueba La estrategia de prueba que el producto que se implementando cumpla con los requerimientos de la lógica del negocio que el GEC ha explicitado en su contrato de servicio. Los criterios de culminación pueden ser tan simples como aprobar el número mínimo de casos de prueba diseñados o tan complejos como tomar en cuenta no sólo el número mínimo.. En algunas circunstancias (las cuales deben ser explicitadas) el proceso de prueba debe suspenderse en vista de los defectos o fallas que se han detectado. Si tenemos donde elegir. 1. patrón y/o herramientas a utilizarse en el diseño de los casos de prueba 1. Describe la técnica. Tangibles Explicita los documentos a entregarse al culminar el proceso previsto por el plan.Estado del plan de pruebas Explicita las condiciones bajo las cuales. el proceso de prueba previsto por el plan puede continuar. El primer factor que hay que tener en consideración es el ambiente de pruebas. casos de prueba. pero debe explicitarse a partir de qué punto. de manera equivalente.2. ya que puede ser necesario repetir algunas pruebas. por ejemplo especificación de pruebas. si es muy compleja a lo mejor no sabemos lo que ha fallado 1. Debe ser la “mejor de la cosecha”..Alcance Indica el tipo de prueba y las propiedades / elementos de la aplicación a ser probada. elegimos la mejor.1.3. Finalizado. No debería ser ni demasiado sencilla ni demasiado compleja.5.4. Si es muy sencilla no aporta nada. Este debe ser igual o muy similar al ambiente de producción donde se pueda evaluar al sistema implementado. sino también el tiempo previsto para las pruebas y la tasa de detección de fallas.. No debe ser redundante. 1. bitácora de pruebas. Cuanto más.. registro de errores . el plan de ser: Suspendido.

cualquier otro software necesario para llevar a cabo las pruebas. El Plan de Pruebas debe ser revisado por todos las partes responsables de su ejecución y aprobado por el equipo de prueba.... Cualquier requerimiento no incluido en esta lista estará fuera del alcance de las pruebas.Calendario Esta sección describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de las tareas a realizar. incluyendo las características del hardware. el sistema de operación).10. así como cualquier habilidad especial que se requiera. las acciones mitigantes y de contingencia.Recursos Especifica las propiedades necesarias y deseables del ambiente de prueba.11. Esta sección del Plan de Pruebas contiene una lista de todos los requerimientos que serán probados.. seguridad.7. 1. tiempo en la máquina del ambiente. el software de sistemas (por ej. qué módulos se colocan en qué máquinas de una red local) y la configuración del software de apoyo. 1. 1. . 1. el líder proyecto y el Director de Desarrollo e Internet..6.1.12.8. También se indican cualquier requerimiento especial del proceso: actualización de licencias... 1.Procedimientos especiales Identifica las tareas necesarias para preparar y ejecutar las pruebas. 1.Manejo de riesgos Explicita los riesgos del plan.Responsables y la matriz de responsabilidad Especifica quién es el responsable de cada una de las tareas previstas en el plan.Descripción de Requerimientos. espacio de oficina. La sección incluye un estimado de los recursos humanos necesarios para el proceso.9.Aprobación del Plan. así como la colocación específica del software a probar (por ej.

Las combinaciones de casos de prueba podrían ser prácticamente infinitas. sin embargo es importante tener buen criterio a la hora de desarrollarlos. Una vez concluidos los casos de prueba es mas sencillo poder estimar cuanto tiempo nos tomara una primera barrida de pruebas y con esto también podremos realizar nuestro cronograma y plan de pruebas. Módulo a probar Descripción del caso Pre-requisitos Data necesaria (valores a ingresar) Pasos o secuencia lógica Resultado esperado (correcto o incorrecto) Resultado obtenido Observaciones o comentarios Analista de Pruebas (responsable de las pruebas) Fecha de Ejecución Estado (concluido. Los casos de prueba nos permitirán probar todas las funcionalidades del sistema. los casos de prueba deben definir los datos de entrada a utilizar. Estructura para casos de prueba • • • • • • • • • • • • Identificador de caso de prueba. en proceso) Ejemplo: Id Caso Modulo a probar Descripción del de caso prueba CP001 Inscripción de Validar que un cursos alumno moroso (biblioteca o financiero no pueda inscribir ramos) Validar que el alumno pueda inscribir asignaturas inherentes a su Pre requisitos Fecha de la Comentarios Estado prueba a la prueba dd/mm/aa Pendiente Debe existir el alumno Debe existir la carrera Debe existir la malla y los prerrequisitos . En las pruebas funcionales los casos de prueba tienen el objetivo de detectar errores. Luego de asimilar estos conocimientos será más sencillo el desarrollo de los casos de prueba. el proceso que debemos seguir en el sistema y el resultado esperado.2 CASOS DE PRUEBA Para conocer como funcionara el sistema y tener una visión general de lo que este hace para el negocio es necesario asimilar la documentación funcional y técnica previamente definida. pendiente.

Esto se refiere a probar la facilidad con lo cual los usuarios de una aplicación la pueden operar. 3. Validar que un alumno no pueda inscribir ramos que no tenga los prerrequisitos aprobados Validar que el alumno inscriba un número mínimo de asignaturas (Créditos) 3 ESQUEMA GENERAL DE LAS PRUEBAS Las pruebas se harán en las siguientes categorías: 1. 4. de acuerdo a los procesos de negocios vigentes Prueba de demanda “on line” (por ejemplo inscripción de asignaturas (cursos) 5. Rendimiento (simulación de matrícula) 6. con los sistemas en producción 7. Usabilidad Unitarias Funcionalidad. Seguridad 10.Pruebas de usabilidad Estas pruebas están orientadas a probar la usabilidad del sistema.1.2 Pruebas unitarias . En nuestro caso.. • Determinar si la interfaz es lo suficientemente intuitiva tanto para usuarios que tienen experiencia como para aquellos que no la tienen. 2. es decir. Carga masiva de datos (ficha prospectos) 8. los objetivos principales serán: • Determinar si los usuarios pueden utilizar las distintas funcionalidades del sistema sin mayores complicaciones. Aceptación 12. • Determinar si la aplicación requiere modificaciones para que cumpla con los objetivos anteriores. 3. Robutez 11. De huella de auditoría 3. Recuperación frente a una caída 9. ubican rápidamente la función que desean ejecutar. Integración.carrera.

esta etapa suele ser la ultima etapa de pruebas y al dar conformidad sobre esta el paso siguiente es el pase a producción. u otros parámetros de rendimiento. esto generalmente se define en los casos de prueba preparados antes del inicio de las pruebas. Al realizar pruebas funcionales lo que se pretende en ponerse en los pies del usuario. básicamente el enfoque de este tipo de prueba se basa en el análisis de los datos de entrada y en los de salida.5 Rendimiento ( por ejemplo: simulación de matrícula) A veces es importante el tiempo de respuesta. Para todos estos parámetros suele ser importante conocer cómo evolucionan al variar la dimensión del problema (por ejemplo. enfocados básicamente al negocio. su objetivo será encontrar posibles debilidades en e sistema bajo prueba 3. o cuánto espacio en disco utiliza. posibles particularidades que no se hayan contemplado adecuadamente en el diseño funcional.6. ya que el analistas de pruebas. no enfocan su atención a como se generan las respuestas del sistema.4 Prueba de demanda “on line” (por ejemplo inscripción de asignaturas (cursos) 3. 3. A este tipo de pruebas se les denomina también pruebas de comportamiento o pruebas de caja negra. Típicamente nos puede preocupar cuánto tiempo le lleva al sistema procesar tantos datos. es común que este tipo de pruebas sean desarrolladas por analistas de pruebas con apoyo de algunos usuarios finales. Generalmente los usuarios realizan las pruebas con la idea que todo debería funcionar.Pretenden probar que los fragmentos individuales (unidades) que forman el sistema cumplen las especificaciones y tienen el comportamiento esperado.Prueba de integración . 3.3 Pruebas funcionales Se denominan pruebas funcionales a las pruebas de software que tienen por objetivo probar que el sistema implementado cumpla con las funciones específicas para los cuales han sido creado.. o cuánta memoria consume. o cuántos datos transfiere por un canal de comunicaciones. al duplicarse el volumen de datos de entrada). El analista de pruebas debe dar fuerza a las pruebas funcionales y más aún a las de robustez. a diferencia del analista de pruebas que tiene más bien una misión crítica. Generalmente se requiere apoyo de los usuarios finales ya que ellos pueden aportar mucho en el desarrollo de casos de prueba complejos.

en particular cuando la interfaz es humana 3. Son básicamente pruebas funcionales.9 Seguridad Se valida la funcionalidad del aplicativo para proveer una estructura de permisos y acceso según sea el perfil del usuario 3. sobre el sistema completo.11 Pruebas de Aceptación Son las que harán de acuerdo a los criterios de aceptación. Estas pruebas son importantes en sistemas con una interfaz al exterior. Determina que el sistema cumple con lo deseado y se obtiene la conformidad del cliente. etc. aplicaciones individuales. y si cumplen con la funcionalidad establecida 3. aplicaciones web. .8 Recuperación frente a caídas 3.10 Prueba de robustez Determinan la capacidad del aplicativo para no soportar entradas incorrectas. estas ‘partes’ pueden ser módulos. que comprueban la compatibilidad y funcionalidad de los interfaces entre las distintas ‘partes’ que componen un sistema. Estas pruebas las realiza el cliente. Se realizan en el ámbito una vez que se han aprobado las pruebas unitarias.Las pruebas de integraciónse refieren a la prueba o pruebas de todos los elementos unitarios. Comprueban la correcta unión de los componentes entre sí a través de sus interfaces. aplicaciones cliente/servidor. Se prueba la capacidad del sistema para salir de situaciones embarazosas provocadas por errores en el suministro de datos.7 Carga masiva de datos (por ejemplo prospectos) 3. y buscan una cobertura de la especificación de requisitos y del manual del usuario.

3 Reportes de defectos y errores En la Intranet se almacenarán todos los resultados y defectos individuales y en conjunto de las pruebas realizadas . probados. En suma.1 Suite de pruebas La suite definirá los casos de prueba asociados a cada prueba. probados condicionalmente o fallidos.4 ENTREGABLES 4. Los resultados de las pruebas serán guardados bajo un control de versiones. 4.2 Registros de pruebas realizadas Servirá para identificar los casos de prueba y hacer seguimiento del estado de cada caso de prueba. Los resultados de las pruebas serán resumidos posteriormente antes de probar. se tendrán los siguientes atributos por cada prueba realizada: • Estado de la prueba • Número de la versión probada • Persona que realizó la prueba • Fecha y hora de la prueba • Notas y observaciones de la prueba Será responsabilidad del QA actualizar el estado de la prueba en los registros. 4.

un caso de prueba es utilizado por el analista para determinar si el requisito de una aplicación es parcial o completamente satisfactorio. Por ejemplo: Divisiones entre cero. es el resultado de un fallo o deficiencia durante el proceso de creación de programas de ordenador o computadora u otro dispositivo. Referente a la programación una prueba de software. una definición de datos o un paso de procesamiento incorrectos en un programa.ANEXO-1 GLOSARIO Pruebas Es una actividad en la cual un sistema o uno de sus componentes se ejecutan para verificar el funcionamiento de un proceso. Por ejemplo. los resultados se observan y registran para realizar una evolución de dicho proceso. una mala interpretación de un requerimiento o de la funcionalidad de un método. Calidad del software Concordancia con lo requisitos funcionales y de rendimiento explícitamente establecidos y con los estándares de desarrollo explícitamente documentados. en inglés testing son los procesos que permiten verificar y revelar la calidad de un producto software. Error Es una equivocación cometida por un desarrollador. condiciones de ejecución y resultados esperados desarrollados para un objetivo particular. Algunos ejemplos de errores son: un error de escritura. Falla Puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación. Validación . Son utilizadas para identificar posibles fallos de implementación. Es la incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados. Defecto Un defecto de software. Verificación La verificación del software es el proceso a través del cual se analiza y revisa que el software satisfaga los objetivos propuestos al inicio del desarrollo. una acción humana que conduce a un resultado incorrecto. Caso de prueba Un conjunto de entradas. y con las características implícitas que se espera de todo software desarrollado profesionalmente. Es una tipo de manifestación del defecto en el sistema que se ejecuta. un proceso.

. • Test de Rendimiento Prueba orientada a determinar la capacidad de la solución de HW/SW en el escenario de producción esperado. Test Unitario Prueba sobre componentes desarrollados individualmente. coordinado de dos o más módulos • Test Funcional Prueba de usuario/cliente sobre funcionalidades desarrolladas.El proceso de evaluación de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario. Test de Integración prueba que valida el funcionamiento desarrollados por separado.

Sign up to vote on this title
UsefulNot useful