Hace unos días leía un post de Craig Thomler acerca del error que es el testeo de páginas webs tributarias en periodos de recaudación. Craig Thomler es toda una eminencia en el Gobierno electrónico, ha sido responsable del programa de Gobierno 2.0 del gobierno de Australia. En resumidas cuentas el post habla acerca de los problemas que causados en la web del gobierno australiano en la unificación de acceso para el pago de impuestos . Los problemas de planificación de rendimiento en servicios on line y los previsibles errores que generan, especialmente en el caso del sector público, y el malestar que genera a los ciudadanos en una situación obligatoria e incómoda como el pago de impuestos. El caso es que el post tocaba dos aspectos que conozco más o menos bien: el arranque a productivo de proyectos digitales complejos y la dificultad de detectar previamente problemas de funcionamiento de servicios masivos. Esto me  llevó a reflexionar acerca de lo que es razonable que esperemos de la web pública, lo que es aceptable y cómo influye esto en aquello a lo que podemos aspirar.

En internet lo natural es testear

Probar es algo intrínseco a la informática. Su propia naturaleza  hace que prácticamente todo funcione  por la iteración de prueba y error hasta llegar a lo esperado. Sin embargo, lo normal es que estas pruebas se hagan antes de ponerlo a disposición del público. Esto es relativamente fácil de decir, pero Internet ha sido algo realmente disruptivo (palabra de moda) por dos motivos:

1. El consumo de recursos de un sistema puede llegar a ser masivo. ¿Cómo puedes prever que tu página vaya de portada de menéame y se te caiga por el número de visitas? ¿Cómo puede afectar que miles de personas interactúen sobre una misma base de datos a la vez? Ciertamente, cuando una tecnología esta controlada, la incertidumbre recae más en el cuánto (cuanta gente viene) que en el cómo (de qué manera puede afectar al sistema la interacción de muchos actores simultáneamente). Sin embargo, la competitividad obliga a la innovación y esta a probar cosas que antes no se han hecho o no de la manera que se pretende.
2. Qué podemos saber lo que la gente hace y lo que no. Antes a lo más que podíamos aspirar es que algo fuera resultón y gustara a un número definido de personas y luego…. esperar a ver si le gustaba al resto. Ahora podemos probar, tocar colores, textos y formas y saber si algo funciona realmente bien o no lo hace en tiempo real.

Estos dos factores hacen que Internet tenga el testeo no tanto como una condición más o menos deseable, sino como un imperativo de suficiencia técnica y  de competitividad. Si no pruebas posiblemente algo estalle y si no pruebas, posiblemente alguien pase por encima tuya.

Testeo, testear y trasteo

Ahora bien, no todas las pruebas son iguales ni afectan de la misma manera a la vida de una web. De esta manera podeos habar de:

Test de rendimiento.

Normalmente un desarrollador prueba el rendimiento de una solución previa a la publicación de una web. De hecho, suele hacerse en la tecnología que lo soporta más que en la web concreta… digo normalmente porque cada proyecto es un mundo y  los plazos aprietan. Algunas veces se lanzan las cosas  sin probar del todo y a veces pasa, como apunta Craig Thomler, que los árboles tocan el claxon (Sim City) o que los mapas son absurdos (Apple Maps). Sin embargo, a veces uno puede haber probado, probado y probado y de repente el público se comporta de manera imprevista, o un componente de un tercero (por ejemplo una interacción con una API) rompe el sistema. No quiere decir esto que alguien lance el trabajo sin terminarlo, sino que a veces la realidad supera el más delirante de los sueños de la ingenieria.

Testeo A/B:

Es el testeo propio del diseño web y del que ya hemos hablado aquí. En él tratamos de comprobar una hipótesis sobre el diseño para mejorar la web. Por ejemplo, el gobierno británico hizo un interesante caso de testing para su organización de transplantes para que la donación de órganos con  resultados que posiblemente supongan muchas vidas.

Este test podríamos considerarlo como inocuo, sin embargo, pensando en un modelo burocrático normal de absoluta igualdad e impersonalidad ¿no sería un problema que a alguien por azar le toque una web para pagar un impuesto de manejo más fácil que otros?

La beta contínua

El concepto de Beta continua está muy asociado a la innovación y a la constante revisión de un sitio o un servicio. Esto, a fin de cuentas, no deja de ser la concepción de un entorno digital como un test constante. Esto, que en principio sería comporta una imagen positiva no deja de ser un problema ¿Cuándo consideramos que un servicio está lo bastante consolidado para pasar al público? En el mundo de la web todavía no está tan consolidado pero, por ejemplo, en el mundo de los videojuegos se ofrecen como betas proyectos en su fase alfa que, simplemente no funcionan o lo hacen de manera muy diferente a la esperada. ¿Podemos, por ejemplo, dar como válido que en 2015 una web de un gobierno de cierta entidad lance como novedad poder descargar un formulario como si estuviéramos en 2001? No, aunque lo llames beta.

Entonces ¿qué podemos testear?

Lo primero que debemos tener claro es que todo proyecto digital tiene una función y esa función básica debe funcionar de manera satisfactora antes de salir a producción. Una vez hecho eso, podemos empezar a probar:

1. Que no afecte a las condiciones mínimas de acceso: Si por ejemplo queremos probar un procedimiento que solo se puede hacer de manera telemática y queremos probar diseños con un plugin muy específico… debemos dejar siempre la opción de un mecanismo alternativo de pago. Si no lo hacemos así, estamos bloqueando la funcionalidad a una parte importante del público.
2. No discriminación: pongamos, por poner un ejemplo, que tenemos un diseñador gráfico que trabaja con una paleta de colores absolutamente ininteligible para daltónicos. O, ejemplo más común, diseños que no estan adaptados a los lectores de webs para invidentes: estamos discriminando a un colectivo.
3. Que el impacto sea el mínimo pero suficiente: ¿Es necesario probar el color de los botones de un sitio web de impuestos justamente en el botón de pagar? Posiblemente, en algún momento de su vida sí, pero antes de eso, probar botones, textos, bordes, etc… pueden probarse en la misma web en otros puntos quizá menos críticos. Siempre debemos buscar el testeo que nos permita tener una muestra representativa de los usuarios reales pero, además, pensando que no siempre tenemos que ir al último extremo a probar.
4. Que suponga un razonamiento que esconda una mejora real y previsible: Probar a lo loco es sencillo y propio de la desesperación. Antes de probar cualquier cosa, piense cuál es el problema, cuáles pueden ser las soluciones y cuánto puede suponer de beneficio… porque a lo mejor un test estupendo y maravilloso puede suponer solo una mejora de un 0,05% respecto a la solución previa que afecta al negocio de manera muy marginal

¿Y si se me encuentro con una bomba?

Como decíamos, a veces los proyectos tecnológicos se encuentran con situaciones imprevistas derivadas de un trabajo mal hecho o de un comportamiento imprevisto de público o tecnología. Es por ello que a veces, como dicen los estadounidenses «shit happens». En ese caso:

1. Antes de hacer un cambio a productivo prevea etapas lógicas de saltos parciales de funcionalidad para que los errores sean detectables rápidamente y recuperables en un plazo corto de tiempo. Buscar una aguja en un pajar es difícil, hacerlo con la responsabilidad de miles de que miles de personas estén  sin cobrar su pensión es el infierno.
2. Ser transparente: Las cosas a veces salen mal, y sobre todo cuando algo es nuevo. Si hay algo que molesta mal que no  poder hacer lo que tienes que hacer en su momento, es que nadie te de una razón de por qué pasa. Ser transparente no es una solución, pero reduce el foco de malestar. Decir: el sistema está indisponible por labores de mantenimiento (por ejemplo) es mejor que ver «error javascript»… pero si la página te dice que se está trabajando para mejorar x o y funcionalidad de la web, la gente lo entiende mejor.
3. Asumir la responsabilidad y el desgaste: Que te explote algo imprevisto (o previsto) por culpa tuya es malo… pero no tienen por qué pagarlo otras personas. Si, por ejemplo, en pleno periodo de recaudación la página de impuestos esta indisponible 1 día, lo menos es que  el usuario tenga un día adicional para poder realizar la declaración.

Es legítimo probar la web, dentro de lo que es razonable: no impedir a la gente ejercer sus derechos, cumplir sus obligaciones y discriminarlos. Aún así, el rápido desarrollo tecnológico no deja mucho margen de error y es fácil encontrarse con problemas, incluso enormes, sin preverlos. Esto no puede ser una obsesión porque nos lleva a la obsolescencia que nos tiene acostumbrado el sector público. Hay que probar, arriesgar, acotar el riesgo pero, sobre todo, contar con los mecanismos para gestionar estos problemas que puedan surgir pensando en que siempre es el ciudadano el beneficiario de estas mejoras, y no el sufridor de las mismas.

Con este post nos vamos de vacaciones hasta septiembre. Espero a la vuelta traer muchas novedades, pero uno nunca sabe con estos asuntos