Pruebas del sistema

Las pruebas de software son una actividad cuyo objetivo es detectar posibles errores y fallos en las aplicaciones de software antes de que se pongan a disposición de los usuarios finales. Tiene lugar en cuatro niveles diferentes: pruebas unitarias, pruebas de integración, pruebas del sistema y pruebas de aceptación. En este artículo, examinaremos en detalle las pruebas del sistema.

Antes, sin embargo, es esencial conocer los distintos niveles de las pruebas de software.

Pruebas unitarias – Consiste en probar cada componente del software por separado para asegurarse de que funciona correctamente. Generalmente, los desarrolladores o programadores realizan pruebas unitarias durante la fase de desarrollo del SDLC.

Pruebas de integración – Siguen las pruebas de integración. Combina lógicamente los componentes de las pruebas unitarias en grupos y verifica su interacción. Detecta los errores que puedan surgir debido a la interacción de los módulos de software.

Pruebas del sistema – Cuando todo el sistema está conectado e integrado en una sola unidad, se evalúa como un todo. El objetivo es comprobar el sistema desde el punto de vista del usuario.

Pruebas de aceptación – El último nivel son las pruebas de aceptación. Un pequeño grupo de usuarios reales o el equipo interno de la organización comprueba que el producto de software cumple todos los requisitos especificados.

Pasemos ahora a una comprensión detallada de las pruebas del sistema.

¿Qué es la prueba del sistema?

La prueba de sistemas es un tipo de prueba de software que evalúa un producto de software en su conjunto basándose en requisitos funcionales y no funcionales. Determina el rendimiento y la funcionalidad generales de un producto de software totalmente integrado.

El objetivo principal de este tipo de pruebas es comprobar que todos los componentes del software funcionan juntos sin errores y que funcionan como deben, cumpliendo todos los requisitos especificados. Se ocupa de la verificación del diseño del producto de software, su comportamiento y el cumplimiento de los requisitos del cliente.

El equipo de control de calidad realiza pruebas del sistema después de las pruebas de integración y antes de las pruebas de aceptación. Eligen un entorno de prueba que se parezca mucho a un entorno de producción real. Como el equipo de control de calidad está probando todo el sistema sin conocer su funcionamiento interno, entra dentro de las pruebas de caja negra.

Los módulos integrados que han superado las pruebas de integración sirven de entrada para las pruebas del sistema. Las pruebas de integración detectan errores o incoherencias entre las unidades integradas. Sin embargo, las pruebas del sistema revelan errores entre las unidades integradas y el sistema completo.

En resumen, este tipo de prueba de software consiste en ejecutar una serie de pruebas para comprobar todo el software.

Ejemplo de prueba del sistema

Tomemos un ejemplo del mundo real. Piensa en el proceso de fabricación de un coche. Al principio, el fabricante del coche fabrica todos los componentes básicos, como los frenos, el motor, los asientos, la dirección, las ruedas, etc. Tras la producción de estos componentes, llega el momento de probarlos individualmente, lo que en desarrollo de software se denomina prueba unitaria.

Una vez confirmada la funcionalidad de todos estos componentes individuales, el fabricante los ensamblará. El siguiente paso es comprobar que la combinación ensamblada no provoca ningún error ni tiene efectos secundarios en la funcionalidad de los componentes individuales. Denominamos a este procedimiento pruebas de integración.

Tras asegurarse de que no hay errores entre la combinación ensamblada, el fabricante comprueba la combinación en su conjunto, lo que constituye la prueba del sistema. El vehículo en su conjunto se somete a una serie de comprobaciones para verificar que cumple los requisitos especificados, por ejemplo, que el vehículo funciona suavemente, que todos los demás componentes (frenos, caja de cambios, ruedas, etc.) funcionan correctamente.

Si el vehículo cumple las expectativas de los clientes, es más probable que lo compren.

¿Por qué necesitamos pruebas de sistema cuando probamos software?

• Incluso después de realizar con éxito pruebas unitarias y de integración, muchos escenarios complejos pueden tener problemas no detectados. Las pruebas del sistema ayudan a detectar estos errores.
• Prueba el software en función de los requisitos funcionales y no funcionales. Es la primera vez que esto ocurre en todo el ciclo de vida del desarrollo de software. Por tanto, verifica la arquitectura o el diseño del software y los requisitos empresariales.
• El entorno de pruebas es exactamente igual que el de producción. Por lo tanto, el éxito de las pruebas del sistema aporta una sensación de confianza en el producto final entregado. Las partes interesadas también pueden comprender cómo reaccionan los usuarios finales ante el software.
• Esto minimiza los problemas posteriores a la implantación, la resolución de problemas y las llamadas al servicio de asistencia.

¿Qué hay que verificar al probar el sistema?

Este tipo de prueba evalúa un producto de software en los siguientes aspectos:

• Interacciones entre los componentes del software, incluidos los periféricos externos, para verificar cómo funciona el software en su conjunto. Se trata de un escenario de pruebas de extremo a extremo.
• Las entradas dadas al programa informático producen los resultados esperados.
• Se cumplen los requisitos funcionales y no funcionales.
• Experiencia del usuario final con el software.

Hemos enumerado aquí algunos de los parámetros más importantes. Sin embargo, probar el sistema implica verificar muchos otros aspectos. Requiere casos de prueba detallados y archivos de prueba sobre cada aspecto del software desde el exterior, sin examinar sus detalles internos.

Criterios de entrada y salida

Cada nivel de las pruebas de software tiene criterios de entrada y de salida. A continuación se indican los criterios de entrada y salida para probar el sistema:

Criterios de acceso

• El software debe superar todos los criterios de salida de las pruebas de integración, es decir j. debe completarse la ejecución de todos los casos de prueba y no debe haber fallos críticos o prioritarios en el estado abierto.
• El plan de pruebas debe ser aprobado y firmado.
• Los casos de prueba, los escenarios de prueba y los guiones de prueba deben estar listos para su ejecución.
• El entorno de pruebas debería estar listo.
• Los requisitos no funcionales deben estar disponibles.

Criterios de salida

• Deben ejecutarse todos los casos de prueba previstos para probar el sistema.
• Ningún fallo prioritario o crítico debe estar en estado abierto.
• Aunque los fallos abiertos sean de prioridad media o baja, deben pasar al siguiente nivel de pruebas: las pruebas de aceptación.
• Debe elaborarse un informe de salida.

Tipos de pruebas del sistema

Como ya se ha dicho, este tipo de prueba evalúa el software en función de los requisitos funcionales y no funcionales. Por lo tanto, el software tiene que pasar por varias técnicas de prueba para evaluar todo el sistema y sus diferentes aspectos.

Los distintos tipos de pruebas del sistema son:

1. Pruebas funcionales: evalúan el software para comprobar que cada función funciona como debe y cumple los requisitos especificados. Si los probadores descubren que faltan algunas funciones, se las comunican al equipo de desarrollo para que las implemente. También sugieren funciones adicionales para mejorar el programa.
2. Pruebas de rendimiento: Es un tipo de prueba no funcional que verifica la estabilidad, escalabilidad, capacidad de respuesta y velocidad del sistema bajo una carga determinada.
3. Pruebas de usabilidad: también son pruebas no funcionales que verifican la facilidad de uso y la eficacia del software. En pocas palabras, determina la facilidad con la que los usuarios pueden gestionar y controlar el software y acceder a sus funciones.
4. Pruebas de fiabilidad: esta técnica de pruebas evalúa el software para verificar que funciona correctamente y de forma constante en determinadas condiciones durante un periodo de tiempo.
5. Pruebas de seguridad: detectan todos los riesgos y vulnerabilidades de seguridad del software y garantizan que no permite el acceso no autorizado a datos y otros recursos.
6. Pruebas de escalabilidad: este tipo de pruebas de carga evalúa el rendimiento del software a medida que aumenta y disminuye el número de usuarios.
7. Pruebas de recuperabilidad: esta técnica de prueba determina la capacidad del software para recuperarse de fallos y caídas.
8. Pruebas de interoperabilidad: analizan lo bien que funciona el software con sus componentes y productos de terceros.
9. Pruebas de regresión: estas pruebas garantizan que los nuevos cambios en el código fuente del software no afectan a la funcionalidad existente. Garantiza la estabilidad del software integrando subsistemas y procedimientos de mantenimiento.

Proceso de prueba del sistema

Aquí tienes los pasos individuales para probar el sistema:

1. Configurar el entorno de pruebas – El primer paso es crear un entorno de pruebas que coincida con el entorno de producción para realizar pruebas de calidad. El entorno de prueba incluye la selección de lenguajes de programación, marcos y herramientas de prueba, y la creación de las dependencias y configuraciones necesarias.
2. Crear casos de prueba – El siguiente paso es crear casos de prueba para el proceso de prueba exhaustiva. También incluye la creación de un documento de prueba que contenga el número de casos de prueba con éxito y sin éxito.
3. Desarrollar datos de prueba – Este paso implica la recogida de datos de prueba. Debe contener toda la información y los campos necesarios. Identifica las combinaciones de entrada/salida favorables y desfavorables.
4. Ejecutar casos de prueba – Utiliza los casos de prueba y los datos de prueba que has creado para ejecutar casos de prueba. Esto te ayudará a saber si los casos de prueba tienen éxito o no.
5. Identificación de errores/deficiencias – Si se produce algún error o deficiencia, los probadores deben comunicarlo en el documento de prueba creado en el Paso 2.
6. Pruebas de regresión – Para corregir los errores encontrados, los desarrolladores realizan cambios en el código fuente. Así, los probadores realizan pruebas de regresión para asegurarse de que las últimas modificaciones del código fuente no afectan a su funcionalidad existente.
7. Volver a probar – Si se encuentran errores durante las pruebas de regresión, el equipo de pruebas los comunicará al equipo de desarrollo. El ciclo de pruebas continúa hasta que el software está listo para pasar a la fase de producción.

Ventajas y desventajas de las pruebas del sistema

He aquí algunas ventajas y desventajas significativas de probar el sistema:

Beneficios

• Las pruebas de sistemas no requieren que los probadores tengan conocimientos de programación.
• Verifica todo el producto de software y revela errores y fallos que las pruebas unitarias y de integración no pueden detectar.
• El entorno de prueba es similar a un entorno de producción real.
• Las pruebas minuciosas de un producto de software se traducen, en última instancia, en una alta calidad.
• Mejora el rendimiento general del sistema, el mantenimiento y la fiabilidad.
• Como expone todos los posibles errores y fallos, los equipos de desarrollo y pruebas tienen la confianza suficiente para lanzar los productos a los usuarios.

Desventajas

• Probar el sistema lleva mucho tiempo.
• Requiere probadores altamente cualificados.
• Es un reto para los proyectos grandes y complejos.
• Los probadores no tienen acceso al código fuente del software.
• Ninguna prueba revelará el 100% de los errores. Aunque las pruebas del sistema verifiquen todos los aspectos del código fuente, pueden seguir existiendo errores.

Pruebas del sistema frente a pruebas de aceptación

La siguiente tabla destaca la diferencia entre las pruebas del sistema y las pruebas de aceptación:

Pruebas del sistema	Pruebas de Aceptación
Prueba el producto de software en su conjunto y verifica que cumple los requisitos funcionales y no funcionales.	Un pequeño grupo de usuarios reales prueba el producto de software para asegurarse de que cumple los requisitos del cliente.
Incluye pruebas funcionales y no funcionales.	Incluye sólo pruebas funcionales.
Tiene lugar después de las pruebas de integración.	Tiene lugar después de que se haya probado el sistema.
Utiliza entradas ficticias creadas por los probadores.	Utiliza entradas aleatorias proporcionadas por los usuarios.
Cualquier error encontrado puede corregirse.	Cualquier defecto encontrado se considera un defecto del producto.
Se centra tanto en los casos positivos como en los negativos.	Se centra sólo en los casos positivos.

Conclusión

Se trataba de la comprobación de sistemas en ingeniería de software. Se trata de un nivel clave en las pruebas de software, ya que comprueba a fondo los productos de software basándose en requisitos funcionales y no funcionales. Cuando se hace correctamente, mejora la calidad, el rendimiento, la mantenibilidad y la fiabilidad del software. De lo contrario, podrían descubrirse errores que no se detectan cuando el programa entra en funcionamiento.