menu_superior

Crowd testing

Hace poco leí un artículo firmado por Alberto Iglesias en Computer World titulado “Crowd testing: el poder de las masas para mejorar apps“. En primer lugar me pareció muy positivo que las publicaciones generalistas del sector IT dediquen espacio al testing de aplicaciones por que no es algo frecuente, menos aún cuando se trata de una práctica tan especializada y tan poco común. Aunque la verdad es que de fondo, me decepcionó un poco el hecho de que el artículo sea tan breve y contenga algunas inexactitudes que no ayudan a mejorar la visión de las actividades que llevamos a cabo dentro del Testing de software.

Este post no es un alegato contra las maldades de la prensa, ni una queja por que seamos unos incomprendidos, me gustaría que fuera una extensión del de Computer World donde haya más información y más profundidad.

El Crowd Testing, literalmente “testing en masa” es una práctica que se basa en la utilización de muchos usuarios que, con sus propios medios, prueban una aplicación. En general este tipo de testing se usa para verificar la usabilidad en dispositivos móviles por que es más barato que hacer las pruebas en un conjunto tan numeroso y diverso como el parque de dispositivos móviles. Es fácil imaginar el coste en tiempo y en dinero que tendría no solo la adquisición de los terminales si no la ejecución de las pruebas sobre todos y cada uno de los dispositivos y la corrección de defectos. Es mucho más simple convocar a usuarios para que se descarguen aplicaciones, las instalen, las prueben y, en un plazo concreto, te remitan sus impresiones, si hay bugs, etc. Este es el proceso general, para mí los puntos clave para que los resultados sean óptimos serían los siguientes:

  • Las aplicaciones tienen que tener varios ciclos de prueba ejecutados. No se pueden poner en circulación apps que no sean minimamente funcionales, estables y seguras.
  • Hay un plan de pruebas definido que ejecutar. El nivel de detalle del plan no tiene por que llegar a especificar casos concretos de prueba pero al menos debe incluir la(s) funcionalidad(es) que cada tester debe recorrer… (suena como testing exploratorio, verdad?).
  • Los dispositivos en los que se desplegará la aplicación tienen que estar catalogados. Si queremos que la prueba sea significativa hay que tener controlados los dispositivos en los que se instalará, no tanto el número como los modelos, SSOO, configuración de pantalla, etc.
  • Plazos. Tiene que haber un plazo definido para hacer la prueba: puede ser fecha de inicio y fecha de fin, puede ser sólo con fecha de fin. No es imprescindible por que siempre podemos contactar con ellos y pedir la información pero personalmente creo que es mejor ser transparente y que cada tester sepa cuanto tiempo tiene y cuando tiene que reportar los resultados.
  • Reporting. Si hay defectos quiero tener evidencias para reproducirlos: en qué dispositivo falla, en qué parte de la app, con qué configuraciones, con qué versiones, qué más tienes instalado, qué datos has usado, si había cobertura y de qué tipo… Mi recomendación es que haya un formulario para remitir el defecto encontrado y un cuestionario amplio para que el tester pueda reportar con el máximo nivel de detalle.
  • ¿Pagar o no pagar? No es imprescindible… Si el prestigio de la compañía hace que tengas fans para descargarse las apps antes que nadie tal vez te puedas ahorrar el coste de ejecución de las pruebas (solo la ejecución por que catalogar los dispositivos y “comunicarse” con los testers es un coste). Si no es una app “deseable” seguramente hay que pagar a los testers para motivarles y que se descarguen la app y la prueben.

En el artículo se mencionan un par de referencias, Software Testing Club, a la que no conozco en detalle pero parece más una comunidad de testers y Mob4Hire, con los que trabajé en un proyecto y sí que proporcionan estos servicios… Si conocéis algún otro, por favor, decídmelo, podéis utilizar los comentarios, twitter, linkedin, correo…

, , , , , , ,

Comments are closed.