La forma en que me gusta pensar acerca de las pruebas es haciendo preguntas no intuitivas que impactan a los usuarios. La forma en que la mayoría de la gente piensa acerca de las pruebas es: ¿funciona? Si piensa hacer preguntas, se vuelve un poco más fácil. Por ejemplo, para el modo fuera de línea: ¿sabe el usuario que el cliente está fuera de línea? ¿Cómo cambia el usuario a en línea? ¿Por qué un usuario se desconecta?
Comenzaría probando los límites. Intente utilizar valores extremos siempre que sea posible, por ejemplo, intente enviar datos grandes, múltiples archivos, carpetas. ¿Puede simular varios clientes (no pase demasiado tiempo en esto ahora, escriba algunos scripts simples que lo ayudarán a continuar). Tenga cuidado al hacer esto. A los desarrolladores puede no gustarles esto. Cuando encuentre problemas, piense en lo que significa. Intentaste transferir un archivo de 2 GB; falló, ¿y qué? ¿Es esto algo que los usuarios harán? Tenga en cuenta nuevamente que en este punto solo está entendiendo el comportamiento del sistema.
Desea comenzar centrándose en el cliente, es decir, preocuparse por el rendimiento del servidor más adelante. No te enfoques en la interfaz de usuario. Piensa en una IU confusa.
- ¿Un buen ingeniero de software es un autodidacta o tiene un excelente mentor?
- ¿Cuál es la mejor manera de aprender a pasar una entrevista técnica en Facebook, Palantir, Google, etc. después de haber estado codificando solo durante unos meses?
- ¿Es una mala práctica usar las declaraciones 'continuar' o 'siguiente' al programar?
- Quiero ser diseñador para startups: ¿qué herramienta de software debo aprender a usar?
- ¿Cómo se decide qué lenguaje de programación usar para un proyecto?
Piense en los problemas relacionados con la red: ¿qué sucede si la red no funciona?
¿Cómo establece el cliente y el servidor la conexión / seguridad? ¿Qué pasa si algo sale mal?
¿Son diferentes las redes?
Pruebe diferentes tipos de datos: debe ser creativo aquí.
Pruebe los datos corruptos: si hay problemas, el desarrollador dirá: ‘nuestros datos nunca pueden ser corruptos’
Asegúrese de hacer preguntas sobre seguridad
Ahora comience a estudiar cómo se comunica el servidor con el cliente. Haga preguntas a los desarrolladores. Comprenda el protocolo que se está utilizando.
Mientras haces todo esto, asegúrate de seguir jugando con la interfaz de usuario.
¿Puedes crear escenarios de cómo los clientes usarán el producto?
¿Puedes simular un escenario de los datos después de unos meses, unos años? (No te pierdas en los guiones para esto). Obtenga ayuda del desarrollador para hacer esto.
Debe crear una biblioteca de scripts para crear escenarios escalables.
Espero que captes la idea.
Eche un vistazo a mis ejemplos de carrito de compras:
fallas del carrito de compras (cualitativo):
¿Cómo puede fallar un carrito de compras de comercio electrónico (fallas cualitativas)
fallas del carro de compras (componente):
¿Cómo puede fallar un carrito de compras de comercio electrónico?
Catálogo de defectos:
XMind: el software de mapeo mental más profesional
Crédito: Cem Kaner, JD, Ph.D., James Bach – Satisfice, Inc., los evaluadores saben que las cosas pueden ser diferentes