Actualizado: Octubre 2018.
Cuando te planteas si habría que probar un producto que estamos desarrollando, ¿realmente te lo planteas como algo opcional?
Independientemente de que estemos desarrollando una nueva aplicación, un servicio, una nueva funcionalidad, un nuevo producto que queremos lanzar al mercado… probarlo no debe ser algo opcional, si no algo que debemos hacer.
¿Probar o no probar?
Nadie te va a decir que no cuando digas que quieres hacer pruebas sobre 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 va a pedir. Aunque lo que estemos implementando sea un producto mínimo viable con el que poder salir al mercado antes que nuestros competidores, este ha de ser funcional y en ese “ser funcional”, debemos tener en cuenta siempre que, al menos, no de fallos.
El problema podemos tenerlo cuando algo tan esencial no ha sido tomado en consideración desde la planificación inicial del proyecto y nos vamos a ver en la situación de tener que decirle a nuestro cliente que vamos a invertir un esfuerzo adicional en probar el producto y que, por ello, vamos a necesitar ampliar el tiempo de entrega y ampliar el coste, claro, porque como vamos a hacer más trabajo, lo que implica más tiempo y a más tiempo…
Aquí nos vamos a encontrar caras largas que te van a recordar compromisos de entrega, presupuestos cerrados, falta de planificación, 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 del proyecto, con compromisos de entrega por cumplir, 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 y verlo como la “parte contraria” de un conflicto porque, más que contraria lo que está es contrariada. Ponte por un momento en su lugar y piénsalo…
Ni el mejor sistema de pruebas del mundo, por más completo y específico que sea, te va a permitir garantizar al 100% la fiabilidad de tu producto.
Esto debemos tenerlo en cuenta porque nos podemos venir arriba y pillarnos las manos al tratar de justificar la necesidad de realizar actividades de testing fundamentándolas en que el resultado va a ser una aplicación totalmente libre de fallos. Eso no lo vas a poder garantizar nunca.
Volvemos a que nadie te va a decir que no montes los recursos necesarios para garantizar la fiabilidad en las entregas de producto, pero debemos ser conscientes de que ese extra de actividad requiere de un trabajo de base que ha de ser realizado desde la misma toma de requisitos que vas a ir realizando a lo largo del desarrollo para poder definir qué va a ser necesario hacer para probarlos.
A lo mejor esto te choca: ¿Cómo voy a pensar en las pruebas, si aún no está desarrollada la funcionalidad? Pues es precisamente ahí, donde está una de las claves.
Si al definir el requisito con tu cliente, estás teniendo en cuenta lo que vas a tener que hacer para probarlo, vas a obtener los criterios de aceptación adecuados a lo que te están pidiendo 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 ya lo has tenido en cuenta en tus planificaciones iniciales.
¿Quién hace las pruebas?
Si me preguntas qué es mejor, si desarrolladores probando su propio 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.
Cuando empecé con temas de calidad, tenía 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 «a must» que ni te planteabas porque eran lo primero que te pedía tu analista o 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. El tiempo destinado al desarrollo puede (suele, aunque siempre hay excepciones) expandirse más allá de lo planificado. Cuando eso ocurre, lo primero que se suele resentir son aspectos «menores» (modo irónico activado, por favor) como mantener actualizada la documentación del proyecto, las pruebas, etc. 🙁
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 que el uso «normal» no falla pero, ¿y el uso «anormal»? Al menos nuestro desarrollo tendría que controlar que ese uso fuera de lo normal, no nos genere un error no controlado que provoque problemas de uso.
Es cierto que ese error no controlado puede ser motivo de un uso indebido y tendríamos una justificación a la que agarrarnos cuando lleguen las reclamaciones de los usuarios, pero la experiencia de usuario se estaría viendo perjudicada. No es lo mismo mostrar un aviso controlado que informe de que no se está usando correctamente, que le aparezca un error que le impida continuar con lo que estaba haciendo.
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, con cada formulario, lo que les lleva a plantear baterías de pruebas con un enfoque más orientado a comprobar que la funcionalidad no solo no falla, si no que además, funciona de la manera más óptima posible. Por ello, otra cosa que has de tener en cuenta a la hora de conformar tu equipo de proyecto, es contar con gente experta en testing que pueda aportar valor añadido a tu desarrollo.
Un funcionamiento correcto es básico, pero la experiencia de usuario va más allá de una correcta funcionalidad y abarca aspectos como el rendimiento, la usabilidad o la multi-canalidad, entre otros.
Tu equipo de testing 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 ayuden a elevar el nivel de fiabilidad del producto y con ello, la satisfacción de los usuarios. Con la de ellos, ahumentará la de vuestro cliente y por ende, la vuestra, así que al final, todos contentos.
El time-to-market va a marcar los tiempos que marcan el ciclo de vida de desarrollo, forzando nuevos desplieges de funcionalidad a entornos productivos de manera habitual. Una estrategia de testing definida con cabeza y no colada con calzador en un Project, va a ser un elemento clave para llevar a cabo una entrega continua de manera eficiente, lo que te va a permitir ser más competitivo.
Si consigues conjuntar un desarrollo ágil en el que tus pruebas unitarias, de interfaz y de servicios tengan cabida, y dispongas de herramientas para generar datos de prueba y un entorno controlado en el que tu equipo de testing pueda trabajar sin interferencias, vas a poder definir un plan de automatización de pruebas óptimo que cubra los requisitos que estáis desarrollando y las funcionalidades a las que da servicio vuestro producto.
Juntando todo esto en la forma en la que vas a gestionar tu proyecto, la entrega continua es posible. ¿Y tú? ¿Qué opinas?
