Puede que hayas oído o leido algo de Crowdtesting, una práctica que genera una gran cantidad de «buzz» ahora y que consiste en entregar una aplicación a una comunidad de ‘testers’ externos a la empresa para que ellos comprueben su robustez.

Con el post de la semana pasada, me pregunté si esta situación podría justificar el uso de esta técnica.

Un departamento TI que debe enfrentarse al fuerte crecimiento de un sitio web de venta online, la gestión de decenas de miles de visitas diarias y miles de productos de más de 1 500 proveedores diferentes. Un portafolio de aplicaciones más y más viejas integradas con ERPs, y un gran número de personalizaciones a tener en cuenta para implantar la reglementación de cada país.

La presión del time-to-market y la baja prioridad para la QA nos lleva a errores que incluso un usuario puede detectar siguiendo un processo normal de compra. Cualquier ‘Crowdtester’ lo lograría con mucha facilidad.

No sería esto un caso ideal para incorporar ‘Crowdtesting’ en la estrategia de QA de este sitio? ¿Cuáles son sus beneficios?

• Costes: realizar más pruebas por un menor coste. Ideal para este departamento de TI que claramente no dedica un presupuesto de control de calidad a la altura de su misión. Más con menos.
• Flexibilidad: realizar más pruebas en un período de tiempo más corto. El caso de uso que hemos encontrado – una excepción al proceso por defecto de entrega – requiere probablemente una o más iteraciones de control de calidad en unas pocas horas, sin duda dentro de una semana. Imposible con un equipo interno no suficientemente grande. Posible con ‘crowdtesters’. Más pronto con menos.
• Infraestructura: ya que este es un sitio comercial en línea, estas pruebas pueden llevarse a cabo en una réplica (privada) del sitio, sin necesidad de importantes esfuerzos de gestión de pruebas o de infraestructura o de despliegue. Además, el Crowdtesting se aplica mejor cuando las pruebas deben ser replicadas en diferentes configuraciones de navegadores y de máquinas clientes (ordenadores, tabletas, teléfonos, sistemas operativos, …).
• Seguridad. Esta aplicación cuenta con pocos datos de carácter personal. El único proceso un poco más sensible es el sistema de identificación y de pago del usuario, pero esto se puede manejar fácilmente. No como si se tratara de los registros médicos de un paciente o de los datos de tus cuentas bancarias.
• Criticidad y diversidad. El Crowdtesting no se aplica bien cuando se trata de probar funciones complejas y sofisticadas que requieren conocimientos avanzados del negocio o del mercado de la empresa. En el caso de un proceso de venta online, este inconveniente no se aplica. Al contrario: el gran número de probadores asegura una diversidad de comportamientos de compra que puede ser beneficioso.

Creo que es una situación en la que es posible imaginar una sinergia entre:

• Un pequeño equipo de profesionales encargados de verificar las especificaciones para la aplicación.
• Crowdtesting para optimizar el time-to-market, la flexibilida y los costes.

El post de la semana pasada era ya demasiado largo para compartir estas ideas, y también quería pasar a otros temas, sobre todo la nueva versión de Sonar. Pero un artículo en el periódico ‘El Pais’ ayer me dio la oportunidad de pensar en un otro tema: Crowdsourcing.

Crowdsourcing es una practica que ha surgido con la Web 2.0, y que consiste en utilizar el potencial colectivo de los usuarios de Internet para desarrollar nuevas aplicaciones. Entonces me pregunté si podíamos, en nuestro caso anterior, mezclar desarrolladores internos con ‘CrowdSourcers’.

El principal argumento en contra de esta idea es que, una vez más, no podemos pedir a los desarrolladores externos de gestionar la complejidad funcional de una aplicación. No? ¿En serio?

Pero que sucede cuando una empresa decide externalizar sus aplicaciones? Esto implica un esfuerzo para la transferencia de este conocimiento funcional al equipo de outsourcing, lo que justifica, además, evitar la externalización de aplicaciones funcionalmente complejas y críticas.

Y luego ya hay ejemplos de ‘CrowdDev’ que demuestran que este modelo es factible. El mundo Open Source nos ha mostrado que se puede construir comunidades de desarrolladores alrededor de un producto de software que ellas contribuirán a extender. En general, el proyecto Open Source está fundado en un equipo pequeño, muy experto, dedicado a la gestión de un núcleo de código abierto al cual la comunidad de ‘CrowdSourcers’ añade componentes anexos.

Otro argumento: este modelo no es aplicable fuera del mundo Open Source, para proyectos empresariales. Y ¿por qué no? La mayoría de los proyectos de desarrollo actuales se basan en frameword Open Source. Y son menos y menos componentes técnicos, pero más y más ERPs funcionales en areas específicas. También he visto a clientes abrir parte de sus desarrollos. Por ejemplo, el departamento de TI de una región administrativa a cargo de todas las aplicaciones para el público, pone a disposición su código a otras regiones con el fin de compartir los costes de mantenimiento. Un editor de un ERP de gestión de universidad, que requiere muchas adaptaciones por cada universidad. Estas personalizaciones se abren al mundo Open Source para permitir a cada universidad beneficiarse de la evolución de los otros equipos, y el editor de software incorpora esas evoluciones para enriquecer la versión empresarial básica.

Si continuamos con este razonamiento, se puede imaginar equipos de CrowdSourcing y de CrowdTesting trabajando en un mundo cada vez más virtualizado con departamentos de TI centrados en equipos reducidos y altamente especializados.
En el ejemplo de este sitio web, como ya hemos visto que tiene previsto ofrecer su sitio online en un formato SaaS, algunas características podrían ser ‘crowdsourced’, como la localización y la traducción del sitio web en diferentes idiomas, la personalización de la tienda según los productos vendidos, o de la interfaz de usuario según diferentes plataformas de hardware (PC, tabletas, etc.)

Contrariamente a lo que algunos creen, no creo que los profesionales de testing o de desarrollo se ven amenazados por estas evoluciones del mercado. Un buen arquitecto o un buen profesional de QA siempre serán necesarios para garantir la calidad una aplicación funcionalmente compleja, o sensible a la seguridad.

Sin embargo, también creo que el tiempo ha pasado cuando alguien podía pasar toda su vida profesional como empleado en una o más empresas, pero cada vez será más necesario en el futuro estar capaz de crear su propio empleo. En este sentido, Crowdsourcing Crowdtesting facilitarán el uso a los expertos externos por los departamentos TI.

Tanto mejor. En mi último trabajo, he tenido cuatro jefes diferentes en cinco años, y no los he elegido. Mis clientes si.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.