¿Cómo realizan las pruebas los probadores? Cual es la estrategia?

No hay una sola estrategia. Depende de múltiples factores.

Al probar una característica específica, dos tipos de pruebas que se realizan comúnmente son:

  1. Prueba de caja blanca (estructural)
  2. Prueba de caja negra (funcional)

La prueba de caja blanca es esencialmente el proceso de probar las estructuras internas de una característica o aplicación. Los desarrolladores deben tener esto en cuenta al diseñar la característica y al implementarla.

La prueba de caja negra es el proceso de probar la funcionalidad de la función desde el exterior. Es mejor asumir que no sabe nada sobre cómo funciona la función e intentar usarla desde todos los ángulos posibles. Idealmente, este debería ser el foco de una posición de probador / QA.

En cualquier proceso, desea intentar romper la función. Este procedimiento parte de la suposición de que si no tiene nada que romper, entonces la función funciona según lo previsto y es de alta calidad.

También hay otras técnicas, como pruebas unitarias, pruebas de integración, pruebas de aceptación, análisis estático y dinámico, etc. Cada una de las cuales tiene un propósito diferente y se implementa en diferentes ámbitos.

Esta lectura bastante breve sobre las pruebas es una buena introducción a las pruebas en general: http://www.cs.cmu.edu/~luluo/Cou…

Además, dependiendo de lo que se esté probando, hay muchas más técnicas de prueba involucradas con las pruebas de aplicaciones móviles, la capacidad de respuesta de la interfaz de usuario del sitio, las pruebas de rendimiento y muchas más.

Recomiendo ir a través de las páginas que figuran en el mapa del sitio de https://sites.google.com/site/pe… y / o navegar / suscribirse al Blog de Google Testing

La mejor manera de pensar en esto es pensar en resolver acertijos o juegos como Pictionary o Mastermind (juego de mesa) o Battleship (juego). Lo que está intentando hacer es descubrir qué se desconoce.

En el siguiente nivel, el desafío es determinar si lo que descubrió es una amenaza para el usuario o no. Las amenazas pueden ser el bloqueo del programa o algo que no funciona (el clic no funciona; falta el botón). Las amenazas pueden ser más difíciles de detectar, como ‘el usuario puede no notar la información sobre herramientas’ o ‘el usuario no está informado sobre operaciones largas’ (primero debe encontrar esas operaciones largas).

Recomendaría probar lo que escribí con cualquier software que use:
1. Al igual que Battleship, ¿cuáles son las incógnitas?
2. ¿Es una amenaza?

Una buena manera de hacer esto es encontrar un software que realmente le guste: use software para crear, como WordPress, Listly, ¡listas fáciles + sociales + divertidas! o un software de gráficos. Luego, úselo para crear algunos proyectos / datos del mundo real.

El probador debe tener un enfoque integral y debe analizar el AUT (Aplicación bajo prueba) con la perspectiva del usuario junto con la comprensión de los requisitos comerciales. Por lo general, se utiliza el enfoque de prueba de caja negra.

La comprensión del dominio subyacente es necesaria para sugerir mejoras cruciales y problemas válidos.

Los conocimientos tecnológicos ayudan a dar una buena descripción de los problemas con soluciones alternativas sugeridas.

  1. Suponga que no sabe nada sobre la funcionalidad.
  2. No lo está usando para determinar qué cosas están funcionando. Está allí para descubrir qué no está funcionando. Intenta bloquear la aplicación / sitio web de todos modos. Tan sencillo como eso. Busque todas y cada una de las permutaciones y combinaciones.