Un bug anda suelto

Uno de los objetivos de nuestros productos es que sean estables, que sean fiables. Intentamos que cada cambio realizado en el producto, en el código fuente, no rompa, no estropea nada. Es vital para todos nosotros que cada usuario disfrute de mejoras y no de disgustos.

En este post voy a intentar explicar como en la última versión velneo 22 un hábil bug ha podido escaparse de todas las barreras de defensa que tenemos.

Barrera 1 – El programador

Un buen desarrollador con años de experiencia comete menos errores, el código que realiza se protege de los bugs. Aunque en algunos casos se ve como el “culpable” de introducir el bug, también es el “culpable” de crear el producto. Si no se toca código es difícil añadir bugs.

Barrera 2 – En la integración continua

Dentro de la integración continua se pueden usar diferentes sistemas para detectar bugs ( Pruebas unitarias, pruebas funcionales, análisis estáticos de código, etc )
Es muy útil tener todas estas pruebas automáticas que detectan fallos de desarrollo y nos da garantías de que los cambios subidos no rompen nada.
En Velneo contamos con la herramienta interna “vEst” que es una aplicación que ejecuta la mayoría de las funciones de Velneo cada vez que un programador toca una línea de código. Vienen a ser unos 2.000 test que prueban base de datos, objetos, procesos, javascript, etc.

Cada día intentamos añadir más tests para poder comprobar el mayor porcentaje de funcionalidades de la plataforma en todos los sistemas operativos (Win, Lin, Mac, iOS, Android)

Barrera 3 – En el equipo de desarrollo

Ya sea por revisión por pares o por programación por parejas, se pueden detectar los bugs antes de que el código salga del departamento de desarrollo.
Actualmente todos los programadores invierten un valioso tiempo en revisar y compartir los cambios de los compañeros. Es vital poner toda la atención posible para descubrir si algún bug paso las dos primeras barreras. En este caso el bug de la versión 22 paso delante de mis ojos y no fui capaz de verlo 🙁

Barrera 4 – En el departamento de pruebas

Todos las incidencias, tienen que ser “cerradas” por el equipo de pruebas o la persona que ha introducido la necesidad/incidencia. Al mismo tiempo se prueban las novedades sobre aplicaciones estándar para ver si funciona correctamente. Un buen tiempo dedicado a probar que todo funciona bien y sin cambios, puede detectar bugs que han llegado a esta barrera.

Barrera 5 – Los betatesters

Si el bug no se ha encontrado dentro de los equipos de desarrollo y pruebas, el producto con el error llega al betatester. Es importante que el betatesters invierta tiempo en probar las novedades y cambios y que actúe casi como un usuario final. En algunos casos intentamos poner esta versión en producción, para poder darle una garantía de prueba real.

 

Si el bug ha pasado todas estas barreras, ha llegado al cliente, posiblemente el coste es ya muy alto. Comunicaciones, revisiones, emails, disculpas, mala imagen, inestabilidad, etc.

Cada vez que un bug salta todas las barreras, intentamos analizar como pudo pasar por cada barrera, para dar un punto de mejora y evitar que pasen más en el futuro.

 

Este artículo Un bug anda suelto es original de Velneo.

Bloqueandome a mi mismo (I)

Vamos a ver un ejemplo curioso, en el que el mismo usuario impide que se realicen las actualizaciones de su propia operación. El proceso es de lo mas sencillo, partiendo de 2 tablas una de cabecera y otra de líneas, modifica el registro de cabecera y da de alta una nueva línea. Proyecto de pruebas […]

Errores no reproducibles en el software

Usuario: No soy capaz de reproducir lo que me pasó con el programa, de verdad que antes me rompió  -explica el usuario con cara de asustado.

Programador: ¿Estás seguro que ocurrió eso? -replica el programador- le mira con cara “mira que eres usuario”.

A todos os habrá pasado esta situación común en las empresas de software. Seguramente habéis estado en la posición de programador y en la de usuario.

Los errores no reproducibles pueden ser los bugs más caros de tu empresa de software. Recuerda que cuando tenemos un error que no somos capaces de reproducir causa una sensación de desconfianza en el producto.

Hay que reportar a los programadores los síntomas claros  de lo que está ocurriendo, estudios han demostrado que los programadores pueden llegar a solucionar un 20% de los errores “no reproducibles” en un software.

En algunas empresas los programadores ignoran los errores no reproducibles, no obstante, la misión de soporte y testing es notificarlos. Si los damos de alta en la base de datos de bugs podemos buscar patrones de comportamiento similares en otros errores “no reproducibles”. Si describes el error “no reproducible” seguramente ese mismo bug se ha introducido unas cuantas veces con síntomas diferentes, juntos, pueden darte pistas de las condiciones por las que no eres capaz de reproducirlo.

Cuando se reporte un error no reproducible a la base de datos de bugs debe quedar claro que el bug es “no reproducible”, muchas bases de datos tienen un campo para esto.

Tienes que usar una captura de pantalla o un vídeo para ayudarte a demostrar la existencia de UFO (unidentified Funny Objects) de otra manera alguien puede decirte que no existen.


Iteraciones, versiones, revisiones, ideas, incidencias, lo que falta y demás….

Velneo V7

Glosario

Para poder comprender mejor este post vamos a empezar por definir desde el punto de vista de Velneo los ítems más importantes.

Iteración:

Iterar es básicamente repetir (http://www.wordreference.com/definicion/iterar). Que es lo que se hace en un proceso productivo para realizar procesos de mejora, repetir para ir añadiendo correcciones y mejoras al proceso productivo tras evaluarlo, para realizar tareas de forma incremental, con productos terminados en cada iteración.

Una iteración en definitiva, es cada una de las repeticiones que se producen. Múltiples iteraciones contribuyen a crear un producto completamente integrado.

Más información:
http://es.wikipedia.org/wiki/Desarrollo_iterativo_y_creciente
http://www.proyectosagiles.org/desarrollo-iterativo-incremental

Producto Completo:

Es lo que espera recibir un cliente cuando adquiere un producto genérico. El producto completo se forma a partir de producto genérico, productos adicionales y servicios.

http://alfonsogu.com/2011/04/05/producto-completo-en-software-whole-product-concept/

Producto Genérico

Esto es lo antiguamente nos llegaba en una bonita caja y hoy día descargamos por internet (el instalable). El producto genérico es lo que cubre el contrato de compra.

Versión

El versionado de software es el proceso de asignación de un nombre o número único a un software para indicar su nivel de desarrollo. Generalmente se asignan dos números, mayor.menor (en inglés: major.minor), que se van incrementando conforme el desarrollo del software aumente y se requiera la asignación de un nuevo nombre o número único. Aunque menos habituales, también puede indicarse otro número más, micro, y la fase de desarrollo en que se encuentra el software.

Números de versión en Velneo v7

Los números de versión que aparecen en los ejecutables de Velneo nos pueden dar información importante a la hora de desarrollar e implantar nuestras aplicaciones.
Los ejecutables de Velneo contienen un número de versión compuesto por cuatro bloques de números separados por puntos (7.4.1.xxxx)
Cada uno de estos bloques de números nos ofrecen información sobre la versión que se está ejecutando y las diferencias con otro ejecutable.

7 – Versión mayor (Cambio mayor de la aplicación con cambios importantes en la estructura básica o filosofía de objetos)
4 – Versión menor (Actualización de la versión anterior con nuevos objetos, reparación de incidencias, optimizaciones, etc.)
1 – Revisión (Versión que sólo soluciona incidencias graves que impiden la ejecución de las aplicaciones, o pudieran poner en peligro la integridad de datos almacenados)
xxxx – Build (Versión diaria en el que se reflejan los cambios desarrollados a lo largo del día por el departamento de desarrollo)

Roadmap

Un RoadMap (que podría traducirse como hoja de ruta) es una planificación del desarrollo de un software con los objetivos a corto y largo plazo, pudiendo incluir plazos aproximados de consecución de cada uno de estos objetivos. Se suele organizar en iteracciones o “milestones”, que son fechas en las que supuestamente estará finalizado un paquete de nuevas funcionalidades.

FAQ

¿Cuál es el producto completo de Velneo (modelo simplificado)?

Producto Genérico

  • Velneo vAdmin V7
  • Velneo vClient V7
  • Velneo vDataclient V7
  • Velneo vDevelop V7
  • Velneo vInstallbuilder V7
  • Velneo vModapache V7
  • Velneo vServer V7
  • Velneo vTranslator V7
  • Velneo vWebclient V7
  • Velneo driver vODBC V7

Software adicional

  • Open apps: Plantillas Empresariales
  • Open apps: Componentes
  • Open apps: Librerías
  • Open apps: Tutores

Servicios adicionales

  • PaaS (vserver)
  • Velneo Directo
  • Servidor de Licencias
  • Blog (wordpress)
  • Foro (Bbpress)
  • Seminarios (Webex)
  • Foro de ideas (uservoice)
  • Seguimiento incidencias (vBugman)

PaaS (Plataform as a Service)

  • vServer en la nube (+5000)
  • Copias de seguridad
  • Panel de control

Soporte y Formación

  • Formación presencial
  • Formación on-line
  • Formación in-company
  • Consultoría
  • Atención al Cliente
  • Soporte
  • Video tutoriales
  • Ayuda
  • Zona Info
  • Videos Youtube
  • Presentación Anual (Life is soft)
  • Preventa consultiva

Instalación y Depuración

  • Integración continua 10 Instalables en 4 plataformas
  • Sistema depurado y estable por versión
  • VEST
  • Perforce
  • Jenkins

Integración de sistemas

  • Windows
  • Mac
  • Linux
  • Móvil
  • Amazon web services
  • Traducción
  • LDAP

¿Cuál es la política de versiones de Velneo?

Lo primero que debemos aclarar es que Velneo no sigue una política de versiones si no de iteraciones. Cada iteración pública introducimos mejoras en el producto completo. Por tanto todas las áreas de la empresa se ven afectadas por esta política.

¿Cuándo salen las iteraciones de Velneo?

El tiempo mínimo para poder poder alinear todos los proyectos de la empresa es de aproximadamente cuatro meses, lo que supone de media tres versiones al año. En estos cuatro meses debemos desarrollar, documentar y alinear todas las mejoras introducidas en el producto completo Velneo.

Si observamos el patrón de repeticiones seguido hasta el momento:

7.0- Febrero 2009
7.1- Junio 2009
7.2- Octubre 2009
7.3- Febrero 2010
7.4- Junio 2010
7.5- Noviembre 2010
7.6- Enero 2011

Aproximadamente estos podrían ser los meses de aparición de las próximas dos iteraciones

7.7-Mayo  2011
7.8-Octubre 2011

¿Cómo notificamos la salida de una versión?

Con un post tipo que ponemos el mes anterior a la salida de una versión. En este post tipo introducimos una de las ideas que ha superado la fase de pruebas y testeo.

¿Cuándo se anuncian las novedades de la versión?

Antes de anunciar las novedades de una versión debemos esperar a que se realice la fase de pruebas y testeo en todas las plataformas, esto evita generar expectativas que no se pueden cumplir. En vBugman se puede hacer un seguimiento en tiempo real del estado de las incidencias cerradas que aparecerán en la próxima versión. El día de la salida de la versión aparece toda la documentación oficial referente a las novedades e incidencias incluidas en la misma.

¿Qué es una revisión?

Una versión sólo de producto genérico que soluciona incidencias graves que impiden la ejecución de las aplicaciones o que puedan llegar a poner en peligro la integridad de datos almacenados.

Ejemplos:
7.1.1 – Julio 2009
7.2.1- Noviembre 2010
7.4.1- Julio 2010

¿Por qué no pueden salir iteraciones cada menos tiempo?

En Velneo llevamos años trabajando en iteraciones de 4 meses y hemos comprobado que es el tiempo mínimo óptimo para trabajar en nuevas funcionalidades, bugs, optimizaciones, nuevos objetos, actualización a nuevas versiones de la librería, open apps, PaaS, componentes, tutores, web, etc. Este proceso nos motiva a trabajar de una forma ágil a la par que fiable para conseguir la estabilidad del producto completo.

En estos ciclos se incluyen 15 días de parada de desarrollo para “estabilizar” la versión y el lanzamiento de la versión candidate que se entrega a Betatester

  • Traducción de los componentes.
  • Pruebas de regresión y de carga.
  • Preparación de la documentación.
  • Open Apps de ejemplo
  • Instalables y descargas
  • Pruebas en todos los sistemas operativos e interoperatividad.
  • Pruebas de PaaS
  • Revisión de documentación y Open Apps
  • Generación de vídeos y tutores
  • Pruebas de la Web y Velneo directo

El coste de tiempo de sacar una iteración con la calidad necesaria es elevado. Si sacáramos versión cada 2 meses, no podríamos mejorar el producto completo. Nuestra idea es que la plataforma avance a medida que se hace más y más robusta.

¿Se tiene en cuenta lo que ponemos en blog, foro, twitter,  vcenas, llamadas, consultorías?

Cuando empezamos con el proyecto Velneo pensábamos que podríamos contestar y recopilar cada post, twitt o foro,..  jóvenes ingenuos, hoy día no somos capaces de leer un pequeño porcentaje de la información que se genera en la red sobre nuestros productos y servicios. Por tanto es simplemente imposible que lo tengamos en cuenta.

¿Cuál es la política de novedades de Velneo?

Ya hemos comentado en alguna ocasión cual es nuestra política de novedades (roadmap), que se divide en tres pilares fundamentales:

Estabilidad de la plataforma

La estabilidad y robustez de la plataforma es una de nuestras obsesiones. Para una mejor comunicación entre la comunidad de programadores y el departamento de Desarrollo de Velneo V7, hemos implantado Velneo vBugMan, una herramienta de gestión de incidencias a la que podéis acceder para conocer el estado de las incidencias y necesidades más apremiantes.

Ideas.velneo.es

Actualmente nos llegan peticiones de cambios en el producto completo. Las peticiones nos llegan por diferentes canales, sin ordenar y priorizar. Ordenar es una tarea titánica que no deja contento a nadie. La situación es que para cada usuario su petición es la más importante y más necesaria.  En noviembre 2010 inauguramos el sistemas de priorización de ideas para suscriptores. (ideas.velneo.es). Aunque antes habíamos trabajado en un sistema en v7 y otro en bbpress. Los resultados de las votaciones de los suscriptores en este tiempo son las siguientes mejoras en el producto completo de Velneo:

  • Soporte telefónico para nivel 4 y que, también, se pueda usar para evitar alargar los hilos de soporte.
  • Soporte de servidores
  • Base de conocimiento
  • Movilidad: versiones para móvil.
  • Deshacer-Rehacer.
  • Rejillas editables.
  • Condición de visible en lanzadores de acción.
  • Pasar de una campo con enter o tab.
  • Aceptar sin cerrar formulario.

Para conocer lo que saldrán en las próximas versiones sólo hay que ir a la pestaña de aceptadas/iniciadas en ideas.velneo.es

Innovación

En el desarrollo de una plataforma como Velneo la anticipación es algo básico. La mayoría de las funcionalidades de las que se disfrutan hoy día fueron pensadas y propuestas por nuestro arquitecto y su equipo en el 2005/2006. Todos recordamos por ejemplo que nadie solicitó las funciones remotas o fórmulas dinámicas y con el tiempo se convierten en componentes básicos de nuestras aplicaciones. Primero no entiendes bien su finalidad cuando te explica la idea, pero cuando lo usas una vez no puedes vivir sin ello. Ejemplos hay muchos, uno es el vDataClient. Esta parte del desarrollo sumada a las necesidades estratégicas de la compañía, es y será una parte fundamental de nuestra estrategia de desarrollo.

En este aspecto se realizan investigaciones sobre diferentes frentes que algunas veces ven la luz y muchas veces se quedan en una simple investigación. Un ejemplo de esto lo hemos publicado sobre nuestra investigación del sistema Android. Por lo general no consideramos necesario comunicar este tipo de investigaciones que levantarían expectativas innecesarias a los clientes que en muchas ocasiones no se cumplirían.

La información de nuestro Roadmap es pública, el problema actual es que está desperdigada en diferentes apartados, nuestra misión es la de unificar la información en una página sencilla.

¿Cómo sabemos las fechas de las cosas?

Actualmente en el foro de ideas informamos de la versión aproximada en la que saldrán las tareas que están iniciadas (Ejem Campos numéricos). Además en el vBugman aparecen en estado “cerrado” las tareas que están finalizadas y que saldrán en la próxima versión.

¿Escuchamos a la comunidad?

Velneo lleva años con una política de escucha a la comunidad, sólo hay que ver la evolución de las versiones y la iniciativa de poner en marcha ideas.velneo.es. Velneo tiene la obligación de tomar las mejores decisiones estratégicas para conseguir su objetivo de convertirse en la “Plataforma completa de aplicaciones empresariales” referente en los desarrolladores hispanos. Para conseguir este objetivo Velneo escucha a clientes, proveedores, competidores, analistas y al mercado objetivo.

¿Cómo puede seguir mejorando la comunicación con la comunidad?

  • El primer frente que tenemos abierto es el de mejorar la usabilidad de vBugman para lograr que las cosas se encuentren de una manera más sencilla y agradable.
  • En ideas.velneo.es debemos actualizar de una manera más precisa y constante.
  • Una vez que tengamos estos dos frentes consolidados deberemos crear una única página de Roadmap que recopile la información más relevante de estas dos bases de datos. Un ejemplo de Roadmap podría ser el mismo de QT, que es una simple página que recopila diferentes fuentes. (Roadmap de QT)

Desde la implantación en la iteración 7.5 de ideas.velneo.es hemos trabajado en estos tres frentes, esperamos que en las tres próximas iteraciones 7,7,7.8 y 7.9 podamos dar pequeños pasos para dar un salto más en la comunicación con la comunidad consolidando estas tres líneas de trabajo.

¿Hay un Roadmap?

NO, actualmente no hay un sistema de Roadmap público, normalmente los roadmap los alimentan los sistemas de gestión de proyectos, ideas y bug tracking (Ejemplo Jira). Por tanto trabajaremos en implementar como hemos indicado lo primero un sistema de bug tracking que satisfaga a todas las partes. Debemos remodelar el vBugman para satisfacer las necesidades internas y externas de la plataforma, ya que al día de hoy no cubre todas las necesidades de información . Una vez tengamos implantado  el sistema de bug tracking y actualicemos de una manera precia y constante la información podemos centralizar la información de los dos sistemas en un sistema tipo (Roadmap de QT).

¿Cuándo estará disponible el sistema de Roadmap?

Es un proyecto de la iteración 7.8-Octubre 2011 que ya está en marcha hoy día. Esta es una fecha orientativa porque todo dependerá del éxito de la implantación interna/externa del sistema de bug tracking, un sistema tipo Jira se tarda mínimo un año en implantar, estamos poniendo todos los esfuerzos de nuestra parte para acortar los tiempos y que el sistema pueda ver la luz lo antes posible. Si queremos implantar algo que sea de futuro hay que hacer las cosas bien analizadas para no estar dentro de 6 meses con los mismos problemas. Hace dos años ya hubo roadmap pero no se hizo un sistema sostenible en el tiempo. No hay que hacer las cosas para que funcionen hoy si no para que funcionen al menos 3 años y eso lleva tiempo. Por tanto no es una tarea de una iteración (7.8-Octubre 2011), hay que ir introduciendo mejoras iteración a iteración en el sistema. Trabajaremos duro para que la primera versión del sistema de Roadmap esté en la iteración 7.8.

¿Hay un sistema de Incidencias graves/necesidades apremiantes?

Realmente esa es la función de un bug tracking. Actualmente el vBugman para nosotros cumple esa función lo que no cubre es la necesidad externa de información que es una de las partes que hay que mejorar. Ya estamos en fase de análisis pero no es una tarea trivial, mejorar la usabilidad del vBugman no es meter dos campos fecha. Hay que mirar y analizar los mejores software de reporte de errores a la comunidad, notificaciones, como mejorar el uso, la introducción, como van a interactuar los departamentos, soporte, atención al cliente, desarrollo, test, vmarco, y la comunidad con la herramienta.