Guía de metodologías de prueba de software: una descripción general de alto nivel

Los sistemas de software confiables, seguros y de alta calidad se entregan porque los desarrolladores, ingenieros y programadores realizan pruebas de software rigurosas como parte de una estrategia de lanzamiento al mercado.

Los beneficios de las pruebas son simples. Elimine defectos, evite errores, reduzca los costos de desarrollo, mejore el rendimiento y evite litigios. Como desarrolladores de pruebas de software, creemos fundamentalmente que debe integrarse en todas las fases del proceso de desarrollo de software.

En el pasado, pocos ingenieros de software, desarrolladores o ingenieros de control de calidad vio el proceso de prueba de software de manera integral. Tradicionalmente, las pruebas de software se han separado del resto del desarrollo, dejando que los ingenieros de control de calidad las ejecuten cerca del final del ciclo de desarrollo.

Si se encontraran defectos, lo más probable es que las soluciones fueran costosas y las fechas de lanzamiento se retrasaran, lo que acabaría con la credibilidad de la empresa y la confianza de las partes interesadas. El resultado fue un aumento de los costos y una disminución de las ganancias.

En esta descripción general de alto nivel de las pruebas, uniremos todas las piezas del rompecabezas de las pruebas de software. Cubriremos:

• ¿Qué es la prueba?
• ¿Quién realiza las pruebas?
• ¿Cuándo empezar a probar?
• ¿Qué son las metodologías de prueba de software?
• ¿Cuáles son los tipos de pruebas de software?
• ¿Cuándo se completa y finaliza la prueba?
• ¿Cómo ayuda Parasoft con las pruebas?

¿Qué es la prueba?

La prueba se puede definir como un proceso de análisis de un elemento de software para detectar las diferencias entre las condiciones existentes y requeridas y para evaluar las características del elemento de software. En este proceso, validamos y verificamos que un producto o aplicación de software hace lo que se supone que debe hacer. El sistema o sus componentes se prueban para garantizar que el software satisfaga todos los requisitos especificados.

Al ejecutar los sistemas, podemos identificar brechas, errores o requisitos faltantes en contraste con los requisitos reales. Nadie quiere los dolores de cabeza de las correcciones de errores, las entregas tardías, los defectos o las fallas graves que resultan en daños o la muerte.

¿Quién realiza las pruebas?

Las personas que realizan las pruebas y desarrollan los procesos de prueba varían mucho de una organización a otra. Las empresas tienen diferentes designaciones para las personas que prueban el software en función de su experiencia y conocimiento, por lo que depende del proceso y las partes interesadas asociadas de un proyecto. Los títulos como ingeniero de control de calidad de software y desarrollador de software son comunes. Estos son algunos títulos generales y sus funciones para la prueba.

Ingeniero de control de calidad/probadores de software son responsables de eliminar los defectos. Muchos son expertos en análisis de software y sistemas, mitigación de riesgos y prevención de problemas relacionados con el software. Es posible que tengan un conocimiento limitado sobre el sistema, pero estudian la documentación de requisitos y realizan pruebas manuales y automatizadas. Ellos crear y ejecutar casos de prueba y reportar errores. Después de que el desarrollo resuelve los errores, vuelven a probar.

Desarrolladores de software puede conocer todo el sistema, de principio a fin. Están involucrados en el diseño, desarrollo y prueba de sistemas, por lo que conocen todas las pautas y requisitos. Además, están altamente capacitados en el desarrollo de software, incluida la automatización de pruebas.

Líder/gerentes de proyecto son responsables de todo el proyecto: calidad del producto, tiempo de entrega y finalización exitosa del ciclo de desarrollo. Cuando surgen problemas con el producto, es el gerente de producto quien prioriza los plazos para resolver los problemas.

Usuarios finales son las partes interesadas o los clientes. La prueba beta es una versión preliminar del software, que ayuda a garantizar la alta calidad y la satisfacción del cliente. Quién mejor para determinar si el producto que se entrega está en la trayectoria para satisfacer su aceptación.

Ingenieros de sistemas diseñar y diseñar el sistema a partir de los requisitos y conceptos recopilados. Debido al conjunto de conocimientos que poseen sobre el sistema, definen los casos de prueba a nivel del sistema para que luego los realice el equipo de control de calidad y/o los desarrolladores de software. También se realiza la verificación de requisitos para los casos de prueba. En sistemas muy complejos en los que se utiliza el modelado, los ingenieros de sistemas suelen realizar pruebas a través de la ejecución del modelo del diseño del sistema lógico y/o físico.

¿Cuándo comenzar a probar?

Lo mejor es comenzar pronto con las pruebas, ya que reduce los costos y el tiempo que lleva volver a trabajar y producir un diseño arquitectónico limpio y un software sin errores. Cada fase del ciclo de vida de desarrollo de software (SDLC) se presta como una oportunidad para la prueba, que se logra de diferentes formas.

Por ejemplo, en el SDLC, una forma de prueba puede comenzar durante la fase de recopilación de requisitos. Los requisitos deben entenderse claramente. Volver a las partes interesadas para aclarar y negociar los requisitos es una forma de probar la interpretación de los requisitos de las partes interesadas para garantizar que se construya el sistema correcto. Esta es una parte vital de la gestión de productos y proyectos. Casos de prueba para las pruebas de aceptación también deben definirse.

Es importante comprender que los casos de prueba definidos durante la fase de ingeniería del sistema son casos de prueba basados ​​en texto que explican qué y cómo se debe probar el sistema. Estos casos de prueba serán realizados posteriormente por el equipo de desarrollo y/o control de calidad, creados a partir del caso de prueba basado en texto de los ingenieros del sistema, así como del requisito vinculado. La validación o ejecución de los casos de prueba realizados producirá los resultados de aprobado/desaprobado que proporcionan prueba de la funcionalidad adecuada y también se pueden utilizar para cualquier necesidades de cumplimiento.

La fase de descomposición de requisitos y diseño arquitectónico detalla aún más el sistema en otro nivel de abstracción. Se definen las interfaces y, si se realiza el modelado mediante SysML, UML u otro lenguaje, probar la arquitectura a través de la simulación para eliminar los defectos de diseño es otra tarea vital.

Durante este proceso se definen requisitos adicionales, incluyendo los casos de prueba que verifican y validan cada uno de ellos. Se produce una descomposición adicional que produce el diseño detallado.

En última instancia, los requisitos a nivel del sistema se rastrean a los casos de prueba a nivel del sistema, los requisitos arquitectónicos se rastrean a los casos de prueba de prueba de integración y los requisitos de diseño detallado o los requisitos de bajo nivel se rastrearán a los casos de prueba de unidad. La verificación de los requisitos puede comenzar a realizarse para garantizar que cada requisito se rastree hasta un caso de prueba. A Requerimientos de trazabilidad matriz es perfecto para encontrar brechas de trazabilidad.

Cuando se lleve a cabo el traspaso del sistema a los ingenieros de software, los desarrolladores comenzarán su implementación en función de los requisitos. Aquí, los desarrolladores de software aplican o deberían aplicar estándares de codificación para garantizar la calidad del código. Análisis de código estático, que es una forma de prueba y en las primeras etapas de la fase de implementación, cuando también es el más barato de reparar, encontrará defectos de codificación, así como problemas de seguridad y protección. Seguirán las pruebas unitarias, y cada caso de prueba unitario realizado debe vincularse con los requisitos de bajo nivel o el caso de prueba que realiza.

A medida que evoluciona la implementación del sistema, los casos de prueba definidos anteriormente durante el proceso de ingeniería de sistemas deben realizarse y ejecutarse contra el sistema en desarrollo. Comenzando con las pruebas unitarias, seguidas de las pruebas de integración, las pruebas del sistema y las pruebas de aceptación. Además, según el tipo de requisitos de calidad de servicio, es posible que sea necesario realizar otros métodos de prueba, como Pruebas de API, pruebas de rendimiento, pruebas de estrés, pruebas de portabilidad, pruebas de usabilidad, etc.

¿Qué son las metodologías de prueba de software?

Las metodologías de prueba de software son las estrategias, los procesos o los entornos utilizados para probar. Las dos metodologías SDLC más utilizadas son Agile y Waterfall, y las pruebas son muy diferentes para estos dos entornos.

Modelo de cascada

Por ejemplo, en el modelo en cascada, las pruebas formales se realizan en la fase de prueba, que comienza una vez que se completa la fase de desarrollo. El modelo de cascada para pruebas funciona bien para proyectos pequeños y menos complejos. Sin embargo, si los requisitos no están claramente definidos al principio, es extremadamente difícil volver atrás y hacer cambios en las fases completadas.

El modelo de cascada es popular entre los proyectos pequeños porque tiene menos procesos y participantes con los que atender, lo que puede conducir a una finalización más rápida del proyecto. Sin embargo, los errores se encuentran más adelante en el desarrollo, lo que los hace más costosos de solucionar.

Modelo ágil

El modelo ágil es diferente del modelo en cascada y es el más adecuado para proyectos de desarrollo más grandes. Las pruebas ágiles son un modelo incremental en el que las pruebas se realizan al final de cada incremento o iteración. Además, toda la aplicación se prueba al finalizar el proyecto. Hay menos riesgo en el proceso de desarrollo con el modelo Agile porque cada miembro del equipo entiende lo que se ha completado o no. Los resultados de los proyectos de desarrollo suelen ser mejores con Agile cuando hay un administrador de proyectos fuerte y experimentado que puede tomar decisiones rápidas.

Modelo iterativo

Otros modelos SDLC incluyen el modelo iterativo y el modelo DevOps. En el modelo iterativo, los desarrolladores crean versiones básicas del software, revisan y mejoran la aplicación en iteraciones: pequeños pasos. Este es un buen enfoque para aplicaciones extremadamente grandes que deben completarse rápidamente. Los defectos se pueden detectar antes, lo que significa que pueden ser menos costosos de resolver.

Enfoque DevOps y pruebas continuas

Al tomar un Enfoque DevOps para las pruebas, o pruebas continuas, existe una colaboración con los equipos de operaciones a lo largo de todo el ciclo de vida del producto. A través de esta colaboración, los equipos de desarrollo y operaciones no esperan hasta que el software esté construido o casi terminado para realizar pruebas. Eso significa que el proceso de entrega de software es más rápido, los defectos se detectan antes y su resolución es menos costosa.

Las pruebas continuas utilizan pruebas automatizadas y herramientas de automatización como componentes de la canalización de desarrollo de software para proporcionar comentarios inmediatos sobre cualquier riesgo comercial que pueda existir.

¿Cuáles son los tipos de pruebas de software?

Los tipos más comunes de pruebas de software incluyen:

• Análisis estático
• Prueba unitaria
• Pruebas de integración
• Prueba del sistema
• Test de aceptación

Análisis estático

El análisis estático no implica la ejecución dinámica del software bajo prueba y puede detectar posibles defectos en una etapa temprana, antes de ejecutar el programa. El análisis estático se realiza durante o después de la codificación y antes de ejecutar las pruebas unitarias. Puede ser ejecutado por un motor de análisis de código para "recorrer" automáticamente el código fuente y detectar reglas que no cumplen, o errores léxicos, sintácticos e incluso algunos semánticos.

Las herramientas de análisis de código estático evalúan, compilan y verifican vulnerabilidades y fallas de seguridad para analizar el código bajo prueba. Las herramientas de análisis estático de Parasoft ayudan a los usuarios a administrar los resultados de las pruebas, incluida la priorización de hallazgos, la supresión de hallazgos no deseados y la asignación de hallazgos a los desarrolladores. Estas herramientas admiten un conjunto integral de ecosistemas de desarrollo para integrarse en una extensa lista de productos IDE para realizar análisis estáticos para C, C ++, Java, C# y VB.NET.

Examen de la unidad

El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes individuales son correctas en términos de requisitos y funcionalidad.

Los desarrolladores realizan este tipo de prueba antes de entregar la configuración al equipo de prueba para ejecutar formalmente los casos de prueba. Las pruebas unitarias las realizan los respectivos desarrolladores en las unidades individuales de las áreas asignadas del código fuente. Los desarrolladores utilizan datos de prueba que son diferentes de los datos de prueba del equipo de control de calidad.

El uso de Parasoft para realizar cobertura de sucursales, extractos y MC/DC es una forma de prueba unitaria. El software está aislado para cada función y se examinan estas partes individuales. La limitación de las pruebas unitarias es que no puede detectar todos los errores en la aplicación, ya que no evalúa un hilo o una ruta de ejecución en la aplicación.

Pruebas de integración

La prueba de integración se define como la prueba de partes combinadas de una aplicación para determinar si funcionan correctamente. Las pruebas de integración se pueden realizar de dos formas:

1. Pruebas de integración ascendentes. Las pruebas comienzan con pruebas unitarias, seguidas de pruebas de combinaciones de unidades de nivel progresivamente más alto llamadas módulos o compilaciones.
2. Pruebas de integración de arriba hacia abajo. En esta prueba, los módulos de nivel más alto se prueban primero y, progresivamente, los módulos de nivel más bajo se prueban a partir de entonces.

Pruebas del sistema

La prueba del sistema prueba el sistema como un todo donde se considera una caja negra y no hay necesidad de comprender el funcionamiento interno del sistema bajo prueba. Las pruebas del sistema se realizan una vez que todos los componentes están integrados, la aplicación en su conjunto se prueba rigurosamente para ver si cumple con los requisitos. Este tipo de prueba es realizada por el equipo de pruebas de control de calidad.

• La prueba del sistema es donde el sistema o la aplicación se ha implementado completamente y se probará como un todo.
• La aplicación se prueba exhaustivamente para verificar que cumple con los requisitos funcionales, los requisitos de calidad del servicio y los requisitos comerciales.
• La aplicación se prueba en el entorno de producción final o uno muy cercano al entorno de producción donde se implementará la aplicación.
• Las pruebas del sistema permiten a las organizaciones tener una idea del tiempo de comercialización cuando se logran resultados satisfactorios.

Test de aceptación

Podría decirse que este es el tipo de prueba más importante, ya que lo lleva a cabo el equipo de control de calidad para evaluar si la aplicación cumple con las especificaciones previstas y satisface los requisitos del cliente. El equipo de control de calidad tendrá un conjunto de escenarios escritos previamente y casos de prueba que se utilizarán para probar la aplicación.

Se compartirán más ideas sobre la aplicación y se podrán realizar más pruebas para medir su precisión y las razones por las que se inició el proyecto. Las pruebas de aceptación no solo pretenden señalar simples errores ortográficos, errores estéticos o lagunas en la interfaz, sino también señalar cualquier error en la aplicación que provocará fallas en el sistema o errores importantes en la aplicación.

Al realizar pruebas de aceptación en una aplicación, el equipo de pruebas deducirá cómo funcionará la aplicación en producción. También existen requisitos legales y contractuales para la aceptación del sistema.

¿Cuándo se completan y finalizan las pruebas?

Es difícil determinar cuándo dejar de probar, ya que la prueba es un proceso interminable y nadie puede afirmar que el software está 100 % probado. Sin embargo, existen criterios a considerar que pueden servir como indicadores para detener las pruebas.

1. Decisión de gestión. Quizás la forma más simple y común de saber que se detuvo la prueba es cuando la administración decide detener el proceso de prueba. La decisión de la gerencia puede deberse a limitaciones de tiempo o presupuesto, lo que puede comprometer la calidad. La decisión puede ser simplemente que el proyecto ha alcanzado el alcance de las pruebas requeridas, lo que significa que se han alcanzado los plazos de las pruebas.
2. Finalización de la ejecución del caso de prueba. Al completar los casos de prueba, la tasa de aprobación del caso de prueba debe ser del 95% y todos los casos de prueba críticos han sido aprobados. El 5% que falla debe ser casos de prueba de baja prioridad.
3. Realización de requisitos y pruebas de robustez. Los desarrolladores y evaluadores pueden analizar los datos de los resultados de las pruebas para asegurarse de que la aplicación funcione como se espera y reciba un resultado de aprobación para cada requisito definido. Además, todos los flujos funcionales principales se ejecutan con éxito con varias entradas y funcionan bien.
4. Cobertura de código a un porcentaje preespecificado. Instrumentar su código y ejecutar todos sus casos de prueba proporcionará no solo un porcentaje del código probado, sino que también expondrá el código que no se ejecutó, que potencialmente tiene errores ocultos. Algunas organizaciones se sienten cómodas obteniendo una cobertura de código del 80 % o superior, mientras que otras organizaciones requieren una cobertura de decisión de estados de cuenta, sucursales y condiciones modificadas del 100 %.
5. La tasa de errores cae por debajo de cierto nivel. Cuando las tasas de errores caen por debajo de un nivel predeterminado y no se identifican errores de alta prioridad, se puede detener la prueba.

¿Cómo ayuda Parasoft con las pruebas?

Parasoft lo ayuda a entregar software de calidad que es seguro, confiable y a escala con soluciones de prueba automatizadas que abarcan cada etapa del ciclo de desarrollo. Las soluciones de automatización de pruebas de software de Parasoft brindan un conjunto unificado de herramientas para acelerar las pruebas al ayudar a los equipos a dejar las pruebas en las primeras etapas de desarrollo mientras mantienen la trazabilidad, el mantenimiento de registros de resultados de pruebas, los detalles de cobertura de código, la generación de informes y la documentación de cumplimiento.

Ofrezca software que potencie coches, aeronave, dispositivos médicos, vias ferreasy automatización industrial soluciones con confianza utilizando herramientas de automatización de pruebas.