Las vitrinas muestran la dirección, los paneles muestran el pulso
«¿Confiarías en un caso de prueba escrito por una IA sin revisión humana?» Esta pregunta fue la que más resonó entre los asistentes al Info.Lunch: Foro de Automatización y Pruebas Bancarias. El 17 de septiembre de 2026, responsables de control de calidad de bancos y empresas de pago de la Suiza de habla alemana y Liechtenstein se reunieron en el Viaducto Arch D de Zúrich. Estuvieron representados los principales bancos, bancos minoristas y bancos privados.
Tal como anunciamos en la edición anterior, en esta ocasión hemos abierto el foro a participantes más allá de Avaloq. Ahora está dirigido a toda la industria FinTech suiza y sigue centrado en su misión principal: la ingeniería de calidad en el sector bancario.
Cuatro perspectivas sobre las pruebas cotidianas
El evento se centró en una mesa redonda moderada que abarcó cuatro temas relevantes para las prácticas diarias de pruebas de los bancos: incidentes de producción y cultura de errores, estrategia de regresión, calidad del software adquirido e inteligencia artificial en las pruebas. Maximilian Matthäus (Infometis) moderó la mesa redonda, que incluyó:
- Domenic Zimmermann, Jefe del Centro de Excelencia de Pruebas, Grupo LGT
- Petra Bohner, directora de soluciones y proyectos, Aargau Cantonal Bank
- Tom Liebau, Jefe de Equipo del Centro de Excelencia de Pruebas de Bank-now
- Tjeerd Olk, propietario de producto de habilitación de calidad, Finnova
Los bancos y los proveedores de software tienen perspectivas diferentes sobre la automatización de pruebas: distintos incentivos, responsabilidades y percepciones de riesgo. Esto hace aún más evidente la similitud de sus enfoques, preguntas y prioridades en la práctica. Junto con la automatización y las pruebas basadas en riesgos, la necesidad de una ingeniería de calidad basada en agentes está creciendo notablemente.
Incidentes de producción: Solución antes de cuestionar la responsabilidad
Todas las empresas participantes cuentan con procedimientos claros para cuando surge algún problema en la producción. El enfoque se centra en encontrar una solución; la búsqueda de culpables pasa a un segundo plano. La clasificación de incidentes ayuda a identificar dónde reside el mayor potencial de optimización. Si un error se origina repetidamente en la misma fuente, es perfectamente aceptable abordarlo. Esto se realiza de forma reflexiva y con el objetivo de resolver el problema de manera colaborativa y sostenible.
El objetivo sigue siendo cero incidentes. Cualquiera que quiera mantener las pruebas bajo control está asumiendo un riesgo conscientemente.
Nuestra valoración: Un riesgo solo puede asumirse conscientemente si es visible. Esto requiere respuestas claras a tres preguntas:
- ¿Qué procesos empresariales son críticos?
- ¿Dónde se acumulan las desviaciones?
- ¿Qué riesgo residual soporta el departamento?
Las pruebas basadas en el riesgo hacen que esta decisión sea comprensible, también para los auditores y los reguladores.
Estrategia de regresión: Los casos de prueba necesitan una fecha de caducidad
Todos los presentes en la mesa están familiarizados con el crecimiento de los conjuntos de regresión. En lugar de debatir sobre el número adecuado de casos de prueba dentro del conjunto de regresión, el grupo se centra deliberadamente en la cobertura de pruebas y las pruebas basadas en riesgos. Casi ninguna empresa cuenta con un proceso que defina cuándo se deben eliminar casos de prueba de la regresión. A medida que aumenta la complejidad de las aplicaciones, también lo hace el esfuerzo de prueba. Lo fundamental es alinear el conjunto con el software modificado después de cada lanzamiento y mantenerlo actualizado.
Nuestra evaluación: Un conjunto de regresión se mantiene conciso si se aplican criterios igualmente claros para incluir y excluir casos de prueba. Dichos criterios incluyen, por ejemplo, el riesgo cubierto, la tasa de aciertos en versiones recientes o la superposición con otros casos de prueba. Es fundamental actualizar el conjunto de regresión después de cada versión. Esta tarea a veces se olvida o se le da poca prioridad.
Software adquirido: Responsables en lugar de los culpables
El panel dejó abierta deliberadamente la cuestión de quién es el responsable de un error de producción en el software adquirido, porque se consideró que no era la pregunta adecuada. El objetivo es identificar a los responsables, no a los culpables. Aquí también, la meta es aprender juntos y lograr el mejor resultado posible. Los bancos solo realizan parcialmente pruebas de aceptación para el software adquirido. Sin embargo, sí devuelven al fabricante el software de mala calidad.
El panel no coincidió en un punto. Los bancos atribuyeron más de la mitad de los problemas reportados al fabricante, mientras que el fabricante atribuyó más de la mitad al cliente.
Nuestra valoración: Esta diferencia es un buen punto de partida. Unos criterios de aceptación definidos conjuntamente y una clasificación de las desviaciones consensuada permiten que ambas partes partan de la misma base fáctica antes de que el software entre en producción.
IA en las pruebas: De las pruebas con IA a las pruebas con IA
Según una encuesta en directo, este fue el segmento que más resonó entre la audiencia. La pregunta central era si se podía confiar en un caso de prueba escrito por una IA sin revisión humana. Tjeerd Olk replicó preguntando si una prueba realizada por humanos merecía realmente la misma confianza. Argumentó que también se cometen errores, pero que los aceptamos con mayor facilidad.
Al mismo tiempo, el panorama está cambiando. Las pruebas con IA se están convirtiendo en pruebas con IA, lo que impone nuevas exigencias a las habilidades individuales. Petra Bohner planteó la cuestión de cómo se debería capacitar a la próxima generación de evaluadores si carecen de la experiencia formativa necesaria.
Nuestra perspectiva: Esta es una cuestión que nos ha preocupado durante algún tiempo. Como la primera empresa suiza en ofrecer formación para la certificación ISTQB en pruebas de IA . En ella, los evaluadores aprenden a examinar metódicamente los sistemas de IA y a evaluar críticamente los resultados generados por la IA.
El intercambio continúa durante el almuerzo
Tras la parte oficial, el debate continuó durante el almuerzo, que incluyó una demostración interactiva de STAMINA con Benjamin Tan. Prácticamente todos los asistentes permanecieron hasta el final, incluso cuando el servicio de catering se retrasó ligeramente. La votación en directo confirmó lo que ya se percibía en la sala: el formato de panel tuvo una excelente acogida.
Conclusión
Una presentación muestra la dirección que está tomando un tema. Un panel de discusión ofrece una visión general, revelando la situación actual de bancos y fabricantes, más allá de las pruebas de concepto y los proyectos piloto. Ambos formatos se complementan. Esta combinación convierte a Info.Lunch en un punto de encuentro habitual para la comunidad de pruebas en la banca suiza.
¿Cuál de los cuatro temas ocupa actualmente a su equipo? Quizás deseen optimizar su conjunto de pruebas de regresión, crear pruebas de aceptación para software estándar o implementar IA en las pruebas. Contáctenosy analizaremos juntos su situación actual.
Agradecemos a todos los panelistas por el debate abierto, así como a Tricentis y UiPath por su apoyo al evento. Ambos patrocinadores mantuvieron su independencia en cuanto al contenido, tanto en la preparación como durante el debate.
Próxima edición: El próximo Info.Lunch: Banking Automation & Testing Forum se celebrará en marzo de 2027 (fecha exacta por confirmar). Si desea recibir una invitación directa, póngase en contacto con maximilian.matthaeus@infometis.ch. Los participantes de ediciones anteriores recibirán una nueva invitación.
