Imagínate esto, estás en un equipo que trabaja en un nuevo producto y necesita diseñar un plan de prueba para él. Es la primera vez que este producto pasa por cualquier tipo de proceso de control de calidad. La automatización no es una prioridad en este momento. Los propietarios de los productos quieren calidad, y el equipo necesita de alguna manera evaluar si la aplicación está haciendo lo que se supone que debe hacer. ¿Entonces, qué haces? R/ Pruebas manuales
En este artículo, revisaremos cuál es, para mí, el mejor enfoque para abordar una nueva funcionalidad en una aplicación.
PRIMERO, NECESITAS SABER SOBRE EL PRODUCTO
Antes de escribir cualquier prueba, debes centrarte en conocer el producto. Familiarizarte con las reglas comerciales, saber cuál es el objetivo de la aplicación. Dependiendo del equipo y las metodologías utilizadas, la documentación puede ser muy útil para esto. Pero si por alguna razón la documentación no es lo suficientemente buena, una reunión con el equipo siempre es útil para obtener esos pequeños detalles qué hacen o rompen la aplicación.
Tan pronto como te sientas familiarizado con la aplicación, puedes comenzar a diseñar un plan de prueba para ella. Generalmente, cuando me pasa esto, trato de seguir un enfoque más o menos estandarizado.
PRUEBAS DE RUTA FELIZ
Lo primero que siempre busco en una funcionalidad que estoy a punto de probar es la Ruta Feliz. Una Ruta Feliz es la suma de pasos que se espera que el usuario tome para una funcionalidad determinada. Conocer la ruta feliz nos ayudará a definir cómo variar de él en nuestras pruebas.
Digamos, por ejemplo, que estamos trabajando para Instagram y nos piden que probemos la funcionalidad de publicación. En este caso, ¿cuál sería la ruta feliz?
Bueno, en este caso, es probable que el usuario utilice un dispositivo / SO compatible, use una foto normal tomada con la cámara de su teléfono con una relación de aspecto de hasta 16: 9.
Cada vez que estamos probando escenarios de ruta feliz, debemos esperar que la aplicación funcione según lo especificado y nada más. Esta es la forma en que la mayoría de los usuarios probablemente usarán la aplicación y debería estar funcionando de manera impecable.
PRUEBAS POSITIVAS
Cuando comencemos a desviarnos de la ruta feliz, comenzaremos a encontrar varios escenarios. Es posible que estos no sean exactamente lo que esperamos que hagan nuestros usuarios, pero son totalmente válidos y deberían funcionar también.
Volviendo a «publicar una foto en Instagram», la ruta feliz sería hacer todo el proceso desde la aplicación … Pero, Instagram también nos permite publicar fotos de la aplicación de la galería en nuestro teléfono. Esta no es la ruta feliz y no es lo que haría la mayoría de los usuarios, pero es una acción totalmente válida que debe ser compatible y manejada con gracia.
PRUEBAS NEGATIVAS
Después de explorar nuestros escenarios positivos, sabremos la mayoría de las cosas que deberíamos poder hacer con nuestra aplicación. Pero esto no nos dará la cobertura de prueba que necesitamos. También necesitamos saber qué puede hacer nuestra aplicación y cómo debe comportarse en esas situaciones.
De nuevo, echando un vistazo a nuestro caso de uso de «publicar una foto en Instagram», ¿qué te viene a la mente que no debería ser posible? ¿Qué pasa con los tipos de archivos no compatibles? ¿Debería la aplicación admitir fotos con tamaños de archivo enormes? ¿Qué pasa con las relaciones de aspecto funky como 21: 9?
Estos son una combinación de escenarios en los que la aplicación no debería permitirnos continuar, y escenarios en los que la aplicación debería ajustar lo que ingresamos a algo que sea válido. Todo esto debe ser documentado y probado en contra.
PRUEBAS NO FUNCIONALES
Después de eliminar todas las pruebas funcionales, podemos profundizar en el lado no practico de las cosas. La prueba no funcional es un agujero de conejo bastante profundo que puede ir tan hondo como el equipo esté dispuesto a hacerlo. El tipo de pruebas no funcionales aplicadas a un producto depende completamente del equipo, sus prioridades y presupuesto. Mis favoritos son las pruebas de compatibilidad y estrés. Echemos un vistazo a cada uno de ellos.
PRUEBAS DE COMPATIBILIDAD
Cuando hacemos pruebas de compatibilidad, todo lo que estamos haciendo es verificar cómo se comporta nuestro sistema con otros. Cosas como la versión del sistema operativo de nuestra aplicación, la versión de nuestro navegador, el navegador mismo o incluso el dispositivo que estamos usando en ese momento pueden afectar nuestra aplicación.
Probar una aplicación móvil en un iPhone definitivamente no es lo mismo que hacerlo en un Samsung. Pero al mismo tiempo, probarlo en un Samsung no es lo mismo que probarlo en un Google Pixel. Entonces, estas son todas las cosas que deben tenerse en cuenta al diseñar tu plan de prueba. Por lo general, lo mejor es apostar por lo que tu base de usuarios utiliza más, para asegurarse de que tu producto funcione como se espera para la mayoría de tus clientes.
PRUEBAS DE ESTRÉS
En las pruebas de estrés, el objetivo es probar qué tan robusta es nuestra aplicación. Este tipo de prueba es aún más importante en las aplicaciones de «misión crítica», en las que una caída puede significar una gran pérdida para la empresa o para el usuario. Este tipo de prueba pone énfasis en cómo la aplicación responde a la carga pesada, la disponibilidad de la misma y cómo maneja los errores cuando surgen.
Idealmente, un sistema nunca debería detenerse y, si se produce un error, la aplicación necesita manejarlo con gracia y ofrecer al usuario la opción de seguir utilizándolo. Este tipo de prueba generalmente se confunde con la prueba de carga. La diferencia clave es que con la prueba de carga, el objetivo es probar cómo la aplicación maneja la carga de trabajo normal esperada en un entorno que simula el uso en el mundo real que obtendrá. Mientras que con la prueba de estrés, el tester va más allá de este punto para probar el límite absoluto en condiciones sub óptimas.
