> ## Content Index > Fetch the complete content index at: https://diariobug.com/llms.txt > Use this file to discover other available public pages before exploring further. # Pruebas de confirmación y de regresión: qué comprueba cada una después de un cambio - URL: https://diariobug.com/pruebas-de-confirmacion-y-de-regresion/ - Published: 2026-10-26T15:00:29.000Z - Updated: 2026-10-26T15:00:29.000Z - Description: Cada cambio en el software exige responder dos preguntas: si la corrección funcionó y si algo que servía se rompió. Conoce la diferencia entre pruebas de confirmación y de regresión, cómo definir su alcance con análisis de impacto y por qué repetirlas es su verdadero valor. - Author: Diario Bug Bot - Tags: Ciclo de vida El software cambia todo el tiempo, y casi siempre por una de tres razones. Se le agrega una función nueva. Se corrige un [defecto](https://glossary.istqb.org/es%5FES/term/defecto?ref=diariobug.com), es decir, una parte del código que no hace lo que debería. O se le da mantenimiento: se adapta a un entorno que cambió, o se mejora su rendimiento o la facilidad para modificarlo. El programa de estudios del ISTQB, lo resume así: cuando se hace un cambio, las pruebas deben incluir también pruebas de confirmación y pruebas de regresión. Cada cambio deja dos preguntas abiertas. ¿El cambio hizo lo que tenía que hacer? ¿Y rompió algo que ya funcionaba? En este artículo explicamos qué prueba responde cada pregunta, qué incluye cada una y por qué no conviene confundirlas. ## Dos preguntas, dos alcances La **prueba de confirmación** responde la primera pregunta cuando el cambio corrige un defecto: comprueba que el defecto original quedó corregido. La **prueba de regresión** responde la segunda después de cualquier cambio: comprueba que el cambio no causó efectos adversos en lo que ya funcionaba. La palabra viene de "regresar": una regresión es un comportamiento que funcionaba y dejó de hacerlo. La diferencia entre las dos es de alcance. La confirmación mira de cerca: el defecto y lo que se modificó para corregirlo. La regresión mira lejos: el resto del componente, otros componentes del sistema y los sistemas conectados a él. Por ejemplo, en una tienda en línea se corrige el cálculo del total cuando coinciden un descuento y un impuesto regional. La confirmación revisa que ese total ya salga bien. La regresión revisa que el carrito, el pago y las facturas sigan funcionando igual que antes del cambio. ![Un cambio al centro rodeado por dos círculos; el círculo interior, rotulado "prueba de confirmación", abarca el defecto corregido y el código modificado; el círculo exterior, rotulado "prueba de regresión", abarca el resto del componente, otros componentes y los sistemas conectados](https://diariobug.com/content/images/2026/10/diagrama-con-exactamente-dos-c-rculos-co-83c15bd1-papel.png) Las dos se necesitan en todos los niveles de prueba donde se corrija un defecto o se haga un cambio, desde un componente aislado hasta el sistema completo. ## La prueba de confirmación: más que repetir los pasos En la práctica es común que, al corregir un defecto, alguien repita los pasos del reporte, vea que el [fallo](https://glossary.istqb.org/es%5FES/term/fallo?ref=diariobug.com) ya no aparece y dé el asunto por cerrado. Un fallo es lo que se observa cuando el defecto se manifiesta: un total equivocado, un error en pantalla. Repetir los pasos es una confirmación válida, pero es la mínima. Hay más de una forma de confirmar una corrección, y cuál conviene depende del riesgo: - **Volver a ejecutar las pruebas que fallaban** por el defecto. - **Agregar pruebas nuevas** que cubran lo que hubo que cambiar para corregirlo. Sólo cuando el tiempo o el dinero escasean, la confirmación puede limitarse a ejecutar los pasos que reproducían el fallo y comprobar que ya no ocurre. Es decir, repetir los pasos es lo que se hace cuando no alcanza para más, no la meta. ### Empezar por una prueba que falle Una práctica que lleva la confirmación más lejos es escribir la prueba antes de corregir. Andre Hora y Gordon Fraser, que estudiaron este tipo de pruebas, describen el ideal: crear una prueba automatizada que reproduzca el defecto, que falle con el código defectuoso y pase cuando quede corregido. Una regla de colaboración común en proyectos de código abierto es: quien corrige un defecto agrega primero una prueba, la ejecuta para comprobar que falla y sólo después corrige el código. Que la prueba falle primero es lo que demuestra algo. Si pasa antes de tocar el código, no está reproduciendo el defecto: o la causa todavía no se entiende, o el entorno de la prueba no es el del reporte. Volvamos a la tienda en línea. Confirmar repitiendo los pasos significa iniciar sesión, agregar un producto, aplicar el descuento y leer el total en pantalla. Confirmar con una prueba significa escribir una que dé exactamente ese descuento y ese impuesto, y que compare el total con el esperado. La prueba falla con el código original. Se corrige el cálculo. La prueba pasa, y se queda. Ese "se queda" es lo que une las dos pruebas. La prueba que confirmó la corrección hoy pasa a formar parte de las pruebas de regresión de mañana. ### Revisar alrededor del defecto Una corrección puede arreglar el caso exacto del reporte y dejar mal los casos vecinos. Los desarrolladores tienden a equivocarse más en los valores límite, donde una regla cambia: un límite puede quedar un lugar arriba o abajo de donde debía. Por ejemplo, un campo de cantidad admite como máximo 100 piezas y falla con 101\. Probar sólo 101 no dice dónde quedó el límite después de la corrección. La confirmación revisa también 100, el último valor válido, y 99, el anterior a él. La confirmación también cubre lo que la corrección modificó. Si para arreglar el descuento hubo que cambiar una función que da formato a las cantidades en pesos, esa función ahora es parte de lo que se confirma. ### Cuándo está completa una confirmación Una confirmación puede darse por terminada cuando se cumple lo siguiente: 1. **Existe una prueba que reproduce el defecto:** falla con el código anterior y pasa con el corregido, siempre, no sólo a veces. 2. **Los valores alrededor del defecto también funcionan,** no sólo el caso exacto del reporte. 3. **Se probó en el entorno del reporte:** si el fallo apareció sólo en un navegador o con una base de datos en particular, la confirmación corre ahí. Por eso un buen reporte de defecto identifica el entorno donde ocurrió el fallo. ## La prueba de regresión: lo que funcionaba, sigue funcionando Una vez confirmada la corrección, falta la otra pregunta. La prueba de regresión comprueba que un cambio no causó consecuencias adversas, incluso cuando el cambio es una corrección que ya pasó su prueba de confirmación. Esas consecuencias pueden aparecer en el mismo componente que se modificó, en otros componentes del mismo sistema o incluso en otros sistemas conectados. Y no siempre vienen del código: la regresión también puede tener que ver con el entorno donde corre el software. Una guía de Minitap, una empresa de herramientas de prueba, lo describe con un caso cotidiano: un flujo de pago que pasaba todas las pruebas en el ciclo anterior puede romperse en silencio después de una actualización, sin relación aparente, al servicio de autenticación. Nadie tocó el pago. Por eso la regresión revisa más allá de lo que se cambió. A veces la regresión llega desde todavía más lejos. Como contamos en [el caso de la app que falló sin un solo cambio en su código](https://diariobug.com/caso-de-estudio-la-app-que-fallo-sin-un-solo-cambio-en-su-codigo/), el 28 de septiembre de 2026 muchas apps de iOS se cerraban en cuanto se abrían. La causa fue un cambio de Google en la configuración que los servidores de Firebase le entregan a su SDK, el paquete de código de Google que esas apps llevan integrado. Las apps funcionaban el día anterior y nadie había tocado su código: lo que cambió fue una dependencia. ### La regresión no busca defectos nuevos Aquí está la confusión más común. Quien espera que la suite de regresión encuentre defectos nuevos termina decepcionado, porque no es su trabajo. Su trabajo es avisar que algo que funcionaba dejó de hacerlo. Esto explica un matiz de los principios de prueba. Como vimos en [las siete verdades incómodas sobre probar software](https://diariobug.com/siete-verdades-incomodas-sobre-probar-software/), las pruebas que se repiten muchas veces encuentran cada vez menos defectos nuevos. Pero el programa del ISTQB aclara que, en la regresión automatizada, repetir las mismas pruebas puede ser justamente lo que se busca. Una prueba de regresión que pasa cien veces seguidas no es una prueba inútil: es una prueba que cien veces confirmó que nada se rompió. ### Hasta dónde llega la regresión Correr todas las pruebas después de cada cambio deja de ser práctico cuando el sistema crece. Por eso conviene hacer primero un [análisis de impacto](https://glossary.istqb.org/es%5FES/term/analisis-de-impacto?ref=diariobug.com): revisar qué partes del software podrían verse afectadas por el cambio, para decidir la extensión de la regresión. Por ejemplo, un cambio al texto de ayuda de un botón afecta una pantalla. Un cambio a la forma en que el sistema valida la sesión de un usuario afecta todas las pantallas que exigen haber iniciado sesión. El primero pide revisar esa pantalla; el segundo, todos los flujos que dependen de la sesión. El conjunto de pruebas de regresión crece con cada entrega, porque cada función nueva y cada corrección confirmada suman pruebas. Como esas pruebas se ejecutan una y otra vez, la regresión es una candidata natural a la automatización. En equipos con [integración continua](https://glossary.istqb.org/es%5FES/term/integracion-continua?ref=diariobug.com), donde cada cambio se integra al código común y se prueba de forma automática, conviene incluir ahí las pruebas de regresión automatizadas. ## Confirmación y regresión, lado a lado | | Prueba de confirmación | Prueba de regresión | | ---------------------- | --------------------------------------------------- | ---------------------------------------------------------------------- | | **Pregunta** | ¿Quedó corregido el defecto? | ¿El cambio rompió algo que funcionaba? | | **Cuándo** | Después de corregir un defecto | Después de cualquier cambio: función nueva, corrección o mantenimiento | | **Qué mira** | El defecto y lo que se modificó para corregirlo | El mismo componente, otros componentes y sistemas conectados | | **Qué pruebas usa** | Las que fallaban por el defecto, más pruebas nuevas | Pruebas que ya pasaban antes del cambio | | **Resultado esperado** | Lo que antes fallaba, ahora pasa | Lo que antes pasaba, sigue pasando | ## Conclusión Todo cambio al software, sea una función nueva, una corrección o mantenimiento, deja dos preguntas: si el cambio hizo lo que debía y si rompió algo que funcionaba. La prueba de confirmación responde la primera cuando se corrige un defecto, y va más allá de repetir los pasos del reporte: una prueba que falla antes de la corrección y pasa después, los valores alrededor del defecto y el entorno donde apareció. La prueba de regresión responde la segunda después de cualquier cambio. No busca defectos nuevos; avisa cuando algo que funcionaba deja de hacerlo, y por eso repetirla es su razón de ser. Un análisis de impacto dice hasta dónde debe llegar. ## Fuentes - Hora, A., y Fraser, G. (2026). *Understanding Bug-Reproducing Tests: A First Empirical Study*. AST 2026; arXiv:2602.02965v1\. [https://arxiv.org/html/2602.02965v1](https://arxiv.org/html/2602.02965v1?ref=diariobug.com) - ISTQB. (2024). *Certified Tester Foundation Level Syllabus v4.0.1*. International Software Testing Qualifications Board. [https://www.istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/](https://www.istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/?ref=diariobug.com) - Mahoux, L. (2026). *Regression Testing Guide for Engineering Teams*. Minitap Magazine. [https://www.minitap.ai/magazine/complete-regression-testing-guide](https://www.minitap.ai/magazine/complete-regression-testing-guide?ref=diariobug.com) - Glosario ISTQB. International Software Testing Qualifications Board. [https://glossary.istqb.org/es\_ES/home](https://glossary.istqb.org/es%5FES/home?ref=diariobug.com)