Tipos de pruebas
En esta sección, aprenderá los conceptos básicos sobre cómo completar las pruebas en su aplicación.
Pruebas unitarias
Puede utilizar una prueba unitaria para comprobar si una función o característica específica de su aplicación está funcionando correctamente. Estas pruebas son repetibles y se ejecutan mediante programación en fracciones de segundo. Es decir, las pruebas unitarias garantizan que el código que se incluye en su solución funcione como se espera.
Pruebas de extremo a extremo
Las pruebas de extremo a extremo le ayudarán a comprobar si la solución general se ejecuta correctamente. Esto es importante porque, aunque todas las pruebas unitarias funcionan correctamente, la integración entre dos unidades puede fallar. Puede completar estas pruebas siguiendo un escenario de prueba similar al caso de uso del proceso empresarial real.
La solución resultante podría no implicar un código personalizado; por lo tanto, es posible que la necesidad de hacer pruebas unitarias no sea muy interesante. Sin embargo, las pruebas de extremo a extremo siempre serán un requisito antes de lanzar una solución para los usuarios dentro de la organización.
Pruebas de aceptación del usuario
Serán los usuarios de las aplicaciones los que administren la prueba de aceptación del usuario (UAT), no el fabricante. El objetivo de esta prueba es garantizar que la aplicación desarrollada se ajuste a los requisitos solicitados inicialmente por el usuario.
Para obtener buenos resultados de las UAT, haga lo siguiente:
Haga las pruebas con usuarios reales.
Seleccione usuarios con diferentes niveles de capacidades de TI. Como resultado, recibirá varios comentarios.
No le dé instrucciones al usuario, compruebe si puede comprender la aplicación de forma intuitiva.
Observe cómo navegan los usuarios por la aplicación sin ayuda y luego determine dónde puede mejorar el diseño.
Cuando el usuario se queda atascado en una pantalla, pídale que explique sus expectativas.
Experimente con diferentes dispositivos para asegurarse de que los casos de prueba se comporten de manera similar.
Pruebe la aplicación en el entorno o la ubicación real del usuario si la aplicación tiene funciones sin conexión. Esta situación es ideal.
Pídales a los usuarios que intenten "estropear" su aplicación; por ejemplo, que introduzcan caracteres inusuales en los campos de texto.
Pídales a los usuarios que prueben escenarios más complejos. Normalmente, los usuarios probarán la "ruta feliz" (la ruta que sigue un usuario cuando todo va perfectamente). En lugar de eso, pídales que prueben otros escenarios, como cancelar un informe de gastos (en lugar de enviarlo) o rechazar un informe de gastos (en lugar de aprobarlo).
Es posible que los usuarios no estén familiarizados con el software de prueba. Explíqueles qué tipo de comentarios está buscando. Suele ser útil proporcionar una plantilla de errores para asegurarse de que los evaluadores expliquen exactamente lo que estaban haciendo, lo que sucedió, lo que esperaban que sucediera y otras cosas importantes sobre el entorno de prueba (como el tipo de dispositivo y el navegador).
Es natural y aceptable que el usuario solicite cambios en las especificaciones o pida otras características.
Estas solicitudes deben registrarse en la lista de características descrita en Priorización de funciones y solicitudes.