República Bolivariana de Venezuela

Ministerio del Poder Popular para la Educación Universitaria

Universidad Politécnica Territorial del Estado Portuguesa “Juan de Jesús Montilla”
Programa Nacional de Formación en Informática
Guanare, Estado Portuguesa

LAS PRUEBAS Y EL PROCESO

DE DESARROLLO DE SOFTWARE

Integrantes:

Durán Génesis C.I 25.912.595

García Alix C.I 22.091.840
Noguera Nesyuri C.I 26.300.000
PNFI: 631

Guanare, Abril 2019

 LAS PRUEBAS DE SOFTWARE

Las pruebas de software son las investigaciones empíricas y técnicas cuyo objetivo
es proporcionar información objetiva e independiente sobre la calidad del producto a
la parte interesada. Es una actividad más en el proceso de control de calidad.

Las pruebas son básicamente un conjunto de actividades dentro del desarrollo

de software. Dependiendo del tipo de pruebas, estas actividades podrán ser
implementadas en cualquier momento de dicho proceso de desarrollo. Existen distintos
modelos de desarrollo de software, así como modelos de pruebas. A cada uno
corresponde un nivel distinto de involucramiento en las actividades de desarrollo.

- Objetivos de las pruebas de software.

El objetivo de las pruebas es presentar información sobre la calidad del producto a

las personas responsables de éste. Las pruebas de calidad presentan los siguientes
objetivos:

o Encontrar defectos o bugs.

o Aumentar la confianza en el nivel de calidad.
o Facilitar información para la toma de decisiones.
o Evitar la aparición de defectos.

Proceso de desarrollo de software.

El proceso para el desarrollo de software, también denominado ciclo de vida del

desarrollo de software es una estructura aplicada al desarrollo de un producto
de software. Hay varios modelos a seguir para el establecimiento de un proceso para el
desarrollo de software, cada uno de los cuales describe un enfoque diferente para
diferentes actividades que tienen lugar durante el proceso.

Tenemos el proceso de desarrollo en Cascada, se denomina de este modo, ya que

a cada salida de una etapa cae en la siguiente, es decir, las etapas se llevan a cabo
una a continuación de la otra. Una de las peculiaridades de este proceso, es que no
está previsto volver a una etapa anterior, es decir si se olvidó relevar algún
requerimiento al comienzo, no tiene una alternativa para considerar este caso. Este
proceso supone cada etapa independiente de las etapas anteriores.

También tenemos el proceso Incremental, se tiene las mismas etapas que en el

Proceso de Desarrollo en Cascada, sin embargo, en este proceso, la etapa de
relevamiento se divide en distintos sub conjuntos, y cada uno de estos sub conjuntos se
construye de la misma forma que con el ciclo de vida en cascada. Se van desarrollando
por partes que luego se integran, una vez finalizadas las mismas.

Otro Proceso de Desarrollo que tenemos es el Iterativo, en este tenemos las

mismas etapas de desarrollo que los procesos anteriores, pero trabajamos sobre el
todo, no necesariamente conocemos el comienzo todos los detalles del producto que
queremos construir.

- Modelo de cascada
También llamado secuencial o ciclo de vida de un programa (denominado así por la
posición de las fases en el desarrollo de esta, que parecen caer en cascada hacia las
siguientes fases), es el enfoque metodológico que ordena rigurosamente las etapas
del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe
esperar a la finalización de la etapa anterior. Al final de cada etapa, el modelo está
diseñado para llevar a cabo una revisión final, que se encarga de determinar si el
proyecto está listo para avanzar a la siguiente fase. Este modelo fue el primero en
originarse y es la base de todos los demás modelos de ciclo de vida.

Un ejemplo de una metodología de desarrollo en cascada es:

1. Análisis de requisitos.
2. Diseño del sistema.
3. Diseño del programa.
4. Codificación.
5. Pruebas.
6. Implementación o verificación del programa.
7. Mantenimiento.
 1. Análisis de requisitos del software.
En esta fase se analizan las necesidades de los usuarios finales del software para
determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD
(documento de especificación de requisitos), que contiene la especificación completa de
lo que debe hacer el sistema sin entrar en detalles internos.

Es importante señalar que en esta etapa se debe consensuar todo lo que se

requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no
pudiéndose requerir nuevos resultados a mitad del proceso de elaboración
del software de una manera.

2. Diseño del sistema.

Descompone y organiza el sistema en elementos que puedan elaborarse por

separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el
SDD (Documento de Diseño del Software), que contiene la descripción de la estructura
relacional global del sistema y la especificación de lo que debe hacer cada una de sus
partes, así como la manera en que se combinan unas con otras.

Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño

detallado. El primero de ellos tiene como objetivo definir la estructura de la solución
(una vez que la fase de análisis ha descrito el problema) identificando grandes módulos
(conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define
la arquitectura de la solución elegida. El segundo define los algoritmos empleados y la
organización del código para comenzar la implementación.

3. Diseño del programa.

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de

los requerimientos del usuario así como también los análisis necesarios para saber qué
herramientas usar en la etapa de Codificación.

4. Codificación.

Es la fase en donde se implementa el código fuente, haciendo uso de prototipos así

como de pruebas y ensayos para corregir errores. Dependiendo del lenguaje de
programación y su versión se crean las bibliotecas y componentes reutilizables dentro
del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.

5. Pruebas.

Los elementos, ya programados, se ensamblan para componer el sistema y se

comprueba que funciona correctamente. Se buscan sistemáticamente y se corrigen
todos los errores antes de ser entregado al usuario final.

6. Implementación o verificación del programa.

Es la fase en donde el usuario final o el cliente ejecutan el sistema, y se asegura

que cubra sus necesidades.

7. Mantenimiento.

Una de las etapas más críticas, ya que se destina un 75 % de los recursos, es el

mantenimiento del software ya que al utilizarlo como usuario final puede ser que no
cumpla con todas nuestras expectativas.

- Pruebas estáticas.

Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación.

Puede referirse a la revisión de documentos, ya que no se hace una ejecución de

código. Esto se debe a que se pueden realizar "pruebas de escritorio" con el objetivo de
seguir los flujos de la aplicación.

- Pruebas dinámicas.

Todas aquellas pruebas que para su ejecución requieren la ejecución de la

aplicación.

Las pruebas dinámicas permiten el uso de técnicas de caja negra y caja blanca con
mayor amplitud. Debido a la naturaleza dinámica de la ejecución de pruebas es posible
medir con mayor precisión el comportamiento de la aplicación desarrollada.
 Proceso de desarrollo en Cascada

Pruebas contra especificación

Antes de entender para que les sirve a los probadores beta trabajar con el
documento de especificación de requerimientos, debemos saber qué son las
especificaciones de requerimientos (ESRE).

Las Especificaciones de Requerimientos son un documento clave en el desarrollo

de Software. Cuando consideramos los ciclos de vida clásicos, tiene la descripción
completa de lo que va a hacer el sistema sin describir cómo lo va a hacer. Estos
documentos tienen una estructura en forma de reporte bastante definida, poseen
carátula, historial de cambios, introducción, definiciones, acrónimos y abreviaturas,
especificación de requerimientos funcionales, especificación de requerimientos no
funcionales y casos de uso.

Los probadores beta se guían en este documento para validar si el sistema se

comporta de la manera que indican las ESRE. Contiene información detallada sobre los
requisitos funcionales y no funcionales que el cliente desea en el sistema. También se
pueden ejecutar casos de pruebas a partir de las especificaciones de requerimientos.
Éstos resultan muy útiles porque son sencillos de seguir y se conocen de antemano los
posibles resultados.

Tipos de pruebas por su ejecución.

o Manuales

Las pruebas funcionales manuales son las que ejecuta un tester como si fuese un
usuario pero siguiendo una serie de pasos establecidos o test plan, diseñado en el
análisis de los requisitos para garantizar que hace lo que debe (casos positivos), que no
falla (casos negativos) y que es lo que se ha solicitado. El tester realizará las acciones
indicadas en cada step del caso de prueba comprobando que se cumple el resultado
esperado. Si el resultado es distinto al esperado, se reportará un defecto con todo
detalle: descripción, datos utilizados, capturas de pantalla, etc. para facilitar la solución
del defecto por parte de los desarrolladores.

o Automáticas

Las pruebas funcionales automáticas son pruebas funcionales que se automatizan

para "ahorrar tiempo de pruebas". A partir de los casos de prueba de las pruebas
manuales, se automatizan los casos de prueba que se repitan en las ejecuciones. Esos
casos suelen ser los más importantes (happy flow) de los módulos o procesos de
negocio "vitales" de la aplicación, es decir, los procesos que siempre tienen que
funcionar y que bajo ningún concepto pueden fallar. El objetivo de las pruebas
funcionales automáticas es comprobar que nada de lo probado con anterioridad ha
dejado de funcionar como debería.

Enfoque de pruebas

o Pruebas de caja blanca

Son pruebas estructurales. Conociendo el código y siguiendo su estructura lógica,

se pueden diseñar pruebas destinadas a comprobar que el código hace correctamente
lo que el diseño de bajo nivel indica y otras que demuestren que no se comporta
adecuadamente ante determinadas situaciones. Ejemplos típicos de ello son las
pruebas unitarias. Se centran en lo que hay codificado o diseñado a bajo nivel por lo
que no es necesario conocer la especificación de requisitos, que por otra parte será
difícil de relacionar con partes diseñadas a muy bajo nivel.

o Las pruebas de caja negra

Son pruebas funcionales. Se parte de los requisitos funcionales, a muy alto nivel,
para diseñar pruebas que se aplican sobre el sistema sin necesidad de conocer como
está construido por dentro (Caja negra). Las pruebas se aplican sobre el sistema
empleando un determinado conjunto de datos de entrada y observando las salidas que
se producen para determinar si la función se está desempeñando correctamente por el
sistema bajo prueba. Las herramientas básicas son observar la funcionalidad y
contrastar con la especificación.

Ejemplos típicos de pruebas de caja negra son la comprobación de valores límite,

pruebas de integridad de la base de datos, pruebas de situaciones de excepción, o
pruebas de rendimiento del sistema. Presentan una limitación en cuanto a que es
prácticamente imposible reproducir todo el espectro por la innumerable cantidad de
combinaciones de entrada posibles, agravada por el desconocimiento de la lógica
interna.