El Testing de Software, o pruebas de software, es el conjunto de actividades que se realizan para evaluar si una aplicación funciona como se espera, si cumple sus requisitos y si puede ser utilizada con un nivel aceptable de calidad y confianza.
Cuando una persona usa un sistema espera que las operaciones importantes funcionen correctamente: iniciar sesión, registrar datos, calcular importes, enviar formularios, guardar cambios, consultar información o realizar pagos. El testing ayuda a descubrir problemas antes de que esos errores lleguen a los usuarios finales.
Probar software no consiste solamente en "hacer clic" en una pantalla para ver qué ocurre. Es una actividad técnica y ordenada que requiere análisis, criterio, documentación y comunicación. Un buen tester no solo ejecuta pasos: piensa en riesgos, busca comportamientos inesperados, compara resultados y ayuda al equipo a tomar mejores decisiones.
Podemos definir el testing de esta manera:
Esta definición contiene varias ideas importantes:
El software es construido por personas, y las personas pueden cometer errores. Un requisito puede estar mal entendido, una condición puede no haberse contemplado, un cálculo puede estar incompleto o una modificación puede romper una funcionalidad que antes funcionaba bien.
Además, los sistemas reales suelen tener muchas combinaciones posibles: distintos usuarios, datos, navegadores, dispositivos, permisos, configuraciones, horarios, idiomas y conexiones con otros sistemas. Aunque el código parezca correcto, puede fallar en situaciones concretas.
El testing permite reducir estos riesgos. No garantiza que el software no tenga errores, pero sí aumenta la probabilidad de descubrir problemas importantes a tiempo.
El objetivo más conocido del testing es encontrar errores, pero no es el único. Las pruebas cumplen varias funciones dentro de un proyecto:
Por eso el testing no debe verse como una etapa final que solo busca "aprobar o rechazar" una aplicación. Debe entenderse como una práctica que acompaña al desarrollo y aporta información útil durante todo el proceso.
Supongamos que estamos desarrollando una pantalla de inicio de sesión. A primera vista, podríamos probar solamente el caso más simple: escribir un usuario correcto, escribir una contraseña correcta y presionar el botón de ingresar.
Sin embargo, un tester pensará en muchas otras situaciones:
Este ejemplo muestra que probar no es solo confirmar el camino correcto. También implica explorar caminos alternativos, datos inválidos, límites, errores y condiciones poco frecuentes.
El testing está muy relacionado con la calidad, pero no son sinónimos. La calidad de software es una característica amplia del producto y del proceso con el que se construye. Incluye aspectos como funcionalidad, rendimiento, seguridad, usabilidad, mantenibilidad, accesibilidad y confiabilidad.
El testing es una de las prácticas que ayuda a evaluar y mejorar esa calidad. Por ejemplo, una prueba puede revelar que una funcionalidad calcula mal un descuento, que una página tarda demasiado en cargar o que un mensaje de error no es claro para el usuario.
Pero la calidad también depende de otras actividades: buenos requisitos, diseño adecuado, código claro, revisiones, refactoring, integración continua, comunicación del equipo y seguimiento de defectos.
Una idea incompleta es pensar que el tester solo "rompe" el sistema. En realidad, el testing produce información. Esa información permite responder preguntas como:
En un proyecto profesional, esta información es tan importante como el defecto encontrado. Un reporte claro puede evitar confusiones, ahorrar tiempo y ayudar a priorizar el trabajo del equipo.
En testing se utilizan varias palabras que conviene distinguir desde el comienzo:
| Concepto | Significado | Ejemplo |
|---|---|---|
| Error | Equivocación humana al analizar, diseñar, programar o configurar. | Un desarrollador interpreta mal cómo debe calcularse un impuesto. |
| Defecto | Problema introducido en el código, documentación, diseño o configuración. | La fórmula implementada usa un porcentaje incorrecto. |
| Falla | Comportamiento observable incorrecto cuando se ejecuta el sistema. | El usuario ve un total mal calculado en la pantalla de compra. |
Un error humano puede generar un defecto en el producto, y ese defecto puede manifestarse como una falla durante la ejecución. Comprender esta diferencia ayuda a comunicar problemas con mayor precisión.
Una práctica poco recomendable es dejar las pruebas para el final del proyecto. Si los problemas se detectan tarde, corregirlos suele ser más costoso porque pueden afectar muchas partes ya construidas.
Lo ideal es probar desde etapas tempranas:
Cuanto antes se encuentra un defecto, más fácil suele ser corregirlo y menor es su impacto.
Se puede probar mucho más que una pantalla visible. Algunos elementos que pueden ser evaluados son:
El alcance de las pruebas depende del objetivo del proyecto, del tiempo disponible, del nivel de riesgo y de la importancia de cada funcionalidad.
En sistemas reales suele ser imposible probar absolutamente todo. Una pantalla con varios campos, permisos, configuraciones y estados puede generar miles o millones de combinaciones posibles.
Por eso el testing necesita técnicas de selección. El objetivo es elegir pruebas representativas y valiosas, no ejecutar combinaciones sin criterio. Algunas preguntas útiles son:
En temas posteriores veremos técnicas concretas para diseñar mejores casos de prueba sin intentar cubrirlo todo de forma desordenada.
Las pruebas pueden ejecutarse de forma manual o automatizada. Ambas formas son útiles y cumplen objetivos distintos.
| Tipo | Características | Uso habitual |
|---|---|---|
| Testing manual | Una persona diseña, ejecuta y observa el comportamiento del sistema. | Exploración, revisión visual, validación de experiencia de usuario, pruebas iniciales. |
| Testing automatizado | Un programa ejecuta verificaciones repetibles y compara resultados esperados. | Regresión, validaciones frecuentes, flujos críticos, integración continua. |
Automatizar no reemplaza por completo el criterio humano. La automatización es muy potente para repetir verificaciones, pero una persona sigue siendo necesaria para analizar riesgos, descubrir casos nuevos, interpretar resultados y decidir qué conviene probar.
Un caso de prueba describe una situación que queremos verificar. Por ejemplo, para una calculadora de descuentos:
| Objetivo | Verificar que se aplique un descuento del 10% a una compra de $1000. |
|---|---|
| Datos de entrada | Importe: 1000. Descuento: 10%. |
| Pasos | Ingresar el importe, seleccionar el descuento y confirmar el cálculo. |
| Resultado esperado | El sistema debe mostrar un total de $900. |
| Resultado obtenido | Se completa durante la ejecución de la prueba. |
Este ejemplo es sencillo, pero muestra la estructura básica: objetivo, datos, pasos y resultado esperado. Sin un resultado esperado claro, no podemos decidir con precisión si la prueba pasó o falló.
En algunos equipos existe un rol específico de QA o tester. En otros, los desarrolladores también escriben y ejecutan pruebas. En proyectos pequeños, una misma persona puede cumplir varias funciones.
Lo importante es entender que la calidad no pertenece a un único rol. Todo el equipo participa:
Un buen proceso de testing mejora cuando existe colaboración entre estos roles, no cuando se trabaja de forma aislada.
El testing es fundamental, pero tiene límites. Conviene conocerlos desde el inicio para no crear expectativas incorrectas:
Por estas razones, el testing profesional se apoya en prioridades, análisis de riesgo, comunicación clara y selección inteligente de casos de prueba.
El Testing de Software es una disciplina esencial para construir aplicaciones más confiables. Su propósito no es criticar el trabajo de otros ni buscar errores sin contexto, sino aportar información concreta sobre la calidad y los riesgos del producto.
Para quien comienza, la idea principal es esta: probar software significa observar el comportamiento de un sistema de manera planificada para comparar lo que hace con lo que debería hacer.
En los próximos temas avanzaremos sobre los motivos por los que probamos, las diferencias entre errores y defectos, los roles del equipo, los niveles de prueba, los tipos de testing y las técnicas básicas para diseñar casos de prueba útiles.