Hacer pruebas es un “must”

Tiempo estimado de lectura: 8 minutos.

Cuando te planteas que habría que probar tu producto, ¿realmente te lo planteas como algo opcional? ¿No debería ser algo inherente a la propia implementación?

Independientemente de que estés desarrollando una nueva aplicación, un servicio que van a consumir tus clientes, una nueva funcionalidad que te han pedido tus usuarios, un nuevo producto que quieres lanzar al mercado, etc. probarlo no debe ser algo que nos planteemos, si no algo que debemos hacer. Usando términos de moda, se puede decir que hacer testing es un “must”.

Índice de contenidos

¿Probar o no probar?

Nadie te va a decir que no cuando digas que quieres probar lo que estás construyendo. Sería muy de insensatos, ¡claro que lo quieren probado! ¡Y que funcione! Es lo mínimo que se nos puede pedir. Aunque lo que estemos implementando sea un producto mínimo viable, este tiene que ser funcional y en ese “ser funcional”, debemos tener en cuenta siempre que haga lo que queremos que haga y que, al menos, no falle.

Le voy a decir a mi cliente que voy a invertir un esfuerzo adicional en probar el producto, pero que voy a necesitar ampliar el tiempo de entrega y ampliar el coste, claro, más trabajo implica más tiempo y a más tiempo…

Plantea tu estrategia

Aquí a lo mejor, te vas a empezar a encontrar caras largas que te van a recordar compromisos de entrega, presupuestos cerrados, complicaciones derivadas del “retraso” en la entrega y van a tener razón, porque si te has planteado que tienes que probar el producto una vez que te has embarcado en la ejecución de tu proyecto, con hitos que alcanzar en el horizonte temporal, vas a tener que lidiar con el hecho de que esas pruebas las tenías que haber tenido en cuenta a la hora de cerrar la planificación.

Tampoco debemos dejar que esas caras largas nos hagan empezar a tensar la relación con nuestro cliente o usuario y verlo como la “parte contraria” de un conflicto porque, más que contraria, ahora mismo lo que está es contrariada. Ponte por un momento en su lugar…

Volvemos a que nadie te va a decir que no a que plantees montar los recursos que consideres necesarios para garantizar la fiabilidad de tus entregas en cada implementación, pero debemos ser conscientes de que ese extra de actividad requiere de cierto trabajo de base que debemos realizar desde el mismo momento en que empezamos con la toma de requisitos, planteándonos lo que vamos a hacer para probarlos.

¡Ojo! Ni el mejor sistema de pruebas del mundo, por más completo y específico que sea, te va a permitir garantizar el 100% de fiabilidad de tu producto.

Tenlo en cuenta, porque nos podemos venir arriba y pillarnos las manos al tratar de justificar la necesidad de realizar actividades de testing con que el resultado va a ser una aplicación totalmente libre de fallos. Eso no lo vas a poder garantizar nunca.

A lo mejor esto te choca. ¿Cómo voy a pensar en las pruebas, si aún no está desarrollado el requisito? Pero es precisamente ahí donde está una de las claves.

Si al tomar los requisitos, estás teniendo en cuenta lo que vas a tener que hacer para probarlos, vas a obtener los criterios de aceptación adecuados a lo que te piden y además, te vas a encontrar con que el tiempo de dedicación a las actividades de testing y los recursos que necesitas para ello, no te van a suponer un esfuerzo extra porque lo vas a poder incluir en tus planificaciones iniciales.

¿Quién hace las pruebas?

Si me planteas la cuestión de qué es mejor, si un desarrollador que también pruebe su desarrollo o un equipo específico de testing, te diré que mi opinión sobre el tema ha cambiado con el paso de los años.

Define tus objetivos

Cuando empecé a entrar en temas de calidad, lo hice con la idea de qué mejor que el desarrollador para probar la funcionalidad desarrollada. Partía de la base, y reconozco ahí mi error, de que cuando yo desarrollaba, el tema de las pruebas era un “must” que ni te planteabas porque eran lo primero que te pedía tu jefe de proyecto cuando le decías que habías terminado la tarea. “¿Está probado?”, “¿Funciona?”, “Como encuentre yo un fallo…”.

La realidad es otra y bastante diferente. En una amplia mayoría de casos, aunque siempre hay excepciones, el tiempo de desarrollo puede expandirse más allá de lo planificado y lo primero que se suele resentir son aspectos como mantener actualizada la documentación del proyecto y las pruebas.

Es por esto que, si los desarrolladores van a tener que hacer además las pruebas, y se han visto en la necesidad de ampliar el tiempo de desarrollo, van a acabar definiendo las pruebas básicas que validan el proceso implementado. Pero… si en lugar de pinchar “Aceptar” después de rellenar los datos del formulario, ¿me da el punto y lo pulso con el formulario vacío? No tiene lógica, cierto, pero al menos tendríamos que controlar que esa acción “ilógica” no nos genere un error no controlado que nos tumbe la aplicación.

Es un ejemplo simplista, pero representativo de lo que suele acabar sucediendo.

Los equipos de testing tienen otra visión, más enfocada a la funcionalidad, a la experiencia de usuario, a las diferentes interacciones que se pueden llevar a cabo con cada página, por lo que se plantean las baterías de pruebas con un enfoque más orientado a probar que la funcionalidad no solo no falla, si no que además, funciona de la manera más óptima posible.

Es por esto que otra cosa que has de tener en cuenta a la hora de conformar tu equipo de proyecto, es contar con gente experta en pruebas que pueda aportar valor añadido a tu producto.

Una buena funcionalidad es crítica…. pero la experiencia de usuario va más allá de una correcta funcionalidad y abarca otras perspectivas como el rendimiento, la usabilidad o la multi-canalidad, entre otros.

Este equipo debe estar implicado en todas las fases de construcción, ya que el conocimiento funcional que van a adquirir les va a permitir realizar baterías de pruebas eficaces que os ayuden a elevar el nivel de fiabilidad de vuestro producto y con ello, la satisfacción de vuestro cliente y por ende, de la vuestra, así que al final, todos contentos.

No tener tiempo para probar es otra justificación que debes borrar de tu proyecto y más con las modalidades de negocio emergentes en las que los tiempos de puesta en producción de productos mínimos viables, son cada vez más ajustados.

El time-to-market de tu producto, seguro que te suena el concepto, acelera los tiempos que marcan el ciclo de vida de desarrollo y trae de la mano subidas de versión a entornos productivos de manera habitual. Una estrategia de testing definida con cabeza y no colada con calzador en tu Project, va a ser un elemento clave para llevar a cabo una entrega continua que te va a permitir ser competitivo y destacar en tu sector de actividad.

Si consigues conjuntar un desarrollo ágil en el que automatices tus pruebas unitarias, de interfaz y de servicios, que dispongas de herramientas para generar datos de prueba y un entorno controlado en el que tu equipo de testing pueda trabajar, vas a poder definir un plan de automatización de pruebas óptimo que va a cubrir los requisitos de negocio y las funcionalidades más importantes que debe cubrir tu producto.

Juntando todo esto en la forma en la que vas a gestionar tu proyecto, la entrega continua es posible.

Evalúa tu producto

¿Crees que las pruebas son patrimonio exclusivo del desarrollo de software?

Buena pregunta, ¿verdad? ¿Que piensas? A fin de cuentas, cuando hacemos pruebas, lo que hacemos es definir una actuación, registrar el resultado que hemos obtenido y evaluar si es satisfactorio. En base a esto, ¿sigues pensando que sólo nos aplica si nuestra actividad se centra en desarrollar un producto de software?

A lo mejor tu actividad se centra en desarrollar un personaje de animación para una serie y según va avanzando ésta, ves que el personaje no está causando el impacto en la audiencia que habíais previsto inicialmente, lo que os lleva a tratar de analizar qué es lo que no está encajando e ir haciendo ajustes que permitan reconducir el resultado.

Se que me vas a decir que esto no es un producto como tal, pero si que vas a ver cómo evolucionar tu personaje en base a evaluar el resultado de los cambios que vas introduciendo.

Puede que te dediques a la radio y quieras hacer cambios en tu programa, tales como incluir una sección nueva y para ello vas probando diferentes temáticas hasta que das con la que aporta lo que buscas y lo que demanda tu audiencia.

Si estás embarcado en una campaña de marketing en Facebook y tu cliente tiene que publicar en varios idiomas, vas a hacer pruebas con la segmentación para intentar mejorar la experiencia de usuario de sus seguidores al mostrarles la publicación en el idioma en el que tienen configurada su red social, en lugar de que les aparezca una publicación en la que muestras todos los idiomas con los que trabajas esperando que el seguidor busque el párrafo que comprende.

Algo más cercano. A lo mejor te estás planteando bajar de peso y no acabas de dar con el mejor método para hacerlo. Tampoco es un producto, cierto, pero si es un objetivo a conseguir para el que vas a estar probando diferentes acciones y evaluando los resultados que obtienes hasta que lo alcances, ¿no?

En todos estos ejemplos, al final siempre volvemos a las mismas actividades de base que se dan en un proceso de pruebas: definir una actuación, registrar el resultado obtenido y evaluar si es satisfactorio.

¿Y tú? ¿Qué opinas? Déjame tus impresiones en los comentarios.

¿Calidad en código o proyectos zombi?

Tiempo estimado de lectura: 3 minutos y medio.
Tiempo de vídeo: 16 minutos, 53 segundos.

Cuando empiezas a rascar un poco en el mundo de los frameworks ágiles, te encuentras con que esto del #Agile no es una moda nueva, ni tampoco pasajera, si no una forma de ver el desarrollo de software que se aparta de la concepción típica de “proyecto en cascada” donde no pasamos a la siguiente fase hasta no haber completado la anterior… vamos, como si estuviésemos levantando una casa.

Cuando vamos a construir una casa, lo primero son los cimientos pensarás, pero antes de los cimientos tienes que tener el plano de arquitectura y para ello, tienes que tener antes los requisitos cerrados de cómo va a ser la casa y no cambiarlos… Aquí te pegas de bruces con la primera pega y no es otra que la de que en desarrollo de software, ¿cuándo tienes los requisitos cerrados?

Asumiendo esto, el planteamiento de proyecto debe ser diferente, debe ser un “proyecto ágil” y aquí es donde entra la interpretación errónea de #agilidad. Cuando empiezas a contarle al equipo de desarrollo todo lo que hay que hacer dentro de un #sprint, siempre hay quien te dice: “pero es que hacer todo esto… ¡no es ágil!” y lo cierto es que si lo ves así, ¡claro que no es ágil!

Es como si te piden que bajes a la calle desde un cuarto piso y te tiras por la ventana… Esa forma de bajar es ágil si, pero… ¿cómo llegas al suelo?

El concepto de agilidad se enfoca en hacer entregas de funcionalidad operativas (importante el detalle de que sean operativas) en un tiempo más o menos breve.

Tenemos que dejar a un lado la concepción de “proyecto en cascada” en el que vamos a necesitar varios meses para poder entregar una primera versión de la aplicación. ¿Cuántas cosas pueden cambiar en esos meses? Las necesidades del usuario pueden ser diferentes y probablemente lo serán.

Situaciones así acaban degenerando en lo que, en el vídeo que os dejo al final de este post, llaman “proyecto zombi”. Proyectos que no se mueren nunca y que se comen todo lo que se cruza en su camino (equipos, presupuestos, paciencias…).

Hacer una entrega funcional en poco tiempo implica eso, que tiene que funcionar. No tiene por qué tener toda la funcionalidad que nos han pedido, pero si entregar algo con lo que nuestro cliente pueda empezar a trabajar, a ver, a trastear, a usar…

Ya sabemos lo que cuesta tener una idea clara de cómo queremos que sea nuestra aplicación hasta que no la tenemos delante y no empezamos a trabajar con ella, no es fácil que aquellas personas que van a darle uso tengan claro lo que verdaderamente necesitan, pues vamos a darles algo con lo que puedan empezar a trabajar y sobre lo que nos vayan diciendo cómo evolucionarlo.

Una entrega que funcione tiene que haber sido probada, obviamente. Hacer pruebas no te garantiza al 100% que la funcionalidad sea perfecta, pero si que estamos poniendo una red bajo el alambre de funambulista al que nos hemos subido, así que si las dejamos para el final, es bastante probable que nos hayamos comido el tiempo con otras tareas y al final, las pruebas, las haremos deprisa y mal (en el mejor de los casos).

Tener un equipo al margen del de desarrollo, encargado de hacer las pruebas no es la mejor forma de incorporar esta funcionalidad en el ciclo ágil, ya que debemos conseguir integrarlas dentro de la operativa del equipo, como una tarea más dentro de las propias de la evolución de nuestro proyecto.

Si intentamos sacar las tareas de testing de las habituales dentro del sprint, va a suponer una inversión mayor de tiempo, ya que si los que prueban no están inmersos en el desarrollo, ¿cómo obtienen el conocimiento de negocio necesario para poder probar lo que otro equipo está desarrollando? Requeriría definir más los requisitos, elaborar documentación más detallada, definir mejor los criterios de aceptación… esas cosas que tanto cuestan hacer en un proyecto en cascada, sobre todo tiempo que al final no tienes.

Bueno, ya está bien de reflexiones, por este post al menos. Os dejo con el vídeo, no tiene desperdicio…