Un examen en línea con ciento cincuenta alumnos a la vez: cómo llegar sin sustos

Por qué un examen simultáneo no se parece a un día normal

En una mañana lectiva corriente el uso de la red está repartido: un grupo ve un vídeo, otro busca información, en el aula de al lado nadie ha encendido nada. Un examen en línea rompe ese reparto. Todos los dispositivos hacen lo mismo, a la vez y concentrados en dos o tres espacios, durante una hora sin margen para repetir.

Hay además dos momentos especialmente exigentes, al principio y al final. Al arrancar, ciento cincuenta equipos salen de suspensión, se conectan, se autentican y abren la misma plataforma en el mismo minuto. Al entregar ocurre lo simétrico. Salvo que ahí ya no se puede decir «espere y vuelva a intentarlo». Entre medias el consumo suele ser modesto.

Por eso este escenario rompe redes que el resto del curso funcionan sin quejas. Que en marzo nadie haya abierto una incidencia no dice gran cosa sobre lo que pasará el día de la prueba, porque ese día se pide algo que no se ha pedido nunca.

Cuatro preguntas que responder con antelación

Antes de tocar nada, lo primero es saber de qué se está hablando, y eso son unos pocos datos que casi nunca están escritos en ningún sitio. Esos datos están en jefatura de estudios, así que la primera gestión es pedirlos. Son también los que necesita quien mantiene la red para decir si el escenario está cubierto.

• En qué espacios se hará. No es lo mismo repartir ciento cincuenta alumnos en seis aulas que juntarlos en un único espacio grande.
• Cuántos dispositivos habrá conectados a la vez, contando los del profesorado que vigila y los de reserva.
• Con qué se van a conectar: equipos del centro, dispositivos 1:1, portátiles de casa o una mezcla. La mezcla es la que más casos raros genera.
• En qué estado están: batería cargada la víspera, sistema y navegador actualizados, sin una actualización pendiente que decida instalarse esa mañana.
• A qué hora abre y cierra la ventana de entrega, si la plataforma la cronometra.

El ensayo previo es el consejo más útil de este artículo

Si de todo el artículo solo se puede aplicar una cosa, que sea esta. Haga un ensayo con el grupo, en el aula donde se hará la prueba y a la hora a la que se hará. Con dos portátiles por la tarde no basta. Tienen que ser los alumnos que van a examinarse entrando en la plataforma a la vez. Media hora la semana anterior evita casi todo lo que suele salir mal.

No tiene que ser un examen. Basta un cuestionario corto sin nota que obligue a recorrer el camino completo: encender, conectarse, entrar con su cuenta, abrir la actividad, escribir algo y entregar. Ese recorrido entero es el que importa, porque los problemas se concentran en los extremos, en el arranque y en la entrega.

Lo que se descubre es siempre concreto y se puede arreglar con tiempo: el alumno que no recuerda su contraseña, el portátil que arranca una actualización de veinte minutos, la esquina del aula donde la señal llega peor, la plataforma que pide un permiso del navegador que nadie había aceptado. Encontrarlo el martes anterior es un recado; encontrarlo con el reloj corriendo es otra cosa.

• Mismo espacio, misma hora y mismo grupo que el día de la prueba.
• Recorrido completo: encendido, conexión, acceso con la cuenta del alumno, apertura de la actividad y entrega.
• Con los dispositivos reales, incluidos los que trae el alumnado de casa.
• Apunte qué falla y a quién, porque esa lista es el trabajo pendiente de la semana.

Las cuentas y los accesos se comprueban dos semanas antes

El fallo más frecuente de una prueba en línea llega por otro lado. Un puñado de alumnos no puede entrar. Y casi siempre son casos sueltos, que se resuelven en cinco minutos si se detectan a tiempo y bloquean la mañana entera si aparecen a las nueve y cuarto. El que se incorporó en enero y nunca llegó a tener cuenta, el que la tiene pero no está matriculado en el aula virtual de esa asignatura, el que arrastra una contraseña caducada.

La comprobación tiene que hacerse con credenciales de alumno. Una cuenta docente entra en sitios donde una de alumno no entra, así que probarlo desde el despacho no demuestra nada. El ensayo previo cubre esto de forma natural.

Y un detalle que se olvida a menudo. Compruebe que el filtrado de contenidos del centro no bloquea la plataforma del examen ni los dominios auxiliares de los que tira, que a veces no llevan el mismo nombre. Si el filtrado trabaja por categorías, una herramienta nueva puede haber caído en una categoría cerrada sin que nadie lo sepa. Se verifica en dos minutos desde un dispositivo de alumno.

El plan B, que casi nadie prepara

Aquí está la diferencia entre un incidente y una crisis. Un examen en línea puede torcerse por motivos que no dependen del centro, como la conexión de la operadora o la plataforma del proveedor, y lo que se decide en ese momento es una cuestión académica: si se sigue, si se para, si se repite. Esa decisión no puede tomarla el responsable TIC en el pasillo.

Por eso el plan B se acuerda antes con jefatura de estudios y se pone por escrito, aunque sean cinco líneas en un correo. Fije además un umbral: cuántos minutos de interrupción se toleran antes de dar la prueba por suspendida. Sin ese número, la decisión se retrasa mientras la situación empeora.

• Se cae la conexión del centro a mitad de prueba: ¿se espera, se amplía el tiempo, se continúa otro día, o hay una versión en papel?
• Un alumno pierde la sesión: ¿vuelve a entrar, se le amplía el tiempo, pasa a un equipo de reserva? Decidido antes, evita agravios comparativos.
• La plataforma va lenta: quién comprueba si el problema es del centro o del servicio, y en cuánto tiempo se responde al aula.
• El umbral de interrupción a partir del cual la prueba se aplaza, y quién tiene la potestad de decirlo.

Acotar lo que el alumno puede abrir durante la prueba

Es una petición razonable de cualquier departamento didáctico y hay que tratarla con precisión, porque aquí se prometen cosas con demasiada alegría. Lo que sí existe hoy son dos capas. Una es el filtrado de contenidos, que decide a qué destinos se puede llegar desde el dispositivo y que suele gestionarse por categorías, de modo que se pueden cerrar bloques enteros durante la franja del examen. La otra es el bloqueo remoto, que corta la navegación de un equipo desde el panel y se retira igual de rápido.

Lo que no se puede dar por supuesto es un «modo examen» que permita únicamente la plataforma de la prueba y cierre todo lo demás sin efectos colaterales. Puede existir o no. Depende del servicio contratado y del tipo de dispositivo. Es justo el tipo de función que se pregunta al proveedor por escrito y se comprueba en el ensayo. Si no se ha probado con el grupo, no se puede prometer en el claustro.

Y hay una pieza que no es técnica y hace buena parte del trabajo: la política de uso de dispositivos. Una norma escrita, conocida por alumnado y familias, que diga qué está permitido durante una prueba y qué consecuencias tiene saltársela, ordena el comportamiento más de lo que la mayoría espera. La herramienta acota; la norma sostiene la decisión después.

El día: quién está, dónde y cómo se avisa

Lo último que se prepara es el reparto de personas, y es lo que más veces se deja al azar. La regla principal es procurar que el responsable TIC no tenga clase a esa hora. Si la única persona que puede resolver el problema está dando lengua en la tercera planta, se resuelve cuando suene el timbre. Y eso es tarde. Cambiar una guardia cuesta muy poco.

Después, el canal de aviso. Que un profesor salga al pasillo a buscar a alguien es la forma más lenta de pedir ayuda. Acuerde un canal único —un teléfono, un grupo de mensajería del claustro, la extensión de conserjería— y dígaselo por escrito al profesorado que vigila.

El resto son detalles pequeños que evitan sorpresas. Y cuando termine, dedique diez minutos a anotar qué falló y qué habría que cambiar. En la próxima convocatoria esas notas valen más que la memoria de nadie.

• El responsable TIC, sin clase asignada durante la franja de la prueba.
• Un canal de aviso único, conocido por todo el profesorado que vigila.
• Datos mínimos al avisar: aula, número de alumnos afectados y mensaje de error literal.
• Equipos de reserva encendidos, cargados y con sesión iniciada.
• Comprobación breve quince minutos antes y notas escritas al terminar.