Lo que debería ser la conclusión de este artículo va a ser el planteamiento inicial. Los clientes (o por lo menos el 99% de ellos) quieren ver contenido propio cuando están probando features en pre-producción. Puede sonar tajante pero es la cruda realidad. Te sorprenderá cómo he llegado a esta conclusión.

A los clientes les encantó esta foto del doctor Mathew Svenson. Incluso me llamó mi jefe para felicitarme.

Estoy seguro de que tus compañeros piensan que eres el alma de la fiesta, te llaman Devops Harlem y se parten de risa con los comentarios que dejas escondidos en tu código. Sin embargo, también estoy seguro de que a la gran mayoría de los clientes no les entusiasma que los nombres de los usuarios de prueba de tu app sean personajes de Juego de Tronos. Perdónalos, Señor, porque no saben lo que hacen.

Qué datos se esperan en el entorno de pre-producción.

– El botón debería de ser naranja.
– Si, no hay problema, esto es solo una prueba.
– Ya, pero no es naranja.
– Correcto, es una  prueba para ver que podemos cambiar el color desde un panel de configuración. Podéis utilizar cualquier color de la paleta.
– Pero es verde y lo quiero naranja.
– Si, podéis configurarlo con el color que queráis, por ejemplo naranja.
– Entiendo, ¿por qué no es naranja?

Ejemplo de conversación con un cliente después de hacer testing.

En el caso anterior, nuestro cliente quiere ver un botón naranja porque en los diseños había un botón naranja y creedme, no parará hasta que cumpla su objetivo: ver un botón naranja. Será como el T-800 persiguiendo a Sarah Connor hasta que consiga eliminarla. Cuando hagamos la próxima demo con esa super mega feature nueva que nos ha llevado 2 meses dirá, muy bien todo pero, ¿por qué el botón todavía es naranja?

Aunque parezca estrambótico, he vivido demasiadas situaciones parecidas a esta como para no aprender. La solución es tan sencilla como intentar reflejar los datos y configuraciones que se muestran en los diseños de la manera más fiel posible. Hacerlo no va suponer más trabajo pero si nos evitará posibles fricciones.

Una imagen vale más que mil fixtures

Siendo sinceros, los textos no suelen ser un gran problema siempre que guardemos cierto decoro. Es cierto que no siempre es fácil y que somos unos diablillos que prefieren tener un usuario llamado Aitor Tilla que uno llamado Antonio García Perez. Lo cierto es que, habiéndonos decantado por la primera opción es posible que pase desapercibida y no nos cause ningún infortunio.

Las principales quejas vienen normalmente dadas por el uso de imágenes inapropiadas ya que es el aspecto que puede causar más fricción si no cumple con las expectativas de nuestro cliente. 

Para probar que una imagen se sube a un servidor y se visualiza correctamente nos sirve cualquier imagen que cumpla con los requisitos de peso, formato o dimensiones que hayamos especificado, independientemente del contenido de esta. Nosotros sabemos esto, pero de veras, a veces nuestros clientes no son conscientes de ello y son incapaces de visualizar la aplicación que les estamos desarrollando de manera abstracta. Siendo justos, no tienen por qué poseer esta capacidad aunque es muy deseable que la tengan para trabajar de un modo menos rígido.

Pongamos un ejemplo. Estamos desarrollando un marketplace de sillas de oficina y necesitamos llenar nuestro servidor de datos de prueba. A continuación nuestro dato de prueba:

Qué mejor imagen de prueba para una tienda de sillas que un inodoro. 

No hace falta decir que nuestra imagen del inodoro está en lo más alto de la escala de molabilidad, y si bien es cierto que puede que nos ganemos el corazoncito de nuestros clientes más guasones, también es posible que otros no entiendan que estos datos se perderán en el tiempo, como lágrimas en la lluvia.

En estos años he probado de todo: utilizar imágenes de series de televisión, de videojuegos, de películas y siempre han terminado causando algún tipo de fricción por lo que llegué a la conclusión de que el mejor dato de prueba es un dato plausible a nuestra plataforma y, a poder ser, un dato existente. Me explico.

Si seguimos con el ejemplo del marketplace de silla simplemente intentemos conseguir contenido de nuestros clientes. Si queremos diferenciarlo basta con añadir una marca de agua a nuestra imagen. Con esto será sencillo identificar nuestro contenido de prueba y a la vez respetar la idea que nuestro cliente tiene de la plataforma. ¿Por qué siendo tan sencillo nos cuesta tanto hacerlo?

El uso de APIs

Para ayudarnos podemos valernos del uso de apis que proporcionan datos de prueba planos y sosos, en definitiva, lo que andamos buscando. Por ejemplo, randomuser ofrece usuarios de  prueba, puedes utilizar avatares de lego pero debes de ser fuerte y no caer en la tentación. Otro ejemplo sería fakestore, donde obtendremos productos de prueba. Son solo dos ejemplos pero podéis encontrar muchas APIs que os ayudarán y de las cuales muchas son gratuitas.

Conclusión

Es cierto que en desarrollos de producto propio puede haber más flexibilidad, pero mirado desde fuera, si el esfuerzo es el mismo ¿por qué tomar el camino que más problemas puede dar?

Nuestros clientes quieren ver un reflejo lo más real posible de lo que va a ser el producto final. Así de sencillo. Esto no es más que una opinión personal basada en todas la experiencias que he vivido desarrollando productos para terceros, puede que tu experiencia sea distinta y me encantaría conocerla de ser así.

¿Es posible que los desarrolladores tengamos un gen que nos hace comportarnos como imbéciles cuando tenemos que introducir un dato para nuestras pruebas? Conforme escribo estas líneas estoy subiendo una imagen para probar una feature en un marketplace de camisetas en el que estoy trabajando y os prometo que la camiseta en cuestión contradice todo el planteamiento del artículo. Igual estoy tratando de ponerle puertas al campo.

Descubre más artículos en nuestro blog