Pruebas ad-hoc: Cómo encontrar defectos sin un proceso formal de pruebas

El propio término ad-hoc implica la falta de estructura o algo que no es metódico. Cuando se habla de pruebas ad-hoc, significa que es una forma de caja negra o pruebas de comportamiento realizadas sin ningún proceso formal.

El proceso formal aquí significa tener documentación como documentos de requisitos, planes de prueba, casos de prueba, y la planificación adecuada de las pruebas en términos de su calendario y el orden de las pruebas realizadas. Además, cualquier acción realizada durante las pruebas no suele estar documentada.

Se realizan principalmente con el objetivo de intentar descubrir defectos o fallos que no pueden ser capturados a través de los procesos tradicionales o formales seguidos durante el ciclo de pruebas.

Como ya se ha entendido, la esencia de estas pruebas radica en no tener una manera formal o estructurada de probar. Cuando se lleva a cabo este tipo de técnicas de pruebas aleatorias, es evidente que los probadores realizan esto sin ningún caso de uso particular en mente con el objetivo de romper el sistema.

Por lo tanto, es definitivamente más obvio que tal metodología de pruebas intuitiva o creativa requiere que el probador sea extremadamente hábil, capaz y tenga un profundo conocimiento del sistema. Las pruebas ad hoc garantizan que las pruebas realizadas sean completas y son particularmente muy útiles para determinar la eficacia del cubo de pruebas.

Lectura recomendada => Pruebas exploratorias – ¿Cómo pensar más allá de los límites de las pruebas tradicionales?

Comencemos con un ejemplo de pruebas ad-hoc

Aquí tenemos un ejemplo de cómo podemos realizar estas pruebas cuando se trata de UI Wizard.

Digamos que necesitas crear un plan o una plantilla para algún tipo de tarea a realizar utilizando este UI wizard. El asistente es una serie de paneles que tienen la entrada del usuario como el nombre, la descripción, etc.

A medida que el asistente avanza: digamos que en uno de los paneles, los datos del usuario es para ser introducido que implica el asistente de interfaz de usuario para lanzar un contexto cuadro emergente que añade los datos asociados para completar el asistente y desplegar / activar el asistente.

Para probar esto el probador hace sus pruebas regulares como:

• Completar el asistente con éxito con todos los datos válidos y crear el plan.
• Cancelar el asistente a mitad de camino.
• Editar un plan creado a través del asistente.
• Borrar el plan creado y ver que no queda ningún residuo del mismo.
• Introducir un valor negativo en el asistente y ver los mensajes de error correspondientes.

Ahora, para el ejemplo anterior aquí hay algunos casos de prueba para pruebas ad-hoc que se podrían realizar para descubrir tantos defectos como sea posible:

Mientras se intenta añadir datos negativos, añadir ciertos caracteres especiales que no están restringidos para ver si se manejan correctamente. Por ejemplo, a veces los asistentes no restringen {o [ llaves pero en ciertas situaciones, esto puede entrar en conflicto con el código basado en el lenguaje en el que está escrito, y causar un comportamiento muy poco fiable.
• Otra prueba es específicamente con respecto a las ventanas emergentes. Un usuario puede hacer que se lance la ventana emergente y luego intentar pulsar el botón de retroceso en el teclado. Muchas veces he observado que al hacerlo, hace que el asistente de fondo desaparezca por completo y todos los datos del usuario que se introdujeron hasta el momento en que se lanzó la ventana emergente, se pierden.

Características de las pruebas Ad-hoc:

Si se fijan en los escenarios anteriores, verán algo muy característico de este tipo de pruebas.

Son:

Siempre están en línea con el objetivo de la prueba. Sin embargo, son ciertas pruebas drásticas realizadas con la intención de romper el sistema.
• El probador necesita tener un completo conocimiento y conciencia sobre el sistema que se está probando. El resultado de esta prueba encuentra errores que intentan poner de manifiesto las lagunas del proceso de prueba.
• También mirando las dos pruebas anteriores, la reacción natural sería que – este tipo de prueba se puede realizar sólo una vez, ya que no es factible para una re-prueba a menos que haya un defecto asociado.

¿Cuándo hacemos pruebas ad-hoc?

Una pregunta del millón, sin duda!

La mayoría de los equipos de prueba siempre están cargados con demasiadas características para probar dentro de plazos limitados. En ese plazo limitado, hay un montón de actividades de prueba que se derivan del proceso formal que también debe completar. En tales situaciones, las pruebas ad-hoc son escasas.

Sin embargo, según mi experiencia, una ronda de pruebas ad-hoc puede hacer maravillas para la calidad del producto y plantear muchas cuestiones de diseño.

Dado que las pruebas ad-hoc son más bien una técnica de prueba «salvaje» que no tiene por qué estar estructurada, la recomendación general es que se realicen después de la ejecución del cubo de pruebas actual. Otro punto de vista es que esto podría hacerse cuando las pruebas detalladas no se pueden realizar debido a la falta de tiempo.

En mi opinión, yo diría que las pruebas ad-hoc se pueden hacer casi en cualquier momento – ¡al principio, hacia la mitad y hacia el final! Simplemente encuentra su lugar en cualquier momento. Sin embargo, el momento en el que se deben realizar las pruebas ad hoc para obtener el máximo valor es mejor que lo juzgue un probador experimentado que tenga un conocimiento profundo del sistema que se está probando.

¿Cuándo no ejecutar?

Si la pregunta anterior valía un millón de dólares, esta debería valer mil millones!

Aunque hemos establecido lo eficaz y fructífero que puede ser el testing ad-hoc, como probador experto y capaz también debemos descifrar cuándo no invertir en este tipo de pruebas. Aunque queda a discreción del probador, aquí hay algunas recomendaciones/ejemplos de cuándo podría no ser necesario.

Evitar estas pruebas cuando hay un caso de prueba para el que existe un defecto. En tal situación es necesario documentar el punto de fallo del caso de prueba y luego verificar/reprobar el defecto cuando se solucione. Por lo tanto, no será aplicable aquí.
• También puede haber ciertos escenarios donde los clientes pueden ser invitados a probar la versión beta del software. En tales casos, esta prueba no debe llevarse a cabo.
• Otro escenario es cuando hay una pantalla de interfaz de usuario muy simple que se añade. Las pruebas tradicionales positivas y negativas deberían ser suficientes aquí para sacar el máximo de defectos.

Tipos de pruebas ad-hoc

Las pruebas ad-hoc se pueden clasificar en tres categorías a continuación:

#1) Buddy Testing

En esta forma de prueba, habrá un miembro de prueba y un miembro de desarrollo que serán elegidos para trabajar en el mismo módulo. Justo después de que el desarrollador complete las pruebas unitarias, el probador y el desarrollador se sientan juntos y trabajan en el módulo. Este tipo de pruebas permite ver la característica en un ámbito más amplio para ambas partes.

El desarrollador obtendrá una perspectiva de todas las diferentes pruebas que el probador ejecuta y el probador obtendrá una perspectiva de cómo es el diseño inherente que le ayudará a evitar el diseño de escenarios no válidos, previniendo así defectos no válidos. Ayudará a uno a pensar como el otro.

#2) Pair Testing

En estas pruebas, dos probadores trabajan juntos en un módulo con la misma configuración de prueba compartida entre ellos. La idea detrás de esta forma de prueba para que los dos probadores de lluvia de ideas y métodos para tener un número de defectos. Ambos pueden compartir el trabajo de las pruebas y hacer la documentación necesaria de todas las observaciones realizadas.

#3) Monkey Testing

Esta prueba se realiza principalmente a nivel de pruebas unitarias. El probador analiza los datos o las pruebas de forma totalmente aleatoria para asegurarse de que el sistema es capaz de soportar cualquier caída. Estas pruebas se pueden clasificar en dos categorías:

Beneficios de las pruebas ad hoc

Estas pruebas garantizan al probador mucho poder para ser tan creativo como sea necesario.

Esto aumenta la calidad de las pruebas y la eficiencia como a continuación:

• La mayor ventaja que se destaca es que un probador puede encontrar el número de defectos que en las pruebas tradicionales debido a los diversos métodos innovadores que pueden aplicar para probar el software.
• Esta forma de prueba se puede aplicar en cualquier parte del SDLC; no sólo se limita al equipo de pruebas. Los desarrolladores también pueden llevar a cabo estas pruebas, lo que les ayudaría a codificar mejor y también a predecir los problemas que podrían producirse.
• Puede combinarse con otras pruebas para obtener los mejores resultados, lo que a veces puede reducir el tiempo necesario para las pruebas habituales. Esto permitiría generar casos de prueba de mejor calidad y mejorar la calidad del producto en su conjunto.
• No obliga a realizar ninguna documentación, lo que evita la carga adicional para el probador. Un probador puede concentrarse en la comprensión real de la arquitectura subyacente.
• En los casos en que no hay mucho tiempo disponible para probar, esto puede llegar a ser muy valioso en términos de cobertura de la prueba y la calidad.

Inconvenientes de las pruebas ad hoc

Las pruebas ad hoc también tienen algunos inconvenientes. Echemos un vistazo a algunos de los inconvenientes que se pronuncian:

Como no está muy organizado y no hay documentación obligatoria, el problema más evidente es que el probador tiene que recordar y rememorar todos los detalles de los escenarios ad-hoc en la memoria. Esto puede ser aún más difícil, especialmente en los escenarios en los que hay mucha interacción entre los diferentes componentes.

Siguiendo con el primer punto, esto también daría lugar a no ser capaz de recrear los defectos en los intentos posteriores si se les pide información.
• Otra cuestión muy importante que esto trae a la luz es la responsabilidad del esfuerzo. Dado que no está planificado/estructurado, no hay forma de contabilizar el tiempo y el esfuerzo invertido en este tipo de pruebas.
• Las pruebas ad hoc sólo deben ser realizadas por un probador muy experto y capacitado en el equipo, ya que exige ser proactivo e intuitivo en cuanto a la previsión de posibles áreas llenas de defectos.

Mejores practicas para hacer estas pruebas mas efectivas

Hemos discutido extensamente las fortalezas y debilidades asociadas con estas pruebas.

De hecho, las pruebas ad-hoc deben encontrar su lugar en el SDLC, sin embargo, si no se enfocan de la manera apropiada pueden resultar costosas y una perdida de tiempo valioso en las pruebas. Así que a continuación se dan algunos consejos para hacer las pruebas ad-hoc efectivas:

#1) Identificar las áreas propensas a los defectos:

Cuando usted tiene un buen control sobre las pruebas de una pieza de software en particular, usted estará de acuerdo en que habrá ciertas características que son más propensas a los errores que las otras. Si usted es nuevo en el sistema, a continuación, seguir adelante y comprobar las características v / s defectos abiertos en contra de ellos.

El número de defectos en una característica particular es le mostrará que es sensible y usted debe elegir precisamente esa área para llevar a cabo las pruebas ad-hoc. Esto resulta ser una forma muy eficiente de tiempo para exponer algunos defectos graves.

#2) Construir experiencia:

Sin duda, un probador que tiene más experiencia es más intuitivo y puede adivinar dónde podrían estar los errores, en comparación con alguien que no tiene mucha experiencia. Yo diría que, con experiencia o sin ella, es el individuo quien debe dar el paso y adquirir experiencia en el sistema que se está probando.

Sí, los probadores con experiencia tienen una ventaja ya que sus habilidades construidas a lo largo de los años son muy útiles, pero los nuevos probadores deben utilizar esto como una plataforma para obtener el mayor conocimiento posible para diseñar mejores escenarios ad-hoc.

#3) Crear categorías de prueba:

Una vez que conozca la lista de características a probar, reserve unos minutos para decidir cómo clasificaría esas características y las probaría. Por ejemplo, debería decidir probar las características más visibles y más usadas por el usuario antes que cualquier otra cosa, ya que éstas parecen ser críticas para el éxito del software.

Entonces podría categorizarlas por funcionalidad/ prioridad y probarlas segmento a segmento.

Otro ejemplo en el que esto es particularmente muy importante es si hay integración entre componentes o módulos. En estos casos, pueden producirse muchas anomalías. Usar la categorización ayudaría a tocar este tipo de pruebas al menos una o dos veces.

#4) Tener un plan aproximado:

Sí, sí este punto puede confundirte un poco ya que describimos las pruebas ad-hoc como pruebas que no deben tener planificación ni documentación. La idea aquí es mantener la esencia de las pruebas ad-hoc, pero aún así, tener algunos puntos aproximados anotados sobre cómo se planea probar.

Un ejemplo muy básico es que a veces no se puede recordar todas las pruebas que se pretende realizar. Así que anotarlas te asegurará que no te pierdas nada.

#5) Herramientas:

Tomemos un ejemplo al que todos nos enfrentamos comúnmente. Muchas veces, si se observa, la prueba de la funcionalidad en sí misma es exitosa sin ninguna discrepancia reportada en su comportamiento. Sin embargo, los registros detrás de las escenas podrían estar reportando algunas excepciones vistas que podrían ser pasadas por alto por los probadores, ya que no obstaculizan el objetivo de la prueba de ninguna manera.

Estos podrían ser incluso de alta gravedad. Por lo tanto, es muy importante para nosotros para aprender y herramientas que ayudarán a identificar esto inmediatamente.

#6) Documento para más defectos:

De nuevo, entiendo que esto puede levantar algunas cejas de nuevo. La documentación no tiene que ser detallada, pero sólo una pequeña nota para su propia referencia de todos los diferentes escenarios cubiertos, la desviación en los pasos involucrados y registrar esos defectos para la categoría de características de prueba en particular.

Esto le ayudará a mejorar el cubo de prueba en general, así por lo que podría decidir cómo improvisar los casos de prueba existentes o añadir más si es necesario.

Conclusión

Hemos discutido en detalle sobre las técnicas de prueba ad-hoc – sus fortalezas, debilidades, situaciones en las que sería y no sería beneficioso.

Esta es una técnica de prueba que garantiza atender y satisfacer la creatividad de un probador al máximo. En toda mi carrera de pruebas, obtengo la máxima satisfacción de las pruebas ad hoc, ya que no hay límite para ser innovador y sólo terminas siendo más conocedor.

Habiendo dicho esto, lo principal a tomar de toda la información anterior sería determinar cómo aprovechar las fortalezas de las pruebas ad hoc y hacer que agreguen valor al proceso de prueba general y a la calidad del producto.

Acerca del autor: Este es un artículo invitado de Sneha Nadig. Ella trabaja como líder de pruebas con más de 7 años de experiencia en proyectos de pruebas manuales y de automatización.

¿Realizas pruebas ad-hoc en tu proyecto? ¿Cuáles son sus sugerencias para que las pruebas ad-hoc tengan éxito?