Optimizando la Calidad en tu App Bancaria

Mejora del Proceso de Prueba

Imagina que trabajas en un banco y lanzan una nueva función para "Inversiones en Cripto". Si el proceso de pruebas es lento o deja pasar errores graves (como saldos incorrectos), el costo para el banco es enorme. De hecho, las pruebas representan hasta el 40% del costo total de un proyecto. Por eso, no basta con probar; hay que mejorar cómo probamos.

¿Por qué mejorar el proceso?

La tecnología bancaria es cada vez más compleja: debe funcionar en mil modelos de celulares, ser ultra segura y cumplir con leyes estrictas. La mejora del proceso busca dos cosas:

• Efectividad: Encontrar los errores que realmente importan (ej. que no se pierda el dinero).
• Eficiencia: Hacerlo más rápido y con menos recursos (ej. automatizando tareas repetitivas).

¿Cómo y cuándo se mejora?

Puedes mejorar a nivel de toda la organización (lo ideal) o solo en tu equipo. Generalmente, la necesidad surge cuando algo sale mal: aparecen defectos inesperados en producción, los clientes se quejan de la app o hay falta de comunicación entre desarrolladores y probadores.

Aplicación en el Banco

Si en la última actualización del banco detectaste que las pruebas de seguridad tardaron demasiado, puedes aplicar técnicas de mejora:

• Aprender de errores: Si un bug llegó al cliente, analizamos por qué no lo vimos antes.
• Buenas prácticas: Implementar herramientas que escaneen el código automáticamente en busca de vulnerabilidades antes de que alguien lo ejecute.

En resumen: Mejorar el proceso de prueba es un ciclo continuo de aprendizaje para que los proyectos sean más exitosos, gasten menos y, sobre todo, protejan mejor al usuario final. 

El "Cómo" Estratégico de tu App Bancaria

Elección de un Enfoque de Prueba

Imagina que eres el responsable de calidad de una nueva función: "Préstamos Express desde el Celular". Tienes poco tiempo y el riesgo de perder dinero es real. No puedes probar todo de la misma forma; aquí es donde eliges tu enfoque de prueba.

¿Qué es elegir el enfoque?
Es decidir la combinación ganadora de niveles (¿probamos piezas sueltas o el flujo completo?), tipos (¿probamos la rapidez o la seguridad?) y técnicas (¿leemos el código o picamos botones?). La estrategia del proyecto es tu guía: detalla objetivos, quién hace qué y con qué herramientas.

Efectividad vs. Eficiencia en tu App Bancaria
Aunque en teoría podrías probar la seguridad manualmente picando la pantalla mil veces, eso sería ineficiente. El texto nos enseña que hay herramientas mejores para cada problema:

• Análisis Estático: Si queremos saber si el código de la tasa de interés está bien escrito y es fácil de mantener, lo mejor es revisar el código sin ejecutarlo. Es rápido y preventivo.
• Pruebas de Sistema (con Scripts): Para ver si la app aguanta a 10,000 personas pidiendo un préstamo al mismo tiempo (desempeño), usamos guiones automáticos que simulen esa carga.
• Pruebas de Aceptación Manuales: Para saber si un cliente real entiende cómo aceptar el contrato del préstamo, lo mejor es observar a un usuario real interactuando con la app.

En Resumen
Como líder de pruebas, mi trabajo es mezclar estos ingredientes. Una buena elección de enfoque hace que las pruebas no solo encuentren errores (efectividad), sino que lo hagan gastando el menor tiempo y dinero posibles (eficiencia). 

Blindando tu App Multimedia con Pruebas Inteligentes

Mitigación del Riesgo 

Imagina que eres el responsable de calidad de una app como Netflix o Spotify. Tienes miles de funciones, pero poco tiempo. ¿Cómo decides qué probar con más ganas? La respuesta es la mitigación del riesgo mediante pruebas adecuadas.

¿Cómo usamos las pruebas para reducir el riesgo?

La prueba es nuestra herramienta principal para que la probabilidad de que algo falle sea mínima. En tu app multimedia, no todas las piezas son iguales:

• Prioridad por riesgo: Si el sistema de pagos de suscripción tiene un riesgo alto, las pruebas deben empezar ya y ser súper rigurosas. En cambio, si el riesgo es que un botón de "compartir" cambie de color (riesgo bajo), las pruebas pueden esperar y ser más sencillas.
• El contexto manda: Como jefe de pruebas, analizo factores clave para elegir el mejor enfoque:
• Características de calidad: No es lo mismo probar la seguridad (que no te roben la cuenta) que la usabilidad (que sea fácil buscar un podcast). Cada una necesita expertos y entornos distintos.
• Niveles y tipos: Algunos fallos de seguridad se encuentran leyendo el código (estáticas), otros viendo cómo se comporta la app encendida (dinámicas).
• El equipo: A los probadores más cracks les asigno las funciones más peligrosas, como el algoritmo de reproducción 4K.

Controlando el "Riesgo Residual"

Al final, mi trabajo es informar cuánto "peligro" queda. Si después de mil pruebas el sistema de video sigue fallando un 1%, ese es el riesgo residual. Los dueños del negocio usarán esta información para decidir: "¿Lanzamos la app así o esperamos a que sea más estable?".

En resumen: No probamos todo al azar; usamos el riesgo como brújula para invertir el esfuerzo donde realmente importa para el usuario.

Estrategias de Caja Negra y Caja Blanca para tu App Multimedia

Gestión de Pruebas

Imagina que estás construyendo una app de contenidos multimedia (videos, podcasts, etc.) Para que sea exitosa, necesitas probarla desde la perspectiva del usuario y desde la lógica interna del código. Una gestión de prueba efectiva requiere un enfoque integrado que combine las pruebas funcionales, no funcionales, de caja negra y de caja blanca.

1. Gestión de la Prueba de Caja Negra (Enfoque del Usuario)

La Prueba de Caja Negra se enfoca en el usuario, sin ver el código interno. Se prueba el comportamiento de la app.

• Propósito: Asegurar que la app multimedia cumpla con todos los escenarios del usuario y los requisitos del negocio. Por ejemplo, verificar que el botón de play funcione correctamente y que el historial de reproducción se guarde.
• Análisis de Cobertura: Como gestor, te aseguras de que las pruebas cubran todos los escenarios de usuario. Por ejemplo, probar la reproducción en diferentes dispositivos, con y sin conexión.
• Retroalimentación: Gestionas la recopilación de feedback de los usuarios. Si los usuarios reportan que es difícil encontrar la opción de subtítulos, usas esa información para mejorar las pruebas de caja negra.

2. Gestión de la Prueba de Caja Blanca (Enfoque del Código)

La Prueba de Caja Blanca se centra en la estructura interna y la lógica del código.

• Propósito: Asegurar que las pruebas cubran a fondo la lógica interna. Por ejemplo, en el código que maneja la carga del video, se busca garantizar que no haya bucles infinitos o caminos de código sin probar.
• Optimización de Cobertura de Código: Supervisas el uso de herramientas que miden el porcentaje de código que ha sido ejecutado por las pruebas. Si una parte del código de reproducción multimedia no está cubierta, diriges los recursos para probar esa área.
• Conocimientos Técnicos: Aseguras que los probadores usen sus conocimientos técnicos para diseñar pruebas que entiendan cómo funciona internamente el sistema de streaming.

Al gestionar ambos enfoques, garantizas que tu app multimedia no solo funcione externamente para el usuario (caja negra), sino que también esté construida con una lógica interna sólida y eficiente (caja blanca).

Probador y Jefe de Pruebas; Roles en las Pruebas de Software

 ¿Quien hace qué?

En el mundo de las pruebas de software, existen dos roles principales: Jefes de Prueba y Probadores. Si bien ambos trabajan para garantizar la calidad del software, sus responsabilidades y enfoque difieren.

Jefe de Prueba:

• Liderazgo y gestión: El Jefe de Prueba es responsable de la planificación, organización, ejecución y control de todas las actividades de prueba dentro de un proyecto.
• Estrategia y visión: Define la estrategia de prueba general para el proyecto, alineada con los objetivos del negocio y las necesidades del software.
• Gestión de recursos: Asigna y supervisa al equipo de prueba, garantizando que cuenten con las habilidades y herramientas necesarias.
• Comunicación y reporte: Comunica el progreso y los resultados de las pruebas a las partes interesadas, como gerentes de proyecto, desarrolladores y clientes.
• Mejora continua: Implementa procesos y herramientas para optimizar las actividades de prueba y la calidad del software.

Probador:

• Ejecución de pruebas: Diseña, ejecuta y documenta casos de prueba para identificar errores y defectos en el software.
• Análisis y reporte: Analiza los resultados de las pruebas, documenta los defectos encontrados y los comunica a los desarrolladores.
• Experiencia técnica: Posee conocimiento técnico del software que se está probando y de las herramientas de prueba utilizadas.
• Pensamiento crítico: Identifica errores y problemas potenciales que podrían afectar el funcionamiento del software.
• Habilidades de comunicación: Comunica efectivamente los resultados de las pruebas a los desarrolladores y otras partes interesadas.

En resumen:
Los Jefes de Prueba son líderes y estrategas que gestionan el proceso de prueba en general.
Los Probadores son ejecutores técnicos que realizan las pruebas y reportan los defectos.

¿Qué prueba de estructura es la mejor?

El Valor de la Prueba de Sentencia y Decisión

Imagina que estás construyendo un robot. El robot tiene un brazo que puede extender y retraer. El robot tiene el siguiente código:

Python

def extender_brazo():
  brazo.extender()

def retraer_brazo():
  brazo.retraer()

Usa el código con precaución. 

La función extender_brazo() tiene una sola sentencia ejecutable: brazo.extender().

La función retractar_brazo() tiene una sola sentencia ejecutable: brazo.retraer().

La prueba de sentencia se centra en probar cada sentencia ejecutable en el código. En este caso, la prueba de sentencia requeriría crear dos casos de prueba: uno para la función extender_brazo() y otro para la función retractar_brazo().

Estos casos de prueba probarían que el robot puede extender y retraer su brazo correctamente.

La prueba de decisión se centra en probar cada decisión en el código. En este caso, la prueba de decisión no requeriría crear ningún caso de prueba adicional.

Esto se debe a que la prueba de decisión ya se ha cubierto con la prueba de sentencia.

Comprobar las decisiones del código

Prueba y Cobertura de Decisión 

Imagina que estás jugando un videojuego y quieres comprar una armadura. El videojuego tiene la siguiente función:

Python

def comprar_espada(jugador):
  if jugador.tiene_dinero():
    armadura = crear_armadura()
    jugador.agregar_armadura(armadura)
    return armadura
  else:
    return None

Usa el código con precaución. Más información

La función comprar_armadura() tiene una sola decisión: jugador.tiene_dinero().

La prueba de decisión es una técnica de prueba de software que se centra en probar cada decisión en el código. En este caso, la prueba de decisión requeriría crear dos casos de prueba: uno que pase un jugador con dinero a la función comprar_armadura() y otro que pase un jugador sin dinero a la función comprar_armadura().

Los casos de prueba probarían que la función comprar_armadura() funciona correctamente en ambos casos:

• Si el jugador tiene dinero, la función debería devolver una armadura.
• Si el jugador no tiene dinero, la función debería devolver None.

¿Cómo funciona internamente el sistema?

Pruebas de la estructura del sistema

Imagina que estás construyendo un robot. Quieres asegurarte de que el robot pueda realizar todas las tareas que necesitas que haga.

Las técnicas de prueba de caja blanca son una forma de hacerlo. Estas técnicas se basan en la estructura interna del robot, como su código fuente o su diagrama de flujo.

Una de las técnicas de prueba de caja blanca más comunes es la prueba de flujo de control. Esta técnica se centra en probar todos los caminos posibles a través del código del robot.

Otra técnica de prueba de caja blanca común es la prueba de cobertura de condiciones. Esta técnica se centra en probar todas las condiciones posibles en el código del robot.

Al utilizar estas técnicas, puedes asegurarte de que tu robot puede realizar todas las tareas que necesitas que haga.