Una estrategia de prueba, proporciona la adecuada planeación para una correcta aplicación de las pruebas que fueron diseñadas. Se trata de una guía lo suficientemente flexible para promover la creatividad y la adaptabilidad necesarias para adecuar las pruebas al entorno y la arquitectura del software aprobar.
Las pruebas son el punto culminante de un proceso de calidad y comenzó desde el análisis y son el punto en el cual se trata de asegurar la calidad del software, razón por la cual es una actividad de suma importancia.
La estrategia de prueba que seleccionaremos debe cubrir los siguientes requisitos:
- Las pruebas comienzan a nivel de módulo
- Las llevan a cabo el responsable del desarrollo, pero de forma ideal debe ser un grupo independiente
- Debe cubrir la aplicación de diferentes técnicas de prueba
La estrategia de prueba es parte fundamental del proceso de validación y verificación del software. La verificación es una actividad la cual nos aseguramos que las distintas partes del software cumple con la función para la cual fueron diseñadas, en este sentido la verificación se encarga de revisar el funcionamiento de los módulos del software, mientras que la validación se encarga de comprobar que los módulos verificados con pleno con los requisitos que el cliente ha expresado.
En cualquier proyecto de software existe el conflicto entre el proceso de desarrollo y el proceso de prueba, este conflicto es derivado del interés que existe por demostrar que el software funciona, razón por la cual en una gran parte de las empresas de desarrollo, en especial las de los juegos, son equipos independientes los que realizan el proceso de prueba.
Un profundo problema que existe sin importar la estrategia de prueba que se use, es el hecho innegable de que por más pruebas que realicemos, éstas no se pueden comparar con el ambiente real hay que se enfrentará el software, razón por la cual muchas empresas han optado por la estrategia de usar los equipos de «BETA TESTER», que no son otra cosa más que consumidores de software que de forma voluntaria acceden a usar en el mundo real una versión de prueba que se conoce con el nombre de beta.
Otras compañías deciden utilizar las conocidas Released Tecnical (RT), las cuales son versiones que pueden llegar a convertirse en la versión definitiva del software, creo que no son entregadas al usuario común, sino a usuarios especializados, generalmente clientes corporativos de la empresa desarrollo.
Otras más, hacen uso de las Release Candidate (RC), las cuales son candidatas a convertirse en la versión definitiva del software y que son probadas por el usuario común, se diferencian de las Betas, en que las Betas son versiones que aún no están listas.
Ahora bien, el proceso de prueba como su nombre lo indica es un proceso, y como tal debe tener un principio y un final, ciertamente conocemos cuál es el principio quedó el punto clave es determinar cuál será el final, es decir, desistir hasta este momento podemos dar por agotadas y satisfactorias todas las pruebas que hemos realizado, a esta interrogante podríamos apresurarnos a responder:¡hasta que ya no haya errores!
Pero en la afirmación anterior debemos tener en cuenta que resulta casi imposible que un software no contenga errores y no es debido a una mala calidad en el proceso de desarrollo del mismo, sino debido a múltiples factores como el tiempo, el dinero, los recursos humanos disponibles, la gran diversidad de hardware y software con las cuales tendrá que convivir nuestro software.
Dada esta situación, diríamos que el proceso de pruebas del software termina hasta obtener un cierto porcentaje que fiabilidad. El porcentaje de fallas restantes sera trasladado a el cliente, esto como parte de la fase de mantenimiento del software, es decir, la fase de prueba trata de depurar y corregir todos aquellos errores que sean previsibles y la fase de mantenimiento corregira todo aquello que no sea previsible.
Sistemasumma.com 