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 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 el alcance de la auditoria. Obtención de resultados de las pruebas. Las conclusiones obtenidas deben comentarse discutirse con los responsables directos del !rea afectada por las razones que se expresan a continuación" # $uede %aber limitaciones en la realización de las pruebas. # $uede %aber controles alternativos que no %aan detectado en el proceso. Todas las deficiencias o riesgos deben ser objeto de comentarios individuales deben incluir" # &escripción de la situación. # 'iesgo existente deficiencia a solucionar. # (i es preciso, sugerencia de solución. $rincipales pruebas %erramientas 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: &eterminar si los )* operan como fueron dise+ados para operar. El
auditor debe determinar si los controles declarados en realidad existen si en realidad trabajan confiablemente. Pruebas sustantivas" erifican el grado de confiabilidad del (* del organismo. (e suelen obtener
mediante observación, c!lculos, muestreos, entrevistas, t-cnicas de examen analítico, revisiones conciliaciones. erifican asimismo la exactitud, integridad validez de la información. Pruebas de cumplimiento " erifican el grado de cumplimiento de lo revelado mediante el an!lisis
de la muestra. $roporciona evidencias de que los controles claves existen que son aplicables efectiva 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 )* de inform!tica.
$ruebas (ustantivas 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.
(e pueden identificar diferentes pruebas sustantivas" / pruebas para identificar errores en el procesamiento o de falta de seguridad o confidencialidad. 0 prueba para asegurar la calidad de los datos. 1 pruebas para identificar la inconsistencia de datos. 2 prueba para comparar con los datos o contadores físicos. 3 confirmación de datos con fuentes externas 4 pruebas para confirmar la adecuada comunicación. 5 prueba para determinar falta de seguridad. pruebas para determinar problemas de legalidad. Pruebas de Comportamiento
El objetivo de esta fase es comprobar que los controles internos funcionan como lo deben de %acer, es decir, que los controles que se suponía que existían, existen realmente funcionan bien. Las t-cnicas utilizadas, adem!s de la recogida manual de evidencias a descrita, contemplan el uso del ordenador para verificar los controles. # 6l final de la fase, el auditor puede decidir evaluar de nuevo el sistema de controles internos, de acuerdo con la fiabilidad que %an mostrado los controles individuales. # El procedimiento de evaluación la elección de nuevos procedimientos de auditoria son los mismos que los de las fases anteriores. $rueba Evaluación de los )ontroles del 7suario El auditor puede decidir que no %ace falta confiar en los controles internos porque existen controles del usuario que los sustituen o compensan. $ara un auditor externo, revisar estos controles del usuario puede resultar m!s costoso que revisar los controles internos. $ara un auditor interno, es importante %acerlo para eliminar posibles controles duplicados, bien internos o bien del usuario, para evitar la redundancia. Prueba y Evaluación de los Controles del Usuario
El auditor puede decidir que no %ace falta confiar en los controles internos porque existen controles del usuario que los sustituen o compensan. $ara un auditor externo, revisar estos controles del usuario puede resultar m!s costoso que revisar los controles internos. $ara un auditor interno, es importante %acerlo para eliminar posibles controles duplicados, bien internos o bien del usuario, para evitar la redundancia. 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. $or ejemplo, un auditor externo podr! formarse una opinión sobre si existen o no discrepancias sobre el estado de cuentas de la empresa, mientras que un auditor interno deber! de tener una perspectiva mas amplia se cuestionara si se esta de acuerdo o no con los controles internos, si %an ocurrido perdidas o pueden ocurrir en el futuro, etc. &e acuerdo con 8&avis et al, /9/:, existen cinco tipos de pruebas de apoo" # $ara identificar procesos erróneos.
# $ara garantizar la calidad de los datos. # $ara identificar datos inconsistentes. # $ara comparar datos cuentas físicas. # &e confirmación de datos con fuentes externas. En todas estas pruebas, se puede utilizar el ordenador como %erramienta de apoo. E6L76)*;<= &E 7= (*(TE>6 )?= &6T?( &E $'7E@6" )omAnmente llamada lotes de prueba. (e ensaa la aplicación con datos de prueba contra resultados obtenidos inicialmente en las pruebas del programa para detectar resultados no v!lidos. 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. Esta t-cnica se utiliza en la fase de prueba del programa, antes de ser enviada a producción cuando se llevan a cabo modificaciones a un programa, por tanto, los programas utilizados para digitar los datos de prueba deben ser los mismos que se encuentran en producción que se utilizan para procesar los movimientos diarios. )uando esta t-cnica se mantiene en el tiempo para ser, consistente cotidianamente, aplicada al sistema en producción, toma el nombre de E6L76)*?= &EL (*(TE>6 &EL )6(? @6(E B<< E()@, en tal caso, la prueba es m!s completa requiere de un alto grado de cooperación entres usuarios, auditores personal de sistemas. &ise+o de $ruebas de 6uditoria Objetivo
&efinir Los procedimientos de 6uditoria que permitan recolectar la evidencia que apoe los %allazgos recomendaciones. Consideraciones
7na vez realizados los pasos anteriores en este punto se tienen las bases para dise+ar las pruebas de auditoría que se %an de efectuar. Este es un trabajo de escritorio donde se determina en t-rminos generales" el objetivo de la prueba, se describe brevemente Cprocedimientos a emplearD, tipo de la prueba, t-cnicas a utilizar, recursos requeridos en cuanto a información, %ardare, softare personal. Tipos de pruebas Pruebas de cumplimiento: @usca determinar si existe el control para el riesgo identificado . Pruebas sustantivas: @usca conocer la forma en que esta implementado el control, en caso de que
este exista. Técnicas comúnmente usadas para el Diseño !jecución de Pruebas de "uditor#a
F ?bservación F *ndagación F )onciliación Ccruce de información con persona o documentosD F *nspección F *nvestigación analítica" Evaluar tendencias F )onfirmación F T66)G(" T-cnicas de 6uditoria 6sistidas por )omputador. !. !jecutar Pruebas de "uditor#a Objetivo
?btener evidencia sobre los controles establecidos, su utilización, el entendimiento ejecución de los mismos por parte de las personas.
Consideraciones
(e ejecutan las pruebas de auditoría dise+adas en el anterior paso, adjunt!ndose para cada prueba ejecutada los soportes correspondientes. &efinición de pruebas. La prueba Es una de las fases m!s importantes del ciclo de vidade desarrollo del softare. La prueba es el proceso de ejecutar un programa con la intención de descubrir defectos en el programa. La fase de prueba ocurre en la penAltima etapa, es decir despu-s de la fase de programación pero antes de la fase de implantación del programa. La fase de prueba se debe realizar de la manera m!s robusta eficiente. $asos para realizar las pruebas. Estas especificaciones son cruciales a la %ora de dise+ar las pruebas de verificación. =ote que el dise+o de estas pruebas requiere los siguientes pasos" /. 'evisar la verificabilidad del requerimientoH 0. Especificar el criterio de verificaciónH 1. Iacer visible las propiedades o elementos del softare necesarios para verificar el cumplimiento del requerimientoH 2. Iacer controlable los elementos del softare necesarios para llevar a cabo las pruebasH 3. Elaborar el plan de pruebasH 4. Ejecutar el plan de pruebas reportar sus resultados. Tipos datos de prueba. # 6n!lisis de requerimientos" $ruebas de sistema, pruebas de verificación Cde requerimientosD # &ise+o" $ruebas de integración, pruebas de subsistema. # )odificación" $ruebas unitarias Tipos de pruebas # $ruebas unitarias # $ruebas funcionales # $ruebas de *ntegración # $ruebas de validación # $ruebas de sistema # )aja blanca CsistemasD # )aja negra CsistemasD # $ruebas de aceptación # $ruebas de regresión # $ruebas de carga # $ruebas de prestaciones # $ruebas de recorrido # $ruebas de mutación Tipos de pruebas" pruebas altas $rueba de enlace Tambi-n se le conoce como prueba en cadena. La prueba de enlace revisa para ver si los programas que son interdependientes trabajan, de %ec%o, como se planeó. 7na peque+a cantidad de datos de prueba, para probar las especificaciones del sistema, así como los programas, se usan para la prueba de enlace. La prueba de todas las combinaciones puede llevarse varios pasos a trav-s del sistema, debido a que es muc%o mu difícil describir los problemas si se trata de probar todo en una sola vez.
procesamiento para la prueba de enlace. $rimero, se procesan datos de prueba típicos para ver si el sistema puede trabajar las transacciones normales, aquellas que conformar!n la maor parte de su carga. (i el sistema trabaja con las transacciones normales, luego se a+aden variaciones, incluendo los datos inv!lidos usados para asegurarse de que el sistema pueda detectar errores adecuadamente. Prueba de aceptación.
La prueba de aceptación se relaciona define la aceptación formal de un producto acabado. )omprueba si el producto satisface los requerimientos originales del negocio. Es realizado por los representantes del negocio, usando los documentos originales de los requerimientos como referencias no por el personal t-cnico. Estas pruebas las realiza el cliente. (on b!sicamente pruebas funcionales, sobre el sistema completo, buscan una cobertura de la especificación de requisitos del manual del usuario. Estas pruebas no se realizan durante el desarrollo, pues sería impresentable de cara al clienteH sino una vez pasada todas las pruebas de integración por parte del desarrollador. Prueba de caja blanca
(e denomina cajas blancas a un tipo de pruebas de softare que se realiza sobre las funciones internas de un módulo. 6sí como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del módulo, las de caja blanca est!n dirigidas a las funciones internas. Entre las t-cnicas usadas se encuentranH la cobertura de caminos Cpruebas que %agan que se recorran todos los posibles caminos de ejecuciónD, pruebas sobre las expresiones lógicoFaritm-ticas, pruebas de camino de datos CdefiniciónF uso de variablesD, comprobación de bucles Cse verifican los bucles para J,/ n iteraciones, luego para las iteraciones m!ximas, m!ximas menos uno m!s uno. Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un módulo concreto, para luego realizar las de caja negra sobre varios subsistemas CintegraciónD. En los sistemas orientados a objetos, las pruebas de caja blanca pueden aplicarse a los m-todos de la clase, pero segAn varias opiniones, ese esfuerzo debería dedicarse a otro tipo de pruebas m!s especializadas Cun argumento podría ser que los m-todos de una clase suelen ser menos complejos que los de una función de programación estructuradaD. Prueba de caja ne$ra.
(e denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesar! su forma de interactuar con el medio que le rodea Cen ocasiones, otros elementos que tambi-n podrían ser cajas negrasD entendiendo qu- es lo que %ace, pero sin dar importancia a cómo lo %ace. $or tanto, de una caja negra deben estar mu bien definidas sus entradas salidas, es decir, su interfazH en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento. 7n sistema formado por módulos que cumplan las características de caja negra ser! m!s f!cil de entender a que permitir! dar una visión m!s clara del conjunto. El sistema tambi-n ser! m!s robusto f!cil de mantener, en caso de ocurrir un fallo, -ste podr! ser aislado abordado m!s !gilmente. En programación modular, donde un programa Co un algoritmoD es divido en módulos, 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, 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 Cun móduloD del programa globalH el implementador de un módulo concreto deber! conocer como es la comunicación con los otros módulos Cla interfazD, pero no necesitar! conocer cómo trabajan esos otros módulos internamenteH en otras palabras, para el desarrollador de un módulo, idealmente, el resto de módulos ser!n cajas negras.
pueden dise+ar pruebas que demuestren que dic%a función est! bien realizada. &ic%as pruebas son llevadas a cabo sobre la interfaz del softare, es decir, de la función, actuando sobre ella como una caja negra, proporcionando unas entradas estudiando las salidas para ver si son o no las esperadas. Tambi-n conocida como prueba funcional, permite descubrir fallas tales como" # Kunciones errónea o faltante # Errores de interfaz # Errores de estructuras de datos base de datos # Errores de inicialización finalización # Errores en el desempe+o Prueba de sensibilidad. Prueba de avance. Prueba de %urac&n. Prueba en paralelo
Las pruebas en paralelo tienen como propósito probar durante un período mínimo de quince C/3D días calendario el sistema de información que contenga las funcionalidades exigibles para la primera etapa de la Kase de )onstrucción del '7=T contrastar los resultados con los de la operación generada por los ?rganismos de Tr!nsito, por las &irecciones Territoriales del >inisterio por los ?tros 6ctores en sus actuales esquemas. Prueba ascendente descendente.
La estrategias de pruebas descendentes ascendentes refleja diferente enfoques de la integración del sistema. En la integración descendente, los componentes de los niveles altos de un sistema se integran prueban antes de que se complete su dise+o e implementación. En la integración ascendente, los componentes de los niveles bajos se integran 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 Altimo inicia con los componentes de los niveles altos descienden en la jerarquía de los componentes. Estos tienen la misma interfaz que los componentes pero funcionalidad mu limitada. &espu-s de que se programa prueba el primer componente de nivel alto, se implantan prueban sus subcomponentes, de la misma forma. Este proceso continAa %asta que los componentes de nivel bajo se implanten. &e esta forma queda completamente probado el sistema completo. En contraste, las pruebas ascendentes comprenden integrar probar los módulos en los niveles bajos de la jerarquía, despu-s asciende por la jerarquía de los módulos %asta 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. (e emplea donde el sistema reutiliza modifica componentes de otros sistemas.
