¿Qué son las pruebas de sistemas?

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

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

Las pruebas de sistemas 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.

Consideremos la cuenta regresiva que precede a los lanzamientos espaciales. Si bien todos recuerdan la dramática cuenta regresiva de 10 pasos antes del encendido y el despegue, menos recuerdan las numerosas verificaciones departamentales que solicita el jefe de vuelo y responde afirmativamente como "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 muchos otros asuntos. Se consulta a cada departamento y cada jefe de departamento responde a su vez.

Del mismo modo, las pruebas de sistemas pueden considerarse la lista de verificación final que precede al lanzamiento de un nuevo sistema de software. Se completó la última ronda de limpieza de errores de software conocidos. Y al igual que las históricas listas de verificación que originaron los primeros pioneros del espacio, todo se reduce a un paso final de cada "departamento" incluido dentro de las pruebas de sistemas.

Cada consulta está sombreada en términos de la funcionalidad del sistema:

• ¿Cada componente funciona como se espera?

• ¿Los componentes funcionan en coordinación adecuada entre sí?

• ¿El software está preparado para admitir una interfaz de usuario fluida y brindar la experiencia de usuario (UX) deseada?

Cuando hablemos de las pruebas de sistemas, naturalmente nos encontraremos con el tema de las dependencias, que son relaciones que existen dentro de los casos de prueba. En tales 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 implicar funcionalidad, entornos de pruebas o políticas de seguridad e incluso pueden afectar todo el proceso de prueba 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 deficiencias, errores o requisitos faltantes, ya que determina la funcionalidad general de la aplicación de software.

Las pruebas del sistema generalmente se realizan 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 abarcan los aspectos funcionales y no funcionales del sistema. Como se basan tanto en las áreas estrictamente funcionales como en las que no son funcionales, abordan aspectos tan amplios como la usabilidad, la seguridad y el rendimiento.

Uno de los principales propósitos de las pruebas del sistema es que permite verificar que la programación de un software se puede traducir a un programa utilizable. Sin embargo, el objetivo general de las pruebas de sistemas es garantizar que el software que se evalúa sea capaz de satisfacer los requisitos empresariales de los usuarios que lo utilizarán.

El proceso de prueba tiene como objetivo reflejar el mismo entorno de producción que se utilizará, para garantizar que el software funcione según lo 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 que se llevan a cabo los casos de prueba, se pueden localizar y corregir los defectos en el software.

Las pruebas de sistemas se pueden clasificar según uno de tres grupos principales. El primero, las pruebas funcionales, se refiere al rendimiento del sistema, pero no busca una respuesta más profunda más allá de saber si el software funciona según lo prometido. 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 mayor realismo 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 qué tan bien "encajan" los diferentes módulos o componentes cuando se ven obligados a trabajar en estrecha colaboración. Esto es una prueba de integración del sistema. Un sistema totalmente integrado ofrece a los evaluadores la capacidad de evaluar interacciones clave.

• Prueba de humo: la prueba de humo proporciona un medio para verificar si se ha mantenido la funcionalidad general después de que un desarrollador haya realizado algún tipo de cambio en el código. El cambio ya se realizó y las pruebas de humo permiten ver rápidamente si hay efectos adversos derivados de ese cambio en el código.

• Pruebas unitarias: En las pruebas unitarias, se comprueba una sección limitada del código en 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 una gran cantidad de variables pertinentes, como la seguridad del sistema, la experiencia de usuario y los aspectos relacionados con el 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 de sistemas 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 atraviese las discapacidades físicas y mentales y garantice la coherencia con los estándares de inclusión establecidos por la Ley de Estadounidenses con Discapacidades (ADA).

• Pruebas de compatibilidad: cuando se considera la amplitud de distribución de las aplicaciones y cuántos recorridos multiplataforma tienen que hacer las aplicaciones, es fácil comprender la necesidad de pruebas de compatibilidad, que miden qué tan bien funcionan las aplicaciones, independientemente de cuántas redes, navegadores, sistemas operativos y configuraciones de hardware tienen que recorrer.

• Pruebas de carga: En una subdisciplina que aborda la física única presentada por la noción de carga y cómo afecta 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 se tratan de asegurarse de que el contenido de software que se exporta a varios lugares del mundo sea apropiado para esa área específica, de acuerdo con las reglas generales relativas a la experiencia de usuario.

• 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 prueba 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 los datos es de suma importancia. Por lo tanto, tiene sentido que exista un tipo de prueba que se centre específicamente en la seguridad. Los métodos de prueba de seguridad se seleccionan de acuerdo con el tipo de amenazas potenciales recibidas por la empresa.

• Pruebas de estrés: así como una prueba de estrés médica busca entender cómo funciona el corazón de una persona bajo la presión de la actividad, las pruebas de esfuerzo de software verifican qué tan bien puede un sistema mantenerse operativamente resiliente cuando se sobrepasa su capacidad normal para detectar cuellos de botella y vulnerabilidades.

• Pruebas de usabilidad: este tipo de pruebas no funcionales se trata completamente de la calidad de la experiencia de usuario (UX). Las pruebas de usabilidad son un proceso de prueba manual que se utiliza más prácticamente a pequeña escala. No obstante, probablemente debería aplicarse con frecuencia, especialmente cuando se ejecutan movimientos complicados como la localización de aplicaciones.

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

• Pruebas de API: las interfaces de programación de aplicaciones (API) son extremadamente importantes, ya que permiten el desarrollo de software al ayudar a conectar diferentes aplicaciones o sistemas. 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 que se gestionan los datos a través de las API.

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

• Pruebas manuales: en contraposición a las pruebas automatizadas, las pruebas manuales se basan en pruebas realizadas por personas para experimentar con el software que se está evaluando, siguiendo diversas situaciones y scripts de prueba. Se recomienda a los evaluadores a poner realmente a prueba el software para identificar 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 procesos de transformación, necesitan asegurarse de que los datos y el software clave se transfieren correctamente del sistema saliente al sistema 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.

Si bien el proceso de prueba de sistemas proporciona las pruebas de rendimiento de caja negra más completas disponibles, la realización de pruebas de sistemas no está exenta de problemas potenciales: