logo HASTQB

Archivos

QA Team

Email: info@qateamperu.com Web: https://qateamperu.com/ Tel: +51 992 062 484 Niveles: Certified Tester Foundation Level (CTFL)

Getronics

logo getronics

www.getronics.com Email: dlclcontacto@getronics.com Partnership level: Platinum País: Chile

Performance: cuando el sistema pierde su capacidad de operación Por: Kelly Tapia

Performance: cuando el sistema pierde su capacidad de operación 3ra. entrega 2026 Newsletter Radar Testing Latam Desde HASTQB impulsamos esta newsletter conun propósito claro: compartir experiencias, ideas, buenas prácticas yaprendizajes reales sobre el apasionante mundo del aseguramiento y control decalidad de software. By Kelly Tapia ¿Quién es Kelly Tapia? Es una destacada Lead Quality Engineer y especialista en Ingeniería de Calidad de Software (QA). Cuenta con una sólida experiencia liderando equipos de calidad en aplicaciones core dentro del sector de banca y finanzas, combinando su rol corporativo con la formación de talento como Quality Engineer Trainer y el fomento de la comunidad tecnológica como speaker internacional. Su trabajo se centra en diseñar estrategias integrales de pruebas manuales, automatizadas, de performance y de seguridad, especializándose en soluciones para plataformas Mainframe y Distribuidas para garantizar la confiabilidad del software. Performance: cuando el sistema pierde su capacidad de operación​ En los sistemas modernos, fallar no siempre significa detenerse. Un sistema puede mantenerse activo y, aun así, haber perdido su capacidad de respuesta. Este tipo de degradación es crítica porque no se percibe como una caída inmediata, sino como una pérdida progresiva de rendimiento. El caso: Amazon Web Services Fuente: https://aws.amazon.com/es/message/101925/ En 2025, AWS experimentó un incidente en su región us-east-1 originado por una condición de carrera en el sistema de gestión DNS de DynamoDB. Aunque el origen fue estructural, el impacto se reflejó principalmente en el performance del sistema. Cómo se manifestó El sistema comenzó a degradarse progresivamente, evidenciando: •      Incremento en los tiempos de respuesta. •      Aumento de errores. •      Dificultades para completar operaciones. Impacto   Aunque en ciertos momentos los servicios respondían, su capacidad de procesamiento estaba comprometida y se generaron retrasos acumulativos en procesos internos, prolongando el impacto incluso después de aplicar correcciones. Desde la perspectiva del usuario, esto se tradujo en una pérdida efectiva de rendimiento, donde las aplicaciones no podían operar de forma consistente, afectando directamente la experiencia y la continuidad del negocio. En este contexto, el problema no fue la ausencia de respuesta, sino la incapacidad del sistema para responder con el nivel de performance esperado.  Qué significa para la calidad Este caso muestra que el performance es un indicador de la capacidad real de operación del sistema. Para los equipos de calidad, esto implica validar no solo tiempos de respuesta bajo carga, sino también cómo se comporta el sistema cuando existen fallos internos, dependencias degradadas o retrasos acumulativos. En la práctica, calidad puede contemplar escenarios como degradación de servicios dependientes, fallas intermitentes de comunicación, aumento progresivo de latencia, errores en APIs críticas, acumulación de colas, lentitud en procesos de recuperación y pérdida parcial de observabilidad. Estos escenarios permiten evaluar si el sistema mantiene su operación, se degrada de forma controlada o amplifica el problema. Pruebas como performance testing, resiliencia, failover, recuperación, pruebas de estrés, pruebas de degradación controlada y validación de monitoreo permiten anticipar estos riesgos. El incidente de Amazon Web Services demuestra que un sistema no necesita caerse para dejar de ser útil. El performance refleja si realmente puede seguir operando cuando las condiciones dejan de ser ideales.  Valorado con 5 de 5 Facebook-f Instagram Linkedin-in

QA en la Banca: ¿Freno de mano o acelerador del “business case”? Por: Ruben Aguirre Paredes

QA en la Banca: ¿Freno de mano o acelerador del “business case”? 2da. entrega 2026 Newsletter Radar Testing Latam Desde HASTQB impulsamos esta newsletter conun propósito claro: compartir experiencias, ideas, buenas prácticas yaprendizajes reales sobre el apasionante mundo del aseguramiento y control decalidad de software. By Rubén Aguirre Paredes ¿Quién es Rubén Aguirre Paredes? Es un destacado especialista boliviano en Aseguramiento de la Calidad de Software (QA). Cuenta con más de 10 años de experiencia combinando su rol corporativo en el sector financiero con la enseñanza académica y el fomento de la comunidad tecnológica. Su trabajo se centra en alinear la gobernanza y automatización del QA con los objetivos de seguridad y negocio, además de promover prácticas como CI/CD, DevOps y métricas escalables dentro de la industria bancaria.  QA en la Banca: ¿Freno de mano o acelerador del “business case”? Bienvenidos esta edición de QA & Banking Tech, un espacio dedicado a explorar la intersección entre la rigurosidad del software testing, la velocidad de la banca moderna y la formación del talento del mañana. Desde mi experiencia en Bancosol y la Universidad Católica Boliviana (UCB), compartiré regularmente  perspectivas estratégicas para elevar la calidad en el sector financiero regional.   1. EL LÍDER: ¿POR QUÉ LA BANCA NO PUEDE PERMITIRSE UN QA «AL FINAL»? En la banca moderna, el negocio tiene hambre de salir «ayer». La presión por lanzar un MVP (Producto Mínimo Viable) a menudo empuja al QA al final de la cola, viéndolo como un «peaje» y no como un acelerador. Sin embargo, en un entorno regulado, un MVP con fallos no es «mínimo», es un riesgo reputacional y operativo. La clave no es frenar el negocio, sino integrar una planificación de capacidad (Capacity Planning) real desde el día cero. Un error común es definir el alcance del desarrollo sin calcular el esfuerzo de testing necesario para cubrirlo. Si la planificación no contempla la capacidad del equipo de QA para ejecutar ciclos de regresión y pruebas de seguridad, el proyecto está destinado al retraso o al fracaso en producción. El QA debe ser el aliado estratégico que asegura que el MVP sea verdaderamente viable, garantizando que los tiempos de entrega estén respaldados por una capacidad operativa real y no por estimaciones optimistas.   2. THE BANKING BUG: GESTIÓN DE DEFECTOS EN EL ECOSISTEMA MÓVIL La banca móvil introduce una complejidad única: la fragmentación de dispositivos, biometría y latencia de red. Probar en este ecosistema exige una estrategia que no detenga el flujo de entrega, pero que proteja la integridad de nuestros indicadores de calidad. Una técnica que implementamos con éxito es el uso de Ambientes Controlados con Umbrales de Etiquetado. Durante las fases Beta o de » Friends & Family», es vital permitir que el equipo de QA sea agresivo en la detección de fallos sin que esto alarme innecesariamente a la alta gerencia mediante el Cuadro de Mando Integral (CMI). Para lograrlo, categorizamos estos hallazgos con etiquetas como InternalDefect o EarlyDetection_Mobile. Esto nos permite mantener indicadores de producción limpios mientras corregimos fallas críticas en dispositivos reales antes del despliegue masivo.   3. ISTQB CORNER: PIPELINES, APROBADORES Y AUDITORÍA Siguiendo los estándares internacionales de ISTQB, la calidad no termina en el código, se extiende al proceso de despliegue. Para la banca, es vital implementar un control rígido de aprobadores en nuestras pipelines de CI/CD. No es solo burocracia; es trazabilidad de auditoría. Cada paso a producción debe tener una firma digital que valide que los criterios de aceptación fueron cumplidos. En una auditoría externa, poder demostrar que ninguna línea de código llegó a producción sin pasar por los filtros y aprobaciones correspondientes es lo que diferencia a una entidad sólida de una vulnerable.   4. EL BIT ACADÉMICO: LA UCB COMO SEMILLERO DE TALENTO BANCARIO Mi rol en la Universidad Católica Boliviana (UCB) me permite ver de cerca el potencial de las nuevas generaciones. La academia no solo es un espacio de teoría, es el nicho perfecto para identificar talentos que entienden la tecnología pero que también están siendo formados bajo una ética de ingeniería rigurosa. Integrar a estos jóvenes talentos en las células de QA bancario permite inyectar frescura técnica y, al mismo tiempo, asegurar que el «ADN bancario» (seguridad, orden y procesos) se transmita desde temprano. La UCB es, hoy por hoy, nuestro mejor aliado para fortalecer el músculo técnico de la banca en Bolivia. ¿Qué opinas sobre el equilibrio entre la velocidad del y la rigurosidad del QA? Te leo en los comentarios. Próximos Eventos: Nos vemos pronto en el Testing Day Bolivia para seguir profundizando en estos temas.  Valorado con 5 de 5 Facebook-f Instagram Linkedin-in

Líderes que nacen digitales. Gen Z. Por: Alfonsina Morgavi

Banner slide

1ra. entrega 2026 Newsletter Radar Testing Latam Liderazgo en clave Z… Qué cambia cuando los nuevos líderes nacen digitales Desde HASTQB impulsamos esta newsletter conun propósito claro: compartir experiencias, ideas, buenas prácticas yaprendizajes reales sobre el apasionante mundo del aseguramiento y control decalidad de software. By Alfonsina Morgavi ¿Quién es Alfonsina Morgavi? Con más de 30 años de trayectoria, Alfonsina es ingeniera en calidad de software, cofundadora de la empresa QActions y actual Directora de su Unidad de Negocio de Calidad. Sin embargo, su impacto trasciende su propia empresa: es la representante de Argentina y Paraguay ante el HASTQB (Hispanic America Software Testing Qualifications Board). A través de su liderazgo, Alfonsina dedica su carrera a transformar el mundo del QA (Quality Assurance), promoviendo el talento, las mejores prácticas y las certificaciones internacionales ISTQB en toda la región. Más que procesos técnicos, ella nos demuestra que la verdadera calidad siempre depende del factor humano. Liderazgo en clave Z… Qué cambia cuando los nuevos líderes nacen digitales Hablar de generaciones en IT siempre implica una advertencia: sirven como mapa, no como sentencia. No todas las personas de una misma edad trabajan igual, pero sí es cierto que cada cohorte fue moldeada por tecnologías, ritmos y crisis distintas. Tomando rangos aproximados, Baby Boomers suele ubicarse entre 1946 y 1964; Gen X entre 1965 y 1980; Millennials entre 1981 y 1996; Gen Z desde 1997 en adelante según Pew; y Generación Alfa suele definirse, en otro marco muy difundido, como quienes nacieron entre 2010 y 2024. Es decir: las etiquetas ayudan a pensar, pero no reemplazan a las personas. En tecnología, ninguna generación empezó de cero. Cada una heredó un terreno imperfecto, peleó sus propias batallas y dejó algo que la siguiente pudo aprovechar. Por eso, más que discutir quién trabaja “mejor”, conviene preguntarse qué construyó cada una y qué responsabilidad tiene la generación actual frente a las generaciones que vienen. Este artículo va exactamente en esa dirección: no caricaturiza a las generaciones, sino que las muestra como una cadena de relevos donde la mezcla entre experiencia, criterio, velocidad y adaptación es la verdadera ventaja competitiva. Los Baby Boomers le dejaron a IT algo que hoy seguimos subestimando: la idea de que la tecnología no puede depender solo “del brillo”, sino también de la confiabilidad. Fue la generación que convivió con mainframes, transición a la PC, estandarización del software y apertura de la web. Pero, además, en la cultura de trabajo dejaron disciplina, trazabilidad, sentido de responsabilidad y una relación casi moral con la calidad: si algo sale con mi nombre, debe salir bien. En tiempos donde todo parece provisional, ese legado sigue siendo enorme. Gracias a ellos, las nuevas generaciones no solo heredaron sistemas; heredaron también la noción de estabilidad, documentación y gestión del riesgo. La Generación X tomó ese piso de robustez y lo volvió pragmático. Si los Boomers ayudaron a ordenar el mundo digital, la Gen X lo hizo funcionar en condiciones reales: menos discurso, más resolución. Fue puente entre el legado y la escala; entre la formalidad corporativa y la cultura del script salvador; entre la operación y la innovación útil. También aportó algo decisivo: una alergia saludable a la burocracia vacía. En IT, la Gen X enseñó que los procesos deben servir al delivery y no al revés. En otras palabras, dejó a los Millennials y la Gen Z una lección muy valiosa: no todo lo nuevo vale, pero tampoco todo lo viejo debe quedarse. Los Millennials cambiaron el eje. Si antes la conversación giraba en torno a sistemas y eficiencia, con ellos entró con fuerza el lenguaje de producto, experiencia de usuario, colaboración transversal, métricas y propósito. Trajeron la lógica de “¿qué problema del usuario resolvemos?”, la cultura del feedback frecuente, el discovery, los dashboards y la articulación natural entre negocio, UX, QA y desarrollo. Su gran herencia para la Gen Z no fue solo tecnológica; fue también cultural: instalaron la idea de que construir software ya no es únicamente entregar funcionalidades, sino aprender rápido, medir impacto y mejorar continuamente. Y entonces aparece la Generación Z, quizá la primera que no “entró” al mundo digital, sino que nació dentro de él. Ese matiz cambia todo. Para Gen Z, lo digital no es una herramienta: es el idioma nativo. Por eso prototipa rápido, automatiza por reflejo, se mueve con naturalidad entre nube, APIs, diseño, documentación viva, low-code, IA y colaboración distribuida. Lo que en otras generaciones era especialización secuencial, en la Gen Z aparece como fluidez simultánea. No les asusta probar; les aburre esperar demasiado para validar. No piden permiso para aprender; abren un tutorial, una comunidad, un prompt y arrancan. Ahí está su primera gran fortaleza: la velocidad para convertir ideas en algo tangible. La Gen Z puede llevar una intuición a un MVP” están más cerca de “hacer algo pequeño pero útil, rápido y medible” y en tiempo récord. La segunda es su sesgo natural a la automatización: si una tarea se repite, la pregunta no es si conviene automatizarla, sino por qué todavía no se automatizó. La tercera es su mirada de experiencia: piensa en onboarding, accesibilidad, UX y developer experience casi desde el inicio. La cuarta es su relación desprejuiciada con el aprendizaje: tutoriales, pares, comunidades, video, prompts, repositorios, todo sirve si acelera comprensión. Y la quinta, muy relevante, es su expectativa de propósito: no quiere solo participar; quiere entender para qué importa lo que hace. Pero sería un error tener de esto una visión romántica. La principal debilidad de Gen Z no es la falta de talento, sino el riesgo de que su velocidad no siempre venga acompañada de profundidad. Tu material lo señala muy bien: puede haber foco fragmentado, baja tolerancia a la ambigüedad sostenida, brechas en fundamentos profundos —arquitectura, costos, seguridad, protocolos— y una peligrosa tendencia al “prototype forever”, donde se crea mucho, pero se industrializa poco. También aparece cierta dependencia de plataformas cerradas, necesidad de feedback constante y dificultad para sostener trabajo profundo cuando el entorno ofrece estímulos infinitos. Dicho

AppWhere, S.A. DE C.V.

LOGO APPWHERE PARTNER ISTQB HASTQB

https://www.appwhere.mx/ Correo: ihernandez@appwhere.mx Puntos: 5 Partnership level: Silver País: México

Crux Consultores S.A.

LOGO CRUZ PARNET PLATINUM ISTQB HASTQB COSTA RICA

www.cruxconsultores.com  Correo: info@cruxconsultores.com  Puntos: 47 Partnership level: Platinum País: Costa Rica

Smart Testing S.R.L.

logo smart testing

www.smarttestinggrd.com Correo: ejguerrero@smarttestingrd.com Puntos: 35 Partnership level: Platinum País: República Dominicana