Las pruebas de regresión son una de las primeras cosas que automaticé en mis proyectos con Playwright. Y tiene todo el sentido — es exactamente el tipo de tarea repetitiva que más tiempo ahorra cuando está automatizada. En este artículo te explico qué son, cómo funcionarlas y cómo implementarlas con Playwright y Python desde cero.
Qué es una prueba de regresión
Una prueba de regresión verifica que algo que funcionaba antes sigue funcionando después de un cambio en el código. Cada vez que un desarrollador añade una funcionalidad nueva, corrige un bug o modifica algo existente, existe el riesgo de que ese cambio rompa algo que ya funcionaba correctamente.
Las pruebas de regresión son la red de seguridad que detecta esos problemas antes de que lleguen a los usuarios.
Por qué Playwright es perfecto para la regresión
Las pruebas de regresión tienen que ejecutarse frecuentemente — idealmente en cada push al repositorio. Eso significa que tienen que ser rápidas, estables y fáciles de mantener.
Playwright cumple los tres requisitos. Su auto-waiting elimina los tests inestables, su velocidad permite ejecutar suites grandes en poco tiempo y su integración nativa con GitHub Actions permite automatizar la ejecución sin configuración compleja.
Si quieres saber más sobre qué es Playwright y por qué se ha convertido en el estándar puedes leer qué es Playwright y por qué cada vez más equipos QA lo eligen.
Estructura de un proyecto de regresión con Playwright
La estructura recomendada para organizar tus tests de regresión es esta:
proyecto/
├── pages/
│ ├── login_page.py
│ └── home_page.py
├── tests/
│ ├── test_login.py
│ └── test_navegacion.py
├── pytest.ini
└── requirements.txtEsta estructura sigue el patrón Page Object Model, que hace que los tests sean fáciles de mantener cuando la interfaz cambia. Si no conoces el POM puedes leer qué es el Page Object Model y cómo usarlo con Playwright.
Cómo marcar los tests de regresión con pytest
Lo primero es diferenciar tus tests de regresión del resto usando markers de pytest. Así puedes ejecutarlos de forma independiente cuando los necesites.
En tu archivo pytest.ini registra el marker:
ini
[pytest]
markers =
regression: pruebas de regresión
smoke: pruebas de smoke testLuego marca cada test de regresión con el decorador correspondiente:
python
import pytest
from playwright.sync_api import Page
from pages.login_page import LoginPage
@pytest.mark.regression
def test_login_usuario_valido(page: Page):
login = LoginPage(page)
login.goto()
login.login("usuario@test.com", "password123")
assert "dashboard" in page.url
@pytest.mark.regression
def test_login_password_incorrecta(page: Page):
login = LoginPage(page)
login.goto()
login.login("usuario@test.com", "wrongpassword")
assert "login" in page.url
@pytest.mark.regression
def test_menu_principal_visible(page: Page):
page.goto("https://miweb.com")
assert page.locator("nav").is_visible()
@pytest.mark.regression
def test_footer_visible(page: Page):
page.goto("https://miweb.com")
assert page.locator("footer").is_visible()Para ejecutar solo los tests de regresión:
powershell
pytest -m regressionPara ejecutar todos los tests excepto los de regresión:
powershell
pytest -m "not regression"Qué funcionalidades cubrir en una suite de regresión
No hace falta incluir todo en la suite de regresión. La clave es cubrir los flujos más críticos — los que no pueden fallar bajo ningún concepto.
En una aplicación típica la suite de regresión debería cubrir el login y logout, la navegación principal, los flujos críticos de negocio como compra o registro, las integraciones con APIs externas y las funcionalidades que han tenido bugs anteriormente.
Las funcionalidades secundarias o poco usadas pueden quedarse fuera de la regresión y testearse de forma manual o en ciclos menos frecuentes.
Cómo automatizar la regresión con GitHub Actions
El verdadero valor de las pruebas de regresión automatizadas está en ejecutarlas de forma automática en cada push al repositorio. Con GitHub Actions esto se configura en minutos.
Crea el archivo .github/workflows/regression.yml con este contenido:
yaml
name: Regression Tests
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
regression:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Instalar Python
uses: actions/setup-python@v4
with:
python-version: '3.11'
- name: Instalar dependencias
run: |
pip install -r requirements.txt
playwright install --with-deps
- name: Ejecutar tests de regresión
run: pytest -m regression -
---
Con esto, cada vez que hagas push a main GitHub ejecutará automáticamente todos los tests marcados como regression y te avisará si algo falla. Puedes ver cómo funciona GitHub Actions en detalle en [GitHub Actions para QA: automatiza tus tests](https://fatimaqa.com/github-actions-qa-automatizar-tests/).
Cuándo ejecutar las pruebas de regresión
Las pruebas de regresión tienen más sentido en estos momentos:
Después de cada push o pull request — es el uso más habitual con CI/CD. Antes de cada release — para confirmar que todo funciona antes de desplegar a producción. Después de corregir un bug — para verificar que la corrección no ha roto nada más. Al integrar cambios de terceros — cuando actualizas dependencias o integras una API externa.
Un ejemplo real de mi portafolio
En mi repositorio qa-suite-saucedemo tienes una suite completa de 20 tests E2E organizados con markers de smoke, regression y negative, Page Object Model y CI/CD con GitHub Actions.
Es un ejemplo real de cómo estructurar una suite de regresión profesional que puedes usar como referencia para tus propios proyectos.
Si quieres profundizar en cómo funciona el testing de regresión a nivel conceptual puedes leer pruebas manuales vs automatizadas: cuándo usar cada una o qué es el testing shift-left.
Y si necesitas implementar una suite de regresión en tu proyecto puedes ver mis servicios en fatimaqa.com