GESTION DE PRUEBAS DE SOFTWARE

INISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN UNIVERSITARIA UNIVERSIDAD NACIONAL EXPERIMENTAL DE LA GRAN CARACAS

PROGRAMA NACIONAL DE FORMACIÓN EN INFORMÁTICA

INGENIERÍA DEL SOFTWARE

GESTION DE PRUEBAS DE SOFTWARE

Caracas, Mayo 2022

INDICE

INDICE

INTRODUCCION…………….………………………………………………………………….3

GESTION DE PRUEBAS DE SOFTWARE…………………………………………………….4

PLAN DE PRUEBAS…………………………………………………………………………...4

PASOS PARA ELABORAR EL PLAN DE PRUEBAS………………………………………..4

DEFINIR LOS CRITERIOS DE INICIO, ACEPTACIÓN Y SUSPENSIÓN DE PRUEBAS…5

EJECUCION Y ANALISIS……………………………………………………………..………6

DOCUMENTACION DE LAS PRUEBAS……………………………………………………..7

IMPORTANCIA DE LA DOCUMENTACIÓN DE SISTEMAS………………………………7

ESTANDARES BÁSICOS DE DOCUMENTACIÓN………………………………………….7

VENTAJAS DE LA ESTANDARIZACION……………………………………………………8

ESTANDARES BÁSICOS DE DOCUMENTACIÓN………………………………………….8

NORMALIZACIÓN…………………………………………………………………………….8

TEORIA GENERAL DE LOS MANUALES DE DOCUMENTACIÓN………………………8

MANUAL ADMINISTRATIVO………………………………………………………………..9

CONTENIDO DEL MANUAL…………………………………………………………………9

RESUMEN ADMINISTRATIVO………………………………………………………………9

PLANTEAMIENTO……………………………………………………………………………10

OBJETIVOS DEL SISTEMA…………………………………………………………………..10

ENTRADAS DEL SISTEMA (INFORMACIÓN A CAPTAR)……………………………….10

SALIDAS DEL SISTEMA (RESULTADOS A OBTENER)………………………………….10

DIAGRAMACION GENERAL DEL SISTEMA………………………………………………11

REQUERIMIENTOS DEL SISTEMA………………………………………………………….11

ESTIMACIÓN DE LA FECHA PROBABLE DE IMPLEMENTACION DEL SISTEMA……11

CONSIDERACIONES GENERALES DEL NUEVO SISTEMA……………………………....11

MANUAL DE USUARIO……………………………………………………………………….11

OBJETIVOS DEL MANUAL DE USUARIO…..………………………………………………12

MANUAL DE OPERACIÓN…………………………………………………………………....12

GENERALIZANDO……………………………………………………………………………..12

CICLO DE VIDA DE PRUEBAS DE SOFTWARE……………………………………………13

CONCLUSIONES……………………………………………………………………………….14

REFERENCIA BIBLIOGRAFICA……………………………………………………………...15

GESTION DE PRUEBAS DE SOFTWARE

La gestión de evidencia es una parte importante del proceso general de aceptación y licencia, que respalda el ciclo de vida de la evidencia (diseño, recopilación, verificación, activación, corrección y uso compartido) durante la reutilización en múltiples programas.

La planificación emprendida estará influenciada por la política de pruebas de la organización, los resultados que esperamos lograr, la disponibilidad de recursos y las limitaciones de tiempo y costo con las que operamos. Sí son precisamente estas limitaciones de tiempo y presupuesto las que nos llevarán a tomar decisiones sobre qué testear, ya que es imposible testear todo.

Para facilitar estas decisiones, también tendremos que tener en cuenta los riesgos, que son eventos inciertos, es decir, no sabemos si sucederán o no y cuáles tendrán un impacto en el proyecto. Este efecto puede ser positivo o negativo y puede afectar el alcance, la duración y el costo del proyecto.

Para evitar la formación de un riesgo que lleve al fracaso del proyecto de prueba, es necesario durante la fase de diseño realizar un análisis de riesgo detallado en el que puedan ocurrir todos los eventos “imprevistos”. Puede surgir durante el mismo período en estudio. También necesitamos crear:

a) Un plan de contingencia con las acciones a realizar si el evento se produce

b) Un plan de mitigación con las acciones a realizar para disminuir la probabilidad de ocurrencia del evento o para que su impacto sea lo menor posible.

PLAN DE PRUEBAS

Los procesos de aseguramiento de la calidad de un producto de software generalmente se dividen según su componente analítico en pruebas estáticas y pruebas dinámicas. La principal diferencia entre este tipo de pruebas es que las pruebas estáticas se enfocan en evaluar la calidad con la que se produce la documentación del proyecto, a través de revisiones periódicas, mientras que las pruebas dinámicas requieren de un software para medir el nivel de calidad con el que están codificadas.

PASOS PARA ELABORAR EL PLAN DE PRUEBAS

1. Identificar las funcionalidades nuevas a probar

2. Basado en documentos de análisis de requisitos y entrevistas con el equipo de ingeniería y desarrollo de requisitos

3. La lista de características debe determinarse e incluirse en el plan de prueba del software.

4. Si se está trabajando con un nuevo sistema informático, no tendrá ningún problema.

En el caso de integrar el desarrollo de software en un sistema existente, es esencial que los analistas de negocios y también los ingenieros de software consideren las funciones que forman parte del software de desarrollo, en todos los niveles de la arquitectura, para determinar cuáles deben probarse.

Existen dos situaciones que se puede encontrar al identificar estas funcionalidades:

- Funcionalidades modificadas de cara al usuario: Por ejemplo, si una funcionalidad está siendo modificada agregando más pantallas o cambios a su flujo de proceso, debe ser incluida en el plan de pruebas de software.

- Funcionalidades modificadas en sus componentes internos: Son funcionalidades no modificadas de cara al usuario, manteniendo la misma interfaz gráfica y flujo de procesos, sin embargo, si se modifican componentes internos que comparten con otras funcionalidades del sistema, en las capas de lógica de negocio o acceso a datos. Estas deben incluirse en el plan de pruebas de software para determinar a partir de ellas pruebas de regresión a realizar.

Definir la estrategia de pruebas, Consiste básicamente en seleccionar cuáles son los tipos de pruebas de software que se deben realizar.

DEFINIR LOS CRITERIOS DE INICIO, ACEPTACIÓN Y SUSPENSIÓN DE PRUEBAS

1. CRITERIOS DE ACEPTACIÓN O RECHAZO: Para determinar los criterios de aceptación o rechazo, en donde, se debe determinar el nivel de tolerancia por defectos de calidad, en caso de que la tolerancia a fallas es muy baja, entonces el 100% de los casos de prueba pueden considerarse libres de accidentes como criterio de aceptación. Lograr este margen en todas las principales situaciones de competencia y prueba será difícil y podría poner en peligro los plazos del proyecto (aumentando el riesgo), pero garantiza la calidad del producto.

Por otro lado, quizás el objetivo sea crear un lanzamiento inicial o producto con la menor rentabilidad, en cuyo caso los criterios de aceptación pueden definirse como el 100% de los casos de prueba principales (considerados básicos) y el 20% de los no centrales casos de prueba (los casos extremos), por consiguiente al cumplir las condiciones, se aceptarán el desarrollo y las pruebas de software.

2. CRITERIOS DE INICIO O REANUDACIÓN: Definen las condiciones que deben cumplirse para dar inicio o reanudar las pruebas. Por ejemplo, en el caso de inicio la condición podría ser la instalación de los componentes de software en el ambiente y que los casos de pruebas de verificación de ambiente sean exitosos.

3. CRITERIOS DE SUSPENSIÓN: Los términos dependerán de los acuerdos de nivel de servicio (SLA) internos de la organización, así como de los establecidos en proyectos individuales. Por ejemplo, si tiene un equipo de prueba que comparte sus esfuerzos en varios proyectos, puede definir criterios estrictos de apagado, donde un determinado porcentaje de fallas conduce a un accidente. Si se cumple la condición, se detendrán las pruebas y los empleados se dedicarán a otras actividades.

Un proceso de pruebas formal, está compuesto, cuando menos por las siguientes 5 típicas etapas:

1. Planeación de pruebas.

2. Diseño de pruebas.

3. implementación de pruebas.

4. Evaluación de criterios de salida.

5. Cierre del proceso.

EJECUCION Y ANALISIS

Esta es la etapa en la que se realizan las primeras actividades correspondientes al proceso de pruebas y que dan lugar

...