TAI
Tema

Pruebas de software para Oposiciones TAI: Guía Completa

📝 0 preguntas 📖 Teoría 🎯 Preparación TAI

💡 Qué aprenderás

En este tema estudiarás todos los conceptos necesarios para responder correctamente las preguntas relacionadas con Pruebas de software en la oposición.

¿Qué son las pruebas de software?

Las pruebas de software (Software Testing) son el conjunto de técnicas y procedimientos utilizados para verificar y validar que una aplicación funciona correctamente, cumple los requisitos especificados y está libre de errores críticos antes de su puesta en producción.

Su objetivo es detectar defectos, mejorar la calidad del software y reducir el riesgo de fallos durante su utilización.

📖 Definición
Las pruebas demuestran la presencia de errores, pero nunca pueden demostrar su ausencia total.

Objetivos de las pruebas

Las pruebas de software persiguen varios objetivos fundamentales:

  • Detectar defectos antes de la puesta en producción.
  • Verificar que se cumplen los requisitos funcionales y no funcionales.
  • Validar que el software satisface las necesidades del usuario.
  • Reducir los riesgos asociados a cambios o nuevas versiones.
  • Incrementar la calidad y fiabilidad del sistema.
🎯 Muy preguntado
Cuanto antes se detecta un error durante el desarrollo, menor es el coste de corregirlo.

Verificación y validación

Aunque suelen confundirse, son conceptos diferentes.

Concepto Pregunta que responde
Verificación ¿Estamos construyendo correctamente el producto?
Validación ¿Estamos construyendo el producto correcto?
  • Verificación: comprueba que el software cumple las especificaciones técnicas.
  • Validación: comprueba que satisface las necesidades del usuario.
💡 Consejo para el examen
Una forma sencilla de recordarlo es:

  • Verificación → Especificaciones.
  • Validación → Usuario.

Principios de las pruebas

Los principios fundamentales del testing son:

  • Las pruebas muestran la presencia de defectos, no su ausencia.
  • Es imposible realizar pruebas exhaustivas en aplicaciones complejas.
  • Las pruebas deben comenzar lo antes posible.
  • Los defectos suelen concentrarse en un número reducido de módulos.
  • Repetir siempre las mismas pruebas pierde eficacia con el tiempo.
  • Las pruebas deben adaptarse al contexto del proyecto.
🎯 Muy preguntado
La denominada Paradoja del pesticida indica que repetir continuamente las mismas pruebas deja de descubrir nuevos errores.

Niveles de prueba

Las pruebas se organizan en distintos niveles según el elemento evaluado.

Pruebas unitarias

Comprueban el funcionamiento de componentes individuales, como funciones o métodos.

Generalmente son desarrolladas por los programadores.

Objetivos

  • Detectar errores de lógica.
  • Verificar funciones individuales.
  • Facilitar el mantenimiento.

Herramientas habituales

  • JUnit.
  • NUnit.
  • PHPUnit.
  • PyTest.
💡 Consejo para el examen
Las pruebas unitarias son las más rápidas y económicas de ejecutar.

Pruebas de integración

Verifican que distintos módulos funcionan correctamente cuando interactúan entre sí.

Permiten detectar errores relacionados con:

  • Interfaces.
  • Comunicación entre componentes.
  • Intercambio de datos.
📌 Recuerda
Un módulo puede funcionar correctamente por separado y fallar al integrarse con otros.

Pruebas de sistema

Evalúan el sistema completo funcionando como una única aplicación.

Comprueban aspectos como:

  • Funcionalidad.
  • Rendimiento.
  • Seguridad.
  • Compatibilidad.
🎯 Muy preguntado
En este nivel se valida el comportamiento global del sistema.

Pruebas de aceptación

Son realizadas por el cliente o los usuarios finales para verificar que el software cumple sus necesidades.

Pueden ser:

  • Alfa.
  • Beta.
💡 Consejo para el examen
La aceptación determina si el software está preparado para entrar en producción.

Tipos de pruebas

Las pruebas pueden clasificarse según distintos criterios.

Pruebas funcionales

Comprueban que cada funcionalidad produce el resultado esperado.

Se basan en los requisitos del sistema.

Ejemplos:

  • Inicio de sesión.
  • Registro de usuarios.
  • Cálculo de impuestos.
  • Generación de informes.

Pruebas no funcionales

Evalúan características relacionadas con la calidad del sistema.

Entre ellas destacan:

  • Rendimiento.
  • Seguridad.
  • Escalabilidad.
  • Usabilidad.
  • Disponibilidad.
  • Compatibilidad.
🎯 Muy preguntado
Una aplicación puede ser funcionalmente correcta y, aun así, presentar un rendimiento inaceptable.

Técnicas de prueba

Caja negra (Black Box)

El tester desconoce el funcionamiento interno del programa.

Solo verifica:

  • Entradas.
  • Salidas.
  • Requisitos funcionales.
💡 Consejo para el examen
Se centra en qué hace el software.

Caja blanca (White Box)

El tester conoce el código fuente y la estructura interna.

Permite comprobar:

  • Cobertura de instrucciones.
  • Cobertura de ramas.
  • Cobertura de caminos.
💡 Consejo para el examen
Se centra en cómo está implementado el software.

Caja gris (Gray Box)

Combina características de la caja negra y la caja blanca.

El tester dispone de cierto conocimiento interno del sistema, pero realiza las pruebas desde la perspectiva del usuario.


Pruebas de regresión

Las pruebas de regresión verifican que una modificación no ha introducido errores en funcionalidades que anteriormente funcionaban correctamente.

Se ejecutan habitualmente:

  • Tras corregir un error.
  • Después de añadir nuevas funcionalidades.
  • Antes de publicar una nueva versión.
🎯 Muy preguntado
Son fundamentales en procesos de integración y despliegue continuos (CI/CD).

Automatización de pruebas

Consiste en ejecutar pruebas mediante herramientas software sin intervención manual.

Ventajas

  • Mayor rapidez.
  • Repetibilidad.
  • Reducción de errores humanos.
  • Integración con CI/CD.

Inconvenientes

  • Coste inicial elevado.
  • Necesidad de mantenimiento.
  • No todas las pruebas pueden automatizarse.

[!NOTE] Las pruebas exploratorias y de usabilidad suelen seguir realizándose manualmente.


Integración continua (CI)

La Integración Continua (Continuous Integration) consiste en integrar frecuentemente los cambios realizados por los desarrolladores.

Cada integración desencadena automáticamente:

  • Compilación.
  • Ejecución de pruebas.
  • Análisis de calidad.
  • Generación de informes.

Herramientas habituales:

  • Jenkins.
  • GitHub Actions.
  • GitLab CI.
  • Azure DevOps.
💡 Consejo para el examen
CI permite detectar errores poco después de introducirlos.

Comparación de niveles de prueba

Nivel Objetivo Responsable habitual
Unitaria Componentes individuales Desarrollador
Integración Comunicación entre módulos Desarrollo / QA
Sistema Aplicación completa QA
Aceptación Validación por el cliente Usuario / Cliente

Caso práctico

Situación

Una aplicación bancaria incorpora una nueva funcionalidad para realizar transferencias internacionales.

Solución

Antes de publicar la nueva versión se realizan:

  • Pruebas unitarias sobre el cálculo de comisiones.
  • Pruebas de integración entre la aplicación y el servicio bancario.
  • Pruebas de sistema para verificar el flujo completo.
  • Pruebas de regresión para comprobar que las transferencias nacionales siguen funcionando.
  • Pruebas de aceptación con usuarios del banco.
🎯 Muy preguntado
Ningún nivel de prueba sustituye a los demás; son complementarios.

Ventajas e inconvenientes

Ventajas

  • Mayor calidad del software.
  • Reducción de errores en producción.
  • Menor coste de mantenimiento.
  • Mayor confianza en las nuevas versiones.
  • Mejora de la satisfacción del usuario.

Inconvenientes

  • Incremento del tiempo de desarrollo.
  • Coste de automatización.
  • Necesidad de mantenimiento de los casos de prueba.
  • Imposibilidad de garantizar la ausencia total de errores.

Errores habituales

⚠️ Error habitual
Los errores más frecuentes relacionados con las pruebas de software son:
  • Confundir verificación con validación.
  • Pensar que las pruebas garantizan un software sin errores.
  • Confundir pruebas unitarias con pruebas de integración.
  • Creer que todas las pruebas pueden automatizarse.
  • No realizar pruebas de regresión tras una modificación.
  • Considerar las pruebas como la última fase del desarrollo.

Cómo evitarlos

  • Diferenciar claramente cada nivel de prueba.
  • Aplicar pruebas desde las primeras fases del desarrollo.
  • Automatizar las pruebas repetitivas.
  • Mantener actualizados los casos de prueba.
  • Integrar las pruebas en el ciclo de desarrollo continuo.

Relaciones con otros temas

Las pruebas de software están estrechamente relacionadas con:

  • Ingeniería del software.
  • Ciclo de vida del software.
  • Calidad del software.
  • Integración continua (CI).
  • Despliegue continuo (CD).
  • Gestión de versiones.
  • Control de cambios.
  • Metodologías ágiles.
  • DevOps.
📌 Recuerda
En exámenes es muy frecuente relacionar las pruebas de software con verificación, validación, pruebas unitarias, integración, regresión, caja negra, caja blanca e integración continua (CI).

Conceptos clave para recordar

[!NOTE]

  • Las pruebas de software permiten verificar y validar la calidad de una aplicación.
  • Verificación: comprueba que el software cumple las especificaciones.
  • Validación: comprueba que satisface las necesidades del usuario.
  • Las pruebas muestran la presencia de errores, no su ausencia.
  • Los principales niveles son: unitarias, integración, sistema y aceptación.
  • Las técnicas más habituales son: caja negra, caja blanca y caja gris.
  • Las pruebas de regresión verifican que los cambios no rompen funcionalidades existentes.
  • La automatización de pruebas es un elemento clave en los procesos CI/CD.
  • Una estrategia de pruebas eficaz combina pruebas manuales y automatizadas.

📝 Preguntas de ejemplo

Comprueba si reconoces este tipo de preguntas.

¿Has terminado de estudiar?

Ahora pon a prueba tus conocimientos realizando el test completo de este tema.

Comenzar test

Utilizamos cookies

Utilizamos cookies analíticas para conocer el uso de la plataforma y mejorar la experiencia del usuario. Puedes aceptar o rechazarlas en cualquier momento. Más información en nuestra Política de Cookies .