Las pruebas, tienen como objetivo buscar errores, y estas deben planearse por adelantado.
- Pero para que esto se logre, primero deben llevarse a cabo revisiones técnicas para eliminar errores en las pruebas.
- Iniciamos en un componente y progresamos hacia afuera
- Las realizan los mismos desarrolladores de software y a veces un grupo de pruebas.
Las pruebas se realizan en el siguiente orden.
CODIGO -> PRUEBA UNITARIA -> DISEÑO -> PRUEBA DE INTEGRACION -> REQUERIMIENTOS -> PRUEBAS DE ALTO NIVEL.
Iniciamos validando que un trozo de código sirva, para luego agregarlo al sistema y realizarse pruebas de alto nivel que sirven para validar las funciones principales del sistema con los requerimientos del cliente.
Verificación y Validación¶
Conocido como V&V, la verificación es asegurarse que el software implemente la función específica correcta, mientras que la validación es asegurarse que el software que se creó pueda identificarse con los requerimientos del cliente.
Verificar la V&V abarca varias actividades de las ACS, revisiones técnicas, auditorias de calidad y configuraciones.
Cómo organizar las pruebas de software¶
Primero, no debemos ver una prueba como un ataque, no buscamos ofender a nadie, lo que buscamos es minimizar errores.
Evitemos creer las siguientes afirmaciones - El desarrollado de software no debe realizar ninguna prueba - El software será masacrado y tratado sin piedad - Los tester solo se deben involucrar en la prueba y no en el proceso de desarrollo.
El desarrollador también debe realizar pruebas, y es común que este lleve a cabo las pruebas unitarias mientras desarrolla, al igual que es común que una unica persona realice las pruebas de integración, pero a medida que el proyecto crezca, se deberá contratar a un ITG (Grupo de pruebas independientes) que realicen las pruebas de integración para quitar carga en los desarrolladores.
las pruebas unitarias se enfocan en cada componente individual. Mientras que las pruebas de integración abordan problemas duales de verificación y construcción del programa.
Una vez se ha integrado el bloque de código, lo siguiente es realizar pruebas de alto orden, estas pruebas de alto orden, quedan fuera del proceso de ingeniería de software, estas pruebas validan que el software cumple con todos los requisitos funcionales, de comportamiento y rendimiento esperados.
¿Cómo sé cuando ya está listo mi componente (modulo)?¶
No hay una respuesta, simplemente cuando hemos completado los requerimientos que estaban en nuestra tabla CRT, entonces ya podemos empezar a buscar fallas o comportamientos ausentes una vez se ha verificado y validado.
Planificación y mantenimiento de registros¶
Se debe planificar cuándo realizar las pruebas y quien las hará antes del primer spirnt (suponiendo que seguimos la metodología ágil SCRUM), pero lo importantes es dejarlo en claro antes de programar, y todos deben estar enterados, no es algo complejo, podemos usar un excel colaborativo, lo importantes es que todos sepan cuándo se hará.
Andamiaje (Scaffolding)¶
El concepto de andamiaje, es la creación de estructuras de control que nos sirvan para probar componentes cuando algo no es existente o queremos simplemente aislar el comportamiento. En este caso, generaremos "stubs/sub programas falsos", o "drivers/controladores" para simular un componente y facilitar las pruebas.
Cuando diseñamos pruebas, necesitamos de un conjunto de casos de pruebas, resultados esperados, y controladores o stubs.
Diseño de casos de prueba¶
Primero, debemos definir rutas de prueba independientes, mediante estructuras de control que no se repita en instrucciones, es decir, rutas en un grafo en las que no sean combinación de sub secuencias seguidas. Diseñar estas tareas simplemente serán las que nos permitan minimizar errores. a esto le llamaremos antibugging
Requerimientos y casos de uso¶
Lo sugerido es iniciar recolectando requerimientos, y con esto vamos a generar historias de usuarios, para que a posteriori, un desarrollador convierta estas historias en casos de uso, estos casos de uso, nos servirán para crear casos de prueba. Respecto a cómo definir el margen de error aceptable, no hay un proceso definido, la persona a cargo irá calculándolos en base a su experiencia.
Los casos de uso nos ayudarán a generar tanto casos de prueba que contendrán las cosas correctas a esperar como los casos negativos, y saber cómo debemos responder a estos casos negativos.
Rastreabilidad¶
Muchos desarrolladores ágiles se niegan a aceptar que una prueba debe ser rastreable hasta el caso de uso, pues le ponen más carga al desarrollador, sin embargo, asegurarse que los casos de prueba se rastreen hasta los requerimientos es importante para las pruebas de componentes futuros.
Pruebas estructurales¶
Prueba de caja blanca¶
Busca ejecutar cada instrucción al menos una vez, por lo que buscamos enlaces y bordes que nos ayuden a generar un grafo, una vez tenemos el grafo, tenemos que buscar todos los posibles flujos de datos para generar el grafo y saber cuántas pruebas debemos calcular.
Hablaremos ahora de enlaces y regiones, la primera es el conjunto de rutas disponibles y el segundo es el no. de paradas que hay. al final, tendremos que aplicar estrategias de ruta para conocer si el sistema responde a distintas rutas.
Pruebas de ruta base¶
Una ruta independiente es cualquier ruta que introduce al menos un nuevo conjunto de declaraciones si y solo si recorre nuevos bordes
Por ende, vamos a diseñar para forzar la ejecución de todas esas rutas. La complejidad ciclomática es una métrica de software que nos dice el no. de rutas que pueden haber para un grafo, y nos da el limite superior de pruebas que podemos realizar para asegurar el funcionamiento
E = no. de bordes
N = no. nodos