Qu es mantenimiento?

En trminos generales por mantenimiento se designa al conjunto de acciones que tienen como
objetivo mantener un artculo o restaurarlo a un estado en el cual el mismo pueda desplegar la funcin
requerida o las que vena desplegando hasta el momento en que se da, en caso que haya sufrido
alguna rotura que hizo que necesite del pertinente mantenimiento y arreglo.
La accin de mantenimiento, de restauracin normalmente no solamente implica acciones de tipo
tcnico sino tambin administrativas.
En tanto, a instancias del mundo de las telecomunicaciones y de la ingeniera, el trmino de
mantenimiento ostenta varias referencias, entre ellas: comprobaciones, mediciones, reemplazos,
ajustes y reparaciones que resulten de vital importancia para mantener o reparar una unidad funcional
de manera que esta pueda cumplir sus funciones pertinentes, aquellas acciones, como ser de
inspeccin, comprobacin, clasificacin o reparacin, para mantener materiales en una condicin
adecuada o los procesos para lograr esta condicin, acciones de provisin y reparacin necesarias
para que un elemento contine cumpliendo el cometido para el cual est destinado o fue creado y las
rutinas recurrentes y necesarias para mantener en buen estado y funcionamiento las instalaciones
(plantas industriales, edificios, propiedades inmobiliarias).
Tipos de mantenimiento
En las operaciones de mantenimiento podemos diferenciar las siguientes definiciones:
1. Mantenimiento de conservacin: es el destinado a compensar el deterioro sufrido por el uso,
los agentes meteorolgicos u otras causas. En el mantenimiento de conservacin pueden
diferenciarse:
1. Mantenimiento correctivo: que corrige los defectos o averas observados.
1. Mantenimiento correctivo inmediato: es el que se realiza inmediatamente de
percibir la avera y defecto, con los medios disponibles, destinados a ese fin.
2. Mantenimiento correctivo diferido: al producirse la avera o defecto, se
produce un paro de la instalacin o equipamiento de que se trate, para
posteriormente afrontar la reparacin, solicitndose los medios para ese fin.
2. Mantenimiento preventivo: como el destinado a garantizar la fiabilidad de equipos en
funcionamiento antes de que pueda producirse un accidente o avera por deterioro. En el
mantenimiento preventivo podemos ver:
1. Mantenimiento programado: como el que se realiza por programa de
revisiones, por tiempo de funcionamiento, kilometraje, etc.
2. Mantenimiento predictivo: que realiza las intervenciones prediciendo el
momento que el equipo quedara fuera de servicio mediante un seguimiento de su
funcionamiento determinando su evolucin, y por tanto el momento en el que las
reparaciones deben efectuarse.
3. Mantenimiento de oportunidad: que es el que aprovecha las paradas o periodos
de no uso de los equipos para realizar las operaciones de mantenimiento,

realizando las revisiones o reparaciones necesarias para garantizar el buen

funcionamiento de los equipos en el nuevo periodo de utilizacin.
2. Mantenimiento de actualizacin: cuyo propsito es compensar la obsolescencia tecnolgica, o
las nuevas exigencias, que en el momento de construccin no existan o no fueron tenidas en
cuenta pero que en la actualidad si tienen que serlo.

El Plan de Pruebas
El propsito del plan de pruebas es explicitar el alcance, enfoque, recursos requeridos, calendario,
responsables y manejo de riesgos de un proceso de pruebas. Note que puede haber un plan global
que explicite el nfasis a realizar sobre los distintos tipos de pruebas (verificacin, integracin e
integracin).
Un plan de pruebas incluye:
1. Identificador del plan. Preferiblemente de alguna forma mnemnica que permita relacionarlo con
su alcance, por ej. TP-Global (plan global del proceso de pruebas), TP-Req-Seguridad1 (plan de
verificacin del requerimiento 1 de seguridad), TP-Contr-X (plan de verificacin del contrato
asociado al evento de sistema X), TP-Unit-Despachador. Iniciar (plan de prueba unitario para el
mtodo iniciar de la clase Despachador). Como todo artefacto del desarrollo, est sujeto a control de
configuracin, por lo que debe distinguirse adicionalmente la versin y fecha del plan.
2. Alcance Indica el tipo de prueba y las propiedades/elementos del software a ser probado.
3. tems a probar Indica la configuracin a probar y las condiciones mnimas que debe cumplir para
comenzar a aplicarle el plan. Por un lado, es difcil y riesgoso probar una configuracin que an
reporta fallas; por otro lado, si esperamos a que todos los mdulos estn perfectos, puede que
detectemos fallas graves demasiado tarde.
4. Estrategia Describe la tcnica, patrn y/o herramientas a utilizarse en el diseo de los casos de
prueba. Por ejemplo, en el caso de pruebas unitarias de un procedimiento, esta seccin podra indicar:
"Se aplicar la estrategia caja-negra de fronteras de la precondicin" o "Ejercicio de los caminos ciclo
mticos vlidos". En lo posible la estrategia debe precisar el nmero mnimo de casos de prueba a
disear, por ej. 100% de las fronteras, 60% de los caminos ciclo mticos... La estrategia tambin
explicita el grado de automatizacin que se exigir, tanto para la generacin de casos de prueba como
para su ejecucin.
5. Categorizacin de la configuracin Explicita las condiciones bajo las cuales, el plan debe ser:
Suspendido,
Repetido;
Culminado.
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 culminacin pueden ser tan simples como aprobar
el nmero mnimo de casos de prueba diseados o tan complejos como tomar en cuenta no slo el
nmero mnimo, sino tambin el tiempo previsto para las pruebas y la tasa de deteccin de fallas.
6. Tangibles Explicita los documentos a entregarse al culminar el proceso previsto por el plan p. ej.
subplanes especificacin de pruebas, casos de prueba, resumen gerencial del proceso y bitcora de
pruebas.
7. Procedimientos especiales Identifica el grafo de las tareas necesarias para preparar y ejecutar las
pruebas, as como cualquier habilidad especial que se requiere.
8. Recursos Especifica las propiedades necesarias y deseables del ambiente de prueba, incluyendo
las caractersticas del hardware, el software de sistemas (p. ej. el sistema de operacin), cualquier otro
software necesario para llevar a cabo las pruebas, as como la colocacin especfica del software a
probar (p. ej. qu mdulos se colocan en qu mquinas de una red local) y la configuracin del
software de apoyo.
La seccin incluye un estimado de los recursos humanos necesarios para el proceso. Tambin se
indican cualquier requerimiento especial del proceso: actualizacin de licencias, espacio de oficina,
tiempo en la mquina de produccin, seguridad.
9. Calendario Esta seccin describe los hitos del proceso de prueba y el grafo de dependencia en el
tiempo de las tareas a realizar.
10. Manejo de riesgos Explicita los riesgos del plan, las acciones mitigantes y de contingencia.
11. Responsables Especifica quin es el responsable de cada una de las tareas previstas en el plan.
Tipos de Plan de Pruebas:
Prueba Unitaria
Particionar los mdulos en pruebas en unidades lgicas fciles de probar.
Por cada unidad hay que definir los casos de prueba (pruebas de caja blanca).
Para esto los casos de prueba deben disearse de forma tal que se recorran todos los caminos de
ejecucin posibles dentro del cdigo bajo prueba; por lo tanto el diseador debe construirlos con
acceso al cdigo fuente de la unidad a probar.
Prueba de Integracin
Describe cmo verificar que las interfaces entre las componentes de software funcionan
correctamente.
Determina cmo la base de datos de prueba ser cargada.
Determina el enfoque para avanzar desde un nivel de integracin de las componentes al siguiente.

 Decide qu acciones tomar cuando se descubren problemas.

Prueba de Regresin
En esta prueba se vuelve a probar el sistema a la luz de los cambios realizados durante el debugging,
mantenimiento o desarrollo de la nueva versin del sistema buscando efectos adversos en otras partes.
Pruebas de Humo (Smoke Testing o Ad Hoc)
Toma ste nombre debido a que su objetivo es probar el sistema constantemente buscando que saque
humo o falle. En algunos proyectos este tipo de prueba va junto con las pruebas funcionales.
Permite detectar problemas que por lo regular no son detectados en las pruebas normales. Algunas
veces, si las Pruebas ocurren tarde en el ciclo de desarrollo est ser una forma de garantizar el buen
desarrollo.
Las pruebas de humo NO SON exhaustivas, pero van de extremo a extremo de la aplicacin.
Pruebas del Sistema
Las pruebas del sistema deben enfocarse en requisitos que puedan ser tomados directamente de casos
de uso y reglas y funciones de negocios. El objetivo de estas pruebas es verificar el ingreso,
procesamiento y recuperacin apropiado de datos, y la implementacin apropiada de las reglas de
negocios. Este tipo de pruebas se basan en tcnicas de caja negra, sto es, verificar el sistema (y sus
procesos internos), la interaccin con las aplicaciones que lo usan via GUI y analizar las salidas o
resultados.
En esta prueba se determina qu pruebas de Sistema (usabilidad, volumen, desempeo, etc.)
asegurarn que la aplicacin alcanzar sus objetivos de negocio.
Pruebas de Desempeo
Las pruebas de desempeo miden tiempos de respuesta, ndices de procesamiento de transacciones y
otros requisitos sensibles al tiempo. El objetivo de las pruebas de desempeo es verificar y validar
los requisitos de desempeo que se han especificado (en este caso, el desempeo ofrecido por el
proponente).
Las pruebas de desempeo usualmente se ejecutan varias veces, utilizando en cada una, carga
diferente en el sistema. La prueba inicial debe ser ejecutada con una carga similar a la esperada en el
sistema. Una segunda prueba debe hacerse utilizando una carga mxima.
Adicionalmente, las pruebas de desempeo pueden ser utilizadas para perfilar y refinar el desempeo
del sistema como una funcin de condiciones tales como carga o configuraciones de hardware
Las principales actividades son:
Comparar el desempeo del sistema actual con los requisitos,
Poner a punto el sistema para mejorar las mtricas de desempeo y proyectar la capacidad futura de
carga del sistema.
Los objetivos de nivel de servicio definidos deben guiar la prueba de performance. Algunas
caractersticas que afectan el desempeo son:
Errores lgicos

Procesamiento ineficiente
Diseo pobre: muchas interfases, instrucciones y entradas/salidas.
Cuellos de botella en discos, CPU canales de entrada/salida
Salidas del sistema
Tiempos de respuesta
Capacidad de almacenamiento
Tasa de entrada/salida de datos
Nmero de transacciones que pueden ser manejadas simultneamente.
Las pruebas de desempeo utilizan las tcnicas de caja blanca y caja negra.

Pruebas de Carga
Las pruebas de carga miden la capacidad del sistema para continuar funcionando apropiadamente
bajo diferentes condiciones de carga.
La meta de las pruebas de carga es determinar y asegurar que el sistema funciona apropiadamente
an ms all de la carga de trabajo mxima esperada. Adicionalmente, las pruebas de carga evalan
las caractersticas de desempeo (tiempos de respuesta, tasas de transacciones y otros aspectos
sensibles al tiempo).
Pruebas de Stress
Las pruebas de stress se proponen encontrar errores debidos a recursos bajos o completitud de
recursos. Poca memoria o espacio en disco puede revelar defectos en el sistema que no son aparentes
bajo condiciones normales. Otros defectos pueden resultar de incluir recursos compartidos, como
bloqueos de base de datos o ancho de banda de la red. Las pruebas de stress identifican la carga
mxima que el sistema puede manejar.
El objetivo de esta prueba es investigar el comportamiento del sistema bajo condiciones que
sobrecargan sus recursos. No debe confundirse con las pruebas de volumen: un esfuerzo grande es un
pico de volumen de datos que se presenta en un corto perodo de tiempo.
Puesto que la prueba de esfuerzo involucra un elemento de tiempo, no resulta aplicable a muchos
programas, por ejemplo a un compilador o a una rutina de pagos.
Es aplicable, sin embargo, a programas que trabajan bajo cargas variables, interactivos, de tiempo
real y de control de proceso.
Aunque muchas pruebas de esfuerzo representan condiciones que el programa encontrar realmente
durante su utilizacin, muchas otras sern en verdad situaciones que nunca ocurrirn en la realidad.
Esto no implica, sin embargo, que estas pruebas no sean tiles.
Si se detectan errores durante estas condiciones imposibles, la prueba es valiosa porque es de
esperar que los mismos errores puedan presentarse en situaciones reales, algo menos exigentes.

Pruebas de Volumen
Las pruebas de volumen hacen referencia a grandes cantidades de datos para determinar los lmites
en que se causa que el Sistema falle. Tambin identifican la carga mxima o volumen que el sistema
puede manejar en un perodo dado. Por ejemplo, si el sistema est procesando un conjunto de registros
de Base de datos para generar un reporte, una prueba de volumen podra usar una Base de datos de
prueba grande y verificar que el sistema se comporta normalmente y produce el reporte
correctamente.
El objetivo de esta prueba es someter al sistema a grandes volmenes de datos para determinar si el
mismo puede manejar el volumen de datos especificado en sus requisitos.
Algunos ejemplos de escenarios de prueba de volmenes:
Un compilador puede ser alimentado por un programa para compilar que sea absurdamente grande.
Un editor de nexos puede recibir un programa que contenga miles de mdulos.
Un simulador de circuito electrnico puede recibir un circuito diseado con miles de componentes.
Puesto que obviamente, la prueba de volumen es una prueba costosa, tanto en tiempo de mquina
como en personal, se debe tratar de no exceder los lmites. Sin embargo, todo programa debera ser
expuesto, al menos, a algunas pruebas de volumen.

Pruebas de Recuperacin y Tolerancia a fallas

Estas pruebas aseguran que una aplicacin o sistema se recupere de una variedad de anomalas de
hardware, software o red con prdidas de datos o fallas de integridad.
Las pruebas de tolerancia a fallas aseguran que, para aquellos sistemas que deben mantenerse
corriendo, cuando una condicin de falla ocurre, los sistemas alternos o de respaldo pueden tomar
control del sistema sin prdida de datos o transacciones.
Las pruebas de recuperacin son contrarias a las pruebas en que la aplicacin o sistema es expuesto
a condiciones extremas (o condiciones simuladas), tales como fallas en dispositivos en entrada/salida
o llaves o apuntadores invlidos de base de datos. Los procesos de recuperacin se invocan y la
aplicacin es monitoreada y/o inspeccionada para verificar que stos mecanismos se han ejecutado
en forma apropiada.
El objetivo de esta prueba es determinar la habilidad del sistema para recuperarse de una falla de
hardware o software. Esta prueba evala las caractersticas de contingencia construidas en el sistema
para procesar interrupciones y para volver a puntos especficos en el ciclo de procesamiento del
sistema. La recuperacin debe ser considerada en el proceso de diseo. Errores de programacin o de
datos pueden ser incorporados ex profeso en un sistema para determinar si se puede recuperar de
ellos. Las fallas de equipo (por ejemplo errores de paridad en memoria, errores en dispositivos de
entrada/salida) pueden ser simuladas.

Prueba de Mltiples Sitios

El propsito de esta prueba es evaluar el correcto funcionamiento del sistema o subsistema en

mltiples instalaciones.
Prueba de Compatibilidad y Conversin
El propsito es demostrar que los objetivos de compatibilidad no han sido logrados y que los
procedimientos de conversin no funcionan.
La mayora de los programas que se desarrollan no son completamente nuevos; con frecuencia son
reemplazos de partes deficientes, ya sea de sistemas de procesamiento de datos, o sistemas manuales.
Como tales, los programas tienen a menudo objetivos especficos con respecto a su compatibilidad y
a sus procedimientos de conversin con el sistema existente.
Pruebas de Integridad de Datos y Base de Datos
La Base de datos y los procesos de Base de datos deben ser probados como sistemas separados del
proyecto. Estos sistemas deberan ser probados sin usar interfaces de usuario (como las interfaces de
datos). Se necesita realizar investigacin adicional en el DBMS para identificar las herramientas y
tcnicas que podran existir para soportar las pruebas identificadas ms adelante.
Pruebas de Seguridad y Control de Acceso
Las pruebas de seguridad y control de acceso se centran en dos reas claves de seguridad:
Seguridad del sistema, incluyendo acceso a datos o Funciones de negocios y
Seguridad del sistema, incluyendo ingresos y accesos remotos al sistema.
Las pruebas de seguridad de la aplicacin garantizan que, con base en la seguridad deseada, los
usuarios estn restringidos a funciones especficas o su acceso est limitado nicamente a los datos
que estn autorizado a acceder. Por ejemplo, cada usuario puede estar autorizado a crear nuevas
cuentas, pero slo los administradores pueden borrarlas. Si existe seguridad a nivel de datos, la prueba
garantiza que un usuario tpico 1 puede ver toda la informacin de clientes, incluyendo datos
financieros; sin embargo, el usuario 2 solamente puede ver los datos institucionales del mismo cliente.
Las pruebas de seguridad del sistema garantizan que solamente aquellos usuarios autorizados a
acceder al sistema son capaces de ejecutar las funciones del sistema a travs de los mecanismos
apropiados.
Debido a la creciente preocupacin de la sociedad por la privacidad de la informacin, muchos
programas tienen objetivos especficos de seguridad.
El objetivo de esta prueba es evaluar el funcionamiento correcto de los controles de seguridad del
sistema para asegurar la integridad y confidencialidad de los datos. El foco principal es probar la
vulnerabilidad del sistema frente a accesos o manipulaciones no autorizadas. Una manera de encontrar
esos casos de prueba es estudiar problemas conocidos de seguridad en sistemas similares y tratar de
mostrar la existencia de problemas parecidos en el sistema que se examina.

Pruebas de GUI

La prueba de interfaz de usuario verifica la interaccin del usuario con el software. El objetivo es
asegurar que la interfaz tiene apropiada navegacin a travs de las diferentes funcionalidades.
Adicionalmente, las pruebas de interfaz aseguran que los objetos de la interfaz a ser probada se
encuentran dentro de los estndares de la industria
Pruebas de Configuracin
Estas pruebas verifican la operacin del sistema en diferentes configuraciones de hardware y
software. En la mayora de los ambientes de produccin, las especificaciones para las estaciones de
trabajo, equipos de red y servidores pueden variar. Las estaciones pueden tener diferentes versiones
de software instaladas (Sistemas Operativos, Drivers, etc) y en cualquier momento, pueden llegar a
utilizarse diferentes combinaciones.
Con frecuencia, el nmero de configuraciones posibles es demasiado grande para intentar una prueba
de cada una de ellas, pero el programa debe probarse al menos con cada tipo de dispositivo y con las
configuraciones mnima y mxima posibles.
Prueba de Instalacin
Las pruebas de instalacin tienen dos propsitos. El primero es asegurar que el sistema puede ser
instalado en todas las configuraciones posibles, tales como nuevas instalaciones, actualizaciones,
instalaciones completas o personalizadas, y bajo condiciones normales o anormales; estas ltimas
incluyen insuficiente espacio en disco, falta de privilegios para algunas tareas, etc.
El segundo propsito es verificar que, una vez instalado, el sistema opera correctamente. Esto
usualmente implica correr un nmero significativo de pruebas de Funcionalidad.