Terminas un cambio, lo pruebas en tu computadora y parece funcionar. Pero en producción puede pasar otra cosa: una persona paga dos veces, un servicio externo tarda demasiado o una actualización rompe una función que ya existía.
El testing, o las pruebas de software, ayuda a encontrar estos problemas antes de que afecten a las personas que usan la aplicación. Es parte de construir software, no es trabajo de una sola persona ni una tarea que se hace al final.
Para qué sirve el testing
Testing es revisar un programa para encontrar errores, comprobar que cumple lo acordado y reducir problemas antes de publicarlo. [1]
En la práctica, el testing ayuda a resolver problemas que aparecen todos los días al desarrollar software:
- Evita malentendidos. Permite confirmar que una función hace lo que producto y las personas usuarias necesitan antes de publicarla.
- Evita romper algo que ya funcionaba. Detecta si un cambio afecta otra parte de la aplicación. Esto se conoce como regresión.
- Prepara al sistema para casos reales. Revisa qué pasa con datos vacíos, errores de otros servicios o muchas personas usando la aplicación al mismo tiempo.
- Ayuda a decidir si un cambio está listo. En lugar de publicar solo porque el código compila, el equipo tiene resultados para conocer los riesgos que quedan.
No hay una forma de probar todas las situaciones posibles. El testing tampoco garantiza que no existan errores. Su valor es encontrar los problemas importantes cuando todavía es más fácil y barato corregirlos.
Por eso la calidad es trabajo de todo el equipo. Quien desarrolla prueba el código, producto aclara qué espera del cambio, QA busca casos que no se habían pensado y operaciones aporta fallos reales de producción.
SDLC y STLC: cómo se relacionan
El SDLC (Software Development Life Cycle) ordena todo el camino para crear software: entender una necesidad, definir qué se va a hacer, diseñar, programar, publicar y mantener el producto.
El STLC (Software Testing Life Cycle) es una guía para organizar las pruebas mientras se crea el producto. Sirve para decidir qué probar, cómo hacerlo, qué debería pasar y cómo atender los errores. No empieza cuando el código está terminado: acompaña al equipo desde el inicio. [2]
Ejemplo: agregar la recuperación de contraseña. El SDLC cubre todo el trabajo, desde acordar la función hasta publicarla. El STLC acompaña ese trabajo: define qué probar, revisa el código y el flujo completo, y mejora las pruebas si aparece un error.
Shift left significa pensar en las pruebas desde que se define la tarea, no solo cuando el código ya está terminado.
Los 7 principios del testing
ISTQB, una organización conocida por sus certificaciones de pruebas, resume siete ideas útiles. Ayudan a decidir dónde poner el esfuerzo. [3]
- Las pruebas pueden encontrar errores, pero no demostrar que no existen. Si todas las pruebas pasan, sabes que esos casos funcionaron. No sabes que todos los casos imaginables funcionarán.
- No se puede probar todo. Hay demasiadas combinaciones de datos, dispositivos, permisos y estados. Hay que elegir qué probar primero.
- Probar temprano ahorra tiempo y dinero. Aclarar una duda antes de programar cuesta menos que corregir una falla después de publicar.
- Los errores suelen aparecer en las mismas zonas. Las partes más complejas, las que cambian mucho o las que se conectan con otros sistemas merecen más atención.
- Repetir siempre las mismas pruebas deja de ayudar. Cuando el producto cambia, las pruebas también deben cambiar. A esto se le conoce como la paradoja del pesticida.
- Cada producto necesita pruebas distintas. Una aplicación de banco no se prueba igual que una página informativa o una herramienta interna.
- No basta con que el programa no falle. Si resuelve el problema equivocado, no sirve aunque técnicamente esté bien hecho.
El segundo principio es importante: no necesitas una cobertura perfecta para empezar. Si una función cobra dinero, mueve datos o da permisos, pruébala primero. Si solo cambiaste un texto, una revisión visual puede ser suficiente.
Las fases del STLC
Cada empresa puede usar nombres distintos, pero el ciclo de pruebas suele incluir estas seis fases. Se repiten con cada cambio. [4]
- Entender y planear. Acordar qué se necesita, qué puede fallar y qué significa que el cambio está listo.
- Diseñar las pruebas. Definir los casos, datos y resultados esperados, incluidos errores y límites.
- Preparar el ambiente. Dejar listos los datos, servicios y herramientas para probar.
- Ejecutar. Correr las pruebas y guardar sus resultados.
- Reportar y corregir errores. Explicar cómo repetir el problema, su impacto y volver a probar cuando se corrija.
- Cerrar y aprender. Revisar qué se probó, qué faltó y qué se puede mejorar.
Reportar un error no es señalar a alguien. Es dar información clara para que el equipo pueda arreglar un problema.
Los niveles de prueba
No todas las pruebas revisan lo mismo. Algunas miran una regla pequeña y otras revisan un recorrido completo. Si vas empezando, piensa en estos cuatro niveles:
| Nivel | Qué revisa | Ejemplo |
|---|---|---|
| Unitaria | Una regla o función pequeña | Un descuento del 10% se calcula bien |
| Integración | Que dos partes trabajen juntas | Un formulario guarda el nombre en la base de datos |
| Sistema o end-to-end | Un recorrido completo | Crear una cuenta, iniciar sesión y editar el perfil |
| Aceptación (UAT) | Que se cumplió lo acordado | Producto confirma que el formulario pide los datos necesarios |
Las pruebas unitarias son el mejor lugar para empezar. Son rápidas y revisan reglas como cálculos, permisos o validaciones. Agrega una cuando crees o cambies una regla importante.
Las pruebas de integración revisan conexiones: por ejemplo, que tu aplicación guarde datos en la base de datos o se comunique bien con otro servicio. Úsalas cuando una función dependa de algo fuera de esa parte de código.
Las pruebas de sistema o end-to-end revisan todo el recorrido como lo haría una persona. Son más lentas, así que elige solo los flujos importantes, como crear una cuenta, iniciar sesión o guardar un formulario.
Las pruebas de aceptación confirman con producto o negocio que la función hace lo que se acordó. Por ejemplo, no basta con que un formulario funcione: también hay que confirmar que pide solo los datos necesarios.
Para empezar, escribe pruebas unitarias para las reglas nuevas. Después agrega una prueba de integración si conectas otra parte del sistema. Cuando un flujo sea importante, agrega una prueba completa. No necesitas tener todas desde el primer día.
Tipos de prueba
Los niveles indican qué parte del sistema revisas; los tipos, qué quieres comprobar. Elige según el riesgo del cambio.
Pruebas funcionales: revisar que haga lo que debe
- Humo (smoke test): revisa lo básico de una versión nueva, como abrir la aplicación e iniciar sesión.
- Sanidad (sanity test): revisa rápido el cambio que acabas de hacer, como enviar un formulario modificado.
- Regresión: confirma que un cambio no rompió una función existente.
- Aceptación: confirma con producto o negocio que se cumplió lo acordado.
- Exploratoria: una persona usa la aplicación sin un guion fijo para encontrar casos inesperados.
Pruebas no funcionales: revisar cómo funciona
- Rendimiento, carga y estrés: miden qué tan rápido responde y qué pasa con muchas personas usando la aplicación.
- Seguridad: busca accesos sin permiso, datos expuestos o dependencias inseguras.
- Accesibilidad y usabilidad: revisan que distintas personas puedan entender y usar la aplicación.
- Compatibilidad: confirma que funciona en los navegadores y dispositivos necesarios.
- Recuperación: comprueba qué pasa si falla una conexión o un servicio externo.
- Manuales: una persona las ejecuta; sirven para explorar y revisar la experiencia.
- Automáticas: una herramienta las ejecuta; sirven para tareas repetidas, como regresión.
Dos preguntas ayudan a elegir: verificación es "¿lo construimos bien?"; validación es "¿construimos lo que la persona necesita?".
Herramientas por nivel de prueba
La herramienta depende del lenguaje y del tipo de prueba. No necesitas usar todas: elige una que tu equipo pueda mantener.
| Nivel | Herramientas o frameworks | Uso común |
|---|---|---|
| Unitaria | Jest, pytest, JUnit, NUnit | Probar funciones y reglas de código |
| Integración | Postman, Bruno, Supertest, REST Assured, Pact | Probar APIs y conexiones entre servicios |
| Sistema o end-to-end | Playwright, Cypress, Selenium | Automatizar recorridos en el navegador |
| Aceptación | Cucumber, SpecFlow, Behave | Describir y comprobar escenarios acordados con producto |
Resumen
El testing no demuestra que una aplicación no tiene errores. Su valor está en encontrar malentendidos, regresiones y fallos importantes antes de que afecten a las personas usuarias. Por eso es una responsabilidad compartida entre desarrollo, producto, QA y operaciones.
El SDLC cubre todo el trabajo para crear y mantener software. El STLC organiza las pruebas dentro de ese trabajo: planear, diseñar casos, preparar el ambiente, ejecutar, corregir y aprender. Empezar estas conversaciones desde que se define una tarea es aplicar shift left.
No puedes probar todo, así que prioriza según el riesgo. Usa pruebas unitarias para reglas pequeñas, de integración para conexiones, de sistema para recorridos importantes y de aceptación para confirmar lo acordado. Compleméntalas con pruebas funcionales y no funcionales, como regresión, rendimiento, seguridad y accesibilidad. Las herramientas aceleran este trabajo, pero lo importante es elegir las pruebas que den información útil para entregar con más confianza.