Unidad 1

“ Introducción al proceso de pruebas ”

Documento de la Unidad 1
Para Evaluar el Saber
De la Materia de Evaluación y mejora para el desarrollo del
software

Técnico Superior Universitario

En

Tecnologías de la Información
Área
Desarrollo de Software Multiplataforma

Elaborado por:
Fabian Guadalupe Ibarra Carrizales

Maestro:
M.A.T.I José Luis Flores Leandro

1
 Función del proceso de pruebas en el desarrollo, mantenimiento y
operación de software.

Antes de ver la funciones del del proceso de pruebas en el desarrollo, mantenimiento y operación de
software un pequeño párrafo de:

¿Qué es una prueba?

“La prueba es un proceso de ejecución de un programa con la intención de encontrar errores”.

Función del proceso de pruebas en el desarrollo, mantenimiento y operación de software

A un alto nivel, las pruebas de software son necesarias para detectar los errores en el software y para probar
si el software cumple con los requisitos del cliente. Esto ayuda al equipo de desarrollo a corregir los errores
y entregar un producto de buena calidad.
Hay varios puntos en el proceso de desarrollo de software en los que el error humano puede llevar a un
software que no cumple con los requisitos de los clientes. Algunos de ellos se enumeran a continuación.

• El cliente/persona que proporciona los requisitos en nombre de la organización del cliente puede no
saber exactamente qué es lo que se requiere o puede olvidarse de proporcionar algunos detalles, lo
que puede llevar a que falten características.

• La persona que está recopilando los requisitos puede malinterpretarlos o no cumplirlos por completo
al documentarlos.

• Durante la fase de diseño, si hay problemas en el diseño, esto puede conducir a errores en el futuro.

• Los errores pueden ser introducidos durante la fase de desarrollo durante un error humano, falta de
experiencia, etc.

• Los probadores pueden perder errores durante la fase de prueba debido a errores humanos, falta de
tiempo, experiencia insuficiente, etc.

• Es posible que los clientes no dispongan del ancho de banda necesario para probar todas las
funciones del producto y que liberen el producto a sus usuarios finales, lo que puede dar lugar a que
los usuarios finales encuentren errores en la aplicación.

• El negocio y la reputación de una organización depende de la calidad de sus productos y en algunos

casos incluso los ingresos pueden depender de las ventas de productos de software.
Los usuarios pueden preferir comprar un producto de la competencia en lugar de un producto de baja
calidad, lo que puede resultar en una pérdida de ingresos para la organización. En el mundo actual, la
calidad es una de las principales prioridades de cualquier organización.

1
 Proceso de pruebas y calidad.

El proceso de prueba generalmente implica que el organismo electoral trabaje de manera conjunta con los
proveedores para asegurar que los bienes o servicios son los adecuados para los objetivos establecidos.
Puede ser un proceso corto para los productos estándar, o uno prolongado cuando los productos tienen que
ser diseñados o fabricados para propósitos específicos.

Para la mayoría de los componentes tecnológicos, se debe preparar una estrategia de prueba muy
estructurada y cuidadosa antes de recibir los productos para efectuar las pruebas. La estrategia debe ser
diseñada para probar que el producto ejecuta debidamente todas las funciones requeridas conforme a las
especificaciones.

En particular, sobre todo cuando la tecnología va a ser utilizada en grandes volúmenes o en situaciones de
gran presión que impliquen plazos perentorios o gran cantidad de información a usuarios, la tecnología debe
ser sometida a rigurosas pruebas de carga para asegurar que resiste todas las presiones reales. Dada la
naturaleza de gran presión que implican las elecciones, el proceso de prueba de la tecnología es crucial
para el éxito del proceso electoral.

Entre los pasos que puede comprender la estrategia para probar la nueva tecnología, se pueden considerar
los siguientes:

• Asignar la responsabilidad de las pruebas a un comité técnico apropiado.

• Recibir formalmente el sistema prototipo o la versión para producción.
• Instalar el sistema en un espacio para prueba.
• Realizar las pruebas programadas, tomando debida nota si los componentes reúnen o no las
especificaciones establecidas.
• Integrar un panel de usuarios para probar el sistema en un ejercicio de simulación.
• De ser el caso, incluir usuarios externos en el proceso de prueba.
• Solicitar a los proveedores que corrijan cualquier problema identificado y lo presenten para una nueva
prueba.
• Si la prueba inicial con carga ligera indica que el producto es adecuado, conducir pruebas con carga
pesada simulando hasta donde sea posible la carga esperada bajo condiciones reales.
• Contar con auditores independientes que verifiquen la integridad de las fuentes de origen.
• Ofrecer a los comités técnico y de administración un reporte de las pruebas.
• Una vez que el sistema ha aprobado todas las pruebas y la administración ha dado su visto bueno,
proceder a la implantación.
• Si las pruebas solo han comprendido prototipos o cantidades limitadas del producto, la versión
definitiva necesita ser probada otra vez antes de su instalación, especialmente cuando forma parte
de una red o se encuentra geográficamente disperso.
• Una vez que la versión definitiva ha sido entregada y ha aprobado las pruebas, puede iniciarse la
fase final de la implantación.

Las pruebas de calidad en un Software ERP son todos aquellos procesos cuya ejecución permiten
conocer la calidad del mismo, así como los posibles fallos que puedan existir a corto, medio o largo
plazo. Cuando se realizan pruebas en los software de gestión empresarial es posible predecir su
comportamiento durante la implantación, su grado de manejabilidad y su interfaz gráfica.

2
 Los siete principios para las pruebas.

Principio 1: Las pruebas demuestran la presencia de defectos

Creo que la mayoría de los testers de aplicaciones del “común” podemos decir que aunque hemos
encontrado demasiados hallazgos durante nuestro proceso de pruebas, y aun cuando hemos realizado
varias iteraciones, nunca vamos a decir que el sistema se encuentra al 100% en su calidad de software, y
esto lo decimos es porque no podemos estar seguros de que la aplicación ya no tiene defectos. Y de esto
se trata este principio, el hecho de que realicemos pruebas no quiere decir que se acaben los defectos.
Muchas veces nos hemos encontrado que en Producción siempre sale ese caso atípico que se nos escapó
a todos los integrantes del proyecto, es por esto que las pruebas demuestran la presencia de defectos.

Principio 2: No es posible realizar pruebas exhaustivas

Es muy complicado hacer absolutamente todas las combinaciones de casos posibles para poder probar un
aplicativo, y digo complicado porque tal vez no sea imposible, si eres una súper compañía que tiene el
musculo financiero y quieres invertir una gran cantidad de dinero en calidad, pues bueno, ese será tu caso
pero no el de la mayoría. Normalmente probamos lo más riesgoso o aseguramos cierto porcentaje de calidad
en el software. La generalidad de los testers no probamos absolutamente todo, exceptuando creería yo los
probadores de la NASA o aparatos médicos, donde la vida de las personas se ve en juego, esto ya es un
tema muy delicado que te lleva a pensar que tanto debes invertir en el aseguramiento de la calidad del
software, y no obstante nos encontramos con errores que nadie ha detectado, es por esto que no es posible
realizar pruebas exhaustivas.
Principio 3: Pruebas Tempranas (“Early Testing”)

Las pruebas no solo son sobre el software funcionando, podemos empezar desde mucho antes, desde la
misma documentación, los probadores tenemos una gran capacidad de análisis, buscando todos los
caminos y variantes que se pueden presentar, es por esto que apoyamos mucho con nuestra revisión
temprana a la documentación, también durante el proceso de desarrollo de software. Aquí es donde entra
en parte la experiencia, y es que los probadores podemos generar los casos de pruebas antes del inicio del
desarrollo y allí es donde ahora se ha vuelvo muy importante trabajar con TDD, BDD y ATDD. Por favor
incorpora este principio de pruebas tempranas en todos tus proyectos.

Principio 4: Agrupamiento de Defectos (“Defect Clustering”)

Muchos probadores sabemos que cuando encontramos un defecto, encontraremos muchísimos más
defectos cerca. Por ejemplo, me ha pasado que cuando veo que un mensaje está mal escrito o no tiene la
ortografía correcta, sé que toda la aplicación será sensible a mis revisiones de presentación. También pasa
muchas veces cuando pruebas si un campo de texto valida el tipo de dato o longitud que un usuario ingresa,
cuando vemos que el primer campo “explota” por decirlo de algún modo, lo más probable es que los demás
campos de texto del formulario también “explotarán”. No obstante, recomiendo a mis compañeros
probadores ser flexibles en estos casos, quiero decir, si hemos detectado un defecto en alguna pantalla y
sabemos que existen muchos más, es posible que sea conveniente volver a considerar el rumbo de las
pruebas posteriores, porque no es el objetivo reportar y reportar y llenar a los desarrolladores de hallazgos
o inconsistencias, sino que debemos plantearnos el objetivo de ayudar a construir o generar un software de
calidad con el apoyo de todos. Esto es algo que me gusta mucho del testing ágil.

3
 Principio 5: Paradoja del Pesticida
Si repetimos las mismas pruebas una y otra vez, eventualmente la misma serie de casos de pruebas dejará
de encontrar defectos nuevos. Para superar esta “paradoja del pesticida”, los casos de pruebas deben
revisarse periódicamente y deben escribirse nuevos casos de pruebas y diferentes, con esto podremos
testear distintas partes del software o del sistema con el objetivo de poder detectar más defectos. Si te
quedas repitiendo las mismas pruebas en las mismas condiciones no vas a ser efectivo. Los bugs se
volverán resistentes a ti, es por eso que deberás cambiar tu pesticida (tu forma de testear) constantemente
para poder encontrar nuevos defectos.

Principio 6: Las pruebas dependen del contexto

Este principio me gusta mucho utilizarlo cuando mi cliente me pregunta cuánto tiempo me voy a demorar, y
es que las pruebas dependen del contexto, es decir, no es lo mismo probar un software médico, a una
página web o hasta un carrito de compras. Y sin irnos muy lejos, como es bien sabido, un único aplicativo
dependerá su funcionamiento si está en un ambiente de pruebas a un ambiente de desarrollo. Es p or esto
que todo depende del contexto, no es lo mismo caminar 1 Kilómetro subiendo una montaña rocosa o si es
solo un paso por la playa.

Principio 7: La falacia de la ausencia de errores

Este punto es uno de los más importantes, porque el hecho de pruebas no es solamente detectar y corregir
los defectos, de nada servirá el sistema si no es usable, o si no cumple con las expectativas o las
necesidades de los usuarios finales. Así que por favor nunca digas que por el mero hecho de que el software
que estés probando ya no le encuentres errores quiera decir que todo está bien, porque no nos podemos
olvidar nunca del usuario final, que es lo que quiere, si le sirve la aplicación que se ha construido, y algo
muy personal que deseo añadir, es si cumplimos con la experiencia de usuario que se desea. Recuerda
siempre que no se puede introducir la calidad a través de las pruebas, la calidad tiene que construirse desde
el principio.

Proceso básico: planificación y control, análisis y diseño, implementación

y ejecución, criterios de salida, cierre.

Planificación y Control de Pruebas

La planificación de pruebas es la actividad de definir los objetivos de las pruebas y la especificación de las
actividades de pruebas con vistas a cumplir los objetivos y la misión establecidos.

• Determina el alcance de riegos ,

• Identifica los objetivos y los criterios de salida,
• Determina el enfoque :técnicas de pruebas, coberturas de pruebas, equipo de pruebas,
• Implementa el método de pruebas / estrategia de pruebas.
• Adquirir /obtener y programar recursos requeridos por las pruebas , presupuesto de pruebas.

4
El control de pruebas es la actividad constante de comparar el progreso real con el plan previsto, e informar
sobre el estado de las pruebas, incluyendo la existencia de desviaciones con respecto a lo que se había
planificado. Implica la adopción de las medidas necesarias para cumplir la misión y los objetivos del
proyecto. A efectos del control de pruebas, las actividades de pruebas deben monitorizarse a lo largo del
proyecto. La planificación de pruebas tiene en cuenta el feedback de las actividades de co ntrol y
seguimiento.

Análisis y diseño de pruebas

El análisis y el diseño de pruebas es la actividad durante la cual los objetivos de las pruebas generales se
transportan en condiciones de prueba y casos de prueba tangibles.

La actividad de análisis y diseño de pruebas consta de las siguientes tareas principales:

1. Revisar la base de pruebas 1 ( especificación de requisitos,el nivel de integridad del software es decir;
nivel de riesgo, informes de análisis de riesgos, arquitectura, el diseño y las especificaciones de
interfaz).
2. Evaluar las testabilidad de la base de prueba y de los objetos de prueba.
3. Identificar y priorizar las condiciones de prueba en base al análisis de los elementos de prueba, la
especificación, el comportamiento y la estructura del software.
4. Diseñar y priorizar los casos de prueba de alto nivel.
5. Identificar los datos de prueba necesarios para soportar las condiciones de prueba y los casos de
prueba.
6. Diseñar la configuración del entorno de pruebas e identificar cualquier infraestructura y herramientas
necesarias.
7. Crear una trazabilidad bidireccional entre la base de pruebas y los casos de prueba.

Implementación y ejecución de pruebas

La implementación y ejecución de pruebas es la actividad en la que se especifican los procedimientos o

guiones de prueba mediante la combinación de los casos de prueba en un orden determinado y la inclusión
de cualquier otra información necesaria para la ejecución de las pruebas, se configura el entorno y se
ejecutan las pruebas.

5
La implementación y ejecución de pruebas incluye las siguientes tareas principales:

• Finalizar , implementar y priorizar los casos de prueba (incluyendo la identificación de los datos de
prueba).
• Desarrollar y priorizar procedimientos de prueba, crear datos de prueba y, de manera opcional,
preparar arneses de pruebas y redactar guiones de pruebas automatizados.
• Crear juegos de pruebas a partir de los procedimientos de prueba para lograr una ejecución de
pruebas eficiente.
• Verificar que el entorno de pruebas ha sido correctamente configurado.
• Verificar y actualizar una trazabilidad bidireccional entre la base de pruebas y los casos de prueba.
• Ejecutar los procedimientos de prueba manualmente o recurriendo a herramientas de ejecución de
pruebas, conforme a la secuencia prevista.
• Registrar los resultados de la ejecución de las pruebas y registrar las identidades y las versiones del
software probado, así como, las herramientas de prueba y los productos de soporte de pruebas.
• Comparar los resultados reales con los resultados esperados.
• Reportar las discrepancias en forma de incidencias y analizar con vistas a establecer sus causas
(ejemplo, un defecto en el código o en los datos de pruebas especificados o en el documento de
prueba, o un error en la forma en que se ha ejecutado la prueba).
• Repetir las actividades de pruebas como resultado de una medida adoptada para cada discrepancia,
por ejemplo, la repetición de una prueba que ha fallado anteriormente con vistas a confirmar que su
corrección (pruebas de confirmación), la ejecución de una prueba corregida y/o la ejecución de
pruebas con vistas a garantizar que los defectos no se han introducido en áreas no modificadas del
software o que la subsanación del defecto no ha revelado la existencia de otros defectos (pruebas de
regresión).

Criterios de salida e informes

La evaluación de los criterios de salida es la actividad que evalúa la ejecución de pruebas contra los objetivos
definidos. Esta evaluación debería hacerse para cada nivel de prueba.

1. Los criterios de de salida consta de las siguientes tareas principales:

2. Comprobar los registros de pruebas con los criterios de salida previstos en la planificaicón de la
prueba.
3. Evaluar si se requieren más pruebas o si deberían modificarse los criterios de salida especificados.
4. Elaborar un resumen de las pruebas para las partes interesadas.

6
 Cierre de pruebas
Durante la fase de cierre de pruebas de un proceso se recopilan los datos e aquellas actividades de pruebas
finalizadas con el objetivo de consolidar la experiencia, los productos de soporte de pruebas, los hechos y
las cifras. Las actividades de cierre de pruebas tienen lugar en los hitos del proyecto, tales como el
lanzamiento de un sistema de software, la finalización (o anulación) de un proyecto de pruebas, la
consecución de un hito, o la finalización de una versión de mantenimiento.

Las actividades de cierre de pruebas incluyen las siguientes tareas principales:

• Comprobar cuáles de los productos entregables previstos han sido efectivamente entregados.
• Cerrar los informes de incidencias o aportar modificaciones a aquellos que siguen abiertos.
• Documentar la aceptación del sistema.
• Finalizar y archivar los productos de soporte de prueba, el entorno de pruebas y la infraestructura de
pruebas para su posterior uso.
• Entregar los productos de soporte de prueba a la organización de mantenimiento.
• Analizar las lecciones aprendidas para determinar los cambios necesarios en futuras versiones y
proyectos.
• Utilizar la información recopilada para mejorar la madurez de las pruebas.

7
Mapas conceptuales

1
2
3
4