Pruebas de regresión en desarrollo móvil — qué son, tipos y cómo se realizan

¿Qué son las pruebas de regresión?

Las pruebas de regresión son un tipo de prueba destinado a confirmar que los cambios en el código no han roto la funcionalidad existente. El término “regresión” significa un retorno a un estado peor — cuando una función que funcionaba en la versión anterior deja de funcionar en la nueva. Las pruebas de regresión se ejecutan repetidamente en cada ciclo de desarrollo, lo que las diferencia de las pruebas de nuevas funcionalidades que se escriben una sola vez.

La necesidad de las pruebas de regresión surge del efecto de cambios en cascada: corregir un error en un módulo puede resolver el problema pero romper la funcionalidad adyacente que dependía de él. Por ejemplo, cambiar una consulta SQL en el repositorio de usuarios puede acelerar la autenticación pero romper la exportación de datos que usaba la misma consulta. Una prueba de regresión en la exportación de datos detectará esta violación antes del lanzamiento.

Según el informe CISQ 2023, el costo de corregir un defecto de regresión encontrado en producción es 15 veces mayor que en la etapa de ejecución automatizada de regresión. Las empresas que invierten en pruebas de regresión automatizadas reducen la proporción de defectos de regresión en los lanzamientos del 25% al 5% en el plazo de un año después de la implementación, según el Capgemini World Quality Report.

Tipos de pruebas de regresión

Existen varios enfoques para las pruebas de regresión que difieren en alcance y criterios de selección de pruebas. La elección del enfoque depende del tamaño del proyecto, la frecuencia de los cambios y el tiempo disponible en el pipeline de CI. A continuación se presentan los principales tipos de pruebas de regresión con sus características.

Pruebas de regresión completas

La ejecución de regresión completa ejecuta todas las pruebas automatizadas del proyecto sin excepción. Este enfoque proporciona la máxima confianza pero requiere importantes recursos informáticos y tiempo. Una ejecución completa se realiza antes de los lanzamientos importantes, cada 2–4 semanas. Para una aplicación con 5000 pruebas, una ejecución completa toma de 2 a 6 horas según la infraestructura.

Pruebas de regresión selectivas

El enfoque selectivo ejecuta solo las pruebas relacionadas con los módulos modificados. Para determinar la relación, se utiliza un análisis de dependencias a nivel de código: si se cambia la clase UserRepository, se ejecutan las pruebas que dependen de UserRepository directa o transitivamente. Herramientas como Jacoco, Android Test Coverage y Xcode Code Coverage proporcionan mapas de cobertura para una selección precisa. Una ejecución selectiva se realiza en cada pull request y toma de 5 a 15 minutos.

Regresión basada en riesgos

La regresión basada en riesgos clasifica las pruebas según la criticidad de la funcionalidad y la probabilidad de fallo. Las funciones críticas — pagos, autenticación, sincronización — se prueban en cada cambio de código. Las funciones auxiliares — pantalla Acerca de, animaciones — se prueban solo antes del lanzamiento. La clasificación se revisa trimestralmente según los datos de incidentes de producción.

Diferencia entre pruebas de regresión y reprueba

A menudo se confunden los conceptos de pruebas de regresión y reprueba, aunque son procesos diferentes. La reprueba es una re-ejecución de una prueba específica que falló anteriormente, después de corregir el defecto. El propósito de la reprueba es confirmar que la corrección funciona: el error ya no se reproduce. La reprueba se realiza una vez, inmediatamente después de la corrección y la confirmación del desarrollador.

Las pruebas de regresión son la ejecución de pruebas sobre funcionalidad existente que NO ha sido modificada. El objetivo es asegurar que la corrección de un defecto no ha creado un nuevo defecto en otro lugar. Las pruebas de regresión se ejecutan repetidamente en cada ciclo de desarrollo, independientemente de qué errores específicos se corrigieron. La principal diferencia: la reprueba verifica la corrección en sí, la regresión verifica las consecuencias de la corrección.

En un pipeline de CI/CD, ambos procesos se ejecutan secuencialmente. Después de fusionar un pull request, se ejecuta una reprueba del error específico, seguida de una ejecución de regresión completa o selectiva. Según SmartBear (2022), separar estos procesos reduce el tiempo de diagnóstico de ejecuciones de CI fallidas en un 30%, ya que el equipo ve inmediatamente qué defectos están relacionados con la regresión y cuáles con correcciones que no funcionan.

Automatización de pruebas de regresión

La automatización de las pruebas de regresión es un factor crítico de éxito para los proyectos móviles modernos. Las pruebas de regresión manuales no escalan: con un conjunto de 200 pruebas, una ejecución requiere de 2 a 3 días hábiles de un ingeniero de QA, lo que hace imposibles las ejecuciones diarias. Las pruebas de regresión automatizadas se ejecutan en 10–60 minutos sin intervención humana, lo que permite ejecutarlas en cada commit o pull request.

• Pruebas unitarias — la base del conjunto de regresión (70%). Se ejecutan en segundos, no requieren emulador y proporcionan una identificación precisa de la clase rota.
• Pruebas de integración — el segundo nivel (20%). Verifican la capa de red, la base de datos y los servicios del sistema con dependencias controladas.
• Pruebas de UI y E2E — la cima de la pirámide (10%). Cubren escenarios críticos de usuario: registro, pago, sincronización.

Para mantener actualizado el conjunto de regresión se utiliza analítica de pruebas: herramientas como Allure, ReportPortal y Xray rastrean las tasas de aprobación, duración y estabilidad de cada prueba. Las pruebas cuya estabilidad cae por debajo del 90% (que a menudo se rompen debido a cambios en los requisitos) se marcan como heredadas y se asignan al propietario para su revisión.

Ejemplo de configuración de una prueba de regresión

Veamos la configuración de una prueba de regresión automatizada en Android utilizando la biblioteca JUnit 5 y Espresso. El ejemplo demuestra la regresión selectiva: la prueba verifica que después de refactorizar el repositorio de usuarios, la pantalla de perfil no se rompa. Para iOS se utiliza XCTest con lógica similar: una prueba repetida en un escenario clave.

Android: prueba de regresión de perfil

La prueba utiliza MockWebServer para emular el servidor y verifica la ruta completa: carga de datos del usuario, visualización en la pantalla de perfil y manejo de errores cuando el servidor no está disponible. Estas pruebas se incluyen en el conjunto de regresión y se ejecutan en cada cambio en el módulo de perfil.

@RunWith(AndroidJUnit4::class)
class ProfileRegressionTest {

    @get:Rule
    val composeRule = createComposeRule()

    @Test
    fun profileScreen_rendersCorrectly() {
        val user = User(id = 1, name = "Alice", email = "alice@test.com")
        composeRule.setContent {
            ProfileScreen(user)
        }
        composeRule.onNodeWithText("Alice").assertIsDisplayed()
        composeRule.onNodeWithText("alice@test.com").assertIsDisplayed()
    }

    @Test
    fun profileScreen_handlesNetworkError() {
        setNetworkError()
        composeRule.onNodeWithText("Error de carga").assertIsDisplayed()
    }
}

iOS: prueba de regresión con XCTest

Para iOS, la prueba de regresión utiliza XCTestExpectation para la verificación asíncrona de la actualización de la UI después de recibir datos de la API. La prueba emula una respuesta de red y verifica que los elementos de la UI se hayan actualizado correctamente.

class ProfileRegressionTests: XCTestCase {
    func testProfileScreen_rendersCorrectly() {
        let viewModel = ProfileViewModel(userId: 1)
        let view = ProfileView(viewModel: viewModel)
        viewModel.loadProfile()

        let expectation = expectation(description: "profile loaded")
        viewModel.onProfileLoaded = {
            XCTAssertEqual(viewModel.userName, "Alice")
            XCTAssertEqual(viewModel.userEmail, "alice@test.com")
            expectation.fulfill()
        }
        waitForExpectations(timeout: 3.0)
    }
}

Estrategia para construir un conjunto de regresión

Construir un conjunto de regresión efectivo es un proceso iterativo basado en datos de defectos y cambios de código. La estrategia inicial es incluir todas las pruebas existentes en el conjunto de regresión y ejecutar una pasada completa antes de cada lanzamiento. A medida que la base de pruebas crece (más de 2000 pruebas), una ejecución completa se vuelve demasiado larga y se requiere un enfoque selectivo.

La segunda fase — implementación de herramientas de análisis de dependencias: Jacoco para Android, Xcode Test Plan para iOS. Estas herramientas construyen un mapa “prueba — clase — método” y permiten determinar qué pruebas se ven afectadas por un cambio específico. Una ejecución selectiva basada en análisis de cobertura reduce el tiempo de ejecución en un 60–80% manteniendo un 95% de efectividad en la detección de regresiones, según Spotify Engineering (2022).

La tercera fase — monitoreo continuo y optimización. Las pruebas que no han fallado en 6 meses se mueven a un conjunto de baja prioridad. Las pruebas que fallan más de una vez al mes son candidatas a revisión: o detectan problemas reales (necesitan una corrección) o son demasiado frágiles (requieren estabilización). Una revisión trimestral del conjunto de regresión es una práctica estándar para mantener su efectividad y velocidad de ejecución.