Aunque pueda resultar paradójico, el principal objetivo de las pruebas debe ser conseguir que el programa funcione incorrectamente y que se descubran sus defectos.
Las pruebas no permiten garantizar la calidad de un producto. Puede decirse que una prueba tiene éxito si se descubre algún error, con lo que se sabe que el producto no cumple con algún criterio de calidad; por el contrario, si la prueba no descubre ningún error, no se garantiza con ello la calidad del producto, ya que pueden existir otros errores que habrían de descubrirse mediante pruebas diferentes.
Probar completamente cada módulo es inabordable y además no resulta rentable ni práctico, pues sólo se explora una parte de todas las posibilidades del programa.
Tipos de Pruebas
Referente a los Tipos de prueba, se sugieren los artefactos que ofrece El Proceso Racional Unificado o RUP (por sus siglas en inglés de Rational Unified Process) en su Plan de Pruebas, puesto que tienen mucha experiencia en la gestión de la documentación relacionada al Desarrollo de software, tal es el caso de los siguientes tipos:
- Pruebas de integridad de datos y de base de datos.
- Pruebas de función.
- Prueba de ciclo empresarial.
- Pruebas de la interfaz de usuario.
- Perfilado de rendimiento.
- Prueba de carga.
- Prueba de tensión.
- Pruebas de volumen.
- Prueba de seguridad y de control de accesos.
- Pruebas de migración tras error y de recuperación.
- Pruebas de configuración.
- Pruebas de instalación.
Fuente: Técnicas de prueba por riesgo de calidad / tipo de prueba
El Plan de Pruebas
La plantilla del Plan de Prueba ya contiene las instrucciones generales sobre su llenado. En esta descripción vemos de qué trata dicha plantilla, resaltando que en ella(la plantilla) se describen los objetivos de la prueba, el ámbito de la iteración/proyecto, elementos objetivos de las pruebas, recursos requeridos, entre otros.
>> Plantillas RUP << para descargar, ordenadas según la etapa del proyecto que deseamos documentar.
Las instrucciones son muy fáciles y transparentes, el Texto azul, son las instrucciones de los que podemos escribir en las diferentes partes del documento.
Solo queda leer las instrucciones, seleccionar los contenidos que le convenga a quien desarrolla o recibe la documentación y guardar cambios.
Los Casos de Prueba
Según la International Software Testing Qualifications Board (ISTQB®) – La definición de un Caso de Prueba es:
“A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement”.
Un conjunto de valores de entrada, precondiciones de ejecución, resultados esperados y postcondiciones de ejecución, desarrollados para un objetivo particular de condición de prueba, tal como para ejercer una ruta de un programa en particular o para verificar el cumplimiento de un requisito específico.
Aunque hay algunos formatos con diferentes tipos de datos, en realidad no podemos considerar un formato único para diseñar casos de prueba, pues las soluciones(aplicaciones/sistemas) siempre son diferentes y para diferentes necesidades, sin embargo, los siguientes puntos, son importantes de considerar para integrarlos a los Casos de Prueba que se vayan a generar:
Identificador: identifica el caso de prueba, puede ser numérico o alfanumérico, la idea es que un caso de prueba se diferencíe de otro caso a través de este indicador.
Nombre del Caso de Prueba: es un nombre descriptivo del caso de prueba, en algunos procesos de calidad se hace necesario cumplir una nomenclatura clara y definida.
Precondición/es: hace referencia a lo que se debe tener listo para la ejecución del caso de prueba, pueden ser la ejecución de otros casos de pruebas, un archivo, la creación de un dato, entre otros.
Pasos: Define las acciones de usuario expresadas en términos de negocio y del aplicativo para la ejecución del caso de prueba, como por ejemplo ingresar el nombre en el campo “Nombre usuario” o hacer clic en el botón “Enviar”.
Resultado esperado: Este apartado es muy importante, porque es el que determina si la ejecución del caso va siendo exitosa por cada paso, en algunos pasos de prueba no es necesario tener siempre un resultado esperado, se recomienda que se utilice en los pasos de mayor importancia para el negocio, como lo puede ser al momento de crear un usuario y se genera una ventana de confirmación, en ese caso si es válido tener un resultado esperado como “Se genera la ventana confirmación de xyz” y se puede apoyar también en una imagen que haga referencia al resultado deseado.
Dato de Prueba: los pasos de pruebas se apoyan en datos, es por esto que por cada paso de prueba se puede hacer necesario especificar cuál es el dato a usar. Como lo puede ser un nombre de usuario, un password, etc.
Resultado Real: como se busca que los casos de pruebas sean reproducibles las veces que sean necesarios, esta opción permite al analista estar registrando los sucesos de cada paso (Donde sea necesario, no implica uno a uno de los pasos).
Pueden agregarse más, pero como se ha mencionado antes va a depender de lo que se está probando.
Ejemplo simple de los datos que se podrían encontrar en un caso de Prueba
