El aseguramiento de la calidad es cada vez más popular. Los expertos estiman que los empleos de pruebas en Estados Unidos por sí solos aumentarán un 25% en la próxima década. Si esto te interesa, quizá te preguntes por dónde empezar a aprender sobre las pruebas de software.
En este artículo responderé preguntas para ayudarte a comenzar con las pruebas de software. Revisaré qué son las pruebas de software, los conceptos de pruebas más importantes y algunas herramientas de pruebas de software que puedes considerar.
Explicación de las pruebas de software
El proceso compuesto por todas las actividades del ciclo de vida, tanto estáticas como dinámicas, relacionadas con la planificación, preparación y evaluación de un componente o sistema, así como de los productos de trabajo relacionados, para determinar que cumplen los requisitos especificados, demostrar que son adecuados para su propósito y detectar defectos.
glosario de ISTQB
Las pruebas de software desempeñan un papel importante en el proceso de desarrollo de software, ya que validan que las funciones de la aplicación de software se ejecuten según lo previsto y cumplan los requisitos y las expectativas de los usuarios finales.
El objetivo es identificar defectos, errores e inconsistencias en la aplicación de software antes de que se lance al público. Las pruebas implican ejecutar el software en diferentes condiciones, configuraciones y escenarios para garantizar que funcione de forma correcta y eficiente.
Si tienes curiosidad por saber cómo comenzar en el campo de las pruebas de software, aquí tienes una lista de preguntas frecuentes de entrevistas de QA (¡y respuestas!).
Ciclo de vida de las pruebas de software
El ciclo de vida de las pruebas de software (STLC) es el proceso que siguen los probadores de software para garantizar que la aplicación sometida a pruebas cumpla los estándares y requisitos de calidad especificados. El STLC normalmente consta de varias fases diseñadas para garantizar que la aplicación de software se pruebe exhaustivamente y alcance el nivel de calidad deseado antes de entregarse a los usuarios finales. Estas son las fases del ciclo de vida de las pruebas de software:

Análisis de requisitos
En esta fase, los probadores de software analizan los requisitos y las especificaciones. Identifican los requisitos funcionales y no funcionales, comprenden el propósito de la aplicación de software y el público objetivo, y desarrollan casos y escenarios de prueba en consecuencia.
Planificación de las pruebas
En esta fase, el equipo de pruebas identifica el alcance de las pruebas, el enfoque de pruebas y los recursos necesarios para realizarlas. El plan de pruebas también identifica los riesgos y las limitaciones asociados con el proceso de pruebas y establece el calendario de pruebas.
Diseño de las pruebas
En esta fase, el equipo de pruebas diseña los casos y escenarios de prueba basándose en los requisitos y las especificaciones. También identifica los datos de prueba necesarios y desarrolla secuencias de comandos de prueba que automatizan el proceso de pruebas.
Ejecución de las pruebas
Los probadores ejecutan los casos y escenarios de prueba diseñados en la fase anterior. Se documentan los resultados de las pruebas y se informa de cualquier defecto o error encontrado en la aplicación de software.
Informes de pruebas
En esta fase, el equipo de pruebas prepara un informe con los resultados de las pruebas y los defectos identificados durante estas. El informe puede incluir sus recomendaciones para corregir los defectos y mejorar la calidad general de la aplicación de software.
Cierre de las pruebas
Es la última fase, en la que el equipo de pruebas evalúa el proceso de pruebas e identifica áreas de mejora. También prepara un informe de cierre de pruebas que resume el proceso y los resultados de las pruebas.
El ciclo de vida de las pruebas de software es un proceso continuo que requiere la colaboración entre el equipo de pruebas y el equipo de desarrollo para garantizar que la aplicación de software alcance el nivel deseado de calidad y funcionalidad.
Tipos de pruebas de software
Existen diferentes tipos de pruebas de software utilizados por los equipos de control de calidad, dependiendo del contexto y los requisitos del proyecto.
Podemos distinguir entre las pruebas manuales y las pruebas automatizadas, dependiendo de cómo se ejecutan las pruebas. Según lo que se está probando, podemos diferenciar entre pruebas funcionales y no funcionales. Dependiendo de los métodos utilizados, tenemos pruebas estáticas y dinámicas. Según el enfoque, podemos identificar los tipos de pruebas de caja blanca y caja negra. También tenemos pruebas exploratorias, pruebas de humo y de verificación rápida, y pruebas de regresión. Todos estos tipos de pruebas pueden solaparse entre sí, dependiendo de cómo se utilicen.
Pruebas manuales
En las pruebas manuales, las pruebas se realizan personalmente, sin utilizar herramientas ni scripts automatizados. Pueden ser más propensas a errores y normalmente requieren más tiempo.
Pruebas automatizadas
Las pruebas automatizadas son realizadas por una máquina que ejecuta scripts escritos previamente. Requieren más conocimientos técnicos, por ejemplo, conocimientos de un lenguaje de programación y de herramientas de automatización como Selenium. Pueden ser más costosas que las pruebas manuales, y ciertos aspectos del proceso de pruebas no pueden automatizarse.
Pruebas funcionales
Las pruebas funcionales consisten en verificar qué hace la aplicación. Las pruebas funcionales comprueban las características y capacidades de la aplicación de software y garantizan que cumplan los requisitos y las especificaciones.
Pruebas no funcionales
A diferencia de las pruebas funcionales, las pruebas no funcionales se centran en cómo se comporta la aplicación. Existen múltiples subtipos de pruebas no funcionales, dependiendo de cuál sea el objetivo principal de las pruebas. En este artículo solo cubriré algunos de ellos.
Pruebas de rendimiento: Miden el tiempo de respuesta, el rendimiento y la escalabilidad de la aplicación de software bajo diversas condiciones de carga. Comprueban la capacidad de la aplicación de software para gestionar varios usuarios y transacciones simultáneamente y garantizan que funcione de manera eficiente en condiciones de carga máxima.
Pruebas de carga: Simulan cargas de usuarios del mundo real y se realizan para determinar el comportamiento de un sistema en condiciones normales y máximas. Se utilizan para identificar si la infraestructura empleada para alojar la aplicación es suficiente y nos indican cuántos usuarios simultáneos puede gestionar la aplicación y la escala de aplicación necesaria en términos de hardware, capacidad de red, etc., para que más usuarios puedan acceder a ella.
Pruebas de estrés: Consisten en realizar pruebas más allá de la capacidad normal, a menudo hasta alcanzar un punto de ruptura, para observar los resultados. El objetivo es garantizar que el software no se bloquee en condiciones de recursos computacionales insuficientes, como memoria, espacio en disco, solicitudes de red, etc.
Pruebas de seguridad: Garantizan que la aplicación de software sea segura y esté protegida frente al acceso no autorizado. Las pruebas de seguridad buscan vulnerabilidades y debilidades en los protocolos de seguridad de la aplicación de software e identifican posibles amenazas de seguridad.
Pruebas de usabilidad: Se utilizan para evaluar si la aplicación es fácil de usar. Comprueban lo sencillo que resulta para los usuarios navegar por la aplicación de software y realizar las funciones previstas de manera eficiente.
Pruebas de accesibilidad: Consideradas un subconjunto de las pruebas de usabilidad, las pruebas de accesibilidad se realizan para garantizar que la aplicación sometida a prueba pueda ser utilizada por personas con discapacidades.
Pruebas de localización: Tipo de prueba de software en el que se comprueba el comportamiento del software para una región, localidad o cultura específicas. Algunos atributos que deben tenerse en cuenta durante las pruebas de localización son: texto correctamente traducido, moneda, unidades de medida, caracteres especiales permitidos y formatos de números de teléfono.
Pruebas de compatibilidad: Comprueban si la aplicación es suficientemente competente para ejecutarse en diferentes navegadores, bases de datos, hardware, sistemas operativos, dispositivos móviles y redes.
Pruebas estáticas y pruebas dinámicas
Las pruebas estáticas se basan en el examen manual de productos de trabajo, es decir, en revisiones, o en la evaluación del código y de otros productos de trabajo mediante herramientas, como el análisis estático. Pueden realizarse sobre, entre otros elementos, especificaciones, requisitos empresariales, criterios de aceptación, código fuente, planes de pruebas, casos de prueba, scripts de prueba y guías de usuario.
Las pruebas dinámicas consisten en la ejecución real del software que se está probando. Pueden ser manuales o automatizadas, o una combinación de ambas.
Pruebas de caja blanca y pruebas de caja negra
Las pruebas de caja blanca son un tipo de prueba en el que el probador conoce la estructura interna del código de la aplicación, mientras que las pruebas de caja negra se realizan sin necesidad de comprender el código fuente. Cada uno de estos tipos de pruebas aplica diferentes técnicas de prueba, como la partición de equivalencias, el análisis de valores límite y la tabla de decisión para las pruebas de caja negra, y la cobertura de sentencias y la cobertura de decisiones para las pruebas de caja blanca.
Pruebas exploratorias
Las pruebas exploratorias son un tipo de prueba basada en la experiencia. Implican una planificación mínima y una ejecución máxima de las pruebas.
Las actividades de diseño y ejecución de las pruebas se realizan en paralelo, normalmente sin documentar formalmente las condiciones de prueba, los casos de prueba ni los scripts de prueba.
Es un enfoque útil cuando no existen especificaciones o estas son deficientes y el tiempo es muy limitado, o funciona muy bien como complemento de las pruebas automatizadas.
Pruebas de humo
Las pruebas de humo, a veces llamadas «pruebas de verificación de compilación» o «pruebas de confianza», son un proceso de pruebas de software en el que los probadores verifican si la compilación implementada es estable. Las pruebas de humo validan que se puede continuar con otras pruebas de software. Consisten en un número mínimo de pruebas que se ejecutan con cada compilación para comprobar las funcionalidades críticas del software.
Pruebas de integridad
Las pruebas de integridad son un tipo de prueba de software que se realiza después de entregar una compilación de software con modificaciones menores en el código o las funcionalidades, con el fin de confirmar que se han resuelto los errores y que no se han introducido nuevos problemas debido a estos cambios. El objetivo es confirmar que la funcionalidad propuesta funciona aproximadamente como se espera.
Pruebas de regresión
Las pruebas de regresión son un tipo de prueba de software en el que se vuelven a probar las funcionalidades existentes para validar que siguen funcionando correctamente después de cualquier cambio o actualización en la aplicación de software. Las pruebas de regresión garantizan que los nuevos cambios o actualizaciones no hayan afectado a la funcionalidad existente de la aplicación de software.
Pruebas de compatibilidad
Las pruebas de compatibilidad se utilizan para garantizar que la aplicación de software funcione correctamente en distintas plataformas, dispositivos y navegadores. Comprueban que la aplicación de software sea compatible con diversas configuraciones de hardware y software

Niveles de prueba
Las pruebas de software se pueden clasificar en distintos niveles según el alcance y los objetivos de las pruebas. A continuación se presentan los niveles habituales de las pruebas de software:
Pruebas unitarias
Las pruebas unitarias son el primer nivel de pruebas y se centran en probar componentes individuales o unidades de código de forma aislada. Las pruebas unitarias verifican que cada unidad de código funcione como se espera y cumpla los requisitos especificados.
Pruebas de integración
Las pruebas de integración se centran en probar las interacciones entre los distintos módulos o componentes de la aplicación de software. Las pruebas de integración verifican que los módulos o componentes funcionen conjuntamente según lo previsto y cumplan los requisitos especificados.
Pruebas del sistema
Las pruebas del sistema son el nivel de pruebas en el que se prueba toda la aplicación de software como un sistema completo. Las pruebas del sistema verifican que la aplicación de software cumpla los requisitos especificados y funcione como se espera en distintos escenarios.
Pruebas de aceptación del usuario
Las pruebas de aceptación son el nivel de pruebas en el que la aplicación de software se prueba desde la perspectiva del usuario final. Las pruebas de aceptación verifican que la aplicación de software satisfaga las necesidades y los requisitos del usuario final y funcione como se espera en el entorno del usuario. Los tipos habituales de pruebas de aceptación del usuario son las pruebas alfa y las pruebas beta.
Cada nivel de pruebas es importante y cumple un propósito específico en el proceso de pruebas de software. Las pruebas deben realizarse en cada nivel para garantizar que la aplicación de software alcance el nivel deseado de calidad y funcionalidad y funcione como se espera en distintos escenarios.
Principios de las pruebas de software
Existen siete principios principales de las pruebas, tal como los define ISTQB:
- Las pruebas demuestran la presencia de defectos, no su ausencia: No se puede garantizar que la aplicación esté libre de defectos simplemente porque se haya probado. Sin embargo, después de las pruebas, puede aumentar la confianza en el producto.
- Las pruebas exhaustivas son imposibles: La mayoría de las aplicaciones son increíblemente complejas, por lo que probar cada combinación y variación posible es imposible, especialmente porque el tiempo y los recursos destinados a las pruebas también son limitados.
- Pruebas tempranas: Cuanto antes se descubran los errores y defectos durante el ciclo de vida del desarrollo de software, más fácil será corregirlos. Ahí es donde Agile acierta, ya que las actividades de prueba comienzan desde una etapa muy temprana.
- Los defectos se concentran: Esto significa que las áreas en las que se encontraron defectos probablemente tendrán aún más defectos. Según el principio de Pareto, el 80 % de los defectos puede encontrarse en el 20 % de las funcionalidades.
- La paradoja del pesticida: Ejecutar las mismas pruebas repetidamente sin actualizarlas probablemente no descubrirá ningún problema nuevo.
- Las pruebas dependen del contexto: Las aplicaciones se probarán de forma diferente según su contexto; por ejemplo, se prueba una API de forma diferente a una interfaz de usuario, y las aplicaciones web se prueban de forma diferente a las aplicaciones móviles o de escritorio.
- Falacia de la ausencia de errores: En resumen, el hecho de que se hayan encontrado y corregido los defectos no significa que el software sea útil para sus usuarios.
Conclusión
Las pruebas de software son un ámbito muy complejo y se pueden ejecutar muchos tipos de pruebas. Es importante adaptar la estrategia de pruebas según el contexto del producto de software que se está probando. Existen infinitos recursos sobre las pruebas de software, incluidos pódcast, libros y mucho más.
Si disfrutaste de este artículo, suscríbete al boletín del responsable de QA y sé el primero en enterarte de las nuevas publicaciones sobre pruebas y calidad.
