Tipos de pruebas de software explicados

Curso de Fundamentos de Pruebas de Software

Contenido del curso

Introducción

1
Fundamentos de testing moderno para mejorar software
01:19 min

Principios de las pruebas

Testing

Gestión, monitoreo y control

Gestión de bugs

Depuración

Bases de la automatización de pruebas

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:004:42

Tipos de pruebas de software explicados

Curso de Fundamentos de Pruebas de Software

Clase 13 de 29

Clase 13 / 29

Recursos

Domina los tipos de pruebas de software con un enfoque claro y práctico: diferencia niveles de pruebas y tipos, alinea objetivos y selecciona técnicas que descubran defectos con eficiencia. Aquí se explican con claridad las pruebas funcionales, no funcionales, estructurales y el manejo de cambios, conectándolas con escenarios reales y decisiones de cobertura.

¿Qué son los tipos de pruebas de software y por qué importan?

Los tipos de pruebas clasifican las actividades de validación según su objetivo, independientemente de la profundidad o nivel. Son las técnicas que se emplean para encontrar defectos y verificar que el producto cumple lo esperado, ya sea por seguridad, performance, funcionalidad o despliegue en una nueva plataforma.

Clasificación basada en objetivos.
Técnicas independientes de la profundidad.
Enfoque en detectar defectos de forma efectiva.
Consideran seguridad, performance, funcionalidad y plataforma.
Se alinean con las estrategias de pruebas.

¿Cómo se relacionan niveles y tipos de prueba?

Los niveles describen la profundidad (componente, integración, sistema). Los tipos definen la técnica aplicada. Se combinan según el impacto del cambio o del defecto.

Nivel de componente.
Nivel de integración.
Nivel de sistema.
Pruebas de regresión que pueden abarcar todo el flujo cuando un cambio impacta múltiples componentes.

¿Cómo se definen las pruebas funcionales y no funcionales?

Las pruebas funcionales validan lo que el sistema debe hacer y cómo interactúa la persona usuaria. Se comprueba que las funciones operen según el diseño y los requisitos, sin importar cómo está construido internamente.

¿Qué valida una prueba funcional en una aplicación?

Ingresar y ver datos correctamente.
Hacer clic en botones para enviar formularios.
Acciones de siguiente y volver.
Interacción con checkboxes.
Que “pueda funcionar” de extremo a extremo según la especificación.

¿Qué cubren las pruebas no funcionales?

Evalúan la experiencia más allá de que “funcione”. Incluyen usabilidad, accesibilidad, aspectos visuales y performance. Aunque una función responda, puede percibirse lenta o poco usable, y debe considerarse la interacción de personas que no leen o no ven.

Usabilidad: facilidad de uso y aprendizaje.
Accesibilidad: interacción inclusiva para distintas capacidades.
Visual: consistencia y legibilidad de la interfaz.
Performance: tiempos de respuesta y fluidez percibida.

¿Qué aportan las pruebas estructurales y el manejo de cambios?

Las pruebas estructurales se centran en la tecnología y el stack del producto: base de datos, servidor y la correcta configuración para las necesidades del sistema. Complementan a las funcionales y no funcionales al inspeccionar cómo está armado el software.

¿Por qué se les conoce como caja blanca o caja negra?

Las estructurales son de caja blanca: se observa lo que hay dentro del software y su construcción. Las funcionales y no funcionales son de caja negra: no es necesario conocer la arquitectura para validar el comportamiento y la experiencia.

¿Cómo organizar pruebas ante cambios y defectos?

El manejo de cambios incluye volver a revisar el software tras arreglar un defecto y ejecutar pruebas de regresión cuando una modificación puede afectar componentes o el flujo completo. Esta organización puede combinar tipos y niveles.

Revisión después de corregir un defecto.
Pruebas de regresión para asegurar que “todo sigue funcionando” tras cambios.
Ejecución en front-end, back-end o estructura según el impacto.
Cobertura en niveles: componente, integración y sistema.

Comparte en comentarios cómo organizas tus pruebas por tipo y qué criterios usas para decidir entre pruebas funcionales, no funcionales, estructurales o de regresión.

Mario Alexander Vargas Celis

Hace 2 años

Los diferente tipos de pruebas

1. Pruebas unitarias

Las pruebas unitarias son de muy bajo nivel y se realizan cerca de la fuente de la aplicación. Consisten en probar métodos y funciones individuales de las clases, componentes o módulos que usa tu software. En general, las pruebas unitarias son bastante baratas de automatizar y se pueden ejecutar rápidamente mediante un servidor de integración continua.

2. Pruebas de integración

Las pruebas de integración verifican que los distintos módulos o servicios utilizados por tu aplicación funcionan bien en conjunto. Por ejemplo, se puede probar la interacción con la base de datos o asegurarse de que los microservicios funcionan bien en conjunto y según lo esperado. Estos tipos de pruebas son más costosos de ejecutar, ya que requieren que varias partes de la aplicación estén en marcha.

3. Pruebas funcionales

Las pruebas funcionales se centran en los requisitos empresariales de una aplicación. Solo verifican el resultado de una acción y no comprueban los estados intermedios del sistema al realizar dicha acción.

A veces, se confunden las pruebas de integración con las funcionales, ya que ambas requieren que varios componentes interactúen entre sí. La diferencia es que una prueba de integración puede simplemente verificar que puedes hacer consultas en la base de datos, mientras que una prueba funcional esperaría obtener un valor específico desde la base de datos, según dicten los requisitos del producto.

4. Pruebas de extremo a extremo

Las pruebas integrales replican el comportamiento de un usuario con el software en un entorno de aplicación completo. Además, verifican que diversos flujos de usuario funcionen según lo previsto, y pueden ser tan sencillos como cargar una página web o iniciar sesión, o mucho más complejos, como la verificación de notificaciones de correo electrónico, pagos en línea, etc.

Las pruebas integrales son muy útiles, pero son costosas de llevar a cabo y pueden resultar difíciles de mantener cuando están automatizadas. Se recomienda tener algunas pruebas integrales clave y depender más de pruebas de menor nivel (unitarias y de integración) para poder detectar rápidamente nuevos cambios.

5. Pruebas de aceptación

Las pruebas de aceptación son pruebas formales que verifican si un sistema satisface los requisitos empresariales. Requieren que se esté ejecutando toda la aplicación durante las pruebas y se centran en replicar las conductas de los usuarios. Sin embargo, también pueden ir más allá y medir el rendimiento del sistema y rechazar cambios si no se han cumplido determinados objetivos.

6. Pruebas de rendimiento

Las pruebas de rendimiento evalúan el rendimiento de un sistema con una carga de trabajo determinada. Ayudan a medir la fiabilidad, la velocidad, la escalabilidad y la capacidad de respuesta de una aplicación. Por ejemplo, una prueba de rendimiento puede analizar los tiempos de respuesta al ejecutar un gran número de solicitudes, o cómo se comporta el sistema con una cantidad significativa de datos. Puede determinar si una aplicación cumple con los requisitos de rendimiento, localizar cuellos de botella, medir la estabilidad durante los picos de tráfico y mucho más.

7. Pruebas de humo

Las pruebas de humo son pruebas básicas que sirven para comprobar el funcionamiento básico de la aplicación. Están concebidas para ejecutarse rápidamente, y su objetivo es ofrecerte la seguridad de que las principales funciones de tu sistema funcionan según lo previsto.

Las pruebas de humo pueden resultar útiles justo después de realizar una compilación nueva para decidir si se pueden ejecutar o no pruebas más caras, o inmediatamente después de una implementación para asegurarse de que la aplicación funciona correctamente en el entorno que se acaba de implementar.

Comentarios (69)69 comentarios

Antonio Demarco Bonino

Hace 6 años

Nazareno Hernan Fagalde

Hace 5 años

Mauricio Enrique Fernandez Lopez

Hace 4 años

Irving Juárez

Carmen Álvarez M.

Kelly Merly Paucar Cahua

Jaime Andres Valencia Gaviria

Rodolfo Briseño Rodríguez

Gustavo Hernan Tiseira

Hace 7 años

Cristian Blandon

Juan Pablo Perez

Jose Montoya

Samir Jimenez Vivas

Hace 3 años

Luzdelia Alba

Hace 8 años

Rene Andres Alfaro Torres

Antonio Rafael González Ferrer

Angela Silva

Luis Hernando Muete García

Ronald Riera Sanchez

JUAN FELIPE CONTRERAS DELGADO

Erick Jiménez del Río

Miguel Angel Reina Walteros

Lady Laura Herrera

Usuario anónimo

User

Erika Lorena Ortiz Aponte

Sandra Castro Ballesteros

Antonio Gil

Politecno Software

Victor Gonzalez

Paolo Carrion

Paula Andrea Lozano Mahecha

Richard Acosta

Andrea Judit Parkhurst Casas

Giuseppe Ramirez

Javier Avila

Introducción

Fundamentos de testing moderno para mejorar software

Principios de las pruebas

Por qué el testing moderno previene errores

Pruebas de software en cada etapa del desarrollo

Pruebas en el Ciclo de Vida del Software: Mejora y Optimización

Anomalía vs defecto vs fallo vs error

Los siete principios del testing moderno

Roles de testing especializados y tu path de crecimiento

Testing

Testing en cada fase del desarrollo

Mapas mentales para estrategias de testing

Testing vs checking en automatización de pruebas

Testing ágil: todo el equipo prueba

Niveles de pruebas: componentes a sistema

Tipos de pruebas de software explicados

Pruebas estáticas vs dinámicas en testing

Cómo diseñar casos de prueba efectivos

Gestión, monitoreo y control

Pruebas de caja negra, blanca y gris

Control y monitoreo de pruebas paso a paso

Cuatro roles clave en equipos de QA

Roles y Responsabilidades en el Testing de Software

Gestión de bugs

Responsabilidades de roles en equipos de pruebas

Métricas y dashboards para control de testing

Gestión de defectos sin sobrecostos

Defectos vs sugerencias: cómo reportar bien

Depuración

Diferencia entre testing y debugging

Pruebas de verificación sin reusar datos

De debugging reactivo a logs preventivos

Bases de la automatización de pruebas

Cuándo automatizar pruebas y cómo prepararse

Yerkin: redactar casos automatizables

Responsabilidades del tester en proyectos

Tipos de pruebas de software explicados