Skip to main content

El aseguramiento de la calidad está ganando cada vez más popularidad. Los expertos estiman que los empleos en testing en EE. UU. aumentarán un 25% en la próxima década. Si te interesa, quizás te preguntes por dónde empezar a aprender sobre pruebas de software.

En este artículo responderé preguntas para ayudarte a comenzar en el mundo de las pruebas de software. Revisaré qué son las pruebas de software, los conceptos más importantes sobre testing y algunas herramientas de pruebas de software que deberías considerar. 

Pruebas de Software Explicadas

El proceso que consiste en 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 y los productos de trabajo asociados, para determinar que cumplen con los requisitos especificados, demostrar que son aptos para el propósito y detectar defectos.

Glosario de ISTQB

Las pruebas de software juegan un papel fundamental en el proceso de desarrollo de software, ya que validan que la aplicación funcione como se espera y cumpla con los requisitos y expectativas de los usuarios finales.

Want more from The CTO Club?

Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.

Este campo es un campo de validación y debe quedar sin cambios.
Name*

El objetivo es identificar defectos, errores e inconsistencias en la aplicación antes de su lanzamiento al público. Las pruebas implican ejecutar el software en diferentes condiciones, configuraciones y escenarios para asegurar que funcione correcta y eficientemente.

Si tienes curiosidad sobre cómo comenzar en el área de pruebas de software, aquí tienes una lista de preguntas comunes de entrevistas de QA (¡y respuestas!).

Ciclo de Vida de las Pruebas de Software

El ciclo de vida de las pruebas de software (STLC, por sus siglas en inglés) es el proceso que siguen los evaluadores de software para asegurarse de que la aplicación cumple con los estándares y requisitos de calidad especificados. Generalmente, el STLC se compone de varias fases diseñadas para garantizar que la aplicación sea rigurosamente evaluada y alcance el nivel de calidad deseado antes de llegar 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 evaluadores de software analizan los requisitos y especificaciones. Identifican los requisitos funcionales y no funcionales, comprenden el propósito de la aplicación y su público objetivo, y desarrollan casos y escenarios de prueba en consecuencia.

Planificación de Pruebas

En esta fase, el equipo de testing identifica el alcance de las pruebas, el enfoque a seguir y los recursos necesarios. El plan de pruebas también define los riesgos y restricciones del proceso y establece la línea de tiempo de las pruebas.

Diseño de Pruebas

En esta etapa, el equipo de pruebas diseña los casos y escenarios de prueba basándose en los requisitos y especificaciones. Asimismo, identifican los datos de prueba necesarios y desarrollan scripts para automatizar el proceso de testing.

Ejecución de Pruebas

Los evaluadores ejecutan los casos y escenarios de prueba diseñados en la fase anterior. Los resultados de las pruebas se documentan y cualquier defecto o error encontrado en la aplicación se reporta.

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Este campo es un campo de validación y debe quedar sin cambios.
Name*

Reporte de Pruebas

En esta fase, el equipo de testing elabora un informe con los resultados y los defectos identificados durante las pruebas. El reporte puede incluir recomendaciones para solucionar los defectos y mejorar la calidad global de la aplicación.

Cierre de Pruebas

Es la última fase, en la que el equipo de pruebas evalúa el proceso de testing e identifica áreas de mejora. También preparan un informe de cierre de pruebas que resume el proceso e incluye los resultados obtenidos.

El ciclo de vida de las pruebas de software es un proceso continuo que exige colaboración entre el equipo de testing y el de desarrollo para asegurar que la aplicación logre el nivel de calidad y funcionalidad deseado.

Tipos de Pruebas de Software 

Existen distintos tipos de pruebas de software que utiliza el equipo de QA según el contexto y los requisitos del proyecto.

Podemos distinguir entre pruebas manuales y automatizadas, dependiendo de cómo se ejecuten las pruebas. Según lo que se prueba, 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 existen pruebas exploratorias, pruebas de humo y pruebas de cordura, y pruebas de regresión. Todos estos tipos de pruebas pueden solaparse entre sí, dependiendo de cómo se utilicen. 

Pruebas Manuales

Con las pruebas manuales, las pruebas se realizan en persona, sin utilizar herramientas o scripts automatizados. Suelen ser más propensas a errores y generalmente requieren más tiempo. 

Pruebas Automatizadas

Las pruebas automatizadas se realizan mediante una máquina que ejecuta scripts escritos previamente. Requiere mayor conocimiento técnico, por ejemplo, conocimiento de un lenguaje de programación y herramientas de automatización como Selenium. Puede ser más costoso que las pruebas manuales y ciertos aspectos del proceso de pruebas no se pueden automatizar.

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 aseguran que cumplan con los requisitos y especificaciones.

Pruebas No Funcionales

A diferencia de las pruebas funcionales, las pruebas no funcionales se centran en cómo se comporta la aplicación. Hay varios subtipos de pruebas no funcionales, dependiendo de cuál sea el objetivo principal de las pruebas. En este artículo sólo cubriré algunas de ellas. 

Pruebas de Rendimiento: Miden el tiempo de respuesta, la capacidad de procesamiento y la escalabilidad de la aplicación de software bajo diferentes condiciones de carga. Verifican la capacidad de la aplicación para manejar varios usuarios y transacciones simultáneamente y aseguran que funcione eficientemente bajo condiciones de carga máxima.

Pruebas de Carga: Simulan cargas de usuarios reales y se realizan para determinar el comportamiento de un sistema en condiciones normales y pico. Se usan para identificar si la infraestructura utilizada para alojar la aplicación es suficiente y nos indica cuántos usuarios simultáneos puede soportar la aplicación y la escala que se requiere en términos de hardware, capacidad de red, etc. para que más usuarios puedan acceder a la aplicación.

Pruebas de Estrés: Implican probar más allá de la capacidad normal, a menudo hasta el punto de ruptura, para observar los resultados. El objetivo es asegurar que el software no se bloquee en condiciones de recursos computacionales insuficientes (como memoria, espacio en disco, solicitudes de red, etc).

Pruebas de Seguridad: Asegura que la aplicación de software sea segura y esté protegida contra accesos no autorizados. Las pruebas de seguridad buscan vulnerabilidades y debilidades en los protocolos de seguridad de la aplicación e identifican posibles amenazas de seguridad.

Pruebas de Usabilidad: Se utilizan para evaluar si la aplicación es fácil de usar para los usuarios. Verifican la facilidad con la que los usuarios pueden 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 asegurar que la aplicación probada sea usable por personas con discapacidad.

Pruebas de Localización: Un tipo de pruebas de software en las que se testea el comportamiento de una aplicación para una región, localización o cultura específica. Algunos atributos a considerar durante las pruebas de localización: 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 lo suficientemente eficiente para ejecutarse en diferentes navegadores, bases de datos, hardware, sistemas operativos, dispositivos móviles y redes.

Pruebas Estáticas y Dinámicas

Pruebas estáticas se basan en el examen manual de los productos de trabajo (es decir, revisiones) o en la evaluación asistida por herramientas del código (como revisiones de código) u otros productos (por ejemplo, análisis estático). Se pueden realizar sobre (pero no se limitan a) especificaciones, requisitos de negocio, criterios de aceptación, código fuente, planes de pruebas, casos de prueba, scripts de pruebas y guías de usuario. 

Pruebas dinámicas corresponden a la ejecución real del software que se está probando. Pueden ser manuales o automatizadas, o

Pruebas de Caja Blanca y Caja Negra 

Las pruebas de caja blanca son un tipo de prueba en las que el evaluador conoce la estructura interna del código de la aplicación, mientras que las pruebas de caja negra se realizan sin necesidad de entender el código fuente. Cada uno de estos tipos aplica técnicas de pruebas diferentes, como partición de equivalencias, análisis de valores límite y tablas de decisión para caja negra, y cobertura de sentencias más cobertura de decisiones para caja blanca.

Pruebas Exploratorias

Las pruebas exploratorias son un tipo de pruebas basadas en la experiencia. Involucran una planificación mínima y la máxima ejecución de pruebas. 

Las actividades de diseño y ejecución de pruebas se realizan en paralelo, normalmente sin documentar formalmente las condiciones de prueba, los casos de prueba o los scripts de prueba.

Es un enfoque útil cuando las especificaciones son nulas o deficientes y el tiempo es muy limitado, o funciona muy bien como complemento a las pruebas automatizadas.

Pruebas de humo 

Las Pruebas de Humo, a veces llamadas "Verificación de Construcción" o "Pruebas de Confianza", son un proceso de prueba de software donde los evaluadores verifican si la versión desplegada es estable. La prueba de humo es una validación para comprobar si se puede proceder con pruebas de software adicionales. Consta de una cantidad mínima de pruebas que se ejecutan en cada versión para comprobar funcionalidades críticas del software. 

Pruebas de cordura

Las pruebas de cordura son un tipo de prueba de software que se realiza tras la entrega de una versión con modificaciones menores de código o funciones, para confirmar que los errores se han resuelto y que no se han introducido nuevos problemas a raíz de estos cambios. El objetivo es confirmar que la funcionalidad propuesta trabaja más o menos como se espera.

Pruebas de regresión

Las pruebas de regresión son un tipo de prueba de software en la que se vuelven a probar funcionalidades existentes para validar que siguen funcionando correctamente después de los cambios o actualizaciones en la aplicación de software. Las pruebas de regresión aseguran que las nuevas modificaciones o actualizaciones no han afectado la funcionalidad existente de la aplicación.

Pruebas de compatibilidad

Las pruebas de compatibilidad se utilizan para garantizar que la aplicación de software funciona correctamente en diferentes plataformas, dispositivos y navegadores. Se verifica que la aplicación sea compatible con diversas configuraciones de hardware y software.

Imagen generada por IA de robots trabajando en una línea de ensamblaje para demostrar cómo funcionan las pruebas de software.

Niveles de prueba

Las pruebas de software pueden categorizarse en diferentes niveles según el alcance y los objetivos de la prueba. Los siguientes son los niveles más comunes de pruebas de software:

Pruebas unitarias

Las pruebas unitarias son el primer nivel de prueba y se centran en probar componentes individuales o unidades de código en aislamiento. Estas pruebas verifican que cada unidad de código funcione según lo esperado y cumpla los requisitos especificados.

Pruebas de integración

Las pruebas de integración se centran en comprobar las interacciones entre los distintos módulos o componentes de la aplicación de software. Estas pruebas verifican que los módulos o componentes trabajen juntos como se espera y cumplan los requisitos especificados.

Pruebas de sistema

Las pruebas de sistema son el nivel en el que se prueba la aplicación completa como un sistema total. Este nivel de prueba verifica que la aplicación de software cumpla los requisitos especificados y funcione como se espera en diversos escenarios.

Pruebas de aceptación del usuario

Las pruebas de aceptación son el nivel en el que la aplicación se evalúa desde la perspectiva del usuario final. Estas pruebas verifican que la aplicación de software satisfaga las necesidades y requisitos del usuario final y funcione según lo esperado en el entorno de usuario. Los tipos de pruebas de aceptación más comunes son las pruebas alfa y las pruebas beta.

Cada nivel de pruebas es importante y cumple un propósito específico dentro del proceso de pruebas de software. Las pruebas deben realizarse en cada nivel para asegurar que la aplicación de software cumple con el nivel de calidad y funcionalidad deseados, y que funciona correctamente en distintos escenarios. 

Principios de las pruebas de software

Hay siete principios principales de las pruebas, tal como los define el ISTQB:

  1. Las pruebas muestran la presencia de defectos, no su ausencia: No se puede garantizar que una aplicación esté libre de defectos solo porque haya sido probada. Sin embargo, después de las pruebas, la confianza en el producto puede aumentar.
  2. 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 para las pruebas también son limitados.
  3. Pruebas tempranas: Cuanto antes se descubran los errores y defectos durante el ciclo de vida de desarrollo del software, más fácil será corregirlos. Ahí es donde Agile acierta, ya que las actividades de prueba comienzan muy temprano.
  4. Los defectos tienden a agruparse: Esto significa que las áreas donde se encuentren defectos probablemente tengan aún más defectos. Según el principio de Pareto, el 80% de los defectos se pueden encontrar en el 20% de las funcionalidades.
  5. La paradoja del pesticida: Ejecutar las mismas pruebas repetidamente sin actualizarlas probablemente no descubra nuevos problemas. 
  6. Las pruebas son dependientes del contexto: Las aplicaciones se probarán de manera diferente según su contexto; por ejemplo, se prueba una API distinto a una interfaz de usuario, y se prueban aplicaciones web de manera diferente a aplicaciones móviles o de escritorio.  
  7. Falacia de la ausencia de errores: En resumen, 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 dominio muy complejo, y se pueden ejecutar muchos tipos de pruebas. Es importante adaptar tu estrategia de pruebas según el contexto del producto de software que se está probando. Existen infinidad de recursos sobre pruebas de software, incluidos podcasts, libros y más.

Si disfrutaste este artículo, por favor suscríbete al newsletter del QA Lead y sé el primero en enterarte de nuevos artículos sobre pruebas y calidad.