Los 10 mandamientos del Testing

Probar es esencial para garantizar que los sistemas funcionen según lo esperado; pero el proceso de testing puede resultar complejo y hasta abrumador. A continuación, revisaremos algunas estrategias de testing que ayudan a enfocarse en lo que es importante para que las instalaciones y upgrades marchen sin inconvenientes.

#1: Que el entorno de prueba represente al entorno real Tener un entorno de prueba que sea levemente distinto al entorno real no es efectivo. Un buen ejemplo para analizar es el de un dominio de Windows Active Directory. Un dominio con configuraciones de Políticas de Grupo altamente customizadas, con complejas configuraciones DNS, con múltiples dominios de confianza, con muchos miembros en los grupos y un gran número de objetos de cuentas, no va a ser representativo de un dominio separado que está vacío y no tiene una configuración real. La virtualización es una buena opción para este caso: se puede promover un domain controller en una máquina virtual, moverla a una red aislada para el testing y luego removerla del dominio de producción.

#2: Hacer que múltiples disciplinas del test lleguen al mismo resultado Al diseñar los pasos para una prueba, es necesario identificar los componentes que pueden ser testeados en dos formas distintas para llegar al mismo resultado. Por ejemplo, si se está considerando ir hacia una nueva versión de Windows Active Directory, se podrá hacer una restauración autoritativa de Active Directory por un lado, y una restauración del backup de sistema por el otro, para garantizar que ambas recuperen el sistema a un estado adecuado para trabajar. Esto puede ser beneficioso si, en el mundo real, fallara un mecanismo. Otra estrategia es hacer que una persona prepare el plan de pruebas y otra persona lo implemente, para garantizar que el plan sea claro y que nada se dé por garantizado o asumido en el testing.

#3: ¡Probar el rollback! Para los planes de testeo de un upgrade o la mejora de un sistema existente, debería probarse el proceso de reversión. Esto también se puede probar de múltiples maneras dependiendo del contexto del upgrade. Algunas estrategias incluyen remover un disco rígido en configuraciones RAID 1 (el disco rígido removido no tendría cambios), un full restore desde un backup, desinstalar funcionalidad del upgrade, backups de bases de datos, o simplemente usar equipamiento nuevo con el sistema actual apagado durante el upgrade.

#4: No proceder sin el testing Si surgen situaciones que interrumpen la fase de testeo, dejar en claro que el testing es una parte importante del proyecto total. Dependiendo de la situación, esto puede ser difícil de hacer entender o tener consecuencias políticas. Si otro tiene la potestad de decidir si se harán o no las pruebas, pero es uno quien tendrá responsabilidad en caso de fallas, es necesario alertar sobre esta situación.

#5: No olvidar el objetivo del testing: que no haya sorpresas en producción Las sorpresas son lo último que necesitamos en un entorno de producción. El testing profundo (representativo) ayuda a prevenir cualquier “experiencia de aprendizaje” cuando el nuevo sistema está en uso. Desde ya, el testing no puede ser 100% idéntico al entorno real, por lo que siempre existe el riesgo de que surja algún imprevisto. Por ejemplo, si se está probando una nueva versión de un software con un modelo de seguridad simple, como ser tener a todos los usuarios configurados con más permisos que los requeridos, cuando se vaya a producción se deberá ajustar el modelo de seguridad para que cumpla con los requerimientos operativos. Esto puede costar un tiempo valioso e introducir riesgos. Un testing profundo tendría un procedimiento documentado para la configuración de seguridad o scripts para configurar el sistema real tal como se usó en el entorno de prueba.

#6: Usar recursos pre-existentes y estándares de testeo Aunque no seamos testers certificados, igualmente debemos aprovechar los recursos existentes para ofrecer un testing confiable para nuestro entorno IT. Una rápida búsqueda en Internet de modelos de planes de testing puede ser útil. Si no se tienen requerimientos rígidos para el testing, existe libertad para el desarrollo del plan. Es necesario pensar bien el plan para que sea integral.

#7: No asumir nada Seguramente el testing brindará un buen ejercicio para las tareas rudimentarias asociadas con el entorno; pero algunas pequeñas piezas de funcionalidad pueden verse afectadas por el upgrade. Dependiendo del proyecto, esto puede incluir: opciones extra, cambios en los permisos y cambios en los archivos de logs. Esto puede ocurrir si se construye el monitoreo alrededor del comportamiento del archivo de logs de un sistema. Si hay un ligero cambio en la forma en la que se escribe el log después de un upgrade, el sistema de monitoreo puede requerir revisión. Siguiendo paso a paso, incluso las tareas elementales, se reduce el riesgo de que pequeños detalles obstaculicen el proyecto total.

#8: Usar la gestión de proyectos para coordinar el testing Contar con gestión del proyecto y con un sponsor gerencial le dará credibilidad al testing. Le permitirá a otras áreas en la organización entender que el testeo es esencial, y la gerencia tendrá una mejor comprensión de los pasos involucrados. Decir simplemente que se está probando la nueva versión de XYZ no resulta tan efectivo como involucrar a la gerencia en el plan del proyecto, compartiendo el estado del plan de pruebas, y colaborando en el testing con múltiples partes. Se debe garantizar que el documento de planificación del test esté disponible para que la gerencia del proyecto o el sponsor de la gerencia puedan ver continuamente el progreso; esto les permitirá tener una buena idea del trabajo y de los desafíos relacionados con el testing que se ha delineado.

#9: Garantizar que las fallas del test sean repetibles Prácticamente todo plan de test incurrirá en fallas. En los sistemas de prueba puede haber muchos administradores probando a la vez o cambiando la configuración, lo cual puede afectar las pruebas. Si ocurriera una falla durante el testing, se debe tomar nota e intentar repetirla. Luego, se deberá pedir a otros testers que realicen la prueba para ver si ellos también obtienen la falla. Si la falla es crítica al éxito general del proyecto, hay que involucrar recursos de soporte del producto para identificar el problema. Dependiendo del alcance de la falla, puede no hacer falta detener el proyecto total, y este proceso de identificación puede mantener las expectativas en línea hasta el estado final.

#10: Aferrarse al entorno de prueba Si se ha hecho todo el esfuerzo de crear un entorno de prueba completo, ¿por qué no aferrarse al mismo para seguir testeando en el futuro? Podría ser un entorno de prueba que se use para probar actualizaciones de versiones y cambios a la funcionalidad principal o para brindar entrenamiento. Solo hay que tener en cuenta las implicaciones de licenciamiento que puede tener un entorno de prueba de uso continuo.