Al probar hay que tener presente las siguientes máximas: •
•
•
•
•
•
Que usted no encuentre debilidades no quiere decir que no existan, Si usted no encuentra una debilidad, tenga por seguro que la encontrará el usuario, Una prueba tiene éxito si encuentra un error o defecto. Las pruebas pueden encontrar fallos; pero jamás demostrar que no los hay, Las pruebas sólo pueden encontrar los errores que buscan. Por esto es tan importante un buen diseño de pruebas, Probar todo es lisa y llanamente imposible.
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, debe resolverse antes.
•
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, no dando lugar a aleatoriedades.
•
Descomposición: Deben estar estructurado de tal forma que puedan aislarse los problemas en componentes simples (modularidad)
• •
Simplicidad: Tanto funcional, como estructural y en el código. Estabilidad: Es recomendable que los cambios no interfieran en la evolución del plan de pruebas.
•
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. Así, cada versión del plan debería ser remplazada por el cambio de control, y cada versión debería contener una agenda para actualizaciones subsiguientes del plan.
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. Cuanto más, mejor. No debe ser redundante. Si ya funciona, no lo probamos más. Debe ser la “mejor de la cosecha”. Si tenemos donde elegir, elegimos la mejor. No debería ser ni demasiado sencilla ni demasiado compleja. Si es muy sencilla no aporta nada, si es muy compleja a lo mejor no sabemos lo que ha fallado
1.1.- Alcance Indica el tipo de prueba y las propiedades / elementos de la aplicación a ser probada.
1.2.- Configuración del ambiente de pruebas. El primer factor que hay que tener en consideración es el ambiente de pruebas. Este debe ser igual o muy similar al ambiente de producción donde se pueda evaluar al sistema implementado, de manera equivalente.
1.3.- 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. Describe la técnica, patrón y/o herramientas a utilizarse en el diseño de los casos de prueba
1.4.- Estado del plan de pruebas Explicita las condiciones bajo las cuales, el plan de ser: Suspendido, Repetido; Finalizado. 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. Al corregirse los defectos, el proceso de prueba previsto por el plan puede continuar, pero debe explicitarse a partir de qué punto, ya que puede ser necesario repetir algunas pruebas. 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, sino también el tiempo previsto para las pruebas y la tasa de detección de fallas.
1.5. Tangibles Explicita los documentos a entregarse al culminar el proceso previsto por el plan, por ejemplo especificación de pruebas, casos de prueba, bitácora de pruebas, registro de errores
1.6.- Procedimientos especiales Identifica las tareas necesarias para preparar y ejecutar las pruebas, así como cualquier habilidad especial que se requiera.
1.7.- Recursos Especifica las propiedades necesarias y deseables del ambiente de prueba, incluyendo las características del hardware, el software de sistemas (por ej. el sistema de operación), cualquier otro software necesario para l levar a cabo las pruebas, así como la colocación específica del software a probar (por ej. qué módulos se colocan en qué máquinas de una red local) y la configuración del software de apoyo. La sección incluye un estimado de los recursos humanos necesarios para el proceso. También se indican cualquier requerimiento especial del proceso: actualización de licencias, espacio de oficina, tiempo en la máquina del ambiente, seguridad.
1.8.- Calendario Esta sección describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de las tareas a realizar.
1.9.- Manejo de riesgos Explicita los riesgos del plan, las acciones mitigantes y de contingencia.
1.10.- Responsables y la matriz de responsabilidad Especifica quién es el responsable de cada una de las tareas previstas en el plan.
1.11.- 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.
1.12.- Aprobación del Plan. El Plan de Pruebas debe ser revisado por todos las partes responsables de su ejecución y aprobado por el equipo de prueba, el líder proyecto y el Director de Desarrollo e Internet.
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. Luego de asimilar estos conocimientos será más sencillo el desarrollo de los casos de prueba. En las pruebas funcionales los casos de prueba tienen el objetivo de detectar errores, los casos de prueba deben definir los datos de entrada a utilizar, el proceso que debemos seguir en el sistema y el resultado esperado. 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.
Los casos de prueba nos permitirán probar todas las funcionalidades del sistema, sin embargo es importante tener buen criterio a la hora de desarrollarlos. Las combinaciones de casos de prueba podrían ser prácticamente infinitas.
Estructura para casos de prueba • • • • • • • • • • • •
Identificador de caso de prueba. 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, pendiente, en proceso)
Ejemplo: Id Caso Modulo a probarDescripción del Pre requisitos de caso prueba
Fecha de la Comentarios Estado prueba a la prueba
CP001
dd/mm/aa
Inscripción de cursos
Validar que un alumno moroso (biblioteca o financiero no pueda inscribir ramos) Validar que el alumno pueda inscribir asignaturas inherentes a su
Debe existir el alumno Debe existir la carrera
Debe existir la malla y los prerrequisitos
Pendiente
carrera. 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. 2. 3. 4.
Usabilidad Unitarias Funcionalidad, 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. Integración, con los sistemas en producción 7. Carga masiva de datos (ficha prospectos) 8. Recuperación frente a una caída 9. Seguridad 10.Robutez 11. Aceptación 12. De huella de auditoría
3.1.- Pruebas de usabilidad Estas pruebas están orientadas a probar la usabilidad del sistema. Esto se refiere a probar la facilidad con lo cual los usuarios de una aplicación la pueden operar. En nuestro caso, los objetivos principales serán: Determinar si los usuarios pueden utilizar las distintas funcionalidades del sistema sin mayores complicaciones, es decir, ubican rápidamente la función que desean ejecutar. Determinar si la interfaz es lo suficientemente intuitiva tanto para usuarios que tienen experiencia como para aquellos que no la tienen. Determinar si la aplicación requiere modificaciones para que cumpla con los objetivos anteriores. •
•
•
3.2 Pruebas unitarias
Pretenden probar que los fragmentos individuales (unidades) que forman el sistema cumplen las especificaciones y tienen el comportamiento esperado.
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, es común que este tipo de pruebas sean desarrolladas por analistas de pruebas con apoyo de algunos usuarios finales, esta etapa suele ser la ultima etapa de pruebas y al dar conformidad sobre esta el paso siguiente es el pase a producción. A este tipo de pruebas se les denomina también pruebas de comportamiento o pruebas de caja negra, ya que el analistas de pruebas, no enfocan su atención a como se generan las respuestas del sistema , 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, 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. Generalmente se requiere apoyo de los usuarios finales ya que ellos pueden aportar mucho en el desarrollo de casos de prueba complejos, enfocados básicamente al negocio, posibles particularidades que no se hayan contemplado adecuadamente en el diseño funcional. El analista de pruebas debe dar fuerza a las pruebas funcionales y más aún a las de robustez. Generalmente los usuarios realizan las pruebas con la idea que todo debería funcionar, a diferencia del analista de pruebas que tiene más bien una misión crítica, su objetivo será encontrar posibles debilidades en e sistema bajo prueba
3.4 Prueba de demanda “on line” (por ejemplo inscripción de asignaturas (cursos) 3.5 Rendimiento ( por ejemplo: simulación de matrícula) A veces es importante el tiempo de respuesta, u otros parámetros de rendimiento. Típicamente nos puede preocupar cuánto tiempo le lleva al sistema procesar tantos datos, o cuánta memoria consume, o cuánto espacio en disco utiliza, o cuántos datos transfiere por un canal de comunicaciones. Para todos estos parámetros suele ser importante conocer cómo evolucionan al variar la dimensión del problema (por ejemplo, al duplicarse el volumen de datos de entrada).
3.6.- Prueba de integración
Las pruebas de integraciónse refieren a la prueba o pruebas de todos los elementos unitarios, que comprueban la compatibilidad y funcionalidad de los interfaces entre las distintas ‘partes’ que componen un sistema, estas ‘partes’ pueden ser módulos, aplicaciones individuales, aplicaciones cliente/servidor, aplicaciones web, etc. Se realizan en el ámbito una vez que se han aprobado las pruebas unitarias. Comprueban la correcta unión de los componentes entre sí a través de sus interfaces, y si cumplen con la funcionalidad establecida
3.7 Carga masiva de datos (por ejemplo prospectos) 3.8 Recuperación frente a caídas 3.9 Seguridad Se valida la funcionalidad del aplicativo para proveer una estructura de permisos y acceso según sea el perfil del usuario
3.10 Prueba de robustez Determinan la capacidad del aplicativo para no soportar entradas incorrectas. Se prueba la capacidad del sistema para salir de situaciones embarazosas provocadas por errores en el suministro de datos. Estas pruebas son importantes en sistemas con una interfaz al exterior, en particular cuando la interfaz es humana
3.11 Pruebas de Aceptación Son las que harán de acuerdo a los criterios de aceptación. Determina que el sistema cumple con lo deseado y se obtiene la conformidad del cliente. Estas pruebas las realiza el cliente. Son básicamente pruebas funcionales, sobre el sistema completo, y buscan una cobertura de la especificación de requisitos y del manual del usuario.
4 ENTREGABLES 4.1Suite de pruebas La suite definirá los casos de prueba asociados a cada prueba.
4.2Registros 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, probados, probados condicionalmente o fallidos. En suma, 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. Los resultados de las pruebas serán guardados bajo un control de versiones.
4.3Reportes de defectos y errores En la Intranet se almacenarán todos los resultados y defectos individuales y en conjunto de las pruebas realizadas
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, los resultados se observan y registran para realizar una evolución de dicho proceso. Referente a la programación una prueba de software, en inglés testing son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación.
Caso de prueba Un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular, un caso de prueba es utilizado por el analista para determinar si el requisito de una aplicación es parcial o completamente satisfactorio.
Calidad del software Concordancia con lo requisitos funcionales y de rendimiento explícitamente establecidos y con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente.
Defecto Un defecto de software, es el resultado de un fallo o deficiencia durante el proceso de creación de programas de ordenador o computadora u otro dispositivo. Por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa.
Error Es una equivocación cometida por un desarrollador. Algunos ejemplos de errores son: un error de escritura, una mala interpretación de un requerimiento o de la funcionalidad de un método, una acción humana que conduce a un resultado incorrecto. Por ejemplo: Divisiones entre cero. Es una tipo de manifestación del defecto en el sistema que se ejecuta.
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. Es la incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.
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.
Validación
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 Unitario Prueba sobre componentes desarrollados individualmente.
Test de Integración prueba que valida el funcionamiento desarrollados por separado.
coordinado de dos o más módulos
• Test Funcional Prueba de usuario/cliente sobre funcionalidades desarrolladas. • Test de Rendimiento Prueba orientada a determinar la capacidad de la solución de HW/SW en el escenario de producción esperado.
