Las pruebas ad hoc son un tipo de pruebas de software que los desarrolladores y las empresas de software aplican cuando comprueban la iteración actual del software. Esta forma de prueba proporciona un mayor nivel de comprensión del programa, localizando problemas que las pruebas convencionales podrían ser incapaces de poner de relieve.
Es primordial que los equipos de pruebas conozcan a fondo el proceso de pruebas ad hoc para saber cómo sortear sus dificultades y asegurarse de que el equipo puede aplicar con éxito esta técnica.
Saber exactamente cómo funcionan las pruebas ad hoc y qué herramientas pueden facilitar su aplicación permite a una empresa mejorar continuamente sus propios procedimientos de garantía de calidad. El proceso formal de pruebas sigue unas normas muy concretas, lo que puede dar lugar a que el equipo pase por alto ciertos fallos. Las comprobaciones ad hoc pueden sortear estos puntos ciegos y probar rápidamente todas las funciones del software.
En este artículo, examinamos de cerca las pruebas ad hoc y cómo puede utilizarlas en su beneficio a la hora de desarrollar un producto de software.
Significado de las pruebas ad hoc: ¿Qué son las pruebas ad hoc?
Las pruebas ad hoc son un proceso de aseguramiento de la calidad que evita las normas formales y la documentación, lo que ayuda a los probadores a encontrar errores en su aplicación que los enfoques convencionales no pueden identificar. Esto suele requerir un conocimiento exhaustivo del software antes de iniciar las pruebas, incluida la comprensión del funcionamiento interno del programa. El objetivo de estas comprobaciones ad hoc es romper la aplicación de forma que refleje la entrada del usuario, teniendo en cuenta varias situaciones potenciales para que los desarrolladores puedan parchear cualquier problema existente.
La falta de documentación es fundamental en esta técnica, que no incluye listas de comprobación ni casos de prueba para guiar a los probadores a través de las características de una aplicación. Las pruebas ad hoc consisten exclusivamente en probar el software de la forma que el equipo decida que es eficaz en ese momento concreto. Esto podría tener en cuenta pruebas formales preexistentes, pero también podría implicar simplemente la realización de tantas pruebas como sea posible en el tiempo (probablemente limitado) que se asigna a esta técnica.
1. ¿Cuándo y por qué es necesario realizar pruebas ad hoc en las pruebas de software?
La principal razón por la que las empresas realizan pruebas ad hoc es su capacidad para descubrir errores que los enfoques tradicionales no pueden hallar. Esto puede deberse a varias razones, como que los casos de prueba convencionales siguen un proceso especialmente estandarizado que no puede tener en cuenta la idiosincrasia de una aplicación.
Cada tipo de prueba puede ofrecer nuevas perspectivas y enfoques interesantes para garantizar la calidad, lo que también pone de manifiesto los problemas que plantea la estrategia de pruebas habitual. Por ejemplo, si las pruebas ad hoc pueden identificar un problema que los casos de prueba del equipo no abordan, esto sugiere que podrían beneficiarse de recalibrar su metodología de pruebas.
Los probadores pueden realizar comprobaciones ad hoc en cualquier momento del proceso de prueba. Esto suele servir de complemento a la garantía de calidad tradicional (y más formal) y, teniendo esto en cuenta, los probadores pueden realizar inspecciones ad hoc mientras sus colegas llevan a cabo exámenes más formales. Sin embargo, es posible que prefieran dejar las comprobaciones ad hoc para después del proceso de pruebas formales, como un seguimiento que aborde específicamente los posibles puntos ciegos.
Las pruebas ad hoc también pueden ser útiles cuando el tiempo es especialmente limitado debido a la falta de documentación; el momento adecuado depende de la empresa y de su enfoque preferido.
2. Cuando no es necesario realizar pruebas ad hoc
Si no hay tiempo suficiente para realizar pruebas ad hoc y formales, es importante que el equipo dé prioridad a estas últimas, ya que garantizan una cobertura sustancial de las pruebas, aunque sigan existiendo algunas lagunas.
Si las pruebas formales del equipo detectan errores que deben corregirse, suele ser mejor esperar a que los desarrolladores completen los cambios necesarios para realizar comprobaciones ad hoc. De lo contrario, los resultados que ofrezcan podrían quedar obsoletos muy pronto, sobre todo si las pruebas se refieren al componente que ya está experimentando fallos.
Además, las pruebas ad hoc deben realizarse antes de la fase de pruebas beta.
3. ¿Quién participa en las pruebas ad hoc?
En el proceso de pruebas ad hoc intervienen varias funciones clave:
– Los probadores de software son los principales miembros del equipo que realizan comprobaciones ad hoc. Si se realizan pruebas por parejas, varios de estos evaluadores trabajarán juntos en los mismos componentes.
– Los desarrolladores pueden utilizar de forma independiente estas comprobaciones antes de la fase formal de aseguramiento de la calidad para inspeccionar rápidamente su propio software, aunque con menor profundidad que las pruebas ad hoc dedicadas.
– Los jefes de equipo o de departamento autorizan la estrategia general de pruebas, ayudando a los probadores a determinar cuándo empezar las pruebas ad hoc y cómo realizarlas sin interrumpir otros controles.
Ventajas de las pruebas ad hoc
Entre las ventajas de las pruebas ad hoc en las pruebas de software se incluyen:
1. Resoluciones rápidas
Como estas pruebas no implican una documentación frecuente antes, durante o después de las comprobaciones, los equipos pueden identificar los problemas mucho más rápidamente. Esta simplicidad ofrece una enorme libertad a los probadores.
Por ejemplo, si prueban un componente y no pueden identificar ningún error, el equipo puede simplemente pasar a la siguiente prueba sin anotarlo en un documento.
2. Complementa otros tipos de pruebas
Ninguna estrategia de pruebas es perfecta, y suele ser imposible lograr una cobertura del 100%, incluso con un programa exhaustivo. Siempre habrá lagunas en las pruebas convencionales, por lo que es importante que las empresas integren múltiples enfoques.
El objetivo de las pruebas ad hoc es detectar los problemas que las pruebas formales no pueden cubrir, lo que garantiza una mayor cobertura global de las pruebas.
3. Ejecución flexible
Las pruebas ad hoc pueden realizarse en cualquier momento del proceso de control de calidad antes de las pruebas beta, lo que permite a las empresas y los equipos decidir cuándo es mejor ejecutar estas comprobaciones. Pueden optar por realizar pruebas ad hoc junto con las pruebas convencionales o pueden esperar hasta después; sea como sea, el equipo se beneficia de las opciones que tiene a su disposición.
4. Mayor colaboración
Los desarrolladores están más implicados en este proceso que en muchas otras formas de pruebas, sobre todo si la empresa utiliza las pruebas por parejas y por compañeros.
Como resultado, los desarrolladores obtienen una mejor visión de sus propias aplicaciones y podrían ser capaces de abordar los errores con un mayor nivel de calidad. Esto ayuda a mejorar aún más la calidad general del software.
5. 5. Perspectivas diversas
Las pruebas ad hoc pueden mostrar la aplicación desde nuevos ángulos, ayudando a los probadores a interactuar con estas funciones de nuevas maneras. Las perspectivas adicionales son fundamentales a lo largo de las pruebas, ya que las comprobaciones formales suelen tener al menos pequeñas lagunas.
Si los probadores ad hoc utilizan el software con la intención específica de romperlo, podrán señalar los límites del programa con mayor facilidad.
Retos de las pruebas ad hoc
El proceso de pruebas ad hoc también presenta varios retos, como:
1. Dificultad para informar
La falta de documentación hace que las pruebas ad hoc sean mucho más rápidas, pero también puede dificultar la elaboración de informes para cualquier cosa que no sea un problema grave.
Por ejemplo, una comprobación realizada con anterioridad podría adquirir mayor relevancia en una fecha posterior a pesar de no haber dado lugar inicialmente a resultados significativos. Sin una documentación exhaustiva, el equipo podría no ser capaz de explicar estas pruebas.
2. Menos repetible
En la misma línea, es posible que los probadores no sean plenamente conscientes de la condición exacta necesaria para provocar las reacciones que observan. Por ejemplo, una comprobación ad hoc que devuelva un error puede no tener información suficiente para que el equipo tome medidas. Es posible que no sepan cómo repetir esta prueba y obtener el mismo resultado.
3. Requiere experiencia en software
Como la velocidad es clave en las pruebas ad hoc y suelen implicar intentar romper la aplicación, es importante que estos probadores conozcan a fondo este programa.
Saber cómo funciona permite a los probadores romper y manipular el software de más formas, pero esto podría aumentar significativamente la exigencia de habilidades para las pruebas ad hoc.
4. 4. Responsabilidad limitada
La falta de documentación puede causar más problemas que unos informes deficientes; también puede alargar inadvertidamente el proceso de pruebas, afectando a la utilidad de las pruebas rápidas individuales ad hoc.
Los encargados de las pruebas pueden tener dificultades para seguir sus progresos si no disponen de documentación suficiente a lo largo de cada etapa. Esto puede incluso llevarles a repetir una comprobación que otros probadores ya han realizado.
5. Puede no reflejar la experiencia del usuario
El objetivo de prácticamente todos los tipos de pruebas es tener en cuenta los errores que afectan de algún modo a los usuarios finales. Las pruebas ad hoc se basan principalmente en un probador experimentado que intenta emular a un usuario inexperto, y esto debe ser coherente en cada comprobación, incluidos sus intentos de romper la aplicación.
Características de las pruebas ad hoc
Las principales características de las pruebas ad hoc exitosas son:
1. Investigación
La principal prioridad de las pruebas ad hoc es identificar errores de la aplicación mediante técnicas que las comprobaciones convencionales no tienen en cuenta. Los exámenes ad hoc recorren este software con el propósito expreso de encontrar agujeros en el procedimiento de pruebas del equipo, incluida la cobertura de sus casos de prueba.
2. No estructurado
Las comprobaciones ad hoc no suelen tener un plan establecido más allá de la realización de tantas pruebas como sea posible fuera de los límites típicos de la garantía de calidad formal. Los encargados de las pruebas suelen agrupar las comprobaciones por componentes para mayor comodidad, pero ni siquiera esto es necesario: incluso pueden idear las comprobaciones mientras las realizan.
3. Basado en la experiencia
Los probadores ad hoc utilizan su experiencia previa en software para evaluar qué pruebas aportarían más beneficios y abordar los puntos ciegos habituales en las pruebas formales.
Aunque el proceso de comprobación sigue siendo totalmente desestructurado, los comprobadores aplican sus conocimientos de comprobaciones ad hoc anteriores, entre otros, a la hora de decidir su estrategia.
4. Amplia
No existen guías exactas sobre qué comprobaciones debe realizar el equipo durante las pruebas ad hoc, pero suelen abarcar una serie de componentes, posiblemente centrándose más en los aspectos más delicados de la aplicación. Esto ayuda a los probadores a garantizar que sus exámenes puedan complementar plenamente las pruebas formales.
¿Qué probamos en las pruebas ad hoc?
Los equipos de control de calidad suelen probar lo siguiente durante las pruebas ad hoc:
1. Calidad del software
Estas comprobaciones pretenden identificar errores en la aplicación que las pruebas convencionales no pueden descubrir; esto significa que el proceso comprueba principalmente la salud general de la aplicación.
Cuantos más errores puedan localizar las pruebas ad hoc, más mejoras podrán aplicar los desarrolladores antes de que se cumpla el plazo.
2. Casos de prueba
Por lo general, las pruebas ad hoc no implementan casos de prueba, y esto es específicamente para que el equipo pueda investigar su eficacia a la hora de proporcionar una amplia cobertura. Es probable que los casos de prueba sean inadecuados si las comprobaciones ad hoc pueden encontrar errores que los procesos de prueba convencionales no pueden.
3. Personal de pruebas
El objetivo también podría ser comprobar las habilidades y conocimientos del equipo de pruebas, incluso si los casos de prueba son adecuados. Por ejemplo, su metodología de aplicación de los casos puede ser insuficiente y las pruebas ad hoc podrían ser fundamentales para subsanar las lagunas resultantes en la cobertura de las pruebas.
4. Límites del software
Las pruebas ad hoc también pretenden conocer los límites de la aplicación, por ejemplo, cómo responde a entradas inesperadas o a cargas elevadas del sistema. Los probadores podrían investigar específicamente los mensajes de error del programa y el rendimiento de esta aplicación cuando está sometida a una presión importante.
Aclarar algunas confusiones:
Pruebas ad hoc y pruebas exploratorias
Algunas personas consideran que las pruebas ad hoc y las exploratorias son sinónimos, aunque la verdad es más complicada que esto.
1. ¿Qué es la prueba exploratoria?
Las pruebas exploratorias son procedimientos de aseguramiento de la calidad que investigan el software desde un punto de vista holístico y combinan específicamente los procesos de descubrimiento y prueba en un único método. Suele ser un término medio entre las pruebas totalmente estructuradas y las comprobaciones ad hoc totalmente libres.
Las pruebas exploratorias funcionan mejor en situaciones específicas, como cuando se necesita una retroalimentación rápida o si el equipo debe abordar casos extremos. Este tipo de pruebas suele alcanzar todo su potencial cuando el equipo las complementa con pruebas guionizadas.
2. Diferencias entre las pruebas exploratorias
y pruebas ad hoc
La mayor diferencia entre las pruebas ad hoc y las exploratorias es que las primeras utilizan documentación para registrar y facilitar sus comprobaciones, mientras que las primeras las evitan por completo. Las pruebas exploratorias ponen más énfasis en la libertad de las pruebas, pero nunca al mismo nivel que un enfoque ad hoc, totalmente desestructurado.
Las pruebas exploratorias también implican aprender sobre la aplicación y su funcionamiento interno durante estas comprobaciones; en cambio, los probadores ad hoc suelen tener un conocimiento exhaustivo de la funcionalidad del software antes de empezar.
Tipos de pruebas ad hoc
Existen tres formas principales de pruebas ad hoc en las pruebas de software:
1. Pruebas con monos
Tal vez el tipo más popular de pruebas ad hoc, las pruebas del mono son aquellas en las que un equipo examina aleatoriamente diferentes componentes.
Suele tener lugar durante el proceso de pruebas unitarias y ejecuta una serie de comprobaciones sin casos de prueba. Los probadores investigan los datos de forma independiente y completamente desestructurada, lo que les permite examinar el sistema en su conjunto y su capacidad para resistir la intensa tensión de las entradas de los usuarios.
Observar el resultado de estas técnicas sin script ayuda al equipo de pruebas a identificar errores que otras pruebas unitarias han pasado por alto debido a las deficiencias de los métodos de prueba convencionales.
2. Pruebas de compañeros
En un contexto ad hoc, las pruebas «buddy» utilizan un mínimo de dos miembros del personal -normalmente un probador y un desarrollador- y tienen lugar principalmente después de la fase de pruebas unitarias. Los «compañeros» trabajan juntos en el mismo módulo para detectar errores. Sus diversos conjuntos de habilidades y su amplia experiencia les convierten en un equipo más eficaz, lo que ayuda a paliar muchos de los problemas que surgen debido a la falta de documentación.
El desarrollador puede incluso sugerir algunas de las pruebas, permitiéndole identificar los componentes que necesitan más atención.
3. Pruebas por parejas
Las pruebas por parejas son similares, ya que implican a dos miembros del personal, pero suele tratarse de dos probadores distintos, uno de los cuales ejecuta las pruebas reales mientras el otro toma notas.
Incluso sin una documentación formal, la toma de notas puede permitir al equipo realizar un seguimiento informal de las comprobaciones individuales ad hoc. Los papeles de probador y escriba pueden cambiar en función de la prueba o la pareja puede mantener sus papeles asignados durante todo el proceso.
El probador que tiene más experiencia suele ser el que realiza las comprobaciones reales, aunque siempre comparten el trabajo entre ellos.
¿Pruebas ad hoc manuales o automatizadas?
Las pruebas automatizadas pueden ayudar a los equipos a ahorrar aún más tiempo en la fase de control de calidad, lo que permite a los evaluadores incluir más comprobaciones en su calendario. Incluso sin una estructura definida, es esencial que los probadores trabajen para maximizar la cobertura y la automatización fomenta inspecciones más profundas de este software.
Las comprobaciones automatizadas ad hoc suelen ser más precisas que las pruebas manuales, ya que evitan los errores humanos en las tareas repetitivas, lo que resulta especialmente útil cuando se realizan las mismas pruebas en diferentes iteraciones. El éxito de este procedimiento suele depender de la herramienta de pruebas automatizadas que seleccione el equipo y de su funcionalidad.
Sin embargo, las pruebas automatizadas tienen ciertas limitaciones. Por ejemplo, el principal punto fuerte de las pruebas ad hoc es su capacidad para emular la entrada del usuario y realizar comprobaciones aleatorias a medida que se le ocurren al probador. Estas pruebas podrían perder su aleatoriedad si el programa de pruebas de la organización tiene dificultades para realizar comprobaciones complejas.
El tiempo que se tarda en automatizar estas tareas tan específicas también podría limitar el ahorro de tiempo típico de este proceso. Es importante que los equipos investiguen a fondo las herramientas de automatización disponibles para encontrar una que se ajuste al proyecto de su empresa.
¿Qué necesita para empezar a hacer pruebas ad hoc?
He aquí los principales requisitos de las pruebas ad hoc:
1. Personal cualificado
Como las pruebas ad hoc son inspecciones rápidas y aleatorias del funcionamiento interno del software, suele ser útil contar con probadores experimentados en el software. También deben tener un conocimiento práctico de los principios clave de las pruebas, lo que les permite identificar fácilmente las comprobaciones más eficaces.
2. Un enfoque no estructurado
Los probadores deben estar dispuestos a abandonar sus estrategias habituales de pruebas ad hoc; esta mentalidad es tan crítica como los propios controles de calidad. Este método sólo puede tener éxito sin estructura ni documentación, y es vital que los probadores lo recuerden en cada fase.
3. Software de automatización
Aunque las pruebas ad hoc se basan más en probar entradas y condiciones aleatorias, la automatización sigue siendo una técnica muy eficaz en cualquier contexto.
Por este motivo, las comprobaciones ad hoc deben seguir aplicando herramientas de comprobación automatizadas siempre que sea posible, ya que la aplicación adecuada puede agilizar considerablemente el proceso.
4. Otras formas de ensayo
Las pruebas ad hoc funcionan mejor junto con otras comprobaciones que adoptan un enfoque más formal, ayudando al equipo a garantizar una cobertura sustancial en todo el software. Es vital que los probadores mezclen varias técnicas, aunque esto puede ser antes, durante o después de que completen las pruebas ad hoc.
Proceso de pruebas ad hoc
Los pasos habituales que deben seguir los probadores cuando realizan pruebas ad hoc en las pruebas de software son:
1. Definición de los objetivos de las pruebas ad hoc
Esta etapa es limitada debido a la falta de documentación y estructura, pero sigue siendo primordial que el equipo tenga un enfoque claro. Es posible que los probadores empiecen a compartir ideas vagas sobre las próximas pruebas que hay que realizar y los componentes a los que hay que dar prioridad.
2. Selección del equipo de pruebas ad hoc
A medida que el equipo idea una serie de posibles comprobaciones ad hoc, también determina qué probadores serían los más adecuados para este tipo de pruebas. Suelen seleccionar a probadores que conozcan a fondo la aplicación y también pueden emparejarlos con un desarrollador.
3. Ejecución de pruebas ad hoc
Tras decidir qué probadores son los adecuados para esta fase, estos miembros del equipo comienzan sus comprobaciones en un punto acordado de las pruebas. Su objetivo es realizar el mayor número posible de comprobaciones ad hoc, que los probadores podrían no idear hasta esta fase.
4. Evaluación de los resultados de las pruebas
Al finalizar las pruebas (o incluso entre comprobaciones individuales), los probadores evaluarán los resultados, pero sin documentarlos formalmente en un caso de prueba. Si descubren algún problema con la aplicación, lo registran informalmente y discuten los siguientes pasos del equipo.
5. Informar de cualquier error descubierto
Una vez evaluados los resultados, los probadores deben informar a los desarrolladores de los errores presentes en el software para que tengan tiempo de sobra para corregirlos antes del lanzamiento.
El equipo de pruebas también utiliza la información para determinar cómo mejorar sus procesos de pruebas formales.
6. Reanálisis en caso necesario
Es probable que el equipo de pruebas repita el proceso ad hoc en las nuevas iteraciones de la aplicación para comprobar lo bien que gestiona las actualizaciones. Como los responsables de las pruebas habrán subsanado muchas de las deficiencias detectadas previamente en sus casos de prueba, las futuras comprobaciones ad hoc podrían requerir un enfoque diferente.
Buenas prácticas para las pruebas ad hoc
Hay ciertas prácticas que los equipos de pruebas deben aplicar durante las pruebas ad hoc, entre ellas:
1. Detectar posibles lagunas en las pruebas
Aunque las pruebas ad hoc implican mucha menos planificación que otros tipos, el equipo sigue tratando de subsanar las deficiencias en la garantía de calidad. Si los evaluadores ad hoc sospechan que hay algún problema específico en los casos de prueba del equipo, deben darle prioridad al realizar sus comprobaciones.
2. Considerar el software de automatización
Las estrategias de automatización como la hiperautomatización pueden ofrecer muchas ventajas a las empresas que desean realizar pruebas ad hoc.
El éxito depende de varios factores clave, como la herramienta que elija la empresa y la complejidad general de sus pruebas ad hoc.
3. Tomar notas exhaustivas
La falta de documentación en las pruebas ad hoc sirve sobre todo para agilizar aún más este proceso: al equipo le vendría bien tomar notas informales a medida que avanza. De este modo, los probadores disponen de un registro claro de estas comprobaciones y sus resultados, lo que aumenta su repetibilidad general.
4. Seguir perfeccionando las pruebas
Los evaluadores ad hoc perfeccionan continuamente su enfoque para tener en cuenta los cambios en la estrategia de evaluación del equipo. Por ejemplo, al examinar las nuevas versiones del software de la empresa, podrían ajustar estas comprobaciones en respuesta a casos de prueba formales más nuevos e inclusivos.
7 errores y escollos en la aplicación
Pruebas ad hoc
Como en cualquier proceso de pruebas, existe una amplia gama de errores potenciales que el equipo debe esforzarse por evitar, como por ejemplo:
1. Probadores inexpertos
Para mantener el ritmo previsto de pruebas ad hoc, el jefe de equipo debe asignar a los probadores en función de sus conocimientos y aptitudes. Mientras que muchas formas de pruebas pueden acomodar a personal de garantía de calidad de nivel básico, las comprobaciones ad hoc requieren miembros del equipo que entiendan perfectamente el software; preferiblemente con experiencia en la ejecución de estas pruebas.
2. Controles desenfocados
Las pruebas ad hoc pueden mejorar significativamente la cobertura de las pruebas gracias a su mayor rapidez: el equipo no necesita rellenar una extensa documentación antes y después de cada comprobación.
Sin embargo, los encargados de las pruebas ad hoc deben mantener un enfoque firme; por ejemplo, podrían decidir dar prioridad a determinados componentes con mayor riesgo de fallo.
3. Ninguna planificación
Evitar cualquier tipo de plan puede limitar la eficacia de las pruebas ad hoc. A pesar de la naturaleza no estructurada de este enfoque, es importante que el equipo tenga una idea aproximada de qué pruebas realizar antes de empezar.
El tiempo es limitado durante este proceso y saber cómo proceder puede ofrecer muchas ventajas.
4. Demasiado estructurado
En el extremo opuesto del espectro, este enfoque suele basarse en la falta de planificación, ya que ayuda a los probadores a subvertir activamente los casos de prueba y encontrar errores ocultos.
Las pruebas ad hoc también se conocen como pruebas aleatorias y forzar una estructura podría impedir que estas comprobaciones localicen errores.
5. Sin cambios a largo plazo
El propósito de las pruebas ad hoc es identificar cualquier punto débil en los casos de prueba del equipo; esto examina su estrategia general tanto como el propio software.
Sin embargo, esto significa que las pruebas ad hoc sólo suelen ser eficaces si el equipo utiliza esta información para perfeccionar sus comprobaciones formales a lo largo del tiempo.
6. Conjuntos de datos incompatibles
Prácticamente todas las formas de prueba requieren una forma de datos simulados para evaluar cómo responde la aplicación; algunas herramientas permiten a los probadores rellenar automáticamente un programa con datos simulados.
Sin embargo, esto podría no reflejar la forma en que un usuario se relacionaría con el software: las comprobaciones ad hoc requieren conjuntos de datos que el software probablemente encontrará.
7. Silos de información
Es esencial que los probadores y los desarrolladores estén en constante comunicación entre sí, aunque estos últimos no formen parte del proceso de pruebas ad hoc.
Esto ayuda a todos a entender qué pruebas se han realizado, mostrando las próximas acciones a realizar y evitando al mismo tiempo que los probadores repitan innecesariamente ciertas comprobaciones.
Tipos de resultados de las pruebas ad hoc
Los controles ad hoc producen varios resultados distintos, entre ellos:
1. 1. Resultados de las pruebas
Las distintas pruebas arrojan resultados diferentes en función del componente exacto y el planteamiento de que se trate, que puede adoptar muchas formas.
Suele ser responsabilidad del probador determinar si los resultados constituyen un error, aunque la falta de documentación dificulta la comparación con sus expectativas. El equipo transmite estos resultados a los desarrolladores si observan algún problema.
2. Registros de pruebas
El propio software utiliza un complicado sistema de registros internos para supervisar las entradas de los usuarios y poner de relieve una serie de problemas de archivos o bases de datos que podrían surgir.
Esto podría apuntar a un error interno, incluida la parte específica del software que causa el problema. Con esta información, los probadores ad hoc y los desarrolladores pueden abordar los problemas que descubren con mucha más facilidad.
3. Mensajes de error
Muchas comprobaciones ad hoc tienen como objetivo específico romper el software y exponer sus límites, lo que significa que los mensajes de error de la aplicación son uno de los resultados más comunes de estas pruebas.
Al provocar deliberadamente mensajes de error, el equipo puede mostrar lo que ve el usuario final medio cada vez que las acciones inesperadas que realiza tienen un efecto adverso en el funcionamiento del programa.
Ejemplos de pruebas ad hoc
A continuación se presentan tres escenarios de pruebas ad hoc que muestran cómo un equipo podría implementarlo para diferentes aplicaciones:
1. Aplicación web de comercio electrónico
Si una empresa desea probar una aplicación web basada en el comercio electrónico, podría utilizar pruebas ad hoc -en concreto, pruebas de monos- para ver lo bien que la plataforma gestiona las interacciones inesperadas de los usuarios.
Los probadores pueden intentar llevar cada función al límite, por ejemplo, añadiendo artículos a la cesta en cantidades poco realistas o intentando comprar productos agotados. No están limitados por los casos de prueba del equipo y hay pocos límites a las comprobaciones que podrían realizar; los probadores podrían incluso intentar completar compras utilizando URL obsoletas.
2. Aplicación de escritorio
Los probadores ad hoc también pueden poner en práctica estas técnicas para aplicaciones de escritorio con un posible enfoque en diferentes máquinas y lo bien que cada una de ellas se adapta al programa.
Los miembros del equipo podrían realizar estas comprobaciones repetidamente para ver cómo afectan los cambios en la configuración del hardware o el software al rendimiento general de una aplicación. Por ejemplo, una tarjeta gráfica específica puede tener problemas para renderizar la interfaz.
Alternativamente, estos probadores podrían simplemente dar a su programa entradas imposibles y ver cómo responde, por ejemplo, si puede mostrar correctamente mensajes de error que expliquen adecuadamente el problema al usuario final.
3. Aplicación móvil
Una forma en que los evaluadores ad hoc podrían examinar una aplicación móvil es probando sus protocolos de seguridad: podrían intentar acceder directamente a las herramientas de desarrollo de la aplicación, por ejemplo.
El equipo puede intentar ver si son capaces de realizar acciones no autorizadas encontrando lagunas y exploits comunes; podrían pedir específicamente a miembros del personal con experiencia en seguridad de aplicaciones que faciliten esta tarea.
Esto también podría implicar pruebas en pareja con los desarrolladores, debido a su conocimiento del diseño de la aplicación, lo que permitiría a un probador romper el software y mostrar exactamente dónde falla su seguridad.
Tipos de errores y fallos detectados
mediante pruebas ad hoc
Las comprobaciones ad hoc pueden descubrir muchos problemas con un programa, como:
1. Errores de funcionalidad
Utilizar pruebas ad hoc para examinar las características básicas de una aplicación puede revelar fallos graves que afecten a la forma en que los usuarios finales pueden interactuar con ella.
Por ejemplo, las pruebas con monos de las opciones de pago de un sitio de comercio electrónico ilustrarán las condiciones que impiden la transacción.
2. Cuestiones de rendimiento
Los probadores pueden trabajar específicamente para crear problemas de rendimiento en el programa, por ejemplo, llenando la base de datos con diversas entradas de spam.
Esto podría manifestarse como un retraso significativo o incluso una inestabilidad general del software, lo que probablemente provocaría un fallo (potencialmente en todo el sistema).
3. Problemas de usabilidad
Estas comprobaciones también pueden poner de manifiesto fallos en la interfaz y la experiencia general del usuario. La interfaz de usuario de una aplicación móvil, por ejemplo, puede presentarse de forma diferente en otro sistema operativo o resolución de pantalla. Una interfaz deficiente puede hacer que los usuarios tengan dificultades para manejar esta aplicación.
4. Defectos de seguridad
La naturaleza aleatoria de las pruebas ad hoc permite cubrir una serie de problemas de seguridad comunes y poco frecuentes; un evaluador podría utilizar estas comprobaciones para encontrar las puertas traseras administrativas de un programa.
Alternativamente, su inspección puede mostrar que el software no tiene cifrado de datos.
Métricas comunes de las pruebas ad hoc
Las pruebas ad hoc utilizan diversas métricas para facilitar sus resultados, entre ellas:
1. Eficacia de la detección de defectos
Esta métrica examina la eficacia del proceso de pruebas para encontrar defectos en cada forma de prueba, incluidas las pruebas ad hoc. La eficacia de la detección de defectos es el porcentaje de defectos descubiertos dividido por el número total de problemas, lo que muestra la eficacia de las pruebas.
2. Tasa de cobertura de las pruebas
Una función auxiliar de las pruebas ad hoc es aumentar la cobertura comprobando componentes de una forma que los casos de prueba no tienen en cuenta. Esto significa que los probadores también tratarán de aumentar radicalmente la cobertura de las pruebas en todas las comprobaciones en la medida de lo posible.
3. Duración total de la prueba
Las pruebas ad hoc son mucho más rápidas que otros procesos de aseguramiento de la calidad, y es esencial que los probadores trabajen para mantener esta ventaja. Las métricas de duración de las pruebas muestran a los miembros del equipo cómo pueden ahorrar tiempo y agravar aún más las ventajas de las estrategias ad hoc.
4. Índice de colisiones
Estas pruebas suelen tener como objetivo romper el software y provocar un fallo o un error grave, lo que les permite ir más allá de las estrategias de prueba típicas y encontrar problemas inesperados. Para ello, puede ser útil saber con qué frecuencia se bloquea el software y cuáles son las causas de estos problemas.
5 mejores herramientas de pruebas ad hoc
Existen muchas herramientas de prueba gratuitas y de pago para realizar pruebas ad hoc en las pruebas de software: las cinco mejores son las siguientes:
1. ZAPTEST Edición Gratuita y Empresarial
ZAPTEST es un completo programa de pruebas de software que proporciona un sólido nivel de funcionalidad de pruebas + RPA tanto en su versión gratuita como en la de empresa.
Esta suite completa de automatización de software + RPA permite realizar pruebas completas en diferentes plataformas de escritorio y móviles; la tecnología 1SCRIPT del software también permite a los usuarios ejecutar las mismas comprobaciones repetidamente con facilidad. Además, la herramienta aprovecha los últimos avances en visión por ordenador, lo que hace posible que ZAPTEST ejecute pruebas ad hoc desde una perspectiva humana.
2. BrowserStack
BrowserStack es una plataforma en la nube que puede facilitar la realización de pruebas en más de 3.000 máquinas distintas, con la característica adicional de automatizar los scripts de Selenium. Aunque ofrece una gran cobertura para proyectos de software, funciona mejor con aplicaciones para navegadores y móviles.
Las soluciones de pruebas BrowserStack también incluyen una prueba gratuita con 100 minutos de pruebas automatizadas, aunque su uso puede ser limitado.
Aunque el enfoque basado en la nube puede ser útil, también afecta negativamente al tiempo de respuesta de la plataforma.
3. LambdaTest
De forma similar, LambdaTest utiliza tecnología basada en la nube y hace especial hincapié en las pruebas en navegadores, lo que puede limitar su eficacia para otras aplicaciones, aunque también funciona bien con programas para iOS y Android. Se trata de una plataforma útil cuando la escalabilidad es una preocupación y se integra con muchos otros servicios de alojamiento de pruebas.
Sin embargo, algunos usuarios tienen reacciones encontradas sobre el precio de la aplicación en las distintas opciones disponibles, lo que podría limitar la accesibilidad de las organizaciones más pequeñas.
4. TestRail
TestRail es, en general, bastante adaptable debido a que se ejecuta completamente en el navegador y, a pesar de estar muy centrado en casos de prueba eficientes, también cuenta con funcionalidades ad-hoc directas. El análisis que proporciona después de cada prueba también puede ayudar a los equipos que evitan activamente realizar su propia documentación independiente, al tiempo que les permite validar su proceso de pruebas.
Sin embargo, las suites más grandes podrían tener problemas con su formato basado en navegador, que puede limitar el ahorro de tiempo de las pruebas ad hoc por un margen significativo.
5. Céfiro
Zephyr es una plataforma de gestión de pruebas de SmartBear que ayuda a los equipos de control de calidad a mejorar la visibilidad de sus pruebas, al tiempo que se integra perfectamente con otros programas de seguimiento de errores.
Sin embargo, esta función está limitada a determinadas aplicaciones, siendo Confluence y Jira las que más se benefician de Zephyr, por lo que podrían no ser las soluciones más eficaces para todas las empresas. Hay varios programas escalables disponibles bajo la marca Zephyr a diferentes precios.
Lista de comprobación, consejos y trucos para las pruebas ad hoc
He aquí otros consejos que los equipos deben tener en cuenta al realizar pruebas ad hoc:
1. Priorizar los componentes sensibles
Algunas funciones o componentes corren naturalmente más riesgo de error que otros, sobre todo si son importantes para el funcionamiento general del programa.
Todo enfoque de las pruebas debe identificar las partes de una aplicación que pueden beneficiarse de una atención más minuciosa. Esto es especialmente útil cuando el tiempo total para las pruebas es limitado.
2. Investigar diferentes herramientas de prueba
La herramienta que implemente una organización para facilitar sus pruebas podría afectar a la cobertura y fiabilidad de estas comprobaciones.
Con las pruebas ad hoc, vale la pena examinar tantos programas como sea posible para encontrar los que se adapten a su aspecto centrado en el usuario. Los programas informáticos que utilizan tecnología de visión por ordenador, como ZAPTEST, pueden abordar las pruebas ad hoc con una estrategia similar a la humana.
3. Adoptar una mentalidad ad hoc
Las pruebas ad hoc ofrecen una enorme libertad en toda la fase de control de calidad, pero el equipo debe comprometerse a realizarlas para obtener las principales ventajas de la estrategia.
Por ejemplo, los probadores ad hoc deben prescindir de todos sus documentos habituales más allá de la toma de notas básica y tienen que inspeccionar el software desde una perspectiva totalmente nueva.
4. Confiar en los instintos de prueba
La experiencia con pruebas ad hoc o comprobaciones generales de software puede ayudar a destacar los puntos comunes de fallo y esto ayuda a los probadores a determinar cómo detectar errores de todo tipo.
Es vital que los probadores confíen en sus instintos y utilicen siempre este conocimiento en su beneficio: pueden intuir qué comprobaciones ad hoc serían más útiles.
5. Registro completo de los errores descubiertos
Aunque las pruebas ad hoc carecen de documentación formal y se basan sobre todo en notas informales, sigue siendo esencial que el equipo sea capaz de identificar y comunicar la causa de un error de software.
Deben registrar cualquier información que la prueba proporcione y que sea relevante para los desarrolladores, como las posibles causas de estos problemas.
6. Tenga siempre en cuenta al usuario
Todas las formas de pruebas pretenden adaptarse en cierta medida a la experiencia global del usuario, y las pruebas ad hoc no son una excepción. Aunque a menudo examinan más a fondo el funcionamiento interno de la aplicación e incluso su código interno, los probadores ad hoc deben intentar romper este software de formas que los usuarios teóricamente podrían.
7. Mejorar continuamente el proceso
Los equipos de pruebas deben perfeccionar su enfoque de las pruebas ad hoc entre varias iteraciones del mismo software y de un proyecto a otro.
Pueden recabar comentarios de los desarrolladores para comprobar hasta qué punto sus pruebas ad hoc ayudaron en la fase de aseguramiento de la calidad y si fueron capaces de aumentar significativamente la cobertura de las pruebas.
Conclusión
Las pruebas ad hoc pueden ayudar a organizaciones de todo tipo a autentificar su estrategia de pruebas de software, pero la forma de aplicar esta técnica puede ser un factor importante para su eficacia.
Equilibrar los distintos tipos de pruebas es la clave para obtener los máximos beneficios de las comprobaciones ad hoc, sobre todo porque esta forma de comprobación pretende complementar a las demás llenando un vacío estratégico.
Con una aplicación como ZAPTEST, es posible que los equipos realicen pruebas ad hoc con mayor confianza o flexibilidad, especialmente si implementan la automatización. Sea cual sea el enfoque específico del equipo, su compromiso con las pruebas ad hoc podría revolucionar todo el programa o proyecto.
