¿Qué son las pruebas del sistema?

Imagine que está observando un sistema de software con un microscopio, comenzando por el nivel de aumento más extremo, la unidad. Este es el bloque de construcción básico del sistema de software. A continuación, la vista se amplía hacia el exterior para incluir el siguiente nivel de aumento: los módulos creados por esas unidades individuales. Finalmente, al alejar completamente la vista, llega al nivel del sistema. En este nivel de aumento, puede ver todo lo que hay dentro del sistema y cómo funcionan juntos todos los componentes creados por esos módulos.

En cierto modo, las pruebas del sistema son como esa vista microscópica, pero con una diferencia clave. Las pruebas del sistema son una forma de prueba de caja negra, lo que significa que los evaluadores están menos interesados en la visión de los componentes implicados en su ensamblaje que en la funcionalidad general del sistema. Desde este tipo de perspectiva de "aprobado/suspenso", el comportamiento del sistema solo es digno de mención en este contexto en la medida en que se relaciona con el rendimiento del sistema. (Las pruebas de caja blanca permiten una mayor visibilidad de la naturaleza de los componentes dentro de un sistema).

Las pruebas del sistema a menudo implican el análisis de múltiples sistemas de software separados que pueden o no funcionar al unísono dentro de un sistema de software en particular.

Piense en la cuenta atrás que precede a los lanzamientos espaciales. Aunque todo el mundo recuerda la dramática cuenta atrás de diez pasos antes del encendido y el despegue, pocos recuerdan las numerosas comprobaciones departamentales que solicita el jefe de vuelo y que se responden afirmativamente con un "adelante". En un lanzamiento espacial típico, se consulta a los jefes de departamento sobre las operaciones planificadas, la seguridad de la misión, los sistemas de los vehículos y las condiciones meteorológicas previstas, entre muchas otras cuestiones. Se consulta a cada departamento y cada jefe de departamento responde por turnos.

De manera similar, las pruebas del sistema pueden considerarse la lista de verificación final que precede al lanzamiento de un nuevo sistema de software. Se ha completado la última ronda de limpieza de los errores de software conocidos. Y, al igual que las históricas listas de verificación que crearon los primeros pioneros espaciales, todo se reduce a una última prueba de cada “departamento” incluido en las pruebas del sistema.

Cada consulta se sombrea en función de la funcionalidad del sistema:

• ¿Todos los componentes funcionan como se esperaba?

• ¿Funcionan los componentes en coordinación adecuada entre sí?

• ¿Está el software preparado para soportar una interfaz de usuario fluida y brindar la experiencia de usuario (UX) deseada?

Cuando hablemos de las pruebas del sistema, naturalmente nos encontraremos con el tema de las dependencias, que son relaciones que existen dentro de los casos de prueba. En estas situaciones, el resultado de un caso de prueba puede depender parcial o totalmente de los resultados de otros casos de prueba. Las dependencias también pueden afectar a la funcionalidad, los entornos de pruebas o las políticas de seguridad, e incluso pueden repercutir en todo el proceso de pruebas que mantiene una organización.

Las metodologías de prueba del sistema no proporcionan una visión profunda de su funcionamiento interno (recuerde, esta es una forma de prueba de caja negra), sino que le permite saber si una aplicación en particular funciona. La idea es que las pruebas del sistema ayuden a localizar huecos, errores o requisitos faltantes, ya que determinan la funcionalidad general de la aplicación de software.

Las pruebas del sistema suelen realizarse después de las pruebas de integración pero antes de las pruebas de aceptación, lo que garantiza que todos los componentes funcionen juntos correctamente. Como veremos, a menudo abarca tanto los aspectos funcionales como los no funcionales del sistema. Como se basa tanto en las áreas estrictamente funcionales como en las que no son funcionales, aborda aspectos tan amplios como la usabilidad, la seguridad y el rendimiento.

Uno de los principales propósitos de las pruebas del sistema es que permiten verificar que el lenguaje de codificación de un software puede traducirse en un programa utilizable. Sin embargo, el objetivo general de las pruebas del sistema es asegurarse de que el software que se está evaluando es compatible con los requisitos empresariales de los usuarios que confiarán en él.

El proceso de prueba pretende reflejar el mismo entorno de producción que se utilizará, para garantizar que el software funciona como es necesario a pesar de las condiciones cambiantes del mundo real. Del mismo modo, los datos de prueba se crean para imitar datos y situaciones del mundo real. Una vez realizados los casos de prueba, se pueden localizar y corregir los defectos del software.

Las pruebas del sistema se pueden clasificar en uno de tres grupos principales. La primera, las pruebas funcionales, se ocupa del rendimiento del sistema, pero no busca una respuesta más profunda más allá de saber si el software funciona como se prometió. Estos son algunos de los principales tipos de pruebas funcionales:

• Pruebas de aceptación: las pruebas de aceptación del usuario buscan incorporar pruebas de rendimiento realizadas por personas que representan el grupo demográfico previsto del software que se está produciendo. Estos usuarios aportan realismo añadido al proceso de prueba al probar el software en condiciones reales.

• Pruebas de integración: un área de importancia crítica de las pruebas funcionales estudia lo bien que "encajan" los diferentes módulos o componentes cuando se ven obligados a trabajar en estrecha colaboración. Eso es prueba de integración del sistema. Un sistema totalmente integrado proporciona a los probadores la capacidad de evaluar las interacciones clave.

• Pruebas de humo: las pruebas de humo suponen un medio para comprobar si se ha mantenido la funcionalidad general después de que un desarrollador realice algún tipo de cambio en el código. El cambio se ha realizado y las pruebas de humo le permiten ver rápidamente si hay algún efecto adverso como resultado de ese cambio en el código.

• Pruebas unitarias: en las pruebas unitarias, se verifica una sección limitada de código dentro de un entorno de prueba aislado. Si la unidad en cuestión no pasa la prueba (como se ve en una comparación de los datos de prueba y los objetivos de funcionalidad), generalmente se necesitan más pruebas de componentes o módulos individuales a nivel de todo el sistema.

Si bien las pruebas funcionales proporcionan información extremadamente importante, esos datos se limitan básicamente a un voto a favor o en contra basado estrictamente en si el sistema funciona como debería. Eso omite un gran número de variables pertinentes, como la seguridad del sistema, la UX y los aspectos de rendimiento.

Las pruebas no funcionales del sistema proporcionan un medio para juzgar cómo funciona el sistema. La diferencia esencial entre las pruebas funcionales y las pruebas no funcionales se puede reducir a la siguiente comparación simple:

• Pruebas funcionales: ¿Funciona el sistema?

• Pruebas no funcionales: ¿Funciona bien el sistema?

Con eso en mente, estas son algunas de las formas clave de pruebas del sistema no funcionales:

• Pruebas de accesibilidad: ¿El contenido digital que se presenta es accesible para todos, incluidas las personas con diversas discapacidades? Las pruebas de accesibilidad investigan esta cuestión y trabajan para garantizar que el contenido se comunique a todos los usuarios posibles, de manera que se superen las discapacidades físicas y mentales y se garantice la coherencia con las normas de inclusión establecidas por la Ley de Estadounidenses con Discapacidades (ADA).

• Pruebas de compatibilidad: Si tenemos en cuenta la amplia distribución de las aplicaciones y la cantidad de plataformas entre las que deben funcionar, es fácil comprender la necesidad de realizar pruebas de compatibilidad, que evalúan el buen funcionamiento de dichas aplicaciones, independientemente de la cantidad de redes, navegadores, sistemas operativos y configuraciones de hardware por los que deben pasar.

• Pruebas de carga: en una subdisciplina que aborda la física única presentada por la noción de carga y cómo afecta a la capacidad de un sistema para procesar las solicitudes del sistema, las pruebas de carga se centran en lo que sucede cuando la escalabilidad ocurre a escala masiva. Suponemos que el sistema no tendrá problemas para procesar una sola solicitud del sistema, pero ¿qué pasa cuando esa carga se multiplica por miles de solicitudes, o incluso mucho más?

• Pruebas de localización: es una economía global en la que participan más países y culturas que nunca. Las pruebas de localización consisten en asegurarse de que el contenido del software que se exporta a varios lugares del mundo es adecuado para esa zona específica, de acuerdo con las normas generales relativas a la UX.

• Pruebas de rendimiento: este tipo de pruebas no funcionales presta especial atención a los problemas de rendimiento. Por ejemplo, es esencial para un buen rendimiento que un sistema responda a las solicitudes de forma rápida y fluida. El plan de pruebas en las pruebas de rendimiento evalúa cuánto tiempo deben esperar los usuarios para que se procesen las solicitudes.

• Pruebas de seguridad: no es ningún secreto que hoy en día la seguridad de datos es de vital importancia. Por lo tanto, tiene sentido que una forma de prueba se ocupe específicamente de la seguridad. Los métodos de comprobación de la seguridad se seleccionan en función del tipo de amenazas potenciales que recibe la empresa.

• Pruebas de estrés: al igual que una prueba de estrés médica busca comprender cómo funciona el corazón de una persona bajo la presión de la actividad, las pruebas de estrés del software verifican cómo de bien puede un sistema mantener su resiliencia operativa cuando se le exige más allá de su capacidad normal para detectar cuellos de botella y vulnerabilidades.

• Pruebas de usabilidad: este tipo de pruebas no funcionales se centran por completo en la calidad de la experiencia del usuario (UX). Las pruebas de usabilidad son un proceso de prueba manual que se utiliza de forma más práctica a pequeña escala. Sin embargo, probablemente debería aplicarse con frecuencia, especialmente cuando se realizan movimientos complicados, como la localización de aplicaciones.

Otros tipos de pruebas del sistema son útiles a pesar de no entrar en las categories de pruebas de funcionamiento o pruebas de no funcionamiento. Estas son algunas de las metodologías más destacadas:

• Pruebas de API: las interfaces de programación de aplicaciones (API) son extremadamente importantes, ya que permiten el desarrollo de software al ayudar a que diferentes aplicaciones o sistemas se conecten. Las pruebas de API garantizan que los puntos de conexión de la API funcionen según lo previsto. También proporciona supervisión sobre los permisos de los usuarios y la forma en la que los datos se gestionan a través de API.

• Pruebas automatizadas: como su nombre indica, las pruebas automatizadas (también llamadas automatización de pruebas) ponen el poder de la automatización al servicio de la comprobación de las aplicaciones de software. Lo hace mediante la creación y el uso de scripts de prueba diseñados para realizar casos de prueba en aplicaciones de software, lo que hace a gran escala, sin intervención humana. Los conjuntos estructurados de directrices, herramientas y prácticas que ayudan a automatizar el proceso de pruebas se denominan marcos.

• Pruebas manuales: en oposición directa a las pruebas automatizadas, las pruebas manuales se basan en pruebas humanas para experimentar con el software que se está evaluando, guiadas por diversos escenarios de prueba y guiones de prueba. Se anima a los probadores a poner realmente a prueba el software para identificar los problemas que necesitan corrección.

• Pruebas de migración: las organizaciones que se dedican a actualizar o transformar su cultura digital corporativa necesitan pruebas de migración. Cuando las empresas están inmersas en este tipo de esfuerzos de transformación, necesitan validar que los datos clave y el software se transfieren correctamente de un sistema saliente a otro entrante.

• Pruebas de regresión: si bien los cambios de código están destinados a mejorar el software o sus capacidades, pueden introducir dificultades inadvertidamente si el error humano se agrega de alguna manera a la mezcla. Las pruebas de regresión permiten a los evaluadores confirmar un funcionamiento estable y correcto volviendo a ejecutar pruebas según sea necesario.

Aunque el proceso de pruebas del sistema proporciona las pruebas de rendimiento de caja negra más completas disponibles, la realización de pruebas del sistema no está exenta de problemas potenciales: