Pruebas y garantía de calidad

El sistema de software debe verificarse para determinar su comportamiento previsto y la dirección de progreso en cada etapa de desarrollo para evitar la duplicación de esfuerzos, los excesos de tiempo y costos, y para asegurar la finalización del sistema dentro del tiempo estipulado. comportamiento previsto y dirección del progreso en cada etapa de desarrollo para evitar la duplicación de esfuerzos, los excesos de tiempo y costos, y para asegurar la finalización del sistema dentro del tiempo estipulado.

Las pruebas del sistema y la garantía de calidad ayudan a comprobar el sistema. Incluye -

  • Calidad a nivel de producto (pruebas)
  • Calidad a nivel de proceso.

Repasemos brevemente -

Pruebas

La prueba es el proceso o actividad que verifica la funcionalidad y la corrección del software de acuerdo con los requisitos específicos del usuario para mejorar la calidad y confiabilidad del sistema. Es un enfoque caro, lento y crítico en el desarrollo de sistemas que requiere una planificación adecuada del proceso de prueba general.

Una prueba exitosa es aquella que encuentra los errores. Ejecuta el programa con la intención explícita de encontrar errores, es decir, hacer que el programa falle. Es un proceso de evaluación del sistema con la intención de crear un sistema fuerte y se enfoca principalmente en las áreas débiles del sistema o software.

Características de las pruebas del sistema

La prueba del sistema comienza en el nivel del módulo y avanza hacia la integración de todo el sistema de software. Se utilizan diferentes técnicas de prueba en diferentes momentos mientras se prueba el sistema. Lo lleva a cabo el desarrollador para proyectos pequeños y grupos de prueba independientes para proyectos grandes.

Etapas de la prueba del sistema

Las siguientes etapas están involucradas en las pruebas:

Test Strategy

Es una declaración que proporciona información sobre los distintos niveles, métodos, herramientas y técnicas que se utilizan para probar el sistema. Debe satisfacer todas las necesidades de una organización.

Test Plan

Proporciona un plan para probar el sistema y verifica que el sistema bajo prueba cumpla con todas las especificaciones funcionales y de diseño. El plan de prueba proporciona la siguiente información:

  • Objetivos de cada fase de prueba
  • Enfoques y herramientas utilizadas para las pruebas
  • Responsabilidades y tiempo requerido para cada actividad de prueba
  • Disponibilidad de herramientas, instalaciones y bibliotecas de prueba
  • Procedimientos y estándares requeridos para planificar y realizar las pruebas.
  • Factores responsables de la finalización exitosa del proceso de prueba

Test Case Design

  • Se identifican varios casos de prueba para cada módulo del sistema que se va a probar.

  • Cada caso de prueba especificará cómo se va a probar la implementación de un requisito particular o decisión de diseño y los criterios para el éxito de la prueba.

  • Los casos de prueba junto con el plan de prueba se documentan como parte de un documento de especificación del sistema o en un documento separado llamado test specification o test description.

Test Procedures

Consta de los pasos que se deben seguir para ejecutar cada uno de los casos de prueba. Estos procedimientos se especifican en un documento separado llamado especificación del procedimiento de prueba. Este documento también especifica los requisitos y formatos especiales para informar el resultado de las pruebas.

Test Result Documentation

El archivo de resultado de la prueba contiene información breve sobre el número total de casos de prueba ejecutados, el número de errores y la naturaleza de los errores. Luego, estos resultados se evalúan contra los criterios en la especificación de la prueba para determinar el resultado general de la prueba.

Tipos de pruebas

Las pruebas pueden ser de varios tipos y se llevan a cabo diferentes tipos de pruebas según el tipo de errores que se busque descubrir:

Examen de la unidad

También conocido como Prueba de programa, es un tipo de prueba donde el analista prueba o se enfoca en cada programa o módulo de forma independiente. Se lleva a cabo con la intención de ejecutar cada sentencia del módulo al menos una vez.

  • En las pruebas unitarias, no se puede garantizar la precisión del programa y es difícil realizar pruebas de varias combinaciones de entrada en detalle.

  • Identifica los errores máximos en un programa en comparación con otras técnicas de prueba.

Pruebas de integración

En las pruebas de integración, el analista prueba varios módulos trabajando juntos. Se utiliza para encontrar discrepancias entre el sistema y su objetivo original, especificaciones actuales y documentación del sistema.

  • Aquí, los analistas intentan encontrar áreas donde los módulos se hayan diseñado con diferentes especificaciones para la longitud, el tipo y el nombre del elemento de datos.

  • Verifica que los tamaños de archivo sean adecuados y que los índices se hayan creado correctamente.

Pruebas funcionales

Las pruebas de funcionamiento determinan si el sistema está funcionando correctamente de acuerdo con sus especificaciones y documentación de estándares relevantes. Las pruebas funcionales generalmente comienzan con la implementación del sistema, que es muy importante para el éxito del sistema.

Las pruebas funcionales se dividen en dos categorías:

  • Positive Functional Testing - Implica probar el sistema con entradas válidas para verificar que las salidas producidas son correctas.

  • Negative Functional Testing - Implica probar el software con entradas no válidas y condiciones de funcionamiento no deseadas.

Reglas para la prueba del sistema

Para llevar a cabo la prueba del sistema con éxito, debe seguir las reglas dadas:

  • Las pruebas deben basarse en los requisitos del usuario.

  • Antes de escribir scripts de prueba, debe comprender la lógica empresarial a fondo.

  • El plan de prueba debe realizarse lo antes posible.

  • Las pruebas deben ser realizadas por un tercero.

  • Debe realizarse en software estático.

  • Se deben realizar pruebas para las condiciones de entrada válidas y no válidas.

  • Las pruebas deben revisarse y examinarse para reducir los costos.

  • Se deben realizar pruebas tanto estáticas como dinámicas en el software.

  • Se debe realizar la documentación de los casos de prueba y los resultados de las pruebas.

Seguro de calidad

Es la revisión del sistema o productos de software y su documentación para garantizar que el sistema cumple con los requisitos y especificaciones.

  • El propósito de QA es brindar confianza a los clientes mediante la entrega constante de productos de acuerdo con las especificaciones.

  • El aseguramiento de la calidad del software (SQA) es una técnica que incluye procedimientos y herramientas aplicadas por los profesionales del software para garantizar que el software cumpla con el estándar especificado para su uso y rendimiento previstos.

  • El objetivo principal de SQA es proporcionar a la administración una visibilidad adecuada y precisa del proyecto de software y su producto desarrollado.

  • Revisa y audita el producto de software y sus actividades a lo largo del ciclo de vida del desarrollo del sistema.

Objetivos de la garantía de calidad

Los objetivos de la realización del aseguramiento de la calidad son los siguientes:

  • Monitorear el proceso de desarrollo de software y el software final desarrollado.

  • Asegurar si el proyecto de software está implementando los estándares y procedimientos establecidos por la gerencia.

  • Para notificar a grupos e individuos sobre las actividades de SQA y los resultados de estas actividades.

  • Para asegurarse de que los problemas que no se resuelven dentro del software sean resueltos por la alta dirección.

  • Identificar deficiencias en el producto, el proceso o los estándares y solucionarlos.

Niveles de garantía de calidad

Hay varios niveles de control de calidad y pruebas que deben realizarse para certificar un producto de software.

Level 1 − Code Walk-through

En este nivel, el software fuera de línea se examina o verifica en busca de violaciones de las reglas oficiales de codificación. En general, el énfasis se coloca en el examen de la documentación y el nivel de comentarios en el código.

Level 2 − Compilation and Linking

En este nivel, se comprueba que el software pueda compilar y vincular todas las plataformas y sistemas operativos oficiales.

Level 3 − Routine Running

En este nivel, se comprueba que el software puede ejecutarse correctamente en una variedad de condiciones, como cierto número de eventos y tamaños de eventos pequeños y grandes, etc.

Level 4 − Performance test

En este nivel final, se comprueba que el rendimiento del software satisfaga el nivel de rendimiento especificado anteriormente.