Clasificación general de las pruebas

DevEd
Las pruebas de software es una actividad fundamental en el ciclo de desarrollo. En el modelo CMMI esta actividad se relaciona con las prácticas en las áreas de proceso de VER y VAL. El entendimiento y uso correcto de éstas técnicas tiene un fuerte impacto en el producto y en la calidad que se entrega al cliente, lo que se traduce en beneficios directos para la Organización.

Tipos de pruebas
Básicamente las pruebas se refieren a dos tipos de técnicas:
  • Caja blanca, implica revisar directamente cada línea de código y ramificaciones en el algoritmo por lo que se requiere conocimiento en el lenguaje y la estructura de programación.
  • Caja negra, las pruebas se basan en un conjunto de datos de entrada y respuestas que son comparadas contra los resultados que proporciona el software en relación a las funcionalidades esperadas.
Escenarios de prueba
Las técnicas de prueba se desarrollan en dos tipos de escenarios:
  • Embebidas, son las pruebas que se realizan como parte del proyecto de software para asegurar que el producto está libre de defectos.
  • Producto, son las pruebas que se realizan a productos comerciales para asegurar que el producto no presenta fallas al operar en diversos escenarios del cliente.
Pruebas embebidas
Este tipo de escenarios se utiliza cuando el software es desarrollado como un producto para un cliente en específico o para un ambiente determinado. Los tipos de pruebas que principalmente se consideran incluyen:
  • Inspecciones, revisiones realizadas por colegas para identificar defectos inicialmente en la especificación y documentación del producto.
  • Unitarias, es ejecutada por la persona que desarrolla el código y/o por una persona independiente que utiliza pruebas de caja blanca.
  • Integración, realizadas de manera incremental con las unidades de software que se van integrando o al final con el producto completo y mayormente como pruebas de caja negra para revisar el acoplamiento de las interfaces del producto.
  • Sistema, permite demostrar que el software funciona en todos los sistemas posibles.
  • Aceptación de usuario, obtiene la aprobación final del cliente para entregar el software y recibir el pago.
Pruebas de producto
Adicional a las pruebas realizadas durante el desarrollo del software se consideran pruebas más rigurosas para cubrir las diferentes necesidades y escenarios de uso del producto. En general se pueden considerar pruebas de:
  • Carga, para aplicaciones web y aplicaciones multi-usuarios se registran una gran cantidad de usuarios para utilizar el software de forma aleatoria. Permite evaluar la capacidad de respuesta del sistema cuando se lleva al límite el ancho de banda, base de datos, capacidad de memoria o en disco.
  • Volumen, somete al software a un gran volumen de información para evaluar el comportamiento.
  • Funcional, revisa que todas las funcionalidades del producto están operando correctamente.
  • Punta a punta, comprueba cómo una entidad pasa por todos los estados desde que nace hasta el final.
  • Paralela, aplica un número de usuarios interactuando simultaneamente para introducir u obtener la misma información protegiendo la integridad de los datos.
  • Concurrente, utiliza para comprobar que dos o más usuarios pueden utilizar la misma funcionalidad y actualizar la misma información con diferentes valores al mismo tiempo
  • Estrés, revisa la capacidad del software para reaccionar ante situaciones donde no se tienen recursos suficientes o se provocan bloqueos.
  • Positiva, utilizado en pruebas de aceptación para demostrar que el software a todas las funcionalidades esperadas, sin provocar situaciones negativas.
  • Negativas, permite identificar fallas ocultas cuando el software se usa de una manera que no es la esperada.


    • Manual de usuario, utiliza el software según lo establece el manual de usuario para comprobar que están sincronizados.
    • Liberación, simula el ambiente de operación para asegurar que el software funciona como se espera.
    • Sanidad, prueba superficial que asegura los componentes del software están completos y con las versiones correctas antes de liberar el producto.
    • Regresión, pruebas realizadas una vez que una falla ha sido corregida.
    • Seguridad, revisa la vulnerabilidad de la aplicación ante software espía o virus.
    • Rendimiento, asegura que los tiempos de respuesta están de los rangos aceptables.
    • Uso, prueba el software para diferentes tipos de uso que aseguran que el software cumple con las funcionalidades esperadas.
    • Instalación y desinstalación, revisa que el software puede ser instalado y desinstalado en todas las posibles plataformas
    • Comparación, revisa el producto contra la competencia para determinar la posición del producto.
    • Intuitiva, prueba el uso del producto de forma intuitiva sin referencia de las guías y manuales de usuario.
    La selección de un tipo de prueba u otra depende del presupuesto disponible, de la disponibilidad de tiempo o de los requisitos del producto o del cliente.
    Información obtenida de Chemuturi, Murali: “Test Effort Estimation”

    No hay comentarios:

    Publicar un comentario

    CMMI v2, cinco puntos para entender la nueva versión del modelo

    El mes de marzo del 2018 fue el lanzamiento de la versión 2.0 del modelo CMMI (Capability Maturity Model for Integration) por el CMMI Ins...