SQA en una startup


SQA (software quality assurance) o aseguramiento (vaya palabro) de la calidad del software es un concepto con el que convivimos los que nos dedicamos, de una u otra manera, al desarrollo de software. Definir qué es el SQA es algo complicado y cada uno tendrá una versión distinta pero para mi no es más que la colección de procesos y herramientas que permite asegurar en cada nueva release que el software desarrollado tiene la calidad suficiente como para poder ser desplegado en producción. Existen metodologías muy desarrolladas en torno a este tema pero yo prefiero ir a lo práctico y sencillo y al final lo reduzco a una serie de pruebas funcionales que debe pasar el software. Estas pruebas deben cubrir todos los procesos de negocio soportados por el software, tanto el funcionamiento esperado como los errores controlados.

La gestión de la calidad del software debería formar parte de manera natural del ciclo de vida del software pero todos sabemos que no es así. En casi todos los proyectos brilla por su ausencia.

SQA en una startup

En la mayoría de los casos, unir en una misma frase startup y SQA es ciencia ficción. Casi siempre en las startups tendemos a confundir rapidez, agilidad y calidad. Pero claro, los recursos y el tiempo en una startup son muy limitados y si hay que reducir por algún sitio, normalmente suele ser a costa de suprimir el SQA. Aunque por otro lado, nuestra tolerancia a los errores es muy baja y siempre queremos que las cosas funcionen perfectamente. Estoy seguro que a muchos os ha venido a la cabeza alguna conversación con vuestro CEO en la que habéis discutido sobre la necesidad de hacer un desarrollo para ayer pero luego, cuando las cosas han fallado por hacerlas deprisa y corriendo, ha puesto el grito en el cielo.

Cuando nos movemos en el entorno de una startup, parece bastante asumido que el SQA hay que dejarlo para más adelante, para cuando la empresa deja de ser una startup y te puedes parar un poco a afianzar todo. Algunos ejemplos:

  • En BuyVIP durante el tiempo que  fui CTO no teníamos ni un plan de pruebas definido ni un proceso de pruebas exaustivo previo al paso a producción.
  • En tagUin, teníamos una guía básica de qué había que comprobar y teníamos en la cabeza el detalle de lo que había que probar pero no lo hacíamos siempre y casi siempre nos dejábamos cosas por probar.
  • En Planeo mientras yo gestioné el proyecto, nunca hubo plan de pruebas y la parte de negocio nunca se involucró lo suficiente en hacer pruebas funcionales de calidad. Así pasaba, que casi siempre había errores totalmente evitables si el negocio hubiera probado lo que le pedíamos que probara.

Qué hacíamos en etece

Digo “hacíamos” y no hacemos porque estamos trabajando para cambiar y mejorar el SQA. Un poco más adelante os cuento qué estamos haciendo.

Desde la primera versión de etece que vio la luz a mediados de julio de 2012, hemos tenido un documento muy sencillo donde hemos ido incorporando las pruebas que considerámos necesarias para comprobar, en cada nueva release, que todo funciona según esperamos. En esa primera versión eran alrededor de unas 80 pruebas. Ahora vamos por casi 300. Estas son algunas de nuestras pruebas:

  • Grupo: registro de cliente
  • Prueba: registro correcto de cliente
  • Pre-requisitos: ninguno
  • Descripción: desde la home, se accede al registro de cliente, se completan todos los datos con un email que no haya sido registrado previamente y se completa el registro
  • Resultado esperado: 1.- Llega correctamente el email de bienvenida; 2.- El usuario está correctamente registrado en el CRM; 3.- El cliente queda correctamente suscrito a las listas usuarios y clientes tanto en la web como en MailChimp
  • Grupo: registro de cliente
  • Prueba: registro de cliente con email dado de baja
  • Pre-requisitos: disponer de un usuario registrado y dado de baja
  • Descripción: desde la home, se accede al registro de cliente, se completan todos los datos usando el email de un usuario dado de baja y se intenta completar el registro
  • Resultado esperado: El registro no se completa, se muestra un mensaje genérico de error y además se marca en rojo el campo email indicando que ya existe

Al principio, hacer todas las pruebas nos llevaba un día de una persona. Ahora, con casi 300 estamos en un par de días de dos personas. Además, según vamos incorporando funcionalidad a la web, las pruebas cada vez son más complejas y requiren de más tiempo. Estaba claro que teníamos que ir un paso más allá, automatizando las pruebas.

Qué estamos haciendo ahora en etece

Desde hace un par de semanas estamos trabajando para automatizar el mayor número de pruebas que podamos. Las ventajas de automatizar las pruebas son claras:

  1. mejora del tiempo necesario para pasar el plan de pruebas.
  2. minimizar la intervención humana. No hace falta, en un procentaje grande, que intervenga ninguna persona.
  3. mejorara la calidad de las pruebas. Es casi consecuencia del punto anterior. Al eliminar el factor humano, eliminamos aquellas pruebas que se dan por buenas por error o que directamente, la persona encargada no las hace ( pasa más de lo que pensáis).
  4. hay que ser más metodológico. Todo lo nuevo que se desarrolla o que se modifica debe tener sus pruebas funcionales programadas. Es algo bueno, pero también lo incluyo como punto negativo ya que muchas veces te puede complicar de más algún desarrollo.

En cambio, hay que asumir algunos puntos negativos:

  1. aumento del tiempo de desarrollo. Ahora, además de programar la funcionalidad, hay que programar las pruebas que comprueban que todo funciona correctamente y hay que mantener operativas las pruebas ya programadas. Estimamos que el tiempo se va a aumentar entre un 10% y un 15%.
  2. hay que se más metodológico.

Para automatizar las pruebas  estamos usando Seleniun2 con JUnit4. En los próximos días publicaré un post escrito por Javier Fernandez que explica a nivel técnico cómo está montada toda la automatizacion de pruebas. Avanzando un poco de lo que él contará, para cada una de las pruebas que teníamos escritas es nuestro plan de pruebas, hemos creado un test de Selenium que hace el proceso completo de la prueba y comprueba todos los resultados esperados. Hemos hecho cada prueba independiente de la anterior de manera que una prueba empieza sin necesitar datos anteriores, se ejecuta y al terminar borra todo rastro para así poder ser ejecutada de nuevo sin problemas. Como imaginaréis, hay muchos procesos que están compartidos entre muchas pruebas (registro de usuario, registro de solucionador, encargar una tarea, etc…) por lo que la estructura de clases que hemos montado nos permite independizar del test toda esta navegación común. El plan de pruebas lo lanzamos desde nuestro servidor de integración contínua (Jenkins) lo que nos permite conocer en todo momento la salud de nuestro proyecto.

Hasta la fecha hemos conseguido automatizar alrededor de un 90% de las pruebas del plan lo que reduce a poco más de un par de horas el trabajo el tiempo humano necesario para completar las pruebas.

Espero que estas líneas os sirvan de estímulo para incluir, de manera más o menos sencilla, el SQA como parte de vuestros proyecto.

Anuncios

Mis errores como emprendedor líder en tagUin


En noviembre de 2009 dejé Toprural para liderar un nuevo proyecto que había concebido algunos meses antes. Me fui de Toprural movido por el gusanillo emprendedor y por el deseo de liderar mi propio proyecto. Si no hubiera sido por eso, voluntariamente me hubiera quedado mucho más tiempo ya que sentía que aportaba cosas a la vez que aprendía otras muchas.
En aquel momento las redes sociales verticales estaban en pleno auge y yo venía de participar en dos proyectos muy exitosos, pensaba que mi momento había llegado. Como ya conté en un post anterior, tanto François Derbaix como José Luis Vallejo me apoyaron desde el principio, me ayudaron con el plan de negocio y me enseñaron cómo encontrar financiación. En paralelo, Javier Fernández y Alberto Rodríguez completaban el equipo emprendedor y trabajaban en ls primera beta del proyecto, que vio la luz en junio de 2009 en forma privada para algunos beta testers. Mi rol no era tan técnico como en anteriores proyectos, para eso estaba Javier. En este caso tenía que liderar el proyecto en todos sus aspectos.
Conseguimos 160.000€ de capital semilla aportado por amigos, familiares y algunos business angels lo que suponía un inmejorable punto de partida. No obstante cometí muchos errores que han hecho que hoy tagUin esté en una vía muerta. Entre tantos errores he destacado tres que creo que son los más significativos, aunque si preguntáis a mis socios, seguramente identifiquen otros muchos:

  • No crear un equipo más heterogéneo. Es uno de los errores de libro pero yo lo cometí. Los fundadores teníamos un perfil demasiado parecido y dejamos cojas áreas clave en una startup. Hacer un buen equipo es muy difícil y además uno de los factores de éxito más importante. Como fundador líder debería haber buscado un equipo más complementario.
  • Invertir demasiado pronto en marketing. En una startup que arranca con poco capital, invertir correctamente cada euro es otro de los factores de éxito y yo no lo hice bien. En mi deseo de crecer rápidamente y alcanzar unos objetivos de negocio razonables que nos permitieran cerrar con garantías la siguiente ronda de financiación, invertimos en marketing cuando nuestro producto no estaba suficientemente maduro y eso suponía que cada usuario que captábamos, no lo rentabilizábamos correctamente. Además, el capital inicial que teníamos no nos permitía hacer demasiados experimentos por lo que teníamos una bala y teníamos que acertar en la diana a la primera. Lo he comentado alguna vez a quien me pregunta sobre el tema: es mejor apuntalar y mejorar el producto antes de invertir en marketing. Si no te puede pasar como a nosotros.
  • Arrancar sin capital suficiente como para demostrar a los inversores que el proyecto tiene “tracción”. Este es quizá el punto más controvertido, sobre todo entre los más firmes defensores del emprendimiento low-cost pero me voy a explicar. Cuando un proyecto va orientado al gran público y además necesita de un volumen importante para que el modelo de negocio tenga sentido, hay que tener claro que la inversión necesaria es muy grande. Los inversores que invierten después de la ronda semilla esperan ver que el proyecto ha despejado algunas de las incógnitas del business plan y además ha encontrado un camino hacia el éxito. Mi error fue arrancar tagUin sin capital suficiente como para llegar con garantías a ese punto, sin gasolina para llegar al punto que los inversores esperan de un proyecto invertible en búsqueda de su segunda ronda de inversión. Sin esa gasolina, nos quedamos a mitad de camino, en la vía muerta en la que estamos ahora. Fueron mis ganas de emprender y mi falta de experiencia en el arranque de proyectos lo que me llevó a pensar que con 160.000€ en un proyecto como tagUin se puede llegar a ese punto, pero no creo que sea así.

Estos errores fueron, bajo mi punto de vista, los más importantes, aunque hubo otros. En diciembre de 2010 y de la mano de José Luis Vallejo a través de su empresa Medianet, Javier y yo pasamos a formar parte del equipo técnico que desarrolló un core de ecommerce para Prisa Digital en paralelo a Planeo, el site de ofertas de ocio del Grupo Prisa. Esto suponía aparcar definitivamente tagUin, dejándolo en modo supervivencia. En este momento tagUin tiene unos 40.000 usuarios registrados, aunque muy poco tráfico. De hecho estamos buscando la mejor manera de liquidar el proyecto, vendiéndolo, traspasándolo o cerrándolo.
Mi rol en Prisa fue la de responsable técnico de Planeo y product-proyect manager de ecommerce en Prisa Digital. Esta nueva fase tampoco estuvo exenta de errores. Pero eso lo contaré otro día.

Mis defectos y virtudes


Voy a empezar a escribir una serie de posts bastante reflexivos, con una dosis fuerte de autocrítica y auto análisis que espero que sirvan a alguien para no cometer los mismos errores y de paso os animen a hacer el mismo ejercicio. Creo que es importante conocer nuestras fortalezas y debilidades para intentar corregir las segundas e impulsar las primeras. Como le decía a un gran amigo hace ya algunos años en tono jocoso: “lo primero es reconocer que eres un atraso de persona. A partir de ahí todo es construir”.

Los posts que quiero escribir en esta serie son:

No van a ser posts demasiado largos ya que no tengo demasiado tiempo. Mi hijo ha cumplido un año hace pocos días y le dedico el poco tiempo libre que tengo. Por eso voy a escribir en ratos cortos e intentaré que los posts sean muy concentrados.
Me pongo a ello…

Nueva versión de tagUin


Llego un poco tarde escribiendo este post ya que hace ya un par de días que pusimos online la nueva versión de tagUin. Lo hemos twiteado y hemos escrito sobre ello en nuestro blog, aunque no hemos dado datos más técnicos que igual pueden ser interesantes.

Empezamos a trabajar en esta nueva versión en el mes de mayo con la colaboración de Juan Leal que nos hizo un primer análisis heurístico muy bien planteado y que ha sido la base de todo el trabajo. Vimos que teníamos que cambiar completamente nuestra capa front por lo que aprovechamos para hacer algunas otras cosas que a continuación menciono:

  • Remaquetación completa de la web. Ya que teníamos que cambiar el diseño, hemos aprovechado para remaquetar toda la web y plantearnos una mejor gestión de las hojas de estilo y las librerías javascript. Todavía tenemos que mejorar algunos puntos pero hemos sentado las bases.
  • Subida de versión del framework CakePHP de 1.2.1 a 1.3.2. Sin duda ha supuesto una parte grande del trabajo, pero estamos viendo que ha mejorado mucho el rendimiento y por tanto ha sido tiempo bien empleado.
  • Subida de versión de PHP de 5.2.6 a 5.3. Es un requisito de la versión 1.3 de CakePHP pero sin duda usar la última versión es bueno.
  • Cambio de la librería de javascript de Prototype a JQuery. Éste ha sido quizá el cambio que menos que “nota” y que nos ha supuesto una carga importante de trabajo, pero sin duda pensamos que era un cambio necesario y que es mejor hacerlo cuanto antes.

Han sido casi tres meses de duro trabajo, pero creemos que el resultado ha valido la pena. Qué os parece? Cualquier feedback constructivo es bienvenido.

mi opinión de la venta de Tuenti a Telefónica


Ayer desayunábamos con la noticia de la venta del 90% de Tuenti a Telefónica, aunque no sorprendió a nadie después del adelanto que nos hizo Carlos Blanco hace unos meses dando la primicia de la noticia.

Sin duda es una noticia importante en el mundo de Internet en España, aunque para Telefónica 70 millones de euros sean poco más que calderilla después de haber cerrado la compra de Vivo por 7.500 millones de euros. Operaciones como esta se ven muy pocas cada año en España, aunque llevamos un verano muy activo ya que hace pocos días se anunciaba la compra de eDreams por parte de Permira.

Bajo mi punto de vista la compra de Tuenti por Telefónica es un gran noticia por los motivos que a continuación enumero:

  • La noticia tiene la repercusión mediática necesaria para poner Internet de nuevo en el punto de mira de muchos inversores, lo que sin duda nos beneficia a todos los que trabajamos en este sector.
  • Es una operación de éxito para los inversores, tanto en fase semilla como de capital riesgo lo que les da oxígeno para acometer nuevas inversiones y quién sabe si de alguna de esas inversiones nos beneficiamos algunos.
  • Es una operación de éxito para los emprendedores, lo que me produce una gran satisfacción. Se habla de muchos emprendedores de éxito en España, pero son muy pocos los que han hecho un exit en el momento adecuado y ganando mucho dinero.
  • Pone de manifiesto que las redes sociales SI son un buen negocio para inversores y espero que más de uno se de cuenta de que merece la pena invertir en este tipo de negocio (como tagUin 😉 ).
  • Creo que alguno o varios de los emprendedores de Tuenti empezarán a ejercer de business angels y pueden ayudar y mucho a nuevas empresas de Internet.

No será la última gran operación de este año, ya que en pocos meses veremos otra en el sector del eCommerce, aunque no será ni tan mediática ni tan rentable para los emprendedores.

Tramposos del CPL


En tagUin estamos trabajando a nivel de marketing online con Actualsales, una agencia especializada en campañas CPL. Para nosotros es muy cómodo porque acordamos un precio por lead y ellos se encargan de hacer todo lo necesario para captar al usuario, ya sea CPC, CPM, afiliación o cualquier otro tipo de campaña. Sin duda para una empresa que empieza como nosotros en la que no hay ningún experto en marketing, es una fórmula muy recomendable.

Las redes de afiliados son una fuente importante de leads y hacer campañas con estas redes supone una ventaja grande tanto para nosotros porque el lead que nos llega suele ser de calidad, como para el afiliado que encuentra en estas campañas un método de monetización de su sitio web. Pero en todos los sitios hay tramposos que buscan aumentar su beneficio valiéndose de diferentes métodos para aumentar el número de leads que llega desde su web y así aumentar sus ingresos.

Uso de dominios de correo temporales

En los últimos días hemos visto que algunos afiliados hacen uso de dominios de correo temporales para generar direcciones de correo que tienen validez de pocas horas. De esa manera una única persona puede generar muchos leads provenientes de su web. Pero esos leads no son válidos para la empresa que paga la campaña CPL, ya que detrás de ese usuario no hay una persona real. Esto nos obliga a implementar mecanismos de control de los datos de los nuevos usuarios y por tanto de manera indirecta estamos incrementando el coste de adquisición de un usuario.

Coste de adquisición fijo

Normalmente los negocios online estudiamos muy bien el coste de adquisición de nuestros usuarios y es una de las variables principales de nuestro business plan. Normalmente, después de estudiarlo con detenimiento y cruzarlo con las necesidades de financiación, fijamos el coste máximo que estamos dispuestos a pagar por un usuario. Como siempre vamos apurando al máximo, buscamos costes de adquisición bajos y por tanto desde el principio nuestras campañas CPL van al coste máximo que estamos dispuestos a pagar. Cuando tenemos que incluir en ese valor los costes derivados de revisar la calidad de los leads que nos vienen de las redes de afiliación, tenemos que bajar el precio que le pagamos a la red de afiliación y por tanto disminuye el precio que se le paga al afiliado final. En resumen, el afiliado recibe menos dinero por el mismo lead. Algunos os preguntaréis a qué precio pagamos el lead, pero eso será motivo de otro post.

Unos pocos tramposos perjudican a la mayoría

La conclusión a la que yo llego después de la reflexión anterior es que unos pocos tramposos están perjudicando a la mayoría de los afiliados que hacen las cosas de manera legal. Nosotros no pagamos por los leads que provienen de dominios temporales porque estamos controlando esta información y por tanto las redes de afiliación saben quiénes están haciendo trampas. En mi opinión a estos afiliados debería ser expulsados de las redes de afiliación y así facilitar el acceso a las campañas CPL a los afiliados que buscan una manera legal de monetizar su sitio.

A continuación os dejo la lista de dominios que chequeamos por si queréis implementar mecanismos de control como hemos hecho nosotros:

  • mailcatch.com
  • mailinator.com
  • yopmail.com
  • uggsrock.com
  • owlpic.com
  • hushmail.com
  • hush.com

¿Crees que los tramposos del CPL deberían ser expulsados de las redes de afiliación?