Repblica Bolivariana de Venezuela

Ministerio del Poder Popular Para la Educacin Universitaria

Universidad Territorial Deltaica Francisco Tamayo
Tucupita, Estado Delta Amacuro

Fundamentos del Proceso de

Pruebas

Profesor(a): Integrantes:
Irangelys Silva Bernardo Lozada C.I.N 24118098
Crismaris Rojas C.I.N 25.38.697
Jos Brito C.I.N 25.398.415
Luis Rangel C.I.N 18.385.570

Tucupita, Noviembre del 2017

 ndice

Pg.

Introduccin

Que son las pruebas de Software?.................................................................... 04

Concepto del Proceso de pruebas 04

Principios del proceso de pruebas 06

Las pruebas y el proceso de desarrollo de software. 08

Participantes en el proceso de pruebas: actores y roles. 12

Conclusin 13

Bibliografa.. 14

2
 Introduccin

En Ingeniera del Software, un modelo de proceso de desarrollo de software puede verse como una
manera de dividir el trabajo en distintas actividades (o el ciclo de vida del producto en distintas
fases) con la intencin de lograr la mejor gestin y el mejor resultado para el proyecto. Estos
modelos pueden incluir la definicin previa de entregables especficos y otros artefactos que son
creados y completados por el equipo para disear, codificar, probar y mantener el software en
cuestin.

3
Que son las pruebas de Software?

Las pruebas de software consisten en la dinmica de la verificacin del comportamiento de

un programa en un conjunto finito de casos de prueba, debidamente seleccionados de por
lo general infinitas ejecuciones de dominio, contra la del comportamiento esperado. Son
una serie de actividades que se realizan con el propsito de encontrar los posibles fallos de
implementacin, calidad o usabilidad de un programa u ordenador; probando el
comportamiento del mismo.

Objetivos de las pruebas de software.

La prueba de software es un elemento crtico para la garanta del correcto funcionamiento

del software. Entre sus objetivos estn:

Detectar defectos en el software.

Verificar la integracin adecuada de los componentes.
Verificar que todos los requisitos se han implementado correctamente.
Identificar y asegurar que los defectos encontrados se han corregido antes de
entregar el software al cliente.
Disear casos de prueba que sistemticamente saquen a la luz diferentes clases de
errores, hacindolo con la menor cantidad de tiempo y esfuerzo.

Concepto del Proceso de pruebas

Pruebas: Las pruebas de software (en ingls software testing) son las investigaciones
empricas y tcnicas cuyo objetivo es proporcionar informacin objetiva e independiente
sobre la calidad del producto a la parte interesada o stakeholder. Es una actividad ms en
el proceso de control de calidad.

Defecto: Un defecto en el software como, por ejemplo, un proceso, una definicin

de datos o un paso de procesamiento incorrectos en un programa.

Falla: La incapacidad de un sistema o de alguno de sus componentes para realizar

las funciones requeridas dentro de los requisitos de rendimiento especificados

4
Error: La diferencia entre un valor calculado, observado o medio y el valor verdadero,
especificado o tericamente correcto.

Verificacin: El proceso de evaluacin de un sistema o de uno de sus

componentes para determinar si los productos de una fase dada satisfacen las condiciones
impuestas al comienzo de dicha fase:

Construir el sistema correctamente.

Descubrir y corregir errores en el Sistema desarrollado.
Tipos: esttica y dinmica.
Criterios a verificar:
Consistencia: vigilar que la informacin sea coherente.
Precisin: correccin de la sintaxis. Errores morfolgicos.
Completitud: lagunas en capacidad deductiva.
Identifica desviaciones con estndares y requerimientos.
Recolecta datos para mejorar el proceso (es opcional).
Verifica que el producto cumpla:
Cumplan con los requerimientos.
Cumplan con los atributos de calidad.
Se ajuste a las regulaciones, estndares y procedimientos definidos.

Validacin: El proceso de evaluacin 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.

Construir el sistema correcto.

Actividad viva no sobre el papel.
Segn ANSI/IEEE evaluar la conformidad con la especificacin de requisitos

5
Principios del proceso de pruebas.

En el proceso de Ingeniera de Software, existen, dependiendo la metodologa de desarrollo

utilizada (SCRUM, RUP, etc.), una serie de etapas claramente identificadas en el proceso,
tales como: anlisis diseo, implementacin, pruebas, etc. Sin embargo, por algunas
razones que no vale la pena discutir en este apartado, es la etapa correspondiente
al proceso de pruebas de un producto, a la que las firmas desarrolladoras menos tiempo
de planeacin asignan y a la que menos recursos comprometen en sus respectivos planes
de trabajo. En muchos casos incluso, las fbricas de software, suelen acudir a una mala
prctica en donde involucran personal de desarrollo, para ejecutar actividades de pruebas,
sin tener en cuenta que estas personas, debido al rol que asumen dentro del proceso, de
manera involuntaria protegern el estado de su producto, muchas veces minimizando la
criticidad de los fallos encontrados, sesgando de esta manera el grado real de calidad del
producto. Por esta y muchas razones ms, es altamente aconsejable, que esta etapa de
pruebas sea ejecutada por un equipo ajeno a los procesos de desarrollo o en el mejor de
los casos por un tercero especializado en el aseguramiento de la calidad del software.

1. Las pruebas exhaustivas no son viables: para proyectos cuyo nmero de casos de
uso o historias de usuario desarrolladas sea considerable, se requerira de
una inversin muy alta en cuanto a tiempo y recursos necesarios para cubrir
pruebas sobre todas las funcionalidades del sistema; por esta razn, es conveniente
realizar un anlisis de riesgos de todas las funcionalidades del aplicativo y
determinar en este punto cuales sern objeto de prueba y cules no.

Naturalmente, ninguna funcionalidad que haga parte del ciclo de negocio del
aplicativo debe quedar por fuera de esta revisin. Por otra parte, es necesario evitar
para el caso de funcionalidades complejas, escribir (n) casos de prueba, que cubran
todas las posibles combinaciones de entrada y salida que puede llegar a tener las
funcionalidades. Disear casos de prueba bajo estas condiciones, solo es justificable
cuando la funcionalidad objeto de prueba tiene una complejidad trivial. Por las

6
 razones ya mencionadas, es altamente sugerible disear y ejecutar pruebas de
muestra, las cuales sean elegidas bajo criterios de experiencia y/o aleatoriedad.

2. El proceso no puede demostrar la ausencia de defectos: independientemente de la

rigurosidad con la que se haya planeado el proceso de pruebas de un producto,
nunca ser posible garantizar al ejecutar este proceso, la ausencia total de defectos
de un producto en su paso a produccin, debido entre otras cosas, al principio no.
1, en el cual no se permite escribir y ejecutar casos de prueba de manera exhaustiva.
Por lo anterior, un proceso de pruebas planeado, puede garantizar
una reduccin significativa de los posibles fallos y/o defectos del software, pero
nunca podr garantizar que el software no fallar en su ambiente de produccin.
3. Inicio temprano de pruebas: es tpico ver como algunas firmas de desarrollo, ven el
proceso de pruebas como una serie de actividades que se dan de manera aislada y
solo hasta el momento en el que se tiene una relase de pruebas del producto, el
equipo de pruebas se incorpora a ejecutar las respectivas actividades; aunque sea
vlido, lo recomendable es que las actividades de pruebas se ejecuten de manera
paralela con cada una de las etapas del proceso. Las actividades de un proceso de
pruebas, deben ser incorporadas incluso desde el mismo momento en el que
se ejecutan las etapas de anlisis y diseo, por esta razn, documentos
de especificacin y de diseo, deben ser sometidos a revisiones, lo que ayudar a
detectar problemas en la lgica del negocio mucho antes de que se escriba una sola
lnea de cdigo. En conclusin, cuanto ms temprano se detecte un defecto bien
sea sobre los entregables de especificacin y diseo o sobre el producto, menos
costoso ser para el equipo del proyecto dar solucin a dichos incidentes.
4. Las pruebas no garantizan la calidad del Software: si bien las pruebas del Software
ayudan a mejorar la calidad de un producto, esto no es totalmente garantizable, si
estas actividades no son incorporadas desde etapas tempranas del proyecto. Este
nivel de calidad no ser garantizado, entre otros aspectos, porque existe la
posibilidad de que algunas funcionalidades del software pueden no suplir las
necesidades y expectativas de los usuarios finales a los cuales va dirigido el

7
 desarrollo, as el comportamiento del software sea correcto y responda fielmente a
lo que fue especificado. Una buena prctica que ayuda a mitigar el riesgo de que el
usuario final no est satisfecho con el producto, es involucrarlo desde instancias
tempranas en el proceso y tener en cuenta sus apreciaciones para generar una
retroalimentacin a tiempo.
5. Ejecucin de pruebas bajo diferentes condiciones: en un plan de pruebas, siempre
existe un apartado relacionado con la estrategia a utilizar por parte del equipo de
pruebas, en este tem, se define entre otros aspectos, el nmero de ciclos de prueba
que se ejecutarn sobre las funcionalidades del negocio. La idea consiste, en que
por cada ciclo de prueba ejecutado, se generen diferentes tipos de condiciones,
basados principalmente en la variabilidad de los datos de entrada y set de datos
utilizados. No es conveniente, ejecutar en cada ciclo, los casos de prueba basados
en los mismos datos del ciclo anterior, dado que con seguridad, se obtendrn los
mismos resultados. En conclusin, ejecutar ciclos bajo diferentes tipos de
condiciones, permitir identificar posibles fallos en el sistema, que antes no
eran fcilmente reproducibles.

Las pruebas y el proceso de desarrollo de software.

Pruebas como proceso

La prueba es un proceso que se enfoca sobre la lgica interna del software y las funciones
externas. Es un proceso de ejecucin de un programa con la intencin de descubrir un error,
no puede asegurar la ausencia de defectos; slo puede demostrar que existen defectos en
el software.

Fases del proceso

Todos los modelos de procesos estn compuestos en su mayora por distintas fases que
varan, aunque ligeramente, de modelo en modelo.

Fase de definicin

Planificacin del proyecto de desarrollo software.

8
 Ingeniera de requisitos / Extraccin de informacin.
Anlisis (estudio) de esos requisitos.
Fase de desarrollo.
Diseo del software.
Generacin del cdigo.
Pruebas del software.

Fase de mantenimiento

Correccin de errores y reajustes que a veces provienen de nuevos requisitos e implican

repetir las actividades de fases anteriores

Modelo en cascada

El modelo en cascada es un enfoque secuencial de desarrollo en el cual el trabajo fluye de

manera secuencial ("como una cascada") a travs de las distintas fases:

Especificacin de requisitos.
Diseo de software.
Implementacin.
Pruebas.
Integracin.
Despliegue.
Mantenimiento.

El modelo en cascada es un enfoque, casi utpico, de la Ingeniera tradicional aplicado a la

Ingeniera de Software. Un modelo en cascada estricto desaprueba la revisin y repeticin
de etapas anterior una vez estas se han completado. Sin embargo existe un enfoque ms
flexible (realista) que permite realizar arreglos y cambios en etapas ya completadas e
incluso solapar actividades de fases consecutivas para evitar la rigidez del flujo de trabajo.

Desarrollo mediante prototipos

9
Este es un enfoque del desarrollo de software que se basa en la creacin de prototipos
(software con funcionalidad parcial, incompleta). Se suele usar como parte de otros
modelos de proceso ms tradicionales.

Los principios bsicos son:

Reducir los riesgos inherentes del proyecto estableciendo el desarrollo en fragmentos ms

pequeos y logrando, en un entorno propenso a cambios, que estos tengan menor impacto.

El usuario involucrado durante el desarrollo (probando prototipos) incrementa la

aceptacin de la implementacin del producto final.

Pequeos prototipos con modificaciones son mostrados al cliente y sirve para confirmar
que se han comprendido sus requisitos.

Muchos de los prototipos se generan con la expectativa de ser descartados, sin embargo,
en algunos casos el prototipo puede evolucionar y convertirse en el producto final.

Es necesario un entendimiento fundamental de los problemas del negocio para evitar

resolver los problemas incorrectos, despilfarrando esfuerzo al desarrollar prototipos que
son prescindibles.

Desarrollo en espiral

En 1988, se realiza la presentacin formal del modelo en espiral por Barry Boehm que
combina los aspectos claves del modelo en cascada y la rpida metodologia de prototipo
en un esfuerzo por combinar las ventajas de ambos modelos. Hace nfasis en el rea clave
en la que han fallado otros modelos: no llevar un anlisis de riesgo iterativo, especialmente
adecuado para sistemas complejos a gran escala.

Los principios bsicos son:

Se enfoca en la evaluacin y minimizacin de los riesgos del proyecto al dividirlo en

segmentos ms pequeos y proporcionar ms facilidad de cambio durante el proceso de
desarrollo, as como proporcionar la oportunidad de evaluar los riesgos y ponderar las
actividades de la continuacin del proyecto durante todo el ciclo de vida.

10
Cada ciclo implica una progresin a travs de la misma secuencia de pasos, para cada parte
del producto y para cada uno de sus niveles de elaboracin, desde un documento general
de operacin hasta el cdigo de cada programa individual.

Cada vuelta del ciclo atraviesa 4 cuadrantes bsicos:

Cuadrante 1: Determinar objetivos, alternativas y restricciones de la iteracin

Cuadrante 2: Evaluar alternativas, identificar y resolver riesgos

Cuadrante 3: Desarrollar y verificar entregables de la iteracin

Cuadrante 4: Planificacin de la siguiente iteracin

Cada ciclo comienza con la identificacin de las condiciones de xito por parte de los dueos
del producto y concluyen con una revisin y compromiso.

Desarrollo gil

Son mtodos que ponen el nfasis en agilizar el desarrollo, cuidando ms la interaccin

auto-organizada entre personas y la entrega de software funcionando que la elaboracin
de documentacin o el seguimiento estricto de protocolos y procesos de actuacin. Algunos
mtodos giles de desarrollo de software:

Adaptive Software Development (ASD).

Agile Unified Process (AUP).
Crystal Clear.
Feature Driven Development (FDD).
Lean Software Development (LSD).
Kanban.
Open Unified Process (OpenUP).
Programacin Extrema (XP).
Mtodo de desarrollo de sistemas dinmicos (DSDM).
Scrum

11
Participantes en el proceso de pruebas: actores y roles.

Existen diferentes roles que participan en un proyecto de pruebas. Una persona puede
asumir ms de un rol en un proyecto y tomar diferentes roles en proyectos distintos.

En general se va creciendo en conocimiento y experiencia a medida que se es capaz de

asumir diferentes roles. Se identifican tres tipos de roles dentro de un equipo de testing:
Tester de Software, Lder de Testing de Software y Consultor.

Tester de software. En el amplio sentido de la palabra, es quien disea, ejecuta e informa

el resultado de las pruebas sobre un producto de software. Los testers integran el equipo
de pruebas e interactan con el equipo de desarrollo y la gerencia de proyectos.

Lder de testing de software. El Lder de un proyecto de pruebas tiene conocimiento y

experiencia en el diseo, ejecucin y reporte de pruebas sobre un producto de software,
pero tambin es capaz de estimar, planificar y dar seguimiento a un proyecto de pruebas.

Consultor. Es un rol adecuado para aquellas personas capaces de dirigir un equipo de

pruebas y orientar sobre mejores prcticas en testing.

12
 Conclusin

El desarrollo de software es uno de los pilares fundamentales de la Informtica y al cual se

dedican muchas horas de esfuerzos en universidades, centros de investigacin y empresas
de todos los tamaos.

Conforme la tecnologa va avanzando, van apareciendo nuevas soluciones, nuevas formas

de programacin, nuevos lenguajes, y un sin fin de herramientas que intentan realizar el
trabajo del desarrollador un poco mas fcil. Tambin surgen nuevos modelos de proceso de
desarrollo y nuevas metodologas que tratan de adaptar la manera de trabajar a las
necesidades concretas de una organizacin y de sus proyectos. Es importante conocer bien
estos modelos, para tener un esquema mental que nos permita gestionar proyectos y
organizar equipos de manera racional, cuando abordemos el desarrollo de software,
especialmente en el caso de aplicaciones grandes y complejas.

13
 Bibliografa

https://prezi.com/ohqn3xfymyna/conceptos-proceso-de-pruebas/

https://www.ecured.cu/Pruebas_de_software

http://clases3gingsof.wikifoundry.com/page/Verificaci%C3%B3n+y+Validaci%C3%B3n

https://pruebasdelsoftware.wordpress.com/2013/01/07/principios-fundamentales-del-
proceso-de-pruebas/

https://es.wikiversity.org/wiki/Procesos_de_desarrollo_software

http://webdelprofesor.ula.ve/ingenieria/gbriceno/presentacion%2008-2-2008.pdf

14