Menú

¿Qué son las pruebas exploratorias en las pruebas de software (una guía completa)?

  • Principal
  • Otro
  • ¿Qué son las pruebas exploratorias en las pruebas de software (una guía completa)?

what is exploratory testing software testing

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

¿Qué son las pruebas exploratorias?

“Pruebas exploratorias”: como su nombre indica, es un proceso de aprendizaje, diseño de pruebas y ejecución de pruebas simultáneos. Podemos decir que en esta prueba, la planificación, el análisis, el diseño y la ejecución de las pruebas se realizan de forma conjunta e instantánea.

Esta prueba se trata de explorar el sistema y fomentar el pensamiento práctico y en tiempo real de un evaluador.

En esta serie hemos cubierto los siguientes tutoriales:

Tutorial #1: ¿Qué son las pruebas exploratorias en las pruebas de software? (Este tutorial)
Tutorial #2: Uso de recorridos para garantizar pruebas exploratorias completas
Tutorial #3: Pruebas exploratorias frente a pruebas con guiones
Tutorial #4: Pruebas exploratorias con HP Sprinter
Tutorial #5: Las 17 mejores herramientas de prueba exploratoria

************************************
Prueba exploratoria

Lo que vas a aprender:

Visión general

En términos simples, las pruebas exploratorias implican el diseño de casos de prueba concurrentes y la ejecución de pruebas de una aplicación o sistema bajo prueba. El evaluador creará o anotará una idea de prueba para orientar, y explorará el sistema mientras prueba para crear más pruebas críticas, prácticas y útiles para la prueba exitosa de una aplicación.

Esto requiere una planificación mínima. Los evaluadores toman continuamente una decisión sobre su próximo paso de acción. Depende completamente del proceso de pensamiento del evaluador.

A veces, esta prueba puede ser más beneficiosa que el enfoque de prueba formal para encontrando algunos defectos sutiles que desaparecen en las pruebas formales.

Consciente o inconscientemente, todos y cada uno de los probadores habrían realizado pruebas exploratorias en algún momento de su carrera.

Como todos sabemos, un alumno aprenderá mejor a través de la experiencia práctica en lugar de abarrotar la teoría.

De la misma manera, un evaluador conocerá mejor la aplicación solo mientras explora y aprende sobre todas las funciones que proporciona por sí misma. Siempre es bueno tener una perspectiva comercial y del cliente durante las pruebas para garantizar que la prueba de una aplicación sea exitosa.

Por ejemplo, Si abre un sitio web de compras, tiene una idea general de que este sitio web de compras le permitirá comprar seleccionando un producto de su elección y luego pagando por el mismo.

Durante este proceso, es posible que descubra que el sitio web le proporciona una apariencia humana virtual que le ayuda en el proceso de selección de productos. También descubrió que puede pedir una serie de productos para prueba en casa o que puede realizar el pago a través de puntos de recompensa de algunos bancos, etc.

Como evaluador, no solo necesita verificar si un sistema está funcionando como se esperaba, sino también verificar si ese sistema no se comporta de una manera inesperada.

Algunas cosas para recordar al realizar esta prueba:

  • Tu misión debe estar clara.
  • Asegúrese de crear notas e informar sobre lo que está haciendo y cómo se está comportando un sistema, lo que podría ser un error potencial.
  • Aprenda, observe y luego cree nuevos casos de prueba.

Servicio de pruebas exploratorias recomendado

# 1) Digivante Direct

Logotipo de Digivante Direct

Digivante Direct realiza pruebas exploratorias utilizando su red global de probadores profesionales para que pueda cubrir las pruebas en todos los dispositivos principales en una escala de tiempo inalcanzable por cualquier otro proveedor de pruebas o equipo interno.

Libere de forma más rápida, segura y permita que sus plataformas digitales brinden una mayor satisfacción al cliente y mayores ingresos en línea.

Características:

  • 24 días hábiles de prueba en solo 24 horas o 90 días hábiles en 72 horas, y un nivel de pruebas completo e inigualable que no se puede lograr por ningún otro medio.
  • Bajo costo , paquetes de precios fáciles de entender sin extras ocultos.
  • Autoservicio portal en línea que no requiere ningún compromiso continuo.
  • Personas reales probando en dispositivos reales - cobertura de navegador y dispositivo mucho mayor de la que puede lograr internamente y todo en un tiempo de respuesta más rápido.
  • Cobertura completa de pruebas exploratorias - reducir el riesgo y mejorar la satisfacción del usuario final y las tasas de conversión, aumentando así los ingresos y reduciendo los costes.
=> Visite el sitio web de Digivante Direct

Ejemplos de pruebas exploratorias

Ejemplo 1:

Un sitio web de un proveedor de servicios de atención domiciliaria con los siguientes componentes:

  • Acceso
  • Servicios
  • Carro
  • Pago
  • Historial de pedidos
  • Asignación de técnico

Una idea general para empezar exploratorio Las pruebas serán para iniciar sesión o reservar un servicio.

¿Cómo cubrir los casos de prueba?

Casos de prueba de pruebas exploratorias

cómo configurar un firewall de red

En lo de arriba Ejemplo, la idea es comenzar con la funcionalidad basada en sus conocimientos. A medida que aprenda y observe más sobre la aplicación, podrá controlar su próximo conjunto de casos de prueba.

Ejemplo # 2:

Una vez fui incluido en un pequeño proyecto que involucró la adición de un nuevo fondo mutuo en la aplicación. Mi tarea consistía en probar la aplicación para asegurarme de que el nuevo fondo mutuo está disponible para que los usuarios lo compren y comprobar si la valoración asociada es correcta. Solo tuve 2 días para completar mis pruebas.

Teniendo en cuenta el plazo ajustado y la severidad de las pruebas, utilicé el enfoque exploratorio de las pruebas. Mi objetivo era probar nuevas funciones y encontrar violaciones de los requisitos de compatibilidad.

El objetivo mencionado anteriormente se convirtió en mi estatuto para esta sesión de prueba.

Los siguientes casos de prueba se desarrollaron durante esta prueba:

  • Pruebas para asegurarse de que el nuevo fondo mutuo se haya agregado a la aplicación.
  • El nuevo MF se compra con éxito.
  • La valoración del nuevo MF es correcta.
  • Intenté comprar un nuevo MF para una cartera existente.
  • ¿Se pueden agregar nuevos MF a todas las carteras?
  • Impacto de New MF en una valoración de existente.
  • Así que en otros casos de prueba se desarrollaron.

Preparé notas e informes durante mis pruebas para discutir mi observación con el BA y el cliente involucrado.

La estrategia fundamental de las pruebas exploratorias es tener un plan de ataque. Comience a probar con su idea e improvise nuevos casos de prueba basados ​​en su conocimiento y observación.

Ejemplo # 3:

Prueba exploratoria del sitio web de IRCTC

=> Haga clic aquí para descargar los casos de prueba de muestra de Pruebas exploratorias del sitio web del IRCTC.

Enfoque de prueba

  • Utilice la heurística para guiar las pruebas.
  • La ejecución de casos de prueba y la creación de casos de prueba van de la mano.
  • Los casos de prueba siguen evolucionando en función de la observación y el aprendizaje del evaluador.
  • Diferentes técnicas de prueba como Análisis de valor límite , pruebas de equivalencia, etc. se pueden aplicar a ET.
  • La ET basada en sesiones se puede utilizar para hacerla más estructurada y enfocada.
  • Los probadores pueden diversificar sus ideas, pero nunca desviarse de su misión.
  • Las pruebas ET no utilizan guiones, sino que dependen de la intuición, la habilidad y la experiencia del evaluador.

Beneficios

Los beneficios de esta prueba incluyen:

  • Promueve el pensamiento en tiempo real y ayuda a descubrir más defectos.
  • Promocionar casos de uso y pruebas basadas en escenarios.
  • Documentación mínima, pruebas máximas.
  • Se hace más hincapié en aprender y ampliar el horizonte de un evaluador.
  • Evite el trabajo duplicado.
  • Útil cuando desea auditar el trabajo de otro evaluador.

Deméritos

Los deméritos se enumeran a continuación:

  • Las pruebas dependen de la experiencia, la habilidad y el conocimiento del evaluador.
  • Requiere tiempo para aprender la aplicación. Es más probable que el evaluador falle si sabe menos sobre la aplicación.
  • No apropiado para proyectos con largo tiempo de ejecución.

Pruebas exploratorias basadas en sesiones

Mientras realizan pruebas exploratorias, es muy difícil para los evaluadores expresar con palabras cuánto ha probado y sobre qué base.

Básicamente, es difícil cuantificar el trabajo y el tiempo invertido. Sin embargo, en cada proyecto, necesitamos proporcionar métricas, estimaciones e informes de progreso a los líderes del equipo y los gerentes. Como dice el refrán, 'si no puedes cuantificarlo, no puedes gestionarlo'.

Las pruebas basadas en sesiones son un enfoque basado en el tiempo para realizar estas pruebas que ayudan en la administración y el seguimiento. Incluye una sesión de prueba en caja de tiempo dedicada sin interrupción del correo electrónico, teléfono, mensajes, etc.

Acercarse:

Las tareas de prueba se dividen en sesiones.

Los siguientes son los componentes de las pruebas basadas en sesiones (SBT):

  • Misión: Misión gritar el propósito de la sesión y de alguna manera proporcionar el enfoque para el evaluador. También incluirá una duración de la sesión.
  • Carta: Incluye el alcance de la prueba. Básicamente, una agenda que detalla los objetivos que deben completarse durante la sesión.

Ejemplo de carta de prueba para la funcionalidad de inicio de sesión del sitio web del servicio de atención domiciliaria:

Ejemplo de carta de prueba para la funcionalidad de inicio de sesión

  • Sesión: Sesión de prueba predefinida en cajas de tiempo sin ninguna interrupción. Cada sesión puede tener la siguiente duración:
    • 'Corto' (60 min)
    • “Normal” (90min)
    • 'Larga' (120 min)
  • Informe de sesión: Incluya notas y un informe ligero para proporcionar métricas a los líderes y gerentes. Proporciona detalles sobre la sesión de charter restante o finalizada, el tiempo de configuración de la sesión, el escenario probado, el proceso de prueba, una lista de errores y los problemas encontrados y otra información para las métricas.
  • Session De-brief: Una reunión breve o una reunión entre el evaluador y el jefe de prueba / gerente para revisar los resultados de la sesión de prueba.

Los gerentes pueden obtener las siguientes métricas prácticas según el informe de la sesión:

  • El número de sesiones completadas y restantes.
  • La cantidad de errores reportados.
  • Tiempo dedicado a la configuración de la sesión.
  • Tiempo dedicado a las pruebas.
  • Tiempo dedicado a analizar cuestiones o problemas.
  • Características cubiertas.

Para resumir lo anterior:

SBT permite la responsabilidad en las pruebas exploratorias y ofrece una mejor gestión del tiempo dedicado a las pruebas. También aumenta la productividad y proporciona una mejor comprensión de la detección de errores. Es una excelente manera de proporcionar métricas a los líderes y gerentes de equipo para verificar el progreso del proyecto.

Pruebas exploratorias basadas en pares

Pair Testing es un enfoque en el que dos personas prueban lo mismo / característica de la aplicación al mismo tiempo compartiendo una PC. Comparten continuamente sus pensamientos e ideas. Durante esta prueba, una persona se hace cargo del teclado mientras que la otra persona sugiere casos de prueba y toma nota.

Siempre es útil tener una buena comunicación entre los socios para que ambos sepan qué se está haciendo y por qué. Un par en el que la fuerza de los probadores complementa mutuamente su debilidad se considera un grupo fuerte.

Este emparejamiento beneficia a ambas partes y cada una puede aprender algo de su pareja. También es una buena forma de formar nuevos recursos combinándolos con recursos experimentados.

Beneficios de la prueba de pares

  • Ayuda al evaluador a concentrarse en la tarea en cuestión.
  • Fomente la confianza y el respeto mutuos entre los socios.
  • La lluvia de ideas entre probadores emparejados generalmente conduce a ideas más constructivas.
  • Evite la visión de túnel.
  • Hay menos posibilidades de que otros los interrumpan.

Técnicas de prueba exploratoria

Excursiones: Es una técnica simple que permite a un evaluador usar su imaginación y pensar en sí mismo como un turista que explora una ciudad que visita. Aquí una aplicación para probar es la ciudad y los probadores son los turistas. Es muy difícil explorar toda la ciudad a menos que tenga mucho tiempo y dinero en la mano, por lo que un turista debe tener un plan con un objetivo determinado en mente.

Un turista puede realizar los siguientes recorridos:

  • Tour con guía - Prueba de característica destacada de la aplicación. Utilice escenarios basados ​​en el usuario.
  • Explorando la historia de la ciudad - Pruebe las funciones antiguas de una aplicación.
  • Gira de dinero, lo que significa asegurarse de que todas las características críticas en referencia al cliente o cliente se prueben y funcionen correctamente.
  • Tour de la juerga del crimen - Ingrese una entrada no válida y pruebe escenarios negativos.
  • Tour por el callejón - Prueba las características menos utilizadas de la aplicación.
  • Tour aburrido - Dedique un tiempo mínimo a cada pantalla de la aplicación, complete los campos mínimos y tome el camino más corto. Esto ayudará con el valor predeterminado y las pruebas de validación.

Mientras realiza un recorrido, siempre tiene la opción de tomar cualquier ruta. Puede navegar a través del software y encontrar una ruta única para probar la función.

A continuación se presentan algunos consejos / trucos que puede utilizar en ET:

  • Divida la aplicación en módulos y bifurque los módulos en diferentes páginas. Inicie su ET desde las páginas. Esto le dará la cobertura adecuada.
  • Haga una lista de verificación de todas las características y ponga una marca de verificación cuando esté cubierta.
  • Comience con un escenario básico y luego mejórelo gradualmente para agregar más funciones para probarlo.
  • Pruebe todos los campos de entrada.
  • Prueba el mensaje de error
  • Prueba todos los escenarios negativos.
  • Verifique la GUI con los estándares.
  • Verifique la integración de la aplicación con otras aplicaciones externas.
  • Compruebe la lógica empresarial compleja.
  • Intenta hacer el hackeo ético de la aplicación.

Los factores que afectan la ET son los siguientes:

  • El objetivo del proyecto
  • Estrategia de prueba
  • El objetivo de prueba de una fase en particular
  • Herramientas e instalaciones disponibles
  • Rol y habilidades de los probadores
  • Tiempo disponible
  • Apoyo de la gerencia
  • Apoyo de los compañeros
  • Recursos disponibles (materiales de estudio, condiciones de prueba, etc.)
  • Interés de los clientes
  • Comprensibilidad del producto.
  • La interfaz de usuario de la aplicación
  • La funcionalidad de la aplicación
  • Resultados de pruebas anteriores
  • Riesgos asociados a la aplicación
  • Defectos previos
  • Cambios recientes
  • Tipos de datos que se utilizarán para las pruebas
  • Tipo de usuario que lo usará

En lugar de preguntar a los evaluadores qué ejecutar, dejamos que el evaluador decida qué quieren probar y cómo lo quieren hacer.

Diferencia entre pruebas exploratorias y pruebas ad-hoc

No confunda ET con Prueba ad-hoc .

  • Las pruebas ad-hoc se refieren a un proceso de búsqueda de defectos no programada, no planificada e improvisada, mientras que las pruebas exploratorias son una metodología reflexiva para las pruebas ad-hoc.
  • Las pruebas ad-hoc son un método exitoso y de prueba para encontrar un error, mientras que ET no lo es. En el enfoque ET, un evaluador aprende sobre el sistema a medida que explora y eventualmente evoluciona las pruebas utilizando el conocimiento adquirido.
  • Las pruebas ad-hoc son una actividad no estructurada, mientras que ET es una actividad estructurada.

Pruebas exploratorias automatizadas (EAT)

La prueba automatizada exploratoria es un método que ayuda a un evaluador a agilizar el informe y la reproducción de errores, la recopilación de instantáneas y la preparación de un futuro traje de regresión. Es un proceso que combina las pruebas de automatización con las pruebas exploratorias.

Hay dos tipos de enfoque EAT:

  • EAT pasivo
  • EAT activo

EAT pasivo

La EAT pasiva puede ser realizada por un solo evaluador o también en pareja. En esta metodología, generalmente, una herramienta que captura y registra cada actividad realizada por un recurso de prueba y se instala en la PC del recurso.

La EAT pasiva es similar a la ET que se realiza manualmente, ya que no hay cambios en la forma en que se ejecutan las pruebas, además de elaborar el resultado de la prueba en función de la sesión capturada. Los resultados de estas pruebas se pueden utilizar para informar y volver a realizar las acciones registradas más adelante.

La herramienta de video instalada ayuda al evaluador con la grabación de casos de prueba y la notificación de defectos.

También tiene algunos otros beneficios como:

  • Proporciona pasos claros para reproducir los errores.
  • La reproducción de defectos es más fácil incluso cuando el informador de defectos no está disponible.
  • Elimine los conflictos entre el equipo de pruebas y el de desarrollo cuando se informe de un error intermitente.
  • Ayuda en las pruebas de rendimiento al obtener el tiempo de respuesta del sistema en un momento específico.

Aquí hay algunos otros puntos que deben tenerse en cuenta antes de EAT pasivo:

  • Se recomienda realizar una prueba piloto antes de adaptar completamente la herramienta para Automated EAT. Esto es para garantizar que el tiempo necesario para rediseñar los registros de prueba creados durante la sesión de prueba no sea más que la ejecución de la prueba. Si es así, el equipo debe tomar una decisión mutua sobre lo siguiente:
    • Si es que se requiere la automatización de la prueba para el proyecto en particular.
    • Si es necesario cambiar la herramienta que se está utilizando.
    • Si se puede optimizar el rendimiento de la herramienta que se está utilizando.
  • La herramienta utilizada para realizar EAT automatizado debe instalarse en cada recurso de prueba involucrado en la prueba. También es una buena idea involucrar a los desarrolladores, lo que puede lograrse dándoles acceso VPN o remoto a las máquinas de prueba o instalando la herramienta en el entorno de desarrollo.
  • Siempre es una buena idea tener el objeto GUI de la aplicación organizado en la herramienta de prueba para que cuando llegue el momento de analizar el error o un problema, el objeto sea reconocible debido a un nombre significativo.
  • Es una buena práctica dar un nombre significativo al objeto GUI utilizado en AUT y mantenerlos organizados para su uso posterior.

Ahora, pasemos al segundo enfoque.

EAT activo

Es recomendable realizar EAT activo con prueba de pares. En este enfoque, la prueba basada en palabras clave se utiliza en sincronización con la prueba de sesión. Un evaluador crea la secuencia de comandos de prueba automatizada y el segundo evaluador ejecuta las secuencias de comandos de prueba creadas por el primer evaluador.

La creación de scripts de prueba de automatización en este enfoque toma un camino diferente al de las pruebas convencionales. Los scripts de prueba automatizados se crean durante las pruebas y lo que se ha descubierto en las pruebas anteriores determina su diseño.

Se ejecuta una fase de cierre al final de la sesión de prueba. Y debería tener las siguientes tareas:

  • Los probadores involucrados deben intercambiar roles para que el recurso de prueba que creó el script de prueba tenga la oportunidad de volver a ejecutar los scripts para confirmar la confiabilidad y solidez de la suite creada.
  • Se debe proporcionar una breve descripción junto con algunas características de identificación para cada script de prueba automatizado.
  • Es necesario definir un criterio para identificar qué scripts de prueba automatizados se pueden utilizar para la prueba de regresión.

Beneficios de EAT

  • Al comienzo de cada sesión, se ejecutan scripts de prueba automatizados ya creados, mejorando así la cobertura de la prueba en todo momento.
  • Mejores informes de errores y documentación para la reproducción de defectos.
  • EAT proporciona suficiente evidencia y documentación para que las partes interesadas vean el progreso.

Tipos de pruebas exploratorias

A continuación se muestran algunos tipos de ET:

1) Estilo libre Y:

Exploración de la aplicación en estilo ad-hoc.

En este tipo de ET, no hay reglas, no hay cuentas para la cobertura, etc. Sin embargo, este tipo de pruebas es bueno cuando necesita familiarizarse rápidamente con la aplicación, cuando quiere verificar el trabajo de los otros probadores y cuando desea investigar un defecto o desea realizar una prueba rápida de humo.

2) ET basado en escenarios:

Como sugiere su propio nombre, las pruebas realizadas se basan en escenarios. Comienza con escenarios de usuarios reales, escenarios de un extremo a otro o escenarios de prueba. Después de la prueba inicial, los evaluadores pueden inyectar variación según su aprendizaje y observación.

Los escenarios son como una guía genérica de qué hacer durante la ET. Se anima a los evaluadores a explorar múltiples rutas posibles mientras ejecutan un escenario para garantizar que todas las rutas posibles para que funcionen las funciones. Los evaluadores también deben asegurarse de recopilar tantos escenarios como sea posible de diferentes categorías.

3) EstrategiaET basado:

Técnicas de prueba conocidas como análisis de valor límite, técnica de equivalencia y técnica basada en riesgos que se combinan con pruebas exploratorias. Para este tipo de pruebas se designa a un probador experimentado o familiarizado con la aplicación.

Pruebas exploratorias ágiles

Incluso si no ha trabajado en un entorno ágil, estoy seguro de que debe haberlo leído o escuchado debido a su creciente popularidad. La metodología ágil tiene sprints cortos y plazos ajustados, lo que le da a un equipo un par de semanas para finalizar la planificación, estimación, desarrollo, codificación, pruebas y lanzamiento.

Las pruebas exploratorias se vuelven útiles en plazos tan ajustados porque en este enfoque de prueba el énfasis está en el resultado rápido y útil. Una vez que haya entendido el requisito, puede comenzar a realizar pruebas en función de su experiencia y conocimiento.

Una vez que esté familiarizado con las características y el comportamiento de la aplicación, puede diseñar más casos de prueba para validar la funcionalidad de la aplicación y detectar errores no planificados. Como se trata de un enfoque de prueba de estilo libre, es necesario documentar todo. Sin embargo, debe mantener notas y un breve informe sobre lo que ha probado, errores y problemas encontrados, etc.

Méritos de la exploración ágil

  • Demostrar retroalimentación a los desarrolladores lo antes posible.
  • Se descubre una variedad más amplia de defectos.
  • Un grupo diverso de un recurso, como un desarrollador, un probador, un BA, los diseñadores pueden realizar ET ya que no hay casos de prueba con guión y cada uno aporta una perspectiva diferente.
  • La exploración realizada en ET ayuda a explorar nuevos territorios y a exponer errores críticos.
  • En el caso de la codificación iterativa de una aplicación, ET puede centrarse en probar nuevas funciones mientras que la automatización realiza pruebas de regresión y compatibilidad con versiones anteriores.
  • En caso de un requisito inestable, ET puede ayudar a probar nuevos requisitos en un tiempo limitado.

Puntos para recordar:

1. Requiere diferentes habilidades: Los evaluadores que realizan ET deben tener buenas habilidades para escuchar, leer, pensar y reportar. Se requiere experiencia en el dominio ya que no hay scripts ni casos de prueba.

2. A veces es difícil Reportar un error: Mientras estamos en un flujo ET, podemos encontrar un defecto, pero es posible que no podamos reproducirlo. Esto se debe a que no estamos siguiendo los pasos de prueba y es posible que olvidemos los pasos exactos para reproducir ese problema.

3. Se puede realizar como actividad recreativa: Personalmente hago ET cuando quiero un descanso de mi ciclo regular de ejecución de pruebas. Pero muchos equipos tienen ET como una fase separada de su ciclo de pruebas.

4. Se puede realizar para todas las fases de prueba: Podemos implementar ET antes del comienzo de cualquier fase de prueba. Puede realizar ET incluso antes de la fase de prueba funcional.

5. Respuesta rápida: ET requiere una respuesta rápida sobre los problemas y las anomalías encontradas.

6. Pensamiento crítico e ideas diversas: Esta prueba requiere un pensamiento crítico. Los evaluadores deben poder reproducir, revisar y expresar sus ideas de forma lógica. Un evaluador puede implementar su experiencia en las diversas tecnologías y dominios en los que trabajó.

Cómo pensar más allá de los límites de las pruebas tradicionales en las pruebas exploratorias

“Realmente aprecio su preocupación por el producto y por hacernos útiles desde una perspectiva comprensiva del usuario final. Va a ser muy útil. ¡¡¡Gracias por el buen trabajo y sigan así !!! '

Este fue el último correo electrónico de una cadena de correo electrónico con 21 correos electrónicos de nuestro cliente. Era medianoche y el lanzamiento de nuestro producto se retrasó debido a un error crítico que encontramos. Podrías pensar, ¿qué hay de nuevo en eso? Puede suceder muchas veces. Pero esto fue realmente diferente ya que el error crítico que informamos no fue el resultado de ningún caso de prueba documentado.

Despues de completar pruebas de regresión por última vez esa noche, estaba jugando con el producto. ¿Qué significa eso? Eres libre de hacer lo que se supone que no debes hacer. Basado en mi experiencia y conocimiento del proyecto, tuve algunas ideas sobre cómo probar el producto además de nuestro repositorio de prueba típico, llamado Prueba exploratoria .

Las pruebas exploratorias realizadas encontraron un error crítico relacionado con un problema de bloqueo del servidor mientras se hacía algo inesperado.

Siendo un fanático de las pruebas exploratorias, me encanta explorar el producto de diferentes maneras. Para mí, la definición de software es:

'Debe hacer lo que se supone que debe hacer, y no debe hacer lo que no debe hacer'.

Proceso de prueba exploratoria

Limitar los límites de las pruebas para verificar si los productos que se supone que funcionan funcionan lo convierte en un evaluador incompleto. De hecho, la vida de un evaluador comienza cuando finalizan las pruebas de regresión documentadas y se actualizan los resultados. Mirar los productos desde diferentes perspectivas y comprender los requisitos del usuario final en diferentes escenarios marca una gran diferencia. Así que hoy, entendamos juntos cómo se puede hacer esa diferencia:

¿Cómo mirar un producto desde diferentes perspectivas?

prueba exploratoria

# 1. Comprender al cliente / usuario final

La prueba de software consiste en comprobar la calidad del producto en términos de satisfacción del cliente. ¿Cómo conoce el punto de vista de un cliente? La respuesta es simple: tienes que ser el cliente. OK, déjame hacer una corrección. Ser cliente no será suficiente. Debe comprender cómo quiere el cliente manejar el producto. No hay dos clientes que hayan comprado las mismas materias primas que preparen la misma receta. Sí, el producto que desarrollamos / entregamos es una materia prima para las empresas del cliente y tienen una mentalidad diferente al usarlo.

Como tester de software, debemos verificar el propósito del producto y no el objeto o aspecto del mismo.

Déjame darte algunos ejemplos prácticos de la vida real:

  • Las tijeras nunca se limitaron a cortar papel únicamente. Cortar es el propósito y no el papel (objeto).
  • Los teléfonos móviles nunca se limitaron a llamar, pero “poder llamar” siempre ha sido el propósito básico.
  • Las cajas de almacenamiento se utilizan para almacenar, pero la seguridad del material almacenado es tan importante como el almacenamiento.

Comprender a las partes interesadas y una amplia gama de sus expectativas debe ser la base de las pruebas exploratorias.

# 2. Una mentalidad

Mientras busca (digamos) un anuncio de empleo, ¿ve ese premio mayor y entre las páginas con la fuente en negrita? La mayoría de nosotros no (créame, es cierto). Porque hemos instruido a nuestra mente para que busque lo que es útil o que debe ser verificado. Cualquier otra cosa no sirve de nada, por lo que la mente nos niega reconocerlo.

Abra su mente y no establezca expectativas cuando comience a explorar un producto . Recuerde siempre que no está bien si el producto está haciendo lo que se supone que debe hacer. También es importante que no haga lo que se supone que no debe hacer.

Recuerdo un ejemplo clásico:

En Linux, el comando 'cat' se usa para verificar el contenido de un archivo y el comando 'ls' es para verificar el contenido del directorio. Trabajando con Linux y realizando pruebas de software durante cinco años, nunca pensé en hacer cat porque mi mente estaba decidida; si necesito contenido de dir, necesito usar 'ls'. Eso funcionó, pero el reverso de la expectativa es que se suponía que el producto no debía comportarse de la manera que no debía, estaba mal. Uno de nuestros clientes, que no conocía bien Linux, cometió un error y el sistema falló. Pagamos por esta mentalidad.

Esté siempre dispuesto a cometer errores con el software porque eso es lo que hará el usuario final. Para probar el software, ha recibido formación, pero el usuario final no estará tan formado como usted. o no será tan experto técnico como usted. Además, él / ella hará cualquier cosa con el software cuando tengan problemas.

Piense en esos escenarios y proporcione comentarios sobre las pruebas. La vida del software y la tuya (como tester) será increíble.

# 3. Conoce a la competencia

Al probar cualquier aplicación de software para su cliente, ¿alguna vez intentó conocer y comprender otro software con el mismo propósito? ¿Alguna vez sugirió alguna funcionalidad útil que observó en el producto de un competidor? No cae en la descripción de nuestro trabajo, es la respuesta típica. ¿Pero conoces el beneficio de hacerlo?

Aquí hay algunos ejemplos de la vida real para que comprenda el punto:

  • ¿No le gusta el diseñador que no solo cose su vestido, sino que también le brinda información sobre los accesorios a juego?
  • ¿No le gusta la marca de pizzas que no solo hace excelentes pizzas sino que también entrega a domicilio a tiempo?
  • ¿No te gusta el fotógrafo que no solo toma buenas fotografías, sino que sugiere un tipo diferente de marcos para la sesión de fotos?

Todo el mundo quiere tener algo extra por lo que paga. Nuestro análisis de software competitivo puede funcionar de la misma manera para nosotros. Al cliente siempre le gusta escuchar sugerencias valiosas, principalmente sugerencias comparativas para hacer que el producto sea más útil o comercializable.

Además, este tipo de comparación y análisis de la misma gama de productos hace que nuestro análisis sea más poderoso y eventualmente creamos un tesoro al que podemos volver en cualquier momento y encontrar algo útil.

abrir archivo .jnlp windows 10

Conclusión

Exploratory no se incluye en una forma convencional de prueba, pero aún así, es una forma muy poderosa de prueba.

Saca a relucir el pensamiento original de un evaluador y lo alienta a presentar casos de prueba prácticos y en tiempo real para encontrar un defecto. Su naturaleza de estilo libre le da una ventaja sobre los otros tipos de pruebas y se puede realizar en cualquier lugar, ya sea un proyecto con Agile o cascada o cualquier otro proyecto que requiera una documentación mínima.

El éxito de las pruebas exploratorias depende de numerosos intangibles como la habilidad de un evaluador, la capacidad de crear casos de prueba efectivos, su experiencia y la habilidad para seguir su instinto.

Es imperativo recordar que la ET es un proceso adaptativo en lugar de predictivo y es esencial para mantener un equilibrio saludable entre las pruebas exploratorias y con guión o regulares.

¿Es usted un evaluador que tiene experiencias típicas de pruebas exploratorias? Estamos esperando escuchar sus pensamientos. No dudes en compartirlos en la sección de comentarios a continuación.

Siguiente tutorial n. ° 2: Cómo utilizar los recorridos para garantizar pruebas exploratorias completas

Lectura recomendada

^