Qué es un entorno de pruebas y cómo configurarlo: guía práctica para QA

Por /

Uno de los conceptos que más confusión genera cuando empiezas en QA es el de entorno de pruebas. ¿Es lo mismo que producción? ¿Por qué no probamos directamente en la aplicación real? En este artículo te lo explico todo desde cero.

Qué es un entorno de pruebas

Un entorno de pruebas es una copia de la aplicación configurada específicamente para ejecutar tests, separada de la versión que usan los usuarios reales.

La razón es sencilla: no puedes probar en producción. Si ejecutas tests en la aplicación real puedes borrar datos de usuarios reales, enviar emails reales o hacer cargos reales en tarjetas de crédito.

Los tipos de entornos más comunes

Entorno de desarrollo (Development) Es el entorno local del desarrollador. Aquí se escribe y prueba el código por primera vez. Es el más inestable porque cambia constantemente.

Entorno de integración (CI) Es donde se ejecutan los tests automatizados de forma continua. En GitHub Actions este entorno se crea y destruye automáticamente para cada ejecución.

Entorno de staging Es la réplica más fiel de producción. Tiene la misma configuración e infraestructura. Es donde el QA hace las pruebas finales antes del despliegue.

Entorno de producción Es la aplicación real que usan los usuarios. No se prueba aquí salvo smoke tests muy controlados post-despliegue.

Por qué la paridad con producción es crítica

El error más común es tener un staging muy diferente a producción. Si staging usa una versión antigua de la base de datos o tiene configuraciones distintas, los tests pasan en staging pero fallan en producción.

La regla es: cuanto más parecido sea el entorno de staging a producción, más confianza da el testing.

Gestionar entornos con variables de entorno en Playwright

python

# conftest.py
import os
import pytest

@pytest.fixture(scope="session")
def base_url():
    entorno = os.getenv("TEST_ENV", "staging")
    urls = {
        "local": "http://localhost:3000",
        "staging": "https://staging.miweb.com",
        "production": "https://miweb.com"
    }
    return urls[entorno]

Para cambiar de entorno simplemente cambias la variable:

bash

TEST_ENV=local pytest tests/
TEST_ENV=staging pytest tests/

Variables de entorno para credenciales

Las credenciales nunca deben estar hardcodeadas en el código:

python

import os
from playwright.sync_api import Page

def test_login(page: Page):
    email = os.getenv("TEST_USER_EMAIL", "usuario@test.com")
    password = os.getenv("TEST_USER_PASSWORD", "password123")
    
    page.goto("https://staging.miweb.com/login")
    page.get_by_label("Email").fill(email)
    page.get_by_label("Password").fill(password)
    page.get_by_role("button", name="Login").click()
    
    assert "dashboard" in page.url

En GitHub Actions las credenciales se configuran en los Secrets del repositorio.

Configurar múltiples entornos en GitHub Actions

yaml

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        entorno: [staging, integration]
    steps:
      - uses: actions/checkout@v3
      - name: Ejecutar tests en ${{ matrix.entorno }}
        env:
          TEST_ENV: ${{ matrix.entorno }}
          TEST_USER_EMAIL: ${{ secrets.TEST_USER_EMAIL }}
          TEST_USER_PASSWORD: ${{ secrets.TEST_USER_PASSWORD }}
        run: pytest tests/ -v

Los errores más comunes

Tests que dependen del orden de ejecución — cada test debe ser completamente independiente. Credenciales hardcodeadas — usa siempre variables de entorno. Staging desactualizado — si no se actualiza regularmente los tests no son representativos.

Si quieres saber más sobre CI/CD puedes leer GitHub Actions para QA.

Y si necesitas ayuda para configurar la estrategia de testing de tu proyecto puedes ver mis servicios en fatimaqa.com.

Scroll al inicio