Diría que lo usamos tanto de forma intencionada como no intencionada. A menudo es difícil entender realmente cuál es el uso intencionado, pero mantener la mente abierta puede ayudar a veces a encontrar bugs muy interesantes. La palabra «romper» es un poco engañosa también, porque a menudo nos encontramos con errores que no están realmente destruyendo el sistema, pero son problemas no obstante.
Para mí, me gusta establecer un plan de cómo probar una característica o producto antes de empezar, y dependiendo de la característica, por lo general contiene algunas o todas las siguientes categorías de pruebas:
- Escenario clave’s: ¿Funciona la función tal y como se ha especificado? Si un cliente de mensajería instantánea no puede enviar mensajes instantáneos, entonces tiene un problema.
- Escenario negativo: ¿Cómo funciona la característica si algo malo sucede. Si el receptor pierde la conectividad de la red justo cuando está a punto de recibir un mensaje, ¿le dice el cliente al remitente que el mensaje no se ha entregado, o actúa como si todo estuviera bien?
- Capacidad/límites: ¿Cuántos datos puede manejar la función y qué tan bien los maneja? Si alguien escribe una novela en la ventana de chat y adjunta algunas películas, fotos, etc… ¿se bloqueará el cliente?
- Rendimiento: ¿Qué tan rápido responde su función? Si envío un mensaje a alguien del otro lado del mundo, ¿tarda mucho tiempo en llegarle?
- Escalabilidad: ¿Qué tan bien escala su función para satisfacer una mayor demanda? Si mi cliente de chat se hace muy popular y la base de usuarios se dispara, ¿puedo añadir más recursos a mis servidores para seguir atendiendo a los usuarios como esperan? ¿Es una relación lineal y rentable?
- Localización/globalización: ¿Puede mi función manejar diferentes idiomas, formatos de texto, codificación, formatos de moneda, formatos de fecha y hora?
- Seguridad: ¿Cómo de seguro es su software? Si puedo poner un rastreador de paquetes en la red y ver una conversación entre dos clientes, ¿está bien?
En términos de llevar a cabo los pasos anteriores, realmente varía en la tecnología y los requisitos del sistema. Los probadores principiantes suelen hacer pruebas de caja negra, en las que no saben nada de cómo funciona la función. Los probadores avanzados suelen incluir también pruebas de caja blanca, en las que entienden el funcionamiento interno de su función para realizar pruebas más complicadas.
A medida que se descubren y corrigen los errores, suele ser una buena idea revisar la lista de errores del producto y buscar patrones y áreas obvias de debilidad. Esto le da al probador una idea de dónde puede encontrar más problemas.