Pruebas ad hoc
¿Qué son las pruebas ad hoc?
Cuando una prueba de software se realiza sin una planificación y documentación adecuadas, se dice que es una prueba ad hoc. Este tipo de pruebas se ejecutan solo una vez a menos que descubramos los defectos.
Las pruebas ad hoc se realizan después de realizar pruebas formales en la aplicación. Los métodos ad hoc son el tipo de prueba menos formal, ya que NO es un enfoque estructurado. Por lo tanto, los defectos encontrados con este método son difíciles de replicar ya que no hay casos de prueba alineados para esos escenarios.
Las pruebas se llevan a cabo con el conocimiento del probador sobre la aplicación y el probador prueba aleatoriamente sin seguir las especificaciones / requisitos. Por lo tanto, el éxito de las pruebas Adhoc depende de la capacidad del evaluador, que realiza la prueba. El probador tiene que encontrar defectos sin una planificación y documentación adecuadas, basándose únicamente en la intuición del probador.
¿Cuándo realizar pruebas ad hoc?
Las pruebas ad hoc se pueden realizar cuando hay un tiempo limitado para realizar pruebas exhaustivas y, por lo general, se realizan después de la ejecución de la prueba formal. Las pruebas ad hoc serán efectivas solo si el probador tiene un conocimiento profundo del sistema bajo prueba.
Formas de pruebas ad hoc:
Buddy Testing: Dos amigos, uno del equipo de desarrollo y otro del equipo de prueba, trabajan mutuamente para identificar defectos en el mismo módulo. Las pruebas de amigos ayudan a los probadores a desarrollar mejores casos de prueba, mientras que el equipo de desarrollo también puede realizar cambios de diseño temprano. Este tipo de prueba ocurre generalmente después de completar la prueba unitaria.
Pair Testing: A dos probadores se les asignan los mismos módulos y comparten ideas y trabajan en los mismos sistemas para encontrar defectos. Un evaluador ejecuta las pruebas mientras que otro registra las notas sobre sus hallazgos.
Monkey Testing: Las pruebas se realizan aleatoriamente sin ningún caso de prueba para romper el sistema.
Varias formas de hacer que las pruebas adhoc sean más efectivas
Preparation: Al obtener los detalles del defecto de una aplicación similar, la probabilidad de encontrar defectos en la aplicación es mayor.
Creating a Rough Idea: Al crear una idea aproximada en su lugar, el evaluador tendrá un enfoque enfocado. NO es necesario documentar un plan detallado sobre qué probar y cómo probar.
Divide and Rule: Al probar la aplicación parte por parte, tendremos un mejor enfoque y una mejor comprensión de los problemas, si los hay.
Targeting Critical Functionalities: Un evaluador debe apuntar a aquellas áreas que NO están cubiertas al diseñar casos de prueba.
Using Tools: Los defectos también se pueden sacar a la luz mediante el uso de perfiladores, depuradores e incluso monitores de tareas. Por lo tanto, si se domina el uso de estas herramientas, se pueden descubrir varios defectos.
Documenting the findings:Aunque las pruebas se realizan al azar, es mejor documentar las pruebas si el tiempo lo permite y anotar las desviaciones, si las hay. Si se encuentran defectos, se crean los casos de prueba correspondientes para ayudar a los probadores a volver a probar el escenario.