Marcos de automatización de pruebas en 2026: tipos, ejemplos y cómo elegir

Elegir el marco de automatización de pruebas adecuado puede significar la diferencia entre una suite de pruebas que escala con su producto y una que se desmorona bajo su propio peso. Esta guía desglosa cada patrón principal de marco, compara las herramientas que los impulsan y le brinda un camino práctico para elegir el enfoque correcto para su equipo en 2026.

Qué encontrará

• Un marco de automatización de pruebas es la estructura reutilizable alrededor de herramientas, código y datos de prueba, no solo una herramienta como Selenium o Playwright. Define cómo se organizan, mantienen y ejecutan las pruebas automatizadas.
• La mayoría de los equipos combinan múltiples patrones (automatización lineal, marco basado en datos, marco de pruebas basado en palabras clave y marco de arquitectura de biblioteca) en pruebas web, móviles y de API.
• Los mejores marcos de automatización de pruebas para 2026 son específicos del contexto. Las opciones comunes incluyen Playwright, Cypress, Selenium, Appium, Robot Framework y herramientas BDD como Cucumber.
• En el Informe de Tendencias de QA de 2026, el 74,6% de los equipos de QA informaron usar dos o más marcos de pruebas automatizadas simultáneamente.
• BridgeApp y Magic Coder de BridgeApp pueden automatizar partes de la construcción y el mantenimiento de estos marcos: Magic Coder se ejecuta en un motor de agente que mapea el repositorio como un gráfico de llamadas, por lo que puede rastrear qué cambios de marco se propagan a qué módulos de prueba antes de tocar algo.

¿Qué es un marco de automatización de pruebas (y en qué se diferencia de una herramienta)?

Un marco de automatización de pruebas es un conjunto estructurado de pautas, bibliotecas y patrones que rigen cómo se crean, organizan y ejecutan las pruebas automatizadas. Cubre todo, desde estándares de codificación y convenciones de nomenclatura hasta gestión de datos de prueba, informes e integración CI/CD.

Una herramienta, por el contrario, es un producto o biblioteca que opera dentro de un marco. Selenium WebDriver, Playwright y Cypress son herramientas que impulsan la automatización del navegador. Proporcionan API de bajo nivel para interactuar con elementos web, pero por sí solas, no prescriben cómo estructurar sus scripts de prueba, compartir bibliotecas de prueba o manejar datos de prueba en diferentes entornos.

Aquí hay ejemplos concretos de cómo las herramientas encajan dentro de los marcos:

• Selenium WebDriver + TestNG en un marco de pruebas basado en datos: la lógica de prueba reside en Java, los conjuntos de datos residen en CSV o Excel, y un modelo de objeto de página gestiona los localizadores.
• Cypress con objetos de página y comandos personalizados: la lógica de interacción de la interfaz de usuario se centraliza y reutiliza en múltiples pruebas.
• Robot Framework: un marco de pruebas basado en palabras clave donde los probadores escriben palabras clave de alto nivel en tablas, y las implementaciones subyacentes manejan las pruebas de aplicaciones web, pruebas de API o verificaciones de bases de datos.

Los componentes típicos de cualquier marco de automatización incluyen repositorios de objetos, bibliotecas de ayuda reutilizables, fuentes de datos de prueba, informes y registros, configuración del entorno y ganchos CI/CD. Los marcos de prueba modernos en 2026 rara vez se centran solo en las pruebas de UI: abarcan capas de pruebas web, móviles, API y de integración.

Por qué los equipos necesitan un marco de automatización de pruebas en 2026

Las cadencias de lanzamiento se han acelerado hasta el punto en que muchos equipos implementan semanal o diariamente. Los scripts de prueba ad-hoc no pueden seguir el ritmo. Sin un marco de automatización estructurado, los costos de mantenimiento se disparan: localizadores frágiles, lógica de prueba duplicada, patrones inconsistentes y una retroalimentación de CI dolorosamente lenta.

Un marco bien diseñado aporta beneficios concretos:

• Consistencia en equipos distribuidos, incluso cuando diferentes escuadrones poseen diferentes microservicios
• Incorporación más rápida para nuevos ingenieros de QA y SDET que pueden seguir patrones establecidos
• Menor inestabilidad a través de estrategias de espera estandarizadas, lógica de reintentos y gestión de localizadores
• Mejor trazabilidad desde los casos de prueba hasta los requisitos, reduciendo el error humano en el seguimiento de la cobertura

Considere una organización de QA que apoya tanto a probadores manuales para trabajos exploratorios como a ingenieros de automatización que construyen suites de pruebas de regresión. Un marco con documentación compartida, convenciones de nomenclatura y abstracciones de palabras clave ayuda a los probadores manuales a comprender las pruebas automatizadas, y a veces incluso a contribuir a través de capas impulsadas por palabras clave.

Escalar de docenas a miles de pruebas en navegadores, dispositivos y versiones de API exige patrones sólidos. Sin la ejecución de pruebas en paralelo, la recopilación de artefactos y la detección de pruebas inestables integradas en su canalización de CI, la calidad a gran velocidad es imposible.

BridgeApp ayuda a centralizar estos estándares. Los equipos almacenan pautas de marcos, flujos, especificaciones de datos de prueba y definiciones de entorno en un solo espacio de trabajo. Esta única fuente de verdad evita la divergencia y garantiza que cada colaborador, humano o agente de IA, trabaje con el mismo manual.

Tipos principales de marcos de automatización de pruebas

La mayoría de los proyectos de pruebas del mundo real en 2026 combinan múltiples tipos de marcos para abordar diferentes capas del proceso de pruebas. Un producto enfocado en la web podría usar un marco modular para la interfaz de usuario, un marco basado en datos para la lógica de negocio y un marco enfocado en API para la validación a nivel de servicio.

Los principales patrones, expandidos en las secciones siguientes, son:

1. Marco de automatización lineal (marco de grabar y reproducir)
2. Marco de pruebas modular
3. Marco basado en datos
4. Marco de pruebas basado en palabras clave
5. Marco de automatización de pruebas híbrido
6. Marcos de desarrollo basado en el comportamiento (BDD)
7. Marco de arquitectura de biblioteca

Estos patrones son agnósticos a la tecnología. Puede implementar cualquiera de ellos con Selenium, Playwright, Cypress, Appium, REST-assured, Karate o Robot Framework. La selección de un patrón debe venir antes de elegir una herramienta de automatización de pruebas específica, porque el patrón controla la mantenibilidad y escalabilidad a largo plazo de su suite de pruebas.

Marco de automatización lineal (grabar y reproducir)

Un marco de automatización lineal consta de scripts de prueba simples y paso a paso generados a partir de acciones de usuario grabadas o codificados manualmente sin reutilización modular. Piense en ello como la ruta más rápida de cero a una prueba en ejecución.

Fortalezas:

• Muy rápido de iniciar: se requiere un conocimiento mínimo de programación.
• Útil para pruebas de humo y comprobaciones rápidas de la interfaz de usuario en las pruebas de aplicaciones web.
• Bueno para la automatización de prueba de concepto o flujos heredados estables.

Debilidades:

• Poca reutilización entre escenarios de prueba.
• Frágil cuando los localizadores o los flujos de trabajo cambian.
• Difícil cubrir variaciones de datos o escenarios complejos.
• Alta carga de mantenimiento a medida que crece la suite de pruebas.

Ejemplos concretos incluyen flujos de trabajo básicos de Selenium IDE, grabaciones de TestComplete o flujos simples de Cypress Studio. Un marco de grabar y reproducir funciona bien cuando necesita una retroalimentación rápida sobre una función estable y de bajo riesgo.

En 2026, la automatización lineal se utiliza mejor como punto de partida. Los equipos suelen comenzar aquí, luego refactorizan en un marco modular o híbrido a medida que el número de pruebas automatizadas aumenta y el costo de mantener scripts lineales se vuelve insostenible.

Marcos modulares y de arquitectura de biblioteca

Tanto el marco modular como el marco de arquitectura de biblioteca enfatizan la reutilización y la separación de preocupaciones, pero operan en diferentes niveles de abstracción.

Un marco de pruebas modular agrupa las pruebas en módulos independientes (inicio de sesión, pago, actualización de perfil), cada uno con sus propias funciones reutilizables, datos de prueba y aserciones. Los cambios en un módulo no se propagan a otros, lo que hace que las pruebas de regresión sean más seguras.

Un marco de arquitectura de biblioteca va más allá al extraer funciones comunes en bibliotecas de prueba compartidas utilizadas en toda la suite de pruebas. Estas bibliotecas compartidas suelen incluir:

• Ayudas de interacción de UI (clic, espera, navegación)
• Envoltorios de cliente API
• Utilidades de bases de datos
• Comparadores personalizados y ayudas de aserción
• Constructores de datos de prueba

Ejemplos prácticos incluyen el modelo de objeto de página en Selenium o Playwright, clientes API compartidos en REST-assured o Karate, y bibliotecas de ayuda expuestas a través de comandos personalizados de Cypress.

Elija este patrón cuando esté probando aplicaciones web modernas o productos SaaS B2B con largas expectativas de ciclo de vida de desarrollo. Si su equipo incluye desarrolladores o SDET cómodos con código personalizado y diseño de pruebas basado en código, un marco de arquitectura de biblioteca proporciona la base más sólida para escalar.

Marcos basados en datos

Un marco basado en datos separa la lógica de prueba de los datos de entrada, lo que permite que el mismo script ejecute pruebas con múltiples conjuntos de datos. En lugar de duplicar los scripts de prueba para cada permutación, escribe un script y le alimenta diferentes datos.

Las fuentes de datos comunes incluyen CSV, Excel, JSON, tablas de bases de datos o servicios externos de datos de prueba. Este patrón es especialmente valioso en sistemas financieros, de facturación, CRM y ERP, donde necesita validar muchas combinaciones de entrada: monedas, configuraciones regionales, ciclos de facturación, casos extremos.

Ejemplos de herramientas:

Un marco de pruebas basado en datos ofrece una amplia cobertura con menos scripts, pruebas negativas más sencillas y una asignación más clara entre requisitos y casos de prueba.

Los desafíos incluyen mantener los datos de prueba actualizados (el deterioro de los datos es real), evitar dependencias frágiles en conjuntos de datos similares a la producción y proteger los datos confidenciales (tokens, PII, credenciales), especialmente bajo el cumplimiento de GDPR, CCPA o HIPAA. Una gestión cuidadosa de los datos de prueba es esencial para que este patrón funcione a escala.

Marcos de pruebas basados en palabras clave

Un marco de pruebas basado en palabras clave mapea palabras clave de alto nivel (LOGIN, ADD_TO_CART, VERIFY_EMAIL) a acciones de automatización subyacentes. Los probadores escriben secuencias de palabras clave en tablas u hojas de cálculo, y las implementaciones subyacentes ejecutan esas acciones contra la aplicación.

Este patrón es popular cuando los probadores manuales, los analistas de negocios o las partes interesadas no técnicas contribuyen al proceso de prueba. Pueden escribir casos de prueba sin necesidad de comprender los lenguajes de programación que impulsan el marco.

El ejemplo más destacado es Robot Framework, que admite de forma nativa el diseño de pruebas de estilo de palabras clave para pruebas web, API y de bases de datos. Los equipos también construyen capas de palabras clave personalizadas sobre Selenium o Appium para exponer acciones de alto nivel a miembros del equipo menos técnicos.

Beneficios:

• Mejor colaboración entre miembros del equipo técnicos y no técnicos.
• Casos de prueba legibles que sirven como documentación viva.
• Capacidad de cambiar la implementación subyacente sin reescribir escenarios de prueba de alto nivel.

Compromisos:

• Las bibliotecas de palabras clave pueden volverse voluminosas con el tiempo.
• La depuración requiere mapear de palabras clave a código.
• Se necesita gobernanza para evitar la duplicación y la nomenclatura inconsistente en grandes conjuntos de palabras clave.

Marcos híbridos, BDD y enfocados en API

Un marco de pruebas híbrido combina patrones para satisfacer necesidades complejas. Por ejemplo, una suite podría usar pruebas impulsadas por datos para la verificación de cálculos, flujos impulsados por palabras clave para pasos de UI y bibliotecas compartidas para llamadas a API y verificaciones de bases de datos. En la práctica, la mayoría de los marcos de producción en 2026 son híbridos.

Los marcos de desarrollo basado en el comportamiento (BDD) escriben escenarios de prueba en lenguaje natural, típicamente sintaxis Gherkin (Dado-Cuando-Entonces), utilizando herramientas como Cucumber (Java, JS), SpecFlow (.NET), Behave (Python) o Gauge. BDD tiene como objetivo hacer que las pruebas de aceptación sean legibles por las partes interesadas del negocio. La desventaja es el sobrecarga: mantener archivos de características y código de pegamento puede volverse costoso si se usa en exceso.

Los marcos enfocados en API forman la columna vertebral de la automatización a nivel de servicio en arquitecturas de microservicios. Herramientas como REST-assured, Karate, Postman/Newman y pytest con HTTPX manejan pruebas de contrato, pruebas de integración y validación de back-end. Las pruebas de API se ejecutan más rápido y son más estables que las pruebas de UI, por lo que la pirámide de pruebas recomendada en 2026 apunta aproximadamente al 70% de pruebas unitarias, 20% de integración y 10% de E2E.

Las empresas adoptan marcos híbridos cuando los sistemas a gran escala —comercio electrónico, banca, logística, incluso dispositivos médicos— se lanzan varias veces por semana y necesitan pruebas de interfaz de usuario, móviles y API alineadas bajo un único proyecto de pruebas con estándares consistentes.

Cómo elegir el mejor marco de automatización de pruebas para su equipo

No existe un único “mejor marco de automatización de pruebas”. El patrón correcto depende de su producto, stack, habilidades del equipo y cadencia de lanzamiento. Estos son los factores clave de decisión:

• Qué está probando: ¿aplicaciones web, aplicaciones móviles, API, escritorio o una mezcla? Las diferentes capas necesitan diferentes herramientas.
• Habilidades del equipo: los desarrolladores y SDET pueden manejar marcos de arquitectura de biblioteca con mucho código; los equipos con probadores manuales pueden beneficiarse de enfoques basados en palabras clave o de Robot Framework.
• Herramientas existentes: las grandes inversiones en Selenium no deben abandonarse de la noche a la mañana. Considere la migración incremental.
• Cadencia de lanzamiento: los ciclos rápidos necesitan baja inestabilidad y alta paralelización; los puntos de referencia independientes de marzo de 2026 muestran que Playwright completa suites en 3m20s frente a los 8m45s de Selenium, con una estabilidad de alrededor del 92% frente a aproximadamente el 72% de Selenium.
• Cumplimiento y gobernanza: las industrias reguladas necesitan registros de auditoría, gestión segura de datos de prueba y entornos controlados de ejecución de pruebas.

Guía para casos típicos:

Comience con un marco modular o híbrido para la mayoría de los proyectos nuevos, incorporando elementos basados en datos y palabras clave a medida que crece la suite. Pilote el patrón elegido en una característica real (un proceso de pago o un endpoint de API clave) durante unas pocas sprints antes de comprometerse con toda la organización. Esto mantiene la inversión reversible.

Integración de marcos de automatización de pruebas con CI/CD y colaboración

En 2026, los marcos de automatización que no se integran con CI/CD son marcos que no se distribuyen. Su suite de pruebas debe ejecutarse en cada solicitud de extracción, con pruebas unitarias y de API rápidas que se completen en minutos y pruebas de UI controladas en ramas de características o compilaciones de sombra.

Las prácticas clave de integración CI/CD incluyen:

• Ejecución de pruebas en paralelo en navegadores y dispositivos para mantener ciclos de retroalimentación cortos.
• Recopilación de artefactos: capturas de pantalla, registros de seguimiento, instantáneas DOM en caso de fallo.
• Detección de pruebas inestables con paneles históricos de aprobado/fallido.
• Notificaciones automatizadas en chats de equipo cuando los fallos superan los umbrales.
• Restricción de lanzamientos basada en los resultados de las pruebas: sin pipeline verde, sin despliegue.

Los informes de pruebas van más allá de los recuentos de aprobados/fallidos. Los equipos necesitan visibilidad de las tendencias históricas, los tiempos de ejecución de las pruebas y las brechas de cobertura. Según el Informe de Tendencias de QA de 2026, aproximadamente el 50,6% de los equipos ahora usan IA para la creación de datos de prueba y el 46% para la formulación de casos de prueba, integrando la inteligencia directamente en los flujos de trabajo de prueba.

BridgeApp ayuda aquí almacenando los estándares de automatización como documentos, rastreando tareas y errores relacionados con el marco como elementos de trabajo, y permitiendo que agentes de IA personalizados resuman los fallos de prueba dentro de los chats del equipo. Para organizaciones reguladas o sensibles a la seguridad, la implementación local o en la nube privada de BridgeApp mantiene los artefactos del marco, los datos de prueba y los registros de ejecución bajo un estricto control organizacional.

Cómo BridgeApp y Magic Coder aceleran el desarrollo de marcos

Un marco rara vez falla porque un equipo eligió el patrón incorrecto. Falla como describen las secciones anteriores: la nomenclatura diverge entre escuadrones, una biblioteca de palabras clave crece más allá de lo que cualquiera recuerda su origen, un conjunto de reglas basadas en datos se copia en lugar de reutilizarse, porque el estándar vive en un documento que nadie tiene abierto mientras escribe o revisa una prueba. BridgeApp es un espacio de trabajo unificado nativo de IA construido para cerrar precisamente esa brecha: chat de equipo, tareas, documentos, bases de datos y un constructor de agentes de IA sin código que mantiene el estándar real del marco junto al código y la revisión, no archivado lejos de ambos.

Los equipos usan los documentos de BridgeApp para definir las pautas del marco —estándares de codificación, convenciones de nomenclatura, reglas basadas en datos, plantillas de planes de prueba— y marcarlos como Conocimiento para los agentes de IA personalizados. Esos agentes pueden luego referenciar sus estándares al responder preguntas, revisar decisiones de diseño de pruebas o generar documentación.

Las bases de datos de BridgeApp modelan entidades como casos de prueba, entornos, puntos finales de API y registros de datos de prueba. Con acceso a la API de la cuenta de servicio, estas bases de datos se integran con los ejecutores de pruebas y los pipelines de CI, lo que le permite gestionar los datos de prueba, realizar un seguimiento de los escenarios de prueba y vincular los resultados de las pruebas a los elementos de trabajo, todo en un solo lugar.

Magic Coder de BridgeApp es un agente de codificación de IA basado en terminal que puede generar código de marco, refactorizar pruebas frágiles, generar objetos de página y actualizar clientes de API en todos los repositorios. Dado que Magic Coder se conecta al contexto del espacio de trabajo de BridgeApp (tareas, documentos, reglas de equipo), garantiza que el código generado siga sus estándares establecidos.

Bajo el capó, Magic Coder se ejecuta en el propio motor de agentes de BridgeApp, lo que hace que la refactorización de pruebas a gran escala sea manejable en lugar de arriesgada. El motor construye un gráfico de llamadas del repositorio, rastreando qué llama a qué y cómo se conectan los servicios, por lo que cuando Magic Coder migra pruebas Selenium heredadas o actualiza un cliente compartido, los cambios aterrizan en los archivos que realmente los necesitan en lugar de producir una diferencia de aspecto plausible en el lugar equivocado. Múltiples subagentes pueden trabajar en paralelo en diferentes módulos de la suite, cada uno con su propio contexto delimitado, mientras que la ejecución del código ocurre en micro-VM aisladas con acceso al repositorio de corta duración y alcance de tarea, por lo que un trabajo de refactorización nunca se ejecuta con más acceso del que requiere la tarea.

Casos de uso concretos:

• Migrar pruebas Selenium heredadas a un marco modular basado en datos: Magic Coder extrae la lógica de localizadores dispersa, genera objetos de página y reestructura los scripts de prueba.
• Agregar pruebas de API a un marco solo de UI: Magic Coder genera bibliotecas cliente REST-assured o HTTPX y suites de pruebas iniciales bajo la misma arquitectura.
• Generar bibliotecas reutilizables para pruebas de varios navegadores o soporte multiplataforma: ayudas compartidas, configuraciones de entorno y definiciones de pipeline de CI creadas en minutos en lugar de días.

Estas capacidades aceleran el desarrollo de pruebas y reducen la sobrecarga de refactorización manual, pero el mayor efecto es que los estándares dejan de divergir de la suite, porque ya no hay un lugar separado para que diverjan.

Preguntas frecuentes

¿Con qué tipo de marco de automatización de pruebas debo empezar si estoy pasando de las pruebas manuales?

Comience con un marco híbrido modular. Use la automatización lineal simple para algunas pruebas de humo para generar confianza, luego agregue gradualmente módulos reutilizables y patrones basados en datos a medida que crecen los conocimientos de programación de su equipo. Herramientas como Robot Framework o una capa basada en palabras clave sobre Playwright son accesibles para los equipos que hacen la transición de las pruebas manuales porque le permiten escribir casos de prueba en un lenguaje casi natural. BridgeApp puede almacenar sus casos de prueba manuales paso a paso existentes como documentos y ayudar a convertirlos en escenarios automatizados con el tiempo utilizando agentes de IA personalizados.

¿Puedo usar un solo marco para pruebas de UI web, móvil y API juntas?

La mayoría de los equipos en 2026 combinan múltiples herramientas bajo un único patrón de marco en lugar de depender de un solo producto para todo. Por ejemplo, podría usar Playwright o Cypress para probar aplicaciones web, Appium o Espresso para pruebas móviles, y Karate o REST-assured para pruebas de API, todo administrado bajo estándares de codificación, bibliotecas de pruebas e informes compartidos. El elemento unificador es el diseño del marco (basado en datos, basado en palabras clave o arquitectura de biblioteca), no una sola herramienta. El uso de múltiples marcos bajo un mismo patrón arquitectónico le permite ejecutar pruebas de manera consistente en todas las plataformas, administrar datos de prueba de forma centralizada y mantener el soporte multiplataforma sin sacrificar las capacidades de pruebas de rendimiento o pruebas visuales.

¿Cómo cambian la IA y los agentes autónomos los marcos de automatización de pruebas en 2026?

La IA ahora ayuda con la generación de pruebas, el mantenimiento de localizadores, el análisis de inestabilidad y la detección de brechas de cobertura. En una encuesta a los asistentes a RoboCon 2026, una instantánea de 65 profesionales de pruebas, no un estudio formal de la industria, el 78,5% señaló la automatización de pruebas impulsada por IA como la principal tendencia para el año. Las herramientas con capacidades de auto-curación pueden adaptarse a los cambios de la interfaz de usuario utilizando heurísticas del árbol de accesibilidad en lugar de costosas llamadas a LLM por ejecución. Magic Coder de BridgeApp actúa como un agente de codificación autónomo que actualiza el código del marco, refactoriza las pruebas y alinea los repositorios con los estándares compartidos almacenados en BridgeApp. Dicho esto, la IA aumenta en lugar de reemplazar a los ingenieros. El juicio humano sigue siendo esencial para la evaluación de riesgos, las decisiones de arquitectura del marco y la decisión de qué escenarios de prueba son más importantes en el proceso de desarrollo de software.

¿Con qué frecuencia debemos revisar el diseño de nuestro marco de automatización?

Revise el diseño de su marco al menos anualmente, o cada vez que ocurran cambios importantes: una nueva pila de front-end, un cambio a microservicios, un cambio de implementación local a la nube, o la adopción de nuevos lenguajes de programación. Rastree los puntos débiles del marco como tareas e hilos de discusión en BridgeApp para que su equipo pueda detectar patrones: inestabilidad recurrente, compilaciones lentas, tiempos de ejecución de pruebas altos o dificultad para incorporar nuevos miembros. Favorezca las mejoras incrementales (agregar una capa basada en datos, refactorizar a un marco de arquitectura de biblioteca, introducir pruebas de rendimiento o soporte de pruebas de aceptación) sobre las reescrituras completas disruptivas. Las pequeñas y continuas inversiones en su marco durante cada fase del ciclo de vida del desarrollo lo mantienen saludable sin detener el trabajo de características.

¿Es un marco de automatización lineal alguna vez una buena opción a largo plazo?

Un marco lineal o un marco de grabar y reproducir por sí solo rara vez es suficiente para la automatización a gran escala a largo plazo en 2026. La carga de mantenimiento crece rápidamente y se pierde la capacidad de escribir casos de prueba que manejen escenarios complejos, múltiples conjuntos de datos o pruebas entre navegadores de manera efectiva. Sin embargo, la automatización lineal conserva su valor para flujos estables y de bajo riesgo, exploraciones rápidas o para que las partes interesadas no técnicas redacten escenarios de prueba que los ingenieros refactorizarán más tarde en marcos modulares o híbridos. Planifique desde el principio cómo evolucionar los scripts lineales hacia tipos más robustos de patrones de automatización de pruebas antes de que su suite de pruebas crezca demasiado para administrarla.