El terremoto ágil de ayer en las redes sociales vino protagonizado por este tweet:
“Testing, as an activity by itself, has no business value”
— Rob Lambert (@Rob_Lambert) noviembre 12, 2012
A este tweet siguió el artículo Testing has no value en el blog Test Obsessed, en el que se defiende la validez de esta afirmación. Según Elisabeth Hendrickson, autora del blog, ni el testeo ni la programación tienen valor de negocio en sí mismo, sino que son un medio para llegar a un fin.
Nosotros estamos rotundamente en desacuerdo con esta afirmación. Siguiendo el mismo razonamiento de la autora, vamos a definir el valor de negocio de una actividad como el resultado que tiene a la hora de incrementar los ingresos o reducir los costes. Según este criterio:
El testeo contribuye al aumento de ingresos
El testeo puede contribuir al aumento de ingresos, en la medida en que contribuye a un menor número de fallos perceptibles por el usuario. Este aumento de calidad puede ser la diferencia entre clientes satisfechos que pagan por nuestro producto o clientes insatisfechos que buscan productos de la competencia.
El testeo contribuye a la reducción de costes
El testeo puede contribuir a la reducción de costes, en la medida en que contribuye a la detección temprana de errores. El coste de reparación de un error recién cometido es mucho menor al coste de reparación de un error cometido hace tiempo cuyo código posiblemente haya caído en el olvido de los programadores, o incluso haya venido heredado de otro equipo.
El testeo (automatizado) incrementa la productividad de los programadores (y por lo tanto reduce los costes) de dos formas: por un lado pueden introducir cambios en el código con la confianza de que si cambian alguna funcionalidad del código existente el sistema les avisará si han cometido un error; por otro lado la existencia de tests cubriendo la funcionalidad existente les permite centrarse en probar la funcionalidad recién implementada, sin tener que preocuparse por volver a probar el resto del sistema por si han cambiado algo inadvertidamente.
Por último el testeo reduce el número de errores que llegan a los sistemas en producción, con la reducción de costes que esto implica en cuanto a atención al usuario final o resolución urgente de bugs.
¿Pero el testeo no puede ser contraproducente?
Uno de los argumentos que emplea la autora para desacoplar los tests de su supuesto valor de negocio es que a veces un mejor testeo empeora la calidad. Sin embargo cualquier práctica mal implementada puede llevar a resultados no deseados.
Entonces, ¿he de testear porque sí?
Uno de los puntos parcialmente válidos del artículo, es que tanto el testeo como la programación, como actividades en sí mismas, no tienen valor de negocio: sólo tiene valor de negocio el software en manos de clientes que pagan. Es decir, no hemos de confundir actividad con logro.
Evidentemente, de la misma forma que programar un sistema totalmente diferente del que el cliente final desea no nos va a proporcionar ningún valor de negocio, testear de forma irracional sin tener claros los objetivos que perseguimos no nos llevará a ningún sitio. El testeo sólo tiene razón de ser cuando somos conscientes de por qué testeamos, de los beneficios que obtenemos al hacerlo, y cuando usamos la información que obtenemos de los tests para mejorar nuestro proceso de desarrollo y nuestro producto.
Conclusión
En conclusión, creemos que los tests tienen un inmenso valor de negocio, así que hay que tener sumo cuidado con lanzar afirmaciones en la dirección contraria para no confundir a nuestros clientes o gestores, que muchas veces ya ven esta actividad como algo superfluo, un coste añadido sin ningún beneficio aparente.
Desde PocketGamer.biz nos llega una interesante infografía sobre el idioma hablado por la mayoría de usuarios de dispositivos móviles, así como las tendencias actuales en cuanto a descargas, mercados emergentes, etc.
Uno de los datos más interesantes es que el 100% de las aplicaciones en el top 10 de ingresos en Japón están en japonés. Esto indica claramente que si queremos abarcar un mercado mundial hemos de realizar un esfuerzo por localizar nuestra aplicación al lenguaje y a las costumbres e idiosincrasias de nuestro mercado objetivo. O eso, u olvidarnos del 25% de descargas que representan ya el mercado chino y el japonés. ¿Qué opinas? ¿Localizas tus aplicaciones o sólo las publicas en inglés?
Cuando nos disponemos a desarrollar una nueva aplicación para iOS una de las primeras consideraciones a tener en cuenta es qué versión de iOS deberíamos soportar como mínimo. Soportar una versión antigua de iOS nos puede proporcionar un mayor número de usuarios para nuestra aplicación, pero a costa de no poder utilizar las últimas novedades de la plataforma, o utilizarlas de forma condicional, lo que puede complicar bastante el desarrollo.
Evidentemente para poder tomar una decisión es conveniente saber la cuota de mercado de cada una de las diferentes versiones de iOS. Y aquí es donde la cosa se complica. Apple, al contrario de lo que hace Google con sus estadísticas sobre Android, no publica estadísticas oficiales de la cuota de mercado de las diferentes versiones de iOS, así que hemos de buscar esta información en algún otro lugar. ¿Cuáles son las opciones?
- En primer lugar, si ya disponemos de una aplicación propia publicada, podemos extraer estadísticas de uso de dicha aplicación… porque estáis obteniendo estadísticas de uso de vuestras aplicaciones, ¿verdad? De todas formas este método solo funcionará si nuestra aplicación tiene soporte para todas las versiones de iOS que queremos medir y además cuenta con un buen número de descargas mensuales, cosa de la que no todos podemos presumir.
- Si no es éste vuestro caso, podemos esperar que algunos blogs publiquen información acerca de la cuota de mercado de las diferentes versiones de iOS, aunque esto suele ocurrir de forma puntual y cuando hay un cambio importante de versión de iOS. Por ejemplo, Chitika, una red de publicidad online, publica de vez en cuando informes acerca de la adopción de iOS, como el que publicaron el 2 de octubre en el que informan de una adopción del 60% de iOS en iPhones, con iPads y iPods un poco más retrasados.
- Por último, algunos desarrolladores publican de forma desinteresada sus propias estadísticas basándose en sus productos. Por ejemplo, David Smith, desarrollador de Audiobooks con más de 100.000 descargas semanales, publica sus estadísticas de versiones iOS sobre las que corre su aplicación, donde a fecha 2 de octubre también se aprecia que iOS 6 alcanza casi el 60% de los dispositivos (aunque no recoge estadísticas de versiones anteriores a la 4.x)
Una vez tenemos esta información podemos tomar una decisión informada acerca de la versión mínima a soportar, ponderando por un lado las funcionalidades de iOS con las que podremos contar y su impacto tanto en la experiencia de usuario como en el tiempo de desarrollo, y por otro, el porcentaje de usuarios a los que no daremos servicio.
¿Conoces alguna otra fuente en la que consultar esta información? Si es así, ¡compártela con nosotros!
Con todo el revuelo existente alrededor de HTML5 muchos clientes nos piden la implementación de aplicaciones usándolo para poder atacar a varias plataformas reduciendo el coste al máximo. ¿Nuestra respuesta? No.
Según nuestra opinión, a pesar de las aparentes ventajas que pueda proporcionar el realizar una aplicación con un solo código base para diferentes plataformas, los inconvenientes desaconsejan seguir ese camino.
¿Nos hemos vuelto locos? ¿Vamos en contra del resto del mundo que se dirige a toda máquina a una Internet perfecta implementada con toda la gloria de HTML5? Creemos que no. Y no somos los únicos. Facebook recientemente ha dado un paso atrás y ha publicado su aplicación para iOS rehaciéndola desde cero como aplicación nativa, abandonando así HTML5. ¿Y por qué? Tobie Langl, arquitecto UI de Facebook y miembro del core de Prototype, daba una serie de razones en la lista de correo de la W3C que coincide en gran parte con las razones que damos a nuestros clientes cuando nos preguntan por este tipo de implementaciones:
- Falta de herramientas que faciliten el diagnóstico cuando la aplicación falla en el dispositivo móvil, lo que se traduce en mayor tiempo de desarrollo invertido para diagnosticar dichos fallos
- Rendimiento horrible de pantallas con scroll: las plataformas móviles están optimizadas para cargar sólo el contenido que se ve en pantalla cuando nos desplazamos por listas con muchos elementos. Si utilizamos HTML5 hemos de cargar todo el contenido como ocurre con una página web, con la consiguiente bajada de rendimiento por el gran uso de memoria. La alternativa es implementar nosotros mismo algún tipo de lógica en Javascript que alivie el problema, con lo que de nuevo incrementamos el tiempo de desarrollo.
- Dificultad o imposibilidad de acelerar determinados contenidos mediante la GPU (Unidad de proceso de gráficos) con la consiguiente pérdida de rendimiento y suavidad en la aplicación
Además de estos problemas (y algunos otros), no hay que olvidar otro punto muy importante: la experiencia de usuario. La creación de una aplicación única en HTML5 implica dejar de lado los componentes nativos de cada una de las plataformas, así como la experiencia ligada a ellos. Es decir, el usuario se encontrará con un interfaz raro, que no casará con el resto de la plataforma.
Todo esto hace que el dinero y tiempo que nos podamos ahorrar al tener un solo código base lo gastemos en solucionar problemas de rendimiento, adaptar el interfaz a las diferentes plataformas, etc. Y lo peor de todo no es eso, es la posible pérdida de clientes o usuarios debido a una aplicación lenta o confusa que no sigue los convenios de la plataforma.
Dicho esto, ¿hay alguna ocasión en que no sea mala idea usar HTML5? No tenemos dudas de que HTML5 tiene un gran futuro, pero ahora mismo sólo lo recomendamos en el caso de presupuestos muy reducidos, para aplicaciones que no necesiten mostrar una gran cantidad de datos y en las que la experiencia de usuario no sea prioritaria. Aunque si éste es tu caso, quizás deberías replantearte tu estrategia móvil.
Ya tenemos iOS 6 oficialmente entre nosotros! Y eso significa que ya podemos hablar abiertamente sobre las nuevas funcionalidades que proporciona sin miedo a que Apple nos denuncie.
¿Qué incluye esta nueva versión de iOS? A continuación os muestro una lista de los cambios más importantes que se han introducido, por si aún no habéis tenido tiempo de echar un vistazo a las betas o a la documentación:
Mapas
Probablemente una de las funcionalidades con más polémica, debido a la mala calidad de los mapas con los que cuenta Apple actualmente. Desde el punto de vista del desarrollador se mantiene la API anterior, por lo que las aplicaciones que usen MapKit deberían seguir funcionando sin problemas.
Por otro lado, ahora tenemos la oportunidad de registrar nuestras aplicaciones como Routing providers, de forma que la aplicación oficial de mapas mostrará nuestra aplicación al usuario que busque una ruta en un área determinada. De esta forma, podemos ofrecer rutas en medios de transporte alternativo a los que ofrece la aplicación oficial, como rutas en bicicleta, transportes públicos, senderismo, etc.
Framework social
Este nuevo framework sustituye a la API para Twitter que se introdujo en iOS 5 y añade soporte para otras redes sociales. En concreto iOS 6 ofrece integración directa con Facebook y Weibo (aunque ésta última sólo para usuarios chinos).
Pass Kit
Pass Kit es el nuevo framework asociado a Passbook, orientado a la utilización de entradas, cupones, etc. desde el teléfono móvil. Passbook también ha cosechado alguna crítica negativa debido a su dificultad de uso, aunque ya hay compañías importantes que se están adaptando a su uso.
Game Center
En este caso tenemos algunas modificaciones que permitirán, por ejemplo, que nuestros jugadores se reten entre sí o establecer tiempos límite de turno en los juegos por turnos. Además se facilita el acceso a Game Center gracias a un nuevo controlador: GKGameCenterViewController.
Recordatorios
Gracias a los cambios en Event Kit ahora podemos crear nuevos recordatorios que se mostrarán en la aplicación oficial, así como acceder a los recordatorios del usuario.
Compras In-App
Store Kit por fin proporciona soporte para la compra y descarga de contenido desde iTunes, con el contenido alojado en los servidores de Apple. Esto simplificará en gran medida la venta de contenido descargable, que antes tenía que estar alojado en nuestros servidores.
Collection Views
Por fin disponemos de un componente, UICollectionView, que nos permite una manera de presentar contenido de forma ordenada a los usuarios. La disposición de las vistas embebidas se realiza delegando la tarea a un objeto layout asociado. iOS 6 por defecto incluye una disposición en parrilla o grid, que probablemente deje obsoletos a los componentes open source que proporcionaban esta funcionalidad, pero es de esperar que a partir de ahora podamos ver precisamente objetos layout que nos permitan organizar nuestras vistas embebidas de múltiples maneras.
Preservación del estado de la interfaz
Otro apartado en el que Apple nos lo pone ahora más fácil es el de mejorar la experiencia de nuestros usuarios, preservando el estado de la aplicación entre diferentes ejecuciones. Gracias a una nueva infraestructura, ahora será mucho más fácil que nuestros usuarios sigan su trabajo o diversión justo donde lo dejaron.
Auto Layout
Todo un nuevo sistema de organización de los componentes gráficos en nuestra aplicación, que nos permitirá establecer relaciones más ricas entre ellos de forma más intuitiva que con el sistema anterior.
Privacidad
A partir de ahora el sistema pedirá permiso al usuario cuando una aplicación intente acceder a sus contactos, calendarios, recordatorios y fotos, además de la información de geolocalización como hasta ahora. Esto mejorará la seguridad de los usuarios, pero hará que desde nuestro lado tengamos que preveer una posible negativa del usuario a que accedamos a sus datos.
Otros cambios
Como siempre, podéis acceder a una lista exhaustiva de cambios en la documentación de Apple:
Saludos, y a programar!
Somos un grupo de desarrolladores con más de 15 años de experiencia en diferentes plataformas bajo entorno empresarial. Llámanos si quieres:
- Proporcionar servicios móviles a tus clientes
- Incrementar exponencialmente tu número de clientes online convirtiendo tus servicios en una experiencia divertida gracias a las técnicas de gamification
- Disminuir el tiempo de desarrollo de tus productos usando métodos ágiles (SCRUM, XP, Kanban, Lean)
