Está en la página 1de 6

Definición de pruebas.

El equipo de auditoría debe realizar pruebas para verificar la consistencia de los controles existentes o
bien para medir el riesgo existente. Toda opinión o evaluación de un auditor debe estar basada en
pruebas realizadas de acuerdo con mina normativa profesional. Las pruebas pueden ser de
cumplimiento, que se
utilizan para comprobar si el riesgo potencial es real. 􀀹
Obtención de resultados de las pruebas.
Los resultados de cada prueba deben valorarse para obtener una conclusión, siempre teniendo en
cuenta los objetivos y el alcance de la auditoria. 􀀹
Obtención de resultados de las pruebas.
Las conclusiones obtenidas deben comentarse y discutirse con los responsables directos del área
afectada por las razones que se expresan a continuación:
• Puede haber limitaciones en la realización de las pruebas.
• Puede haber controles alternativos que no hayan detectado en el proceso.
Todas las deficiencias o riesgos deben ser objeto de comentarios individuales y deben incluir:
• Descripción de la situación.
• Riesgo existente y deficiencia a solucionar.
• Si es preciso, sugerencia de solución.

Principales pruebas y herramientas para efectuar una auditoría informática
En la realización de una auditoría informática el auditor puede realizar las siguientes pruebas:
 Pruebas de consentimiento: Determinar si los CI operan como fueron diseñados para operar. El
auditor debe determinar si los controles declarados en realidad existen y si en realidad trabajan
confiablemente.

Pruebas sustantivas: Verifican el grado de confiabilidad del SI del organismo. Se suelen obtener
mediante observación, cálculos, muestreos, entrevistas, técnicas de examen analítico, revisiones y
conciliaciones. Verifican asimismo la exactitud, integridad y validez de la información.

Pruebas de cumplimiento: Verifican el grado de cumplimiento de lo revelado mediante el análisis
de la muestra. Proporciona evidencias de que los controles claves existen y que son aplicables
efectiva y uniformemente.

Pruebas Controles De Usuario: En algunos casos el auditor puede decidir el no confiar en los
controles internos dentro de las instalaciones informáticas, porque el usuario ejerce controles que
compensan cualquier debilidad dentro de los CI de informática.

Pruebas Sustantivas
El objetivo de las pruebas sustantivas es obtener evidencia suficiente que permita al auditor emitir su
juicio en las conclusiones acerca de cuándo pueden ocurrir perdida materiales durante el proceso de la
información.

que los controles que se suponía que existían. 4 prueba para comparar con los datos o contadores físicos. • El procedimiento de evaluación y la elección de nuevos procedimientos de auditoria son los mismos que los de las fases anteriores. si han ocurrido perdidas o pueden ocurrir en el futuro. Prueba y Evaluación de los Controles del Usuario El auditor puede decidir que no hace falta confiar en los controles internos porque existen controles del usuario que los sustituyen o compensan. 2 prueba para asegurar la calidad de los datos. bien internos o bien del usuario. Para un auditor externo. es decir. Fase IV: Pruebas de Apoyo El objetivo de esta fase es obtener evidencias suficientes para tomar la decisión final sobre si pueden ocurrir o no pérdidas materiales durante el procesamiento de los datos. Para un auditor interno. Para un auditor interno.Se pueden identificar 8 diferentes pruebas sustantivas: 1 pruebas para identificar errores en el procesamiento o de falta de seguridad o confidencialidad. bien internos o bien del usuario. para evitar la redundancia. • Al final de la fase. un auditor externo podrá formarse una opinión sobre si existen o no discrepancias sobre el estado de cuentas de la empresa. revisar estos controles del usuario puede resultar más costoso que revisar los controles internos. es importante hacerlo para eliminar posibles controles duplicados. para evitar la redundancia. de acuerdo con la fiabilidad que han mostrado los controles individuales. Prueba y Evaluación de los Controles del Usuario El auditor puede decidir que no hace falta confiar en los controles internos porque existen controles del usuario que los sustituyen o compensan. es importante hacerlo para eliminar posibles controles duplicados. . Pruebas de Comportamiento El objetivo de esta fase es comprobar que los controles internos funcionan como lo deben de hacer. 3 pruebas para identificar la inconsistencia de datos. mientras que un auditor interno deberá de tener una perspectiva mas amplia y se cuestionara si se esta de acuerdo o no con los controles internos. existen cinco tipos de pruebas de apoyo: • Para identificar procesos erróneos. revisar estos controles del usuario puede resultar más costoso que revisar los controles internos. Por ejemplo. 1981]. Para un auditor externo. existen realmente y funcionan bien. 7 prueba para determinar falta de seguridad. el auditor puede decidir evaluar de nuevo el sistema de controles internos. De acuerdo con [Davis et al. etc. 5 confirmación de datos con fuentes externas 6 pruebas para confirmar la adecuada comunicación. además de la recogida manual de evidencias ya descrita. 8 pruebas para determinar problemas de legalidad. contemplan el uso del ordenador para verificar los controles. Las técnicas utilizadas.

Pruebas sustantivas: Busca conocer la forma en que esta implementado el control. consistente y cotidianamente. Se ensaya la aplicación con datos de prueba contra resultados obtenidos inicialmente en las pruebas del programa para detectar resultados no válidos. recursos requeridos en cuanto a información. Tipos de pruebas Pruebas de cumplimiento: Busca determinar si existe el control para el riesgo identificado . • Para comparar datos y cuentas físicas.Inspección . E. se describe brevemente (procedimientos a emplear). en tal caso. antes de ser enviada a producción y cuando se llevan a cabo modificaciones a un programa. técnicas a utilizar. tipo de la prueba. hardware. su utilización. Diseño de Pruebas de Auditoria Objetivo Definir Los procedimientos de Auditoria que permitan recolectar la evidencia que apoye los hallazgos y recomendaciones. los programas utilizados para digitar los datos de prueba deben ser los mismos que se encuentran en producción y que se utilizan para procesar los movimientos diarios. Este es un trabajo de escritorio donde se determina en términos generales: el objetivo de la prueba. Técnicas comúnmente usadas para el Diseño y Ejecución de Pruebas de Auditoría .Observación . EVALUACIÃ?N DE UN SISTEMA CON DATOS DE PRUEBA: Comúnmente llamada lotes de prueba. software y personal. • Para identificar datos inconsistentes. y el entendimiento y ejecución de los mismos por parte de las personas.Indagación . toma el nombre de EVALUACION DEL SISTEMA DEL CASO BASE â?? ESCB. auditores y personal de sistemas. por tanto.Conciliación (cruce de información con persona o documentos) . En todas estas pruebas. Consideraciones Una vez realizados los pasos anteriores en este punto se tienen las bases para diseñar las pruebas de auditoría que se han de efectuar.Investigación analítica: Evaluar tendencias . aplicada al sistema en producción. Esta técnica se utiliza en la fase de prueba del programa.• Para garantizar la calidad de los datos. Ejecutar Pruebas de Auditoría Objetivo Obtener evidencia sobre los controles establecidos. • De confirmación de datos con fuentes externas.Confirmación . la prueba es más completa y requiere de un alto grado de cooperación entres usuarios. Los datos de prueba deben representar la aplicación que se examina con todas las posibles combinaciones de transacciones que se lleven a cabo en situaciones reales. Cuando esta técnica se mantiene en el tiempo para ser. . se puede utilizar el ordenador como herramienta de apoyo. en caso de que este exista.TAAC'S: Técnicas de Auditoria Asistidas por Computador.

La prueba de todas las combinaciones puede llevarse varios pasos a través del sistema. 2. pruebas de subsistema. para probar las especificaciones del sistema. La fase de prueba ocurre en la penúltima etapa. • Codificación: Pruebas unitarias Tipos de pruebas • Pruebas unitarias • Pruebas funcionales • Pruebas de Integración • Pruebas de validación • Pruebas de sistema • Caja blanca (sistemas) • Caja negra (sistemas) • Pruebas de aceptación • Pruebas de regresión • Pruebas de carga • Pruebas de prestaciones • Pruebas de recorrido • Pruebas de mutación Tipos de pruebas: pruebas altas Prueba de enlace También se le conoce como prueba en cadena. • Análisis de requerimientos: Pruebas de sistema. Note que el diseño de estas pruebas requiere los siguientes pasos: 1. Pasos para realizar las pruebas. como se planeó. es decir después de la fase de programación pero antes de la fase de implantación del programa. Definición de pruebas. La prueba de enlace revisa para ver si los programas que son interdependientes trabajan. 3. La prueba es el proceso de ejecutar un programa con la intención de descubrir defectos en el programa. Elaborar el plan de pruebas. El analista crea datos de prueba especiales que cubren una diversidad de situaciones de . así como los programas. Estas especificaciones son cruciales a la hora de diseñar las pruebas de verificación. La prueba Es una de las fases más importantes del ciclo de vidade desarrollo del software. 4. de hecho. Hacer controlable los elementos del software necesarios para llevar a cabo las pruebas. pruebas de verificación (de requerimientos) • Diseño: Pruebas de integración. Revisar la verificabilidad del requerimiento. Una pequeña cantidad de datos de prueba. 5. Tipos datos de prueba. Ejecutar el plan de pruebas y reportar sus resultados. La fase de prueba se debe realizar de la manera más robusta y eficiente. debido a que es mucho muy difícil describir los problemas si se trata de probar todo en una sola vez. Hacer visible las propiedades o elementos del software necesarios para verificar el cumplimiento del requerimiento. se usan para la prueba de enlace. Especificar el criterio de verificación. 6. adjuntándose para cada prueba ejecutada los soportes correspondientes.Consideraciones Se ejecutan las pruebas de auditoría diseñadas en el anterior paso.

Primero. pruebas de camino de datos (definiciónuso de variables). Si el sistema trabaja con las transacciones normales. sino una vez pasada todas las pruebas de integración por parte del desarrollador. se . pues sería impresentable de cara al cliente. sobre el sistema completo. Son básicamente pruebas funcionales. pruebas sobre las expresiones lógico-aritméticas. su interfaz. Por tanto. sobre un módulo concreto. en cambio. no se precisa definir ni conocer los detalles internos de su funcionamiento. El sistema también será más robusto y fácil de mantener. aquellas que conformarán la mayor parte de su carga. Prueba de caja blanca Se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo. sin tener en cuenta su funcionamiento interno. Prueba de caja negra. en la fase de diseño se buscará que cada módulo sea una caja negra dentro del sistema global que es el programa que se pretende desarrollar. Entre las técnicas usadas se encuentran. de una caja negra deben estar muy bien definidas sus entradas y salidas.1 y n iteraciones. En pruebas de software. en otras palabras. usando los documentos originales de los requerimientos como referencias y no por el personal técnico.procesamiento para la prueba de enlace. incluyendo los datos inválidos usados para asegurarse de que el sistema pueda detectar errores adecuadamente. para luego realizar las de caja negra sobre varios subsistemas (integración). En los sistemas orientados a objetos. pero según varias opiniones. de esta manera se consigue una independencia entre los módulos que facilita su implementación separada por un equipo de trabajo donde cada miembro va a encargarse de implementar una parte (un módulo) del programa global. de una caja negra nos interesará su forma de interactuar con el medio que le rodea (en ocasiones. Se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce. pero sin dar importancia a cómo lo hace. la cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecución). En otras palabras. las pruebas de caja blanca pueden aplicarse a los métodos de la clase. Es realizado por los representantes del negocio. Las pruebas de caja blanca se llevan a cabo en primer lugar. las de caja blanca están dirigidas a las funciones internas. Un sistema formado por módulos que cumplan las características de caja negra será más fácil de entender ya que permitirá dar una visión más clara del conjunto. comprobación de bucles (se verifican los bucles para 0. conociendo una función específica para la que fue diseñado el producto. el implementador de un módulo concreto deberá conocer como es la comunicación con los otros módulos (la interfaz). se procesan datos de prueba típicos para ver si el sistema puede trabajar las transacciones normales. La prueba de aceptación se relaciona y define la aceptación formal de un producto acabado. Comprueba si el producto satisface los requerimientos originales del negocio. en caso de ocurrir un fallo. otros elementos que también podrían ser cajas negras) entendiendo qué es lo que hace. para el desarrollador de un módulo. Estas pruebas no se realizan durante el desarrollo. Así como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del módulo. Prueba de aceptación. ese esfuerzo debería dedicarse a otro tipo de pruebas más especializadas (un argumento podría ser que los métodos de una clase suelen ser menos complejos que los de una función de programación estructurada). máximas menos uno y más uno. En programación modular. idealmente. pero no necesitará conocer cómo trabajan esos otros módulos internamente. donde un programa (o un algoritmo) es divido en módulos. y buscan una cobertura de la especificación de requisitos y del manual del usuario. luego se añaden variaciones. es decir. el resto de módulos serán cajas negras. éste podrá ser aislado y abordado más ágilmente. Estas pruebas las realiza el cliente. y luego para las iteraciones máximas.

En contraste. se implantan y prueban sus subcomponentes. La estrategias de pruebas descendentes y ascendentes refleja diferente enfoques de la integración del sistema. Dichas pruebas son llevadas a cabo sobre la interfaz del software. actuando sobre ella como una caja negra. Se emplea donde el sistema reutiliza y modifica componentes de otros sistemas. Prueba ascendente y descendente. De esta forma queda completamente probado el sistema completo. y después asciende por la jerarquía de los módulos hasta que el módulo final se prueba. Este enfoque no requiere que el diseño arquitectónico del sistema este completo por lo que se puede comenzar en una etapa inicial del proceso de desarrollo. En la integración descendente. permite descubrir fallas tales como: • Funciones errónea o faltante • Errores de interfaz • Errores de estructuras de datos y base de datos • Errores de inicialización y finalización • Errores en el desempeño Prueba de sensibilidad. Después de que se programa y prueba el primer componente de nivel alto. . de la misma forma. Prueba en paralelo Las pruebas en paralelo tienen como propósito probar durante un período mínimo de quince (15) días calendario el sistema de información que contenga las funcionalidades exigibles para la primera etapa de la Fase de Construcción del RUNT y contrastar los resultados con los de la operación generada por los Organismos de Tránsito. por las Direcciones Territoriales del Ministerio y por los Otros Actores en sus actuales esquemas. Este proceso continúa hasta que los componentes de nivel bajo se implanten. de la función. Prueba de avance. es decir.pueden diseñar pruebas que demuestren que dicha función está bien realizada. También conocida como prueba funcional. En la integración ascendente. Estos tienen la misma interfaz que los componentes pero funcionalidad muy limitada. proporcionando unas entradas y estudiando las salidas para ver si son o no las esperadas. las pruebas ascendentes comprenden integrar y probar los módulos en los niveles bajos de la jerarquía. los componentes de los niveles altos de un sistema se integran y prueban antes de que se complete su diseño e implementación. los componentes de los niveles bajos se integran y prueban antes de que se desarrollen los componentes de los niveles altos. Las pruebas descendentes son una parte integral del proceso de desarrollo descendente en el cual este último inicia con los componentes de los niveles altos y descienden en la jerarquía de los componentes. Prueba de huracán.