Menú

Pruebas ad-hoc: cómo encontrar defectos sin un proceso de prueba formal

ad hoc testing how find defects without formal testing process

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

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

El proceso formal aquí significa tener documentación como documentos de requisitos, planes de prueba, casos de prueba y una planificación de prueba adecuada en términos de su cronograma y orden de las pruebas realizadas. Además, las acciones realizadas durante las pruebas no suelen estar documentadas.

Pruebas ad-hoc

Esto se hace principalmente con el objetivo de intentar descubrir defectos o fallas que no pueden ser capturados a través de procesos formales o tradicionales seguidos durante el ciclo de prueba.

Como ya se entendió, la esencia de esta prueba radica en no tener una forma formal o estructurada de prueba. Cuando se realiza este tipo de técnicas de prueba 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, definitivamente es aún más obvio que una metodología de prueba tan intuitiva o creativa requiere que el probador sea extremadamente hábil, capaz y tenga un conocimiento profundo del sistema. Las pruebas ad-hoc aseguran que las pruebas realizadas estén completas y son particularmente muy útiles para determinar la efectividad del cubo de prueba.

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

Lo que vas a aprender:

Comencemos con un ejemplo de prueba ad-hoc

A continuación, se muestra un ejemplo de cómo podemos realizar estas pruebas cuando se trata de UI Wizard.

Supongamos que necesita crear un plan o una plantilla para que se realice algún tipo de tarea con este asistente de interfaz de usuario. El asistente es una serie de paneles que tienen entradas de usuario como nombre, descripción, etc.

A medida que avanza el asistente: digamos en uno de los paneles, se deben ingresar los datos del usuario, lo que implica que el asistente de la interfaz de usuario lance un cuadro emergente de contexto que agrega los datos asociados para completar el asistente y desplegar / activar el asistente.

Para probar, este probador realiza sus pruebas regulares como:

¿Qué herramienta puede utilizar para representar y analizar visualmente una base de datos?
  • Complete el asistente con éxito con todos los datos válidos y cree el plan.
  • Cancele el asistente a mitad de camino.
  • Edite un plan creado a través del asistente.
  • Elimine el plano creado y compruebe que no quede ningún residuo.
  • Ingrese un valor negativo en el asistente y vea los mensajes de error correspondientes.

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

  • Al intentar agregar datos negativos, agregue 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 idioma en el que está escrito y causar un comportamiento muy poco confiable.
  • Otra prueba es específicamente con respecto a las ventanas emergentes. Un usuario puede hacer que se inicie la ventana emergente y luego intentar presionar el botón de retroceso en el teclado. Muchas veces he observado que al hacerlo, el asistente en segundo plano desaparece por completo y se pierden todos los datos del usuario que se ingresaron hasta el momento en que se lanzó la ventana emergente.

Características de las pruebas ad-hoc:

Si observa los escenarios anteriores, verá características muy distintas de este tipo de pruebas.

Son:

  • Siempre están alineados con el objetivo de la prueba. Sin embargo, son ciertas pruebas drásticas realizadas con la intención de romper el sistema.
  • El probador debe tener conocimiento y conocimiento completos sobre el sistema que se está probando. El resultado de esta prueba encuentra errores que intentan resaltar las lagunas del proceso de prueba.
  • También al observar las dos pruebas anteriores, la reacción natural sería que: este tipo de prueba se puede realizar solo una vez, ya que no es factible volver a realizar la prueba a menos que haya un defecto asociado.

¿Cuándo hacemos pruebas ad-hoc?

¡Ciertamente una pregunta de un millón de dólares!

La mayoría de los equipos de prueba siempre están cargados con demasiadas funciones para probar en plazos limitados. En ese lapso de tiempo limitado, hay muchas actividades de prueba que se derivan del proceso formal que también deben completarse. En tales situaciones, las pruebas ad-hoc que llegan a las pruebas son escasas.

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

Dado que las pruebas ad-hoc son más una técnica de prueba 'salvaje' que no tiene que estar estructurada, la recomendación general es que se deben realizar después de que se complete la ejecución del depósito de prueba actual. Otro punto de vista es que esto podría hacerse cuando no se pueden realizar pruebas detalladas debido a menos tiempo.

En mi opinión, diría que Las pruebas ad-hoc se pueden realizar casi en cualquier momento: ¡al principio, hacia el medio y hacia el final! Simplemente encuentra su lugar en un momento dado. Sin embargo, cuando se deben realizar pruebas ad-hoc para obtener el máximo valor, lo mejor es un evaluador experimentado que tenga un conocimiento profundo sobre el sistema que se está probando.

¿Cuándo no ejecutar?

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

Si bien hemos establecido cuán efectivas y fructíferas pueden ser las pruebas ad-hoc, como probadores hábiles y capaces 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 cuando podría no ser necesario.

  • Evite esta prueba cuando haya un caso de prueba en el que exista un defecto. En tal situación, es necesario documentar el punto de falla del caso de prueba y luego verificar / volver a probar el defecto cuando se solucione. Por lo tanto, no será aplicable aquí.
  • También puede haber ciertos escenarios donde los clientes o clientes pueden ser invitados a probar la versión beta del software . En tales casos, esta prueba no debe realizarse.
  • Otro escenario es cuando se agrega una pantalla de interfaz de usuario muy simple. Las pruebas tradicionales positivas y negativas deberían ser suficientes aquí para resaltar los defectos máximos.

Tipos de pruebas ad-hoc

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

# 1) Prueba de amigos

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 del el desarrollador completa la prueba unitaria , la probador y desarrollador se sientan juntos y trabajar en el módulo. Este tipo de prueba permite que la función se vea en un ámbito más amplio para ambas partes.

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

# 2) Prueba de pareja

En esta prueba, 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 es que los dos evaluadores intercambien ideas y métodos para tener una serie de defectos. Ambos pueden compartir el trabajo de prueba y hacer la documentación necesaria de todas las observaciones realizadas.

# 3) Prueba de mono

Esta prueba se realiza principalmente a nivel de prueba unitaria. El probador analiza los datos o las pruebas de una manera completamente aleatoria para garantizar que el sistema sea capaz de resistir cualquier bloqueo. Esta prueba se puede clasificar además en dos categorías:

diferencia entre el servidor cliente y la aplicación basada en web

Beneficios de las pruebas ad-hoc

La prueba garantiza que el evaluador con mucho poder sea tan creativo como sea necesario.

Esto aumenta la calidad y la eficiencia de las pruebas de la siguiente manera:

  • La mayor ventaja que se destaca es que un evaluador puede encontrar la cantidad 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 lugar del SDLC; no solo está restringido al equipo de pruebas. Los desarrolladores también pueden realizar estas pruebas, lo que les ayudaría a codificar mejor y también a predecir qué problemas podrían ocurrir.
  • Se puede combinar con otras pruebas para obtener los mejores resultados, lo que a veces puede acortar el tiempo necesario para las pruebas regulares. Esto permitiría generar casos de prueba de mejor calidad y una mejor calidad del producto en general.
  • No exige que se realice ninguna documentación, lo que evita la carga adicional para el evaluador. Un evaluador puede concentrarse en comprender realmente la arquitectura subyacente.
  • En los casos en que no hay mucho tiempo disponible para realizar la prueba, esto puede resultar muy valioso en términos de cobertura y calidad de la prueba.

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 manifiestan:

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

  • Seguido desde el primer punto, esto también resultaría en no poder recrear defectos en los intentos posteriores si se solicita información.
  • Otra cuestión muy importante que esto saca a la luz es la responsabilidad del esfuerzo. Dado que esto no está planificado / estructurado, no hay forma de contabilizar el tiempo y el esfuerzo invertidos en este tipo de pruebas.
  • Las pruebas ad-hoc solo deben ser realizadas por un probador muy experimentado y capacitado en el equipo, ya que exige ser proactivo e intuitivo en términos de prever áreas potenciales con defectos.

Mejores prácticas para que esta prueba sea más eficaz

Hemos discutido en detalle las fortalezas y debilidades asociadas con esta prueba.

Idealmente, las pruebas ad-hoc deberían encontrar su lugar en el SDLC; sin embargo, si no se abordan de la manera adecuada, pueden resultar costosas y una pérdida de tiempo de prueba valioso. A continuación, se muestran algunos consejos para hacer que las pruebas ad-hoc sean efectivas:

# 1) Identifique las áreas propensas a defectos:

Cuando tenga un buen control sobre la prueba de una pieza de software en particular, estará de acuerdo en que habrá ciertas características que son más propensas a errores que otras. Si es nuevo en el sistema, continúe y verifique las características v / s defectos abiertos en su contra.

La cantidad de defectos en una característica en particular le mostrará que es sensible y debe elegir precisamente esa área para realizar pruebas ad-hoc. Esto demuestra ser una forma muy eficiente de exponer algunos defectos graves.

# 2) Construyendo experiencia:

Sin duda, un tester que tiene más experiencia es más intuitivo y puede adivinar dónde pueden estar los errores, en comparación con alguien que no tiene mucha experiencia. Yo diría que, con experiencia o no, depende de la persona dar el paso y desarrollar experiencia en el sistema que se está probando.

Sí, los probadores experimentados tienen una ventaja, ya que sus habilidades adquiridas a lo largo de los años son útiles, pero los nuevos evaluadores deberían usar esto como una plataforma para obtener la mayor cantidad de conocimiento posible para diseñar mejores escenarios ad-hoc.

# 3) Cree categorías de prueba:

Una vez que conozca la lista de funciones que se probarán, reserve unos minutos para decidir cómo categorizar esas funciones y probarlas. Por ejemplo, antes que nada, debe decidir probar las funciones que son más visibles y más utilizadas por el usuario, ya que estas parecen fundamentales para el éxito del software.

Luego, podría clasificarlos en función de su funcionalidad / prioridad y probarlos segmento por 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 ocurrir muchas anomalías. Usar la categorización ayudaría a abordar este tipo de prueba al menos una o dos veces.

# 4) Tenga un plan aproximado:

Sí, sí, este punto podría confundirlo un poco, ya que describimos las pruebas ad-hoc como pruebas que no deberían tener planificación ni documentación. La idea aquí es ceñirse a la esencia de las pruebas ad-hoc, pero aún así, anote algunos consejos generales sobre cómo planea realizar la prueba.

Un ejemplo muy básico es que a veces es posible que no pueda recordar todas las pruebas que desea realizar. Por lo tanto, anotarlos aseguraría que no se pierda nada.

# 5) Herramientas:

Tomemos un ejemplo al que nos enfrentamos todos con mucha frecuencia. Muchas veces, si observa, la prueba de la funcionalidad en sí misma es exitosa y no se informa ninguna discrepancia en su comportamiento. Sin embargo, los registros detrás de escena podrían estar informando algunas excepciones observadas que los probadores podrían pasar por alto, ya que no obstaculiza el objetivo de la prueba de ninguna manera.

Estos podrían ser incluso de gravedad alta. Por lo tanto, es muy importante que aprendamos y herramientas que nos ayuden a identificar esto de inmediato.

# 6) Documento para más defectos:

Una vez más, entiendo que esto puede volver a levantar algunas cejas. La documentación no tiene que ser detallada, sino solo 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ística de prueba en particular.

Esto le ayudará a mejorar el grupo de pruebas general y, además, podrá decidir cómo improvisar casos de prueba existentes o agregar más si es necesario.

Conclusión

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

Esta es una técnica de prueba que garantiza satisfacer y satisfacer al máximo la creatividad de un evaluador. En mi totalidad carrera de prueba , Obtengo la máxima satisfacción de las pruebas ad-hoc, ya que no hay límite para innovar y solo terminas teniendo más conocimientos.

Habiendo dicho eso, lo principal a recuperar 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 la calidad del producto.

Sobre el Autor: Este es un artículo invitado de Sneha Nadig. Trabaja como líder de pruebas con más de 7 años de experiencia en proyectos de pruebas manuales y de automatización.

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

Lectura recomendada

^