Fundamentos del  Proceso de Pruebas

¿Qué son las pruebas de software?

son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Es una actividad más en el proceso de control de calidad. Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software.

 Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo. Existen distintos modelos de desarrollo de software, así como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento en las actividades de desarrollo.

Conceptos del proceso de pruebas

Verificación:El proceso de evaluación 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.

Validación: El proceso de evaluación 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.

Defectos: un defecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa.

Fallas: La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.

Errores: tiene varias acepciones

Fallo---------La diferencia entre un valor calculado, observado o medio y el valor verdadero, especificado o teóricamente correcto.

Defecto--------Un defecto.

Fallo-------Un resultado incorrecto.

Error-------Una acción humana que conduce a un resultado incorrecto.

Pruebas:una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto

Principios de proceso de pruebas

Principio 1: Las pruebas revelan la presencia de bugs, no la ausencia de ellos

Probar reduce la probabilidad de que existan bugs pero nunca se puede asegurar que no quede ninguno oculto. Además, cada tipo de pruebas que realicemos (de sistema, de integración, añadir auditorias de código…) son más efectivas para detectar un tipo de bug.

Principio 2: Es imposible probarlo todo

El flujo de control de un sistema software no trivial como los que acostumbramos a utilizar en el día a día contiene miles de decisiones. Estas decisiones se pueden combinar entre ellas para dar lugar a una infinidad de posibles caminos. De entrada, probar todos los caminos es un problema inabordable.

Y eso si no tenemos en cuenta la prueba de requisitos no funcionales, como el rendimiento de un sistema ante una exigente carga de usuarios, o requisitos específicos de seguridad (por ejemplo, en un sistema bancario) para protegerse de usuarios malintencionados.

Principio 3: Cuanto antes se comience a probar…mejor

Corregir un bug con una revisión en la fase de captura de requisitos o en una prueba unitaria tiene un coste mucho menor a lo que costará corregir este bug cuando se detecte en una prueba de sistema, o peor aún, en una prueba de aceptación por el cliente. En demasiadas ocasiones existe una confianza excesiva en las pruebas de sistema, y todo el plan de pruebas (cuando existe) se reduce a estas. Se confía en que todos los componentes que no se probaron con una estrategia de pruebas unitarias y de integración se puedan entender bien a unos días del hito de entrega (cuando corregir un bug ya es demasiado caro, en lo que se denomina una prueba de integración «big-bang»).

Principio 4: Las aglomeración de defectos. ¡Los bugs siempre van en pandilla!

Entender esto es muy importante para plantear una buena estrategia de pruebas: los bugs suelen ir en grupo. Se concentran en determinados puntos de un sistema software, no manteniendo una distribución uniforme a lo largo del mismo. Conclusión: si encuentras un bug en un componente, es muy probable que hayan más. Con lo que una posible estrategia sería centrarse en mejorar las pruebas de aquellos componentes para los que se han reportado un número mayor de bugs, para ser más eficaces a la hora de cazarlos en fases tempranas.

Principio 5: La paradoja del pesticida

la necesidad de ajustar continuamente tu plan de pruebas… porque según este principio un plan de pruebas va perdiendo efectividad conforme se ejecuta sucesivas veces. Con lo que cada vez tenderá a encontrar menos bugs… ¡lo que no significa que no hayan! (vuelve a leer el primer principio). Se habla de paradoja del pesticida ya que estos matabichos usualmente sirven para un tipo de bichos, pero una vez no queda ninguno del tipo específico que mata el pesticida… ¡nadie te dice que no hayan otros bichos campando a sus anchas!.

Principio 6: Las pruebas se deben adaptar a necesidades específicas

Esto viene a enlazar con lo que he comentado antes. Si tu producto se centr

a en el ámbito de la seguridad deberás adaptar tus casos de prueba para intentar forzar situaciones o posibles escenarios no amistosos. Si quieres probar una intranet donde los servicios más vitales son los de imputación de horas y el de vacaciones, es lógico centrarse en estos servicios y no invertir tiempo en otros componentes infrautilizados.  Además, hay que tener en cuenta que los recursos en los proyectos son siempre escasos, con lo que en el inicio del proyecto hay que preguntarse… qué estrategia debemos seguir para encontrar y corregir lo antes posible los bugs en las funcionalidades de mayor valor para nuestros usuarios.

Principio 7: La falacia de la ausencia de errores

Para terminar, nos encontramos con la satisfacción del usuario y con el hecho de que los usuarios elijan tu software para resolver sus necesidades.Que hayas corregido muchos bugs no significa que finalmente tu software sea un éxito. En ocasiones hay que primar un buen time to market, para luego corregir los problemas de calidad que quedaron por el camino. Y esto si se hace de manera consciente y con una buena estrategia, a priori, no debe ser un problema.

Las pruebas y el proceso de desarrollo de software

Un proceso de desarrollo de software es la descripción de una secuencia de actividades que deben ser seguida por un equipo de trabajadores para generar un conjunto coherente de productos, uno de los cuales en el programa del sistema deseado.

Objetivos de un proceso de desarrollo

 Proporcionar una guía de ejecución del proyecto que defina para los técnicos la secuencia de tareas que se requieren y los productos que deben generar.

•  Mejorar la calidad del producto en:
•  Disminuir el número de fallos
• Bajar la severidad de los defectos
•  Mejorar la reusabilidad
•  Mejorar la estabilidad del desarrollo y el costo de mantenibilidad.
•   Mejorar la predecibilidad del proyecto en:
•   La cantidad de trabajo que requiere
•   El tiempo de desarrollo que se necesita

            Generar la información adecuada a los diferentes responsables de forma que ellos puedan hacer un seguimiento efectivo.

      El SDP define el qué, quién, cuándo y cómo del desarrollo de software.

       Cuatro actividades fundamentales que son comunes para todos los procesos de desarrollo de software :

       Especificación del software

       Desarrollo del software

       Validación del software

        Evolución del software

    Participantes en el  proceso de pruebas: actores y roles

Para poder entender los elementos que intervienen en el Proyecto de TI empezaremos a definir los siguientes conceptos:

Roles: El concepto está vinculado a la función o papel que cumple alguien.

Responsabilidades: Se define como la contribución activa y voluntaria al mejoramiento social, económico y ambiental por parte de las empresas, generalmente con el objetivo de mejorar su situación competitiva, valorativa y su valor añadido.

Actores involucrados: Un actor es todo individuo que se encuentra o forma parte de un grupo, organización, entidad, corporativo, público, social o privado, que tenga relación directa o indirecta con el proyecto a ejecutar.Un equipo de desarrollo de software está compuesto por lo menos de los siguientes roles de TI Gerente de Proyecto: Es el responsable de la definición del proyecto y de la asignación de recursos al mismo. Da soporte a las tareas de estimación y definición de las actividades contenidas en los planes y realiza la revisión y aprobación de los mismos.

Líder de Proyecto: Alguna vez te preguntaste, ¿entonces que hace el líder? Bueno te explico, este rol es el responsable de atender las necesidades de los Analistas de Sistemas, Arquitectos, Ingenieros de Software, Capacitadores, Responsable de pruebas, Testers, Responsable de calidad, Administradores de la configuración del proyecto y Administradores de la configuración global, brindando una solución a los requerimientos que soliciten. Establece el control de los avances del proyecto, asignaciones de trabajo, juntas de seguimiento y sobre todo dar buena cara y tener contento al cliente. En resumen, este rol es el responsable de llevar a buen término la ejecución del proyecto. ¿ha cambiado tu perspectiva?

Analista de Sistemas:

¿Y entonces el analista? Es el encargado del diseño del sistema: Análisis general, análisis detallado, diagrama conceptual, diseño y generación de la base de datos y normalización de la misma, documento de flujo de operación y especificaciones funcionales.

Recuerda la mayor parte del éxito de un proyecto está en el buen entendimiento y especificación de los requerimientos. No solo basta con tomar nota de lo que requieren los usuarios funcionales, un analista debe de convertirse en un consultor de negocios que proponga mejoras y soluciones a las necesidades del cliente. Pregúntate ¿Vas más allá de solo tomar notas?

Diseñador:

¿El verdugo de los desarrolladores? Bueno él es el responsable de la creación de un concepto de sistema que ayude a cumplir los objetivos de negocio fijados por los interesados, asegurándose que el sitio cumpla con las características de accesibilidad, navegabilidad, interactividad y usabilidad que garanticen una experiencia agradable al usuario. Hoy en día el diseño se ha vuelto fundamental para que un buen sistema de software invite a ser usado por sí solo. Ya no solo basta que un diseñador te genere plantillas como imágenes (png, jpg, etc), y las pase a construir a los desarrolladores dándoles la responsabilidad de la generación de los HTMLS (hablando de web), sino que las organizaciones cada vez esperan más sobre este rol, la exigencia de que el mismo diseñador sea el responsable de generar el HTML de esos diseños tan sofisticados y modernistas ya se da por hecho incluso que trabajen ya en mente con marcos de trabajo responsivos y dinámicos. ¿Te suena conocido, less, sass, boostrap? Te invito a que busques estos conceptos sé que te ayudarán a ser competitivo.

Ingeniero de Software:

¿Un ser que habla en ceros y unos, un todo poderoso, intocable, el héroe y el destino está en sus manos? Bueno algo así y nada lejano a la realidad, sin estas personas el software no podría generar más software, por lo tanto, su principal responsabilidad es definir y mantener el código fuente de uno o varios componentes, garantizando que cada componente implemente la funcionalidad correcta. Tiene responsabilidad por la integridad de uno o más subsistemas de implementación y de sus contenidos a lo largo del desarrollo. Es también responsable de asegurarse que el código generado esté libre de errores por medio de la ejecución de pruebas unitarias del código construido.

Responsable de Calidad:

¿Inspectores, auditores, el verdugo de los líderes? Pues gracias a este rol los proyectos van encaminados a buen éxito ya que su principal responsabilidad es de garantizar el cumplimiento de los compromisos hechos con el proyecto desde el punto de vista del proceso a seguir. Si un proyecto de desarrollo no cuenta con una metodología con procesos y procedimientos bien ejecutados la probabilidad de éxito se vuelve baja y tiende al caos y heroísmo y buena fe de los integrantes del proyecto para sacarlo adelante.

Responsable de Pruebas:

¿Otro verdugo o un aliado del desarrollador?, gánatelo como aliado, aprende de los issues que te reporta, hazlos tuyos, documéntalos corrígelos y que no te vuelvan a pasar. Esta persona tiene como responsabilidad garantizar que se cumplan los requerimientos funcionales establecidos para el producto y el que el producto esté libre de fallas, por medio de la planeación y ejecución de las pruebas a todo el software construido. Es el encargado de dar el visto bueno de que un producto o aplicación pueda pasar a un ambiente productivo, su responsabilidad es tan grande que se juega parte del éxito del proyecto en el.

Administrador de la Configuración del Proyecto:

¿Y dónde están las especificaciones del proyecto, cuál es la versión final, porque no tengo acceso a esa información, donde están los cambios que hice a mí página? ¿Te suena familiar? Por lo tanto, este rol es responsable del versionamiento y ubicación de cada producto de trabajo del proyecto que permita asegurar la disponibilidad de los mismos en un repositorio de proyecto incluyendo el código y la documentación generada durante el ciclo del proyecto. ¿No conoces mucho de este tema?, algunos softwares de control de versiones de código “Subversión, TortoiseSVN, GitHub, TFS”

Cliente:

¿El cliente?, si claro el cliente, para la consecución exitosa de las actividades y fases del proyecto, es indispensable la participación de personas clave del cliente relacionadas al proyecto; así como también del personal de Sistemas.

Las personas por parte del cliente que se identifiquen para participar en el proyecto deberán tener el tiempo suficiente para agendar entrevistas con los Analistas de Sistemas, con la finalidad de que se revisen y se especifiquen las reglas de negocio y procesos críticos. Su participación es muy importante durante las fases de análisis, diseño, pruebas y capacitación.

Es responsabilidad por parte del cliente designar a un líder de proyecto de su parte que funja como el canal principal sobre el cual se estarán llevando acuerdos, notificaciones, reuniones de avance y autorización de requerimientos, así como de la aceptación del producto y proyecto.

El líder de proyecto que representa al cliente es responsable de establecer los requerimientos, revisarlos y autorizarlos a fin de definirlos como base para la construcción del software.

Es también responsable de la verificación y validación del producto de software entregado a fin de que permita aceptar de conformidad la entrega del producto y cierre formal del proyecto.

  Proceso de pruebas:

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.

Existen diferentes maneras para realizar las pruebas de calidad, las mismas van dadas por el contexto que representa cada uno de los clientes en particular, en otras palabras, no hay un plan de prueba que pueda servir para todos los escenarios, porque puede ser que una prueba para un software ERP específico sea perfecta, pero en otro puede llegar a ser perjudicial.

TIPOS DE PRUEBAS DE CALIDAD DE SOFTWARE

Todas las pruebas de este tipo varían, no obstante, su finalidad sigue siendo la misma y es el hecho de comprobar y dar el visto bueno a todo el software de una empresa, sin importar que se trate de un ERP para empresas instaladoras o para empresas distribuidoras. A continuación se explican algunas pruebas de calidad:

PRUEBAS DE FUNCIONAMIENTO: Dentro de esta categoría es posible encontrar tres subgrupos, los cuales se clasifican, según sus objetivos, en:

Testing de función: Enfocada en conseguir informes sobre la aptitud de las funciones, los métodos y los servicios que componen el ERP

Testing de seguridad: Ideada para comprobar la seguridad de los datos que maneja el ERP para Pymes, es decir, los datos de la empresa.

Testing de volumen: Dirigida a medir la velocidad del ERP para procesar grandes cantidades de información en la base de datos, bien sea en entrada o en salida.

PRUEBAS DE USABILIDAD: La finalidad de éstas es comprobar la relación del usuario con el software de gestión empresarial, prestando especial atención a la interfaz, la experiencia del usuario, asistentes de ayuda integrados, interactividad, entre otras cosas.

PRUEBAS DE FIABILIDAD: Al igual que las de funcionamiento, se dividen en tres grupos:

Testing de integridad: Trata de valorar y calificar la resistencia a fallos que presenta el software.

Testing de estructura: Consiste en verificar que cada una de las partes que componen el diseño del software ERP se encuentren conectadas a las funciones correctas, en otras palabras, que no exista contenido huérfano en el ERP.

Testing de estrés: Se utiliza para evaluar el comportamiento del software ERP en situaciones poco usuales, como por ejemplo, una sobre carga de funciones, la saturación de la memoria, la restricción de los recursos compartidos, etc…

PRUEBAS DE RENDIMIENTO: Miden la relación función resultado de un ERP, éstas se dividen en:

Testing Benchamark: Se encarga de cuantificar el rendimiento de un nuevo componente del ERP, comparándolo directamente con otro existente.

Testing de contención: Ésta valora la capacidad de respuesta de un elemento, en cuanto a sus habilidades, al momento de ser requerido por diversos actores, un ejemplo de dicho elemento podría ser el registro de recursos o la memoria.

Testing de carga: Su finalidad es probar y asegurar los límites operacionales del software de gestión empresarial, mediante la aplicación de cargas de trabajo promedio. Por ejemplo, si se quiere hacer la prueba sobre un ERP para una empresa de obras y servicios, es necesario indicar cuales son las cargas habituales de trabajo de las mismas.

PRUEBAS PARA LA CAPACIDAD DE SOPORTE: Existen dos formas de medirlo, éstas son:

Testing de configuración: Su principal objetivo es asegurarse que un ERP funciona de forma correcta, sin importar la configuración que la empresa decida aplicar, tanto a nivel de software como a nivel hardware. De igual forma es posible aplicar esta prueba como un medidor de rendimiento del sistema, o bien utilizarla en asociación con una prueba especializada en dicho tema.

Testing de instalación: Es probablemente una de las pruebas más importantes, puesto que de ella dependerá, en gran medida, la correcta implementación del ERP. Consiste en certificar que el software ERP se encuentra en plena capacidad de ser instalado en condiciones extremas de hardware o de software, como por ejemplo, problemas con la capacidad de memoria o con la velocidad de procesamiento.

Objetivos de prueba

La prueba de software es un elemento crítico para la garantía del correcto funcionamiento del software. Entre sus objetivos están:

1. Detectar defectos en el software.
2. Verificar la integración adecuada de los componentes.
3. Verificar que todos los requisitos se ha
4.  implementado correctamente.
5. Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al 

cliente:

Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.

Para lograr los objetivos propuestos, un ingeniero de software deberá conocer los principios básicos que guían las pruebas del software.

Diseño de casos de prueba

El formato para el caso de prueba de inicio de sesión contiene el siguiente formato:

    ID del caso de prueba

    Parte del escenario de prueba

    Pasos de prueba a realizar

    Datos de prueba

    Resultados esperados

    Resultados reales

    Resultado de la prueba (exitoso o no)

 Análisis de resultado

El análisis de resultados es la parte del informe en la que estableces las conclusiones del mismo. Debe ser claro y conciso, ya que el lector suele llegar cansado a esta parte del ensayo. Este análisis debe proponer cuestiones sobre el tema estudiado y plantear nuevas corrientes y perspectivas para futuras investigaciones. Desde un Como.com marcaremos una línea de abordaje y te explicaremos cómo hacer un análisis de resultados.

Pasos a seguir:

1-Empezar con las relaciones y generalizaciones que los propios resultados guardan con informe. Evidentemente, los resultados salen del desarrollo del informe, por lo que deberás mostrar esas relaciones en el análisis de resultados.

2-

Señalar los aspectos no resueltos y no tratar de ocultarlos. Delimita lo que no cuadre. En algunos ensayos puede haber algún resultado que no encaje o cuadre con el desarrollo de la investigación. Debes señalarlo y dejar abierto el tema.

3-

Mostrar las relaciones de tus resultados con trabajos anteriormente publicados, y también mostrar las nuevas conclusiones propias de tu ensayo.

4-

Explicar cuáles son las bases teóricas de la investigación y las posibles aplicaciones prácticas que pueda tener. De donde salen tus conclusiones y para que sirven.

5-

Formular detalladamente y de forma clara las conclusiones.

6-

Dar recomendaciones o sugerencias si es necesario, para facilitar la compresión del informe.

7-

Por último, resumir las pruebas que recogen esa información así como las fuentes.

Ambiente de desarrollo

Cada vez adquiere una mayor importancia la definición de procedimientos adecuados para administrar los ambientes de desarrollo de software, considerando que las empresas en la actualidad demandan la ejecución de múltiples proyectos simultáneos, con tiempos de puesta en producción exigentes, lo que conlleva a muchos desarrolladores de software, tanto internos como externos a la organización, compartiendo los mismos ambientes de desarrollo.

En este artículo, se exploran algunas buenas prácticas para la administración de ambientes de desarrollo, que van desde la definición las características adecuadas de infraestructura, base de datos, organización, plantación y procedimientos de cambios, homologación, altas y bajas.

Presentamos a continuación las buenas prácticas para ambientes de desarrollo de software.

Características del ambiente

Disponer de herramientas de:

Desarrollo (Eclipse, Java Empresarial, Visual Studio .NET, Bases de datos), instalado.

Logging (bitácoras), monitoreo de desempeño y debugging.

Control de versiones automatizado.

Herramientas de gestión de compilaciones (Build Management).

Podría residir en el computador personal del desarrollador, en otros casos, podría ser un servidor compartido en el cual varios desarrolladores trabajan sobre el mismo proyecto.

Ser lo más similar posible a los ambientes de pruebas y producción, a efectos de prevenir situaciones en las cuales el software desarrollado presente comportamientos distintos y errores en esos ambientes.

También en componentes de infraestructura de TI deben ser similares, por ejemplo, ¿usa clusters en producción?, si es así, ¿Cómo se asegura que los componentes instalados en un servidor puedan desplegarse hacia otros servidores que componen el cluster?. La única forma, es tener un ambiente de desarrollo o pruebas configurado en clusters en el cual los desarrolladores puedan validar sus programas.

Incluir replicas de todos los componentes con los cuales el software tendrá interoperación en producción incluyendo: otras aplicaciones cliente servidor, bases de datos relacionales, componentes middleware, interfaces, demonios (daemons), procesos personalizados, utilidades FTP y otros.

Utilizar nombres de dominio diferentes para los ambientes de producción, pruebas y desarrollo, a efectos de evitar confusión durante la ejecución de las pruebas.

Tener instalado el mismo manejador de base de datos, versión y calidad de los ambientes de prueba y producción. Si esto no es posible, usar herramientas automatizadas de propagación de una base de datos a otros.

Organización y plantación

Encargar la labor de determinar que ambientes se necesitan y asegurar que estén operativos cuando se necesiten a un arquitecto, gerente de operaciones o gerente de cambios.

Todos los equipos de desarrollo, tanto internos como externos a la organización, deben suministrar con antelación sus requerimientos de ambiente al ente encargado de la administración. Los tiempos de antelación deben ser prestablecidos en acuerdos de nivel de servicio.

Los requerimientos de ambiente de desarrollo deben ser documentados por cada proyecto, usando los formatos y plantillas prestablecidos).

Usados estrictamente sólo para desarrollo y pruebas (de los desarrolladores).

Los desarrolladores deben realizar su trabajo exclusivamente en ambiente de desarrollo, nunca en otros ambientes directamente.

Debe ser un ambiente distinto a los de pruebas y producción.

Deben contener sólo datos de prueba que no sean críticos para el negocio, por lo que deben disponerse de procedimientos para eliminar datos sensibles (blanquear datos), cuando se traen de ambiente de pruebas o producción.

Pueden disponerse de múltiples ambientes de desarrollo, pero es necesario asegurar que periódicamente sean homologados entre ellos y con los ambientes de pruebas y producción.

Contar con procesos claramente definidos y auditables para:

Asignación de ambientes.

Uso compartido.

Accesos múltiples.

Acuerdos de nivel de servicio.

Actualizaciones.

Upgrades.

Instalaciones.

Desincorporación.

Preparación.

Conectividad.

Asistencia a los múltiples equipos usuarios del ambiente.

Emitir reportes de uso y carga que asistan a la planeación.

Paradas de mantenimiento o instalaciones

Las paradas de mantenimiento o instalaciones de versiones, homologaciones, o correcciones deben en la medida de lo posible:

Ser planificadas en el mediano plazo.

Comunicadas a los equipos de desarrollo para considerarlas en su planificación.

Ejecutarse fuera de horario laboral, para no interrumpir las operaciones diarias.

Comunicadas al momento de inicio y finalización

Reindexar las de bases de datos cuando se realiza mantenimiento en las noches, para evitar que al día siguiente las pruebas tengan fallos por timeout.

Procedimientos de Cambio y Homologación

Asignar un administrador encargado de organizar los cambios al ambiente por múltiples equipo, el momento en que serán instalados y los procedimientos de revisión y aprobación de cambios.

Implementar procedimientos de control de código fuente, versiones y compilación. Utilizando herramientas automatizadas.

Realizar revisiones de código antes de comprometer los cambios en una versión e instalación en un ambiente, evaluar los componentes afectados y evitar instalación de cambios que afecten de forma adversa los componentes de otro equipo de desarrollo.

Notificar a todos los usuarios los cambios a instalar en un ambiente, para que tengan la oportunidad de revisar la afectación sobre sus componentes.

Realizar periódicamente comparaciones de configuración de ambientes, existen herramientas automatizadas capaces de comparar configuraciones, aplicaciones, bases de datos y la infraestructura subyacente.

Implementar controles que aseguren la reconfiguración de archivos de parámetros de configuración (por ejemplo Properties en J2EE) al movilizarlos de un ambiente a otro.

La virtualización puede ayudar a evitar riesgos por cambios en configuración de un entorno a otro.

Administración de accesos al ambiente

Puede tener controles menos estrictos de privilegios acceso al sistema, para permitir a los programadores hacer cambios de registro, base de datos, red o cualquier otro componente con mayor facilidad. En todo caso, estos accesos especiales deben ser autorizados (según procedimiento de autorización de accesos).

A pesar de poder tener controles menos estrictos de privilegios de acceso, las altas del sistema deben ser controladas, por medio de procedimientos de solicitud y autorización.

Las bajas de la organización o equipo de desarrollo deben registrarse lo antes posible en el ambiente de desarrollo. Adicionalmente, es necesario realizar una revisión periódica del listado de usuarios, e identificar usuarios que egresaron de la compañía y debían estar de baja.

La actividad de cada usuario debe registrarse en el log (bitácora), en caso de necesitar realizar alguna investigación