Lo que el testing manual entre navegadores les cuesta de verdad a las agencias

Las agencias web rara vez viven de un único proyecto. El caso normal es una cartera: veinte, treinta, cincuenta webs de clientes que se atienden, se actualizan y se mantienen en marcha. A ese mantenimiento pertenece un trabajo que apenas figura como partida propia en ningún presupuesto y que, aun así, se repite con regularidad: comprobar tras cada cambio si la página sigue viéndose en todas partes como debe. Este trabajo invisible tiene un precio muy visible — solo hay que calcularlo una vez.

Un ejemplo de cálculo, planteado deliberadamente a la baja: una web de cliente tiene ocho tipos de página que cubren el riesgo de layout — página de inicio, dos plantillas de contenido, panorama de servicios, formulario de contacto, artículo de blog, páginas legales, página de error. Se comprueba en tres navegadores y tres clases de dispositivo. Eso da 72 vistas por web y pasada. Quien necesite solo medio minuto por vista — abrir, hacer scroll, mirar — está ocupado más de media hora. Por web. Por pasada.

Ahora bien, esa cifra se multiplica en dos direcciones. Primero, por la cartera: con treinta webs atendidas, la media hora se convierte en una jornada laboral entera de no hacer otra cosa que mirar. Segundo, por el tiempo: los gestores de contenidos y sus plugins piden actualizaciones regulares, a menudo mensuales, por razones de seguridad casi siempre inaplazables. Cada una de esas actualizaciones puede desplazar el layout — y debería, en rigor, disparar una pasada de comprobación. Quien suma ambas cosas aterriza rápidamente en varios días-persona al mes dedicados exclusivamente a inspección visual repetida.

En la realidad, esta cuenta rara vez se paga — y justo ese es el problema. Poquísimos contratos de mantenimiento desglosan el testing de navegadores como partida. El trabajo acaba, pues, o bien sin pagar en el margen de la agencia, o bien se recorta tácitamente: se comprueba ya solo el navegador propio, ya solo la página de inicio, ya solo cuando hay tiempo. Ambas son decisiones económicas, aunque rara vez se llamen así. La primera cuesta beneficio; la segunda compra riesgo.

La misma cuenta puede plantearse también desde el lado del presupuesto: ¿cuánta comprobación cabe siquiera en un contrato de mantenimiento habitual? Un cupo de dos horas al mes queda casi siempre agotado con actualizaciones, pequeños cambios de texto y soporte ocasional antes de que haya empezado la primera revisión de navegadores. La inspección visual no compite, por tanto, con tiempo muerto, sino con otro trabajo más visible — y pierde esa competición estructuralmente, porque su ausencia, al principio, no la nota nadie. Justo por eso sirve de poco apelar a la disciplina. Una comprobación que deba producirse con fiabilidad tiene que figurar como partida propia pagada en el contrato o volverse tan pequeña en esfuerzo que ocurra de pasada. En la práctica hacen falta casi siempre ambas cosas: la partida, para que el trabajo se pague, y la automatización, para que quepa dentro de la partida.

A eso se añade un factor que las tarifas por hora no reflejan: la inspección visual repetida fatiga, y los ojos fatigados pasan cosas por alto. Quien contempla por cuadragésima vez la misma página de inicio ve lo que espera ver — no los tres píxeles de desplazamiento en el header ni el botón que en pantallas estrechas ahora salta de línea. La fiabilidad de la comprobación baja precisamente allí donde su volumen sube. Las personas son excelentes juzgando críticamente un layout una vez, y malas juzgando críticamente el mismo layout, sin cambios, todos los meses.

¿Qué cuesta, a la inversa, no comprobar? La variante más cara es la más frecuente: el cliente descubre el fallo primero. Un formulario de contacto roto en el iPhone, un menú que se superpone en Firefox — semanas sin que nadie lo note, hasta que llega un correo enfadado. El verdadero daño rara vez es el coste de reparación, sino la pérdida de confianza: el contrato de mantenimiento que debía impedir exactamente esos casos, visiblemente, no ha funcionado. A eso se suman intervenciones de bomberos a deshora, que desplazan el trabajo planificado y generan a su vez costes derivados.

En este punto la automatización cambia la cuenta — no porque el software mire con más atención que una persona, sino porque paraleliza la generación de las vistas y asume la comparación. Los servicios de capturas generan a partir de una URL, en poco tiempo, el juego completo de vistas de navegador y dispositivo; en ScanU, una pasada así dura unos 30 segundos y cubre Chrome, Firefox y Safari en vistas de móvil, tableta y escritorio. El desarrollo de un ciclo de prueba de este tipo lo explica ScanU en su web. De media jornada de clics sale un cuarto de hora de revisar informes.

La palanca decisiva no es, con todo, la captura suelta, sino la comparación. Si tras cada cambio aprobado se guarda un estado de referencia, en la siguiente actualización ya nadie tiene que juzgar 72 vistas — sino solo los puntos en los que algo ha cambiado. La máquina responde a la pregunta «¿hay algo distinto de antes?»; la persona, a la pregunta «¿es grave?». Es un reparto de trabajo claramente mejor que el anterior, en el que la persona debía responder ambas preguntas a la vez, vista por vista.

A la cuenta honesta pertenecen los costes de la herramienta. ScanU escalona por créditos, proyectos y número de dispositivos: el nivel gratuito comprende 500 créditos al mes con un proyecto; el nivel Pro, 3000 créditos y cinco proyectos por 19 euros; Pro+, 10000 créditos y diez proyectos por 29 euros; el nivel Max, 50000 créditos y veinte proyectos por 49 euros al mes — los detalles los enumera la tabla de precios de ScanU. Si eso compensa puede recalcularlo cada agencia con su propia tarifa horaria: los costes mensuales del nivel más grande equivalen, en la mayoría de las agencias, a menos de una sola hora de trabajo facturable.

El escalonado por proyectos y créditos impone, de paso, una disciplina útil: ¿qué proyectos de clientes necesitan comprobación en malla fina, cuáles se conforman con una pasada mensual? Una tienda online en desarrollo activo justifica más ciclos de prueba que una web de tarjeta de visita estática que se toca dos veces al año. Quien ordena así su cartera una vez obtiene, de paso, una base para la siguiente negociación del contrato de mantenimiento — el alcance de las comprobaciones se puede de pronto cifrar y presentar como servicio, en lugar de como silenciosa obviedad.

Cómo puede transcurrir en concreto una implantación sobre toda una cartera se deja esbozar en cuatro pasos. Primero, inventario: todas las webs atendidas en una lista, anotando por proyecto con qué frecuencia cambia allí algo realmente y qué tipos de página existen. Segundo, clasificación: los proyectos con cambios frecuentes o procesos de pedido reciben un perfil de comprobación en malla fina; las páginas tranquilas del fondo de cartera, uno mensual. Tercero, crear las baselines — y hacerlo sobre la base de un estado que alguien haya comprobado y aprobado, no simplemente del estado actual, que quizá ya contenga un fallo inadvertido. Cuarto, enganchar la comprobación en la rutina de actualización existente, de modo que tras cada actualización de plugin o de CMS se generen automáticamente vistas nuevas y se comparen con la baseline. De forma realista, esto se extiende a lo largo de algunas semanas cuando la cartera abarca treinta proyectos — no porque la técnica sea lenta, sino porque crear estados de referencia limpios exige por proyecto una decisión de calidad breve pero real, que nadie debería despachar en bloque.

Un efecto secundario es de naturaleza documental: los informes de comprobación compartibles se dejan integrar en la comunicación con el cliente. En lugar de asegurar «lo hemos probado todo», la agencia puede mostrar qué se comprobó cuándo y en qué navegadores. Eso no sustituye una relación de confianza, pero hace visible por primera vez el trabajo invisible — y el trabajo visible se paga más fácilmente que el invisible.

Abierta queda en muchas agencias la pregunta de quién mira realmente los informes. Para las pasadas con motivo concreto la respuesta es sencilla: quien instaló la actualización juzga las desviaciones notificadas — esa persona puede clasificarlas más rápido. Para las pasadas regulares sin motivo concreto se acredita un turno rotatorio, como el que muchos equipos conocen del buzón de soporte: una persona designada por semana, con el mandato de registrar las anomalías directamente como tarea en lugar de darse solo por enterada. Lo importante es menos la regulación concreta que su existencia. Los informes que no pertenecen a nadie se convierten en pocas semanas en ruido de fondo — y entonces toda la automatización queda sin efecto, por muy fiable que funcione técnicamente.

Igual de claro debería estar qué no rinde la automatización. Las comparaciones de capturas comprueban presentación, no función: si el formulario envía de verdad, si el pago se completa, si la búsqueda encuentra — eso solo lo aclaran los tests funcionales o el trabajo manual. También el juicio sobre las desviaciones notificadas sigue siendo trabajo humano, y las falsas alarmas por banners publicitarios, carruseles o contenidos cambiantes cuestan a su vez tiempo hasta que los entornos de prueba quedan bien configurados. Quien introduce automatización cambia trabajo rutinario por trabajo de configuración y cuidado — el cambio casi siempre compensa, pero no es gratuito.

A la planificación realista pertenece, por eso: las primeras semanas son las más duras. Las carteras son heterogéneas — una web de cliente lleva un carrusel de noticias, la siguiente banners publicitarios cambiantes, la tercera un widget de reservas con datos del día. Cada una de esas fuentes produce al principio falsas alarmas, hasta que los ajustes de comprobación de cada proyecto quedan afinados. Quien no lo tenga en cuenta vive la implantación como una decepción y abandona antes de que el beneficio se haga visible. Más sensato es tratar el cambio como un pequeño proyecto interno: con responsable, presupuesto de tiempo y el objetivo declarado de tener al cabo de unas semanas, para cada proyecto, una señal de comprobación tranquila y digna de confianza. Las respuestas a las preguntas típicas de configuración las reúne el proveedor en las preguntas frecuentes sobre ScanU.

Y no para toda agencia la cuenta es igual. Quien atiende dos webs que rara vez cambian comprueba a mano en una hora lo que la automatización apenas haría más rápido. La matemática bascula con el volumen: con cada proyecto adicional, cada ciclo de actualización adicional, cada navegador de más en la lista de comprobación. Hay un punto en el que el trabajo manual es la elección más honesta — y uno a partir del cual solo lo parece.

Para empezar se ofrece un experimento controlado: reproducir un único proyecto de cliente cambiante en el nivel gratuito, dejarlo correr un mes en paralelo a la práctica actual y comparar después — desviaciones encontradas, tiempo consumido, falsas alarmas. Una visión general del servicio en español la da la página de inicio en español de ScanU. Tras ese mes hay sobre la mesa una cifra propia en lugar de una estimación.

Al final es una decisión sencilla sobre la forma de los costes. Comprobar hay que comprobar de todos modos — la única pregunta es si una agencia paga por ello, de forma recurrente, horas de trabajo cuya fiabilidad baja con la repetición, o construye estructura una vez y asume costes de herramienta corrientes. Ambas cosas son legítimas. Solo la tercera variante, dejar caer la comprobación en silencio, no es un ahorro. Es un crédito contra la confianza de los clientes, y ese crédito algún día vence.