¡Blindando tu App!

Pruebas y Gestión de la Configuración

Seguimos en el desarrollo de una aplicación. La seguridad y la estabilidad son críticas, ¿verdad? Pues bien, la prueba y gestión de la configuración son como el sistema de seguridad y el control de calidad automáticos de tu app. En el desarrollo ágil, usamos muchísimas herramientas para que cada vez que se hace un cambio en el código, la app se revise a sí misma.

¿Cómo Protegemos tu App?

Cuando los desarrolladores escriben código para una nueva función, como una transferencia de dinero, no solo lo programan. También usan herramientas para:

• Análisis estático: es como un corrector de estilo automático que revisa el código en busca de errores o posibles vulnerabilidades, ¡antes de que la app se ejecute!
• Pruebas unitarias: prueban pequeños fragmentos de ese código para asegurarse de que cada pieza funcione perfectamente por sí sola.
• Gestión de la Configuración: cada vez que se actualiza el código o las pruebas, todo se guarda en un sistema centralizado. Es como tener un control de versiones de cada ingrediente de tu app, siempre listo para ser combinado.

Luego, todo esto se conecta a un sistema de integración continua. Piensa en ello como una línea de ensamblaje automatizada. Cada vez que se añade un nuevo código, la app se "construye" y se somete a pruebas automáticas de inmediato. Esto incluye:

Pruebas funcionales automatizadas: Estas pruebas van más allá de las unitarias. Revisan si la nueva función de transferencia (y cómo interactúa con otras partes de la app) hace lo que se espera. Usamos herramientas especializadas para esto.

Detección temprana de fallos: Si algo sale mal en una prueba automatizada, el equipo se entera al instante. Esto es genial porque evita el problema de las "construcciones fallidas" que se dan en proyectos más antiguos: detectamos el error, lo arreglamos y volvemos a probar, ¡todo muy rápido!

Beneficios Clave para la Calidad

Este enfoque reduce drásticamente el riesgo de que una nueva función rompa algo que ya funcionaba (lo que llamamos regresión). Sin embargo, no podemos depender solo de las pruebas unitarias; también necesitamos pruebas automatizadas a niveles más altos (integración y sistema) para asegurarnos de que toda la aplicación bancaria trabaje en conjunto sin problemas.

Al final, este sistema garantiza que tu app sea robusta y confiable.

¡Asegurando tu App en Cada Paso!

Niveles de Prueba

Continuemos con la construcción de una aplicación bancaria. Para que sea impecable, segura y confiable, no la pruebas solo al final. En el desarrollo ágil, la pruebas en diferentes niveles, como si estuvieras verificando cada componente, cada conexión y cada función por separado, y luego todo junto.

¿Cómo se Prueban las Apps en un Enfoque Ágil?

En el desarrollo ágil, que se mueve en iteraciones cortas (piensa en ciclos de 2 a 4 semanas), las pruebas no son un paso final, sino una actividad continua y entrelazada con el desarrollo. Es como construir la app pedacito a pedacito, y cada pedazo se prueba de inmediato.

Durante cada una de estas iteraciones, una función típica de tu app (como "transferir dinero") pasa por varios niveles de prueba:

• Prueba Unitaria: Los desarrolladores hacen esto. Es como si probaran que cada línea de código, cada "engranaje" de la app bancaria, funcione por sí solo. Si un botón de la app tiene un código, se prueba ese código para asegurarse de que hace lo que debe.

• Prueba de Aceptación de Prestaciones: Aquí ya estamos probando una función completa de la app. A veces se divide en dos:

• Verificación de Prestación: Suele ser automatizada y la hacen desarrolladores o probadores. Se asegura que la función cumple con los criterios de aceptación definidos. Por ejemplo, si un criterio es que "una transferencia debe reflejarse en 5 segundos", esta prueba lo verifica.

• Validación de Prestación: Es más manual y participan probadores, desarrolladores y hasta el "cliente" (alguien del banco). Aquí se ve si la función no solo cumple los criterios, sino que realmente es útil y fácil de usar para el usuario. Es como darle la app a un cliente real para que pruebe la transferencia y nos diga si la experiencia es buena.

• Pruebas de Regresión: Mientras se construyen nuevas funciones, se ejecutan constantemente las pruebas de las funciones viejas. Esto es crucial en una app bancaria para asegurar que una nueva función no rompió accidentalmente algo que ya funcionaba, como el inicio de sesión o el historial de transacciones. Estas suelen ser muy automatizadas.

• Pruebas de Sistema: Una vez que varias funciones están listas, se prueba la app como un todo. Aquí se ven cosas como el rendimiento (¿la app es rápida?), la seguridad (¿está protegida mi información bancaria?), y la usabilidad (¿es fácil de navegar?).

También existen otras pruebas de aceptación que pueden hacerse al final de cada iteración o después de varias, como las pruebas Alfa y Beta (donde usuarios reales prueban la app antes de lanzarla), o pruebas específicas de cumplimiento normativo (para asegurar que la app cumple con las leyes bancarias).

¡Los Ladrillos y el Plano de tu App!

Los Productos de Trabajo:

Imagina que estás construyendo una aplicación bancaria. Para que esta app sea segura y funcione sin problemas, necesitas una serie de elementos clave: documentos, código, pruebas, etc. A estos elementos los llamamos productos de trabajo. Son como los planos, los materiales y las herramientas que usas para construir algo de alta calidad.

Tipos de Productos de Trabajo en Proyectos Ágiles

En el desarrollo ágil, estos productos se dividen en tres categorías principales, buscando ser directos y enfocados en lo que realmente aporta valor:

Orientados al Negocio (El "Qué" y el "Para Qué"):

Piensa en las historias de usuario. Son como las instrucciones de tu cliente: "Como usuario de la app, quiero poder transferir dinero a un contacto de forma segura". También incluyen los criterios de aceptación, que son los detalles específicos que te dicen cuándo esa transferencia se considera "hecha" y funciona bien. Estas historias deben ser pequeñas para que puedan terminarse rápidamente. Si son muy grandes, las llamamos "épicas" y las dividimos en historias más pequeñas.

De Desarrollo (El "Cómo" se Construye):

Aquí está el corazón de la app: el código. También incluye cosas como los diagramas que muestran cómo se conectan las diferentes partes de la app (por ejemplo, cómo se guarda la información en la base de datos). Además, los desarrolladores crean pruebas unitarias automatizadas, que son como pequeños exámenes para cada pedacito de código, asegurándose de que funcionen correctamente desde el principio.

De Prueba (El "Cómo" se Verifica):

Estos son los elementos que usas para asegurar la calidad. Incluyen los planes y estrategias de prueba (tu hoja de ruta para probar), las pruebas manuales que realizas tú, y, muy importante, las pruebas automatizadas (los "robots" que revisan la app una y otra vez). También generas informes de defectos (si encuentras algo que no funciona) y registros de resultados, que te muestran el estado de las pruebas, como un "tablero de control" para la calidad de la app.

En los proyectos ágiles, la idea es evitar la documentación excesiva. Nos centramos en tener una aplicación bancaria que funcione perfectamente y en pruebas automatizadas que demuestren que cumple con los requisitos. La clave es encontrar un equilibrio: tener suficiente documentación para que todos entiendan lo que se está haciendo, pero sin que se convierta en un obstáculo.

Como probador, entender estos productos de trabajo te da una visión clara de todo el proyecto y te permite colaborar de forma efectiva.

¡Una App Bancaria Siempre en Forma!

Las Pruebas en el Desarrollo Ágil

Imagina que estás construyendo una aplicación bancaria. En el mundo ágil, no esperamos a tener la app completamente terminada para empezar a probarla. En lugar de eso, la construimos y probamos en partes pequeñas y funcionales, como si estuvieras agregando una función de pagos, luego una de transferencias, y así sucesivamente, asegurándote de que cada una funcione a la perfección antes de pasar a la siguiente.

La principal diferencia con el desarrollo tradicional es que aquí, las pruebas ocurren a lo largo de cada ciclo corto (iteración), no solo al final. Esto significa que desarrolladores, probadores y hasta los representantes del banco (los "implicados de negocio") trabajan juntos. Los desarrolladores hacen sus pruebas unitarias mientras escriben el código para una función específica. Luego, los probadores se encargan de las pruebas de la función, asegurando que esta parte de la app haga lo que se espera. Incluso los representantes del banco prueban las funciones para dar una retroalimentación rápida y ver si la app cumple con sus necesidades.

A veces, para asegurar que todo está funcionando bien, el equipo puede tener iteraciones de consolidación, como un "repaso general" para arreglar cualquier error persistente. Una buena práctica es siempre solucionar los errores pendientes de la iteración anterior antes de empezar con nuevas funciones.

Como probador en este ambiente, tu rol es clave. 

Participarás en la planificación de la entrega (el plan general de la app) y en la planificación de cada iteración (qué se hará en ese ciclo corto). Esto incluye ayudar a definir las historias de usuario (lo que la app debe hacer desde la perspectiva del usuario), identificar riesgos y estimar cuánto tiempo tomarán las pruebas.

Además, en el desarrollo ágil, se utiliza mucho la automatización de pruebas. Esto significa que gran parte del trabajo de probar se hace con código, liberando a los probadores para que se enfoquen en pruebas más complejas o exploratorias. Incluso puedes trabajar en pareja con un desarrollador para construir y probar una función al mismo tiempo. El objetivo es que la calidad sea responsabilidad de todo el equipo, y tú, como probador, actúas como un entrenador en ese camino. 

El Mito del Software "Perfecto"

¿Software Sin Fallos? 

Imagina que estás desarrollando una aplicación de fondos de inversión. Aquí, un pequeño error podría significar pérdidas enormes para los usuarios. Nos preguntamos: ¿Es posible crear software que nunca falle?

El Mito del Software "Perfecto"
En el mundo real, estamos acostumbrados a que las aplicaciones fallen de vez en cuando. Pero en áreas críticas como las finanzas, los errores pueden ser catastróficos. La buena noticia es que sí es posible construir software lo suficientemente bueno como para que sus fallos no afecten a los usuarios o al negocio.

Wikipedia menciona un ejemplo asombroso(1): la Línea 14 del metro de París, que funciona sin conductor desde 1998 gracias a un software que, durante años, no tuvo ningún fallo significativo. Esto no significa que el software sea "perfecto" en un sentido absoluto (siempre podría haber un error oculto), sino que los posibles errores nunca se manifestaron de una manera que afectara a los pasajeros.

Tu Rol como Probador: Buscando la "Calidad Suficiente"
Entonces, ¿cómo aplicamos esto a tu app de fondos de inversión? No se trata de eliminar todos los errores posibles (algo casi imposible), sino de enfocarnos en la calidad "suficiente". Esto significa:

• Identificar lo Crítico: Como probador, tu misión es identificar y probar a fondo los comportamientos más importantes de la app. Por ejemplo, en una app de fondos de inversión, asegurar que las transacciones se realicen correctamente, que los saldos se muestren bien y que los cálculos sean exactos es mucho más crítico que el color de un botón.
• Probar el Impacto: Nos interesa que los errores que podrían existir no sean tan graves como para causar pérdidas de dinero o afectar la confianza del usuario.
• Validar Comportamientos Típicos: ¿Cómo interactúa un usuario normal con la app? Esas son las áreas donde debemos ser más rigurosos con nuestras pruebas.

Aunque los probadores "muestran la presencia de fallos, pero no la ausencia" (una frase famosa en el testing), lo importante es que, al realizar pruebas inteligentes y estratégicas, aportamos un valor inmenso para acercarnos a esa calidad que evita tragedias y genera confianza.
 

1https://es.wikipedia.org/wiki/L%C3%ADnea_14_del_Metro_de_Par%C3%ADs