Smoke Test en el desarrollo móvil — qué es, tareas y cómo se aplica

¿Qué es un Smoke Test?

Smoke Test es un conjunto de pruebas rápidas que verifican las funciones principales de una aplicación sin un análisis profundo. El término proviene de la ingeniería de hardware: si un dispositivo empieza a humear después del ensamblaje, no se envía a pruebas completas. En el desarrollo móvil, el Smoke Test cumple la misma función — filtrar compilaciones obviamente no funcionales. Según Microsoft DevOps (2024), la implementación de un Smoke Test reduce la cantidad de defectos que llegan al equipo de QA en un 40%.

Un Smoke Test se ejecuta en cada nueva compilación — tanto en Android como en iOS. Idealmente, un Smoke Test no debe durar más de 15 minutos y debe ejecutarse automáticamente después de una compilación exitosa. Criterio de aprobación — el 100% de las pruebas del conjunto Smoke Test deben completarse con éxito. Si al menos una prueba falla, la compilación se marca como inestable y no se envía a pruebas adicionales. Según Google Testing Blog (2024), este enfoque reduce el tiempo de entrega de funcionalidades a los usuarios en un 25%.

Un Smoke Test puede ser manual (una lista de verificación de 5 a 10 puntos) o automatizado. En proyectos móviles modernos, se prefiere un Smoke Test automatizado integrado en CI/CD. Smoke Test manual solo se justifica en las etapas tempranas del proyecto, cuando la automatización no es económicamente viable. Según Bitrise (2025), el 73% de los equipos de desarrollo móvil automatizan sus Smoke Tests.

¿En qué se diferencia un Smoke Test de las pruebas de regresión?

Smoke Test y las pruebas de regresión a menudo se confunden, pero son prácticas diferentes con diferentes objetivos. Las pruebas de regresión verifican que los cambios en el código no hayan roto la funcionalidad existente. Cubren todos los módulos y escenarios de la aplicación, incluidos los casos raros y extremos. Un Smoke Test verifica solo la ruta crítica — los escenarios principales sin los cuales la aplicación es inútil. Profundidad de cobertura es la principal diferencia: Smoke Test cubre del 5 al 10% de la funcionalidad, la regresión cubre del 80 al 100%.

La segunda diferencia es el tiempo de ejecución. Un conjunto de regresión para una aplicación móvil puede tomar de 2 a 12 horas, dependiendo del tamaño del proyecto y la cantidad de plataformas. Un Smoke Test toma de 5 a 15 minutos. Según Sauce Labs (2025), el tiempo promedio de ejecución de un conjunto de regresión para una aplicación iOS es de 4,5 horas, y para Android — 3,2 horas. Un Smoke Test en ambas plataformas se completa en 10–15 minutos.

La tercera diferencia es la ubicación en el pipeline. Un Smoke Test se ejecuta inmediatamente después de la compilación, antes de las pruebas de regresión. Si el Smoke Test falla, la regresión no se inicia — esto ahorra recursos de CI/CD. Eficiencia del pipeline — un Smoke Test filtra hasta el 30% de las compilaciones que habrían fallado en la regresión, y los recursos ahorrados son suficientes para ejecutar otras tareas en paralelo.

Qué incluye un Smoke Test de aplicación móvil

Inicio de la aplicación

Inicio de la aplicación — la primera y más importante prueba. La aplicación debe iniciarse sin fallos en todos los dispositivos objetivo. Un Smoke Test verifica el inicio en frío: instalación → apertura → visualización de la primera pantalla. Si la aplicación falla al iniciar, las pruebas adicionales no tienen sentido. XCUITest y Espresso permiten automatizar la verificación de inicio en 2–3 líneas de código. Argumento de inicio `-AppleLanguages (ru)` ayuda a verificar la localización al inicio.

Autenticación

Autenticación — el segundo escenario crítico. Un Smoke Test debe verificar que el formulario de inicio de sesión se muestra, los campos de entrada responden al tacto, el botón de inicio de sesión envía una solicitud y la aplicación navega a la pantalla principal después de una autenticación exitosa. Un error de autenticación bloquea el acceso a todas las demás funciones, por lo que su verificación está incluida en el conjunto mínimo. Token refresh — una verificación adicional para aplicaciones con OAuth 2.0.

Carga de contenido y navegación

Carga de contenido principal — la tercera prueba del Smoke Test. La pantalla principal o el feed de la aplicación deben cargarse y mostrar datos. Si la API no responde o el análisis de la respuesta está roto, el usuario ve una pantalla vacía. La verificación de red en un Smoke Test incluye una solicitud GET básica al endpoint principal y la verificación de que la respuesta tenga la estructura esperada. Navegación — el cuarto escenario. Un Smoke Test recorre las pantallas principales de la aplicación: inicio → búsqueda → perfil → configuraciones. La barra de pestañas y el menú lateral son fuentes típicas de problemas de navegación que un Smoke Test detecta temprano.

Automatización del Smoke Test en CI/CD

Fastlane — la herramienta estándar para automatizar CI/CD móvil. Un Smoke Test en Fastlane se ejecuta mediante `scan` (para XCUITest) o `gradle` (para Espresso). Fastlane permite configurar la ejecución del Smoke Test en varios dispositivos en paralelo, reduciendo el tiempo total. Configuración en Fastfile incluye el destino del conjunto Smoke Test y un umbral de aprobación: 100% de pruebas exitosas.

GitHub Actions (2024) publicó una plantilla de CI/CD móvil con un Smoke Test integrado. La plantilla incluye tres etapas: compilación → Smoke Test → regresión. Si el Smoke Test falla, la plantilla finaliza automáticamente el pipeline y envía una notificación a Slack o Telegram. Matrix strategy permite ejecutar el Smoke Test en tres versiones de iOS y cinco modelos de Android simultáneamente.

División de responsabilidades en CI/CD: el Smoke Test proporciona retroalimentación rápida, mientras que la regresión proporciona cobertura completa. El Smoke Test no debe duplicar la regresión, y viceversa. Granularidad del Smoke Test — una verificación por escenario crítico. Si un Smoke Test toma más de 15 minutos, debe optimizarse: eliminar verificaciones redundantes o paralelizar la ejecución.

# Configuración de Fastfile para Smoke Test
platform :ios do
    lane :smoke do
        scan(
            scheme: 'App',
            devices: ['iPhone 15', 'iPhone SE'],
            testplan: 'SmokeTest',
            output_directory: 'reports/smoke',
            fail_build: true
        )
    end

    lane :regression do
        scan(
            scheme: 'App',
            devices: ['iPhone 15', 'iPhone 14', 'iPhone SE'],
            testplan: 'FullRegression'
        )
    end
end

Herramientas para Smoke Test

XCUITest — el framework de Apple para pruebas de UI en aplicaciones iOS. XCUITest se utiliza para automatizar Smoke Tests: iniciar la aplicación, verificar elementos de la interfaz, simular acciones del usuario. Combinado con Xcode Server o GitHub Actions, XCUITest se ejecuta en cada commit. XCTest — el framework base para pruebas unitarias que complementa XCUITest para la verificación de lógica.

Espresso — el framework de Google para pruebas de UI en Android. Espresso se sincroniza con el hilo de UI y garantiza que todas las animaciones se completen antes de iniciar la verificación. Espresso admite la verificación mediante `onView(withId(...)).check(matches(...))`. Android Test Orchestrator ejecuta cada Smoke Test en un proceso separado, evitando que las pruebas anteriores influyan en las siguientes.

Detox — un framework para React Native que admite Smoke Test y pruebas de caja gris. Detox se sincroniza con el puente de React Native y espera automáticamente a que finalicen las operaciones asincrónicas. Pruebas de caja gris permiten a Detox verificar el estado de la aplicación sin acceso directo al código fuente.

Ejemplo de Smoke Test en Swift y Kotlin

XCUITest para iOS contiene dos verificaciones: iniciar la aplicación y mostrar la pantalla principal. La prueba inicia la aplicación mediante `XCUIApplication().launch()` y verifica que un elemento clave (por ejemplo, `navigationBar`) exista. Si la aplicación falla al iniciar, el framework XCTest registra el error y la prueba termina con FAIL. Smoke Test no verifica el contenido — solo que la pantalla se abrió.

Espresso para Android utiliza `ActivityScenario` para iniciar una Activity y `onView` para verificar elementos. Una diferencia crítica entre plataformas: el simulador de iOS puede mostrar un comportamiento diferente al de un dispositivo real, por lo que se recomienda ejecutar los Smoke Tests de Android en Firebase Test Lab o un emulador. Firebase Test Lab admite la ejecución en paralelo de Smoke Tests en 10 dispositivos.

import XCTest

class LoginSmokeTest: XCTestCase {
    let app = XCUIApplication()

    override func setUp() {
        continueAfterFailure = false
        app.launch()
    }

    func testLoginButtonExists() {
        XCTAssertTrue(app.buttons["Iniciar sesión"].exists)
    }

    func testLoginFlow() {
        app.textFields["email"].tap()
        app.textFields["email"].typeText("test@test.com")
        app.secureTextFields["password"].tap()
        app.secureTextFields["password"].typeText("password123")
        app.buttons["Log In"].tap()
        XCTAssertTrue(app.staticTexts["Welcome"].waitForExistence(timeout: 5))
    }
}

El ejemplo anterior muestra un Smoke Test para la pantalla de inicio de sesión en iOS. La primera prueba verifica que el botón de inicio de sesión existe en la pantalla. La segunda prueba recorre la ruta completa de autenticación y verifica que después de un inicio de sesión exitoso se muestre un mensaje de bienvenida. Tiempo de espera de 5 segundos para `waitForExistence` es el valor estándar para un Smoke Test: si el elemento de UI no aparece en ese tiempo, la aplicación no funciona correctamente.