Las pruebas manuales son el proceso de probar manualmente el software para detectar defectos. Requiere que un evaluador desempeñe el papel de un usuario final, en el que utiliza la mayoría de las funciones de la aplicación para garantizar un comportamiento correcto. Para garantizar la integridad de las pruebas, el evaluador suele seguir un plan de pruebas escrito que lo guía a través de un conjunto de casos de prueba importantes .
Un paso clave en el proceso es probar el software para verificar su correcto comportamiento antes de lanzarlo a los usuarios finales.
Para los esfuerzos de ingeniería a pequeña escala (incluidos los prototipos), las pruebas ad hoc pueden ser suficientes. Con este enfoque informal, el evaluador no sigue ningún procedimiento de prueba riguroso y simplemente realiza pruebas sin planificación ni documentación. Por el contrario, las pruebas exploratorias , que implican aprendizaje simultáneo, diseño de pruebas y ejecución de pruebas, exploran la interfaz de usuario de la aplicación utilizando tantas de sus características como sea posible, utilizando la información obtenida en pruebas anteriores para derivar intuitivamente pruebas adicionales. El éxito de las pruebas manuales exploratorias depende en gran medida de la experiencia del evaluador en el dominio, porque la falta de conocimiento conducirá a pruebas incompletas. Una de las principales ventajas de un enfoque informal es obtener una visión intuitiva de cómo se siente al usar la aplicación.
Los proyectos de ingeniería a gran escala que dependen de pruebas de software manuales siguen una metodología más rigurosa para maximizar la cantidad de defectos que se pueden encontrar. Un enfoque sistemático se centra en casos de prueba predeterminados y, por lo general, implica los siguientes pasos. [1]
Un enfoque riguroso basado en casos de prueba suele ser tradicional para grandes proyectos de ingeniería de software que siguen un modelo en cascada . [2] Sin embargo, al menos un estudio reciente no mostró una diferencia drástica en la eficiencia de detección de defectos entre las pruebas exploratorias y las pruebas basadas en casos de prueba. [3]
Las pruebas pueden realizarse mediante pruebas de caja negra , blanca o gris . En las pruebas de caja blanca, el evaluador se ocupa de la ejecución de las instrucciones a través del código fuente. En las pruebas de caja negra, el software se ejecuta para verificar los defectos y se preocupa menos por cómo se realiza el procesamiento de la entrada. Los evaluadores de caja negra no tienen acceso al código fuente. Las pruebas de caja gris se ocupan de ejecutar el software teniendo una comprensión del código fuente y los algoritmos. [4]
También se pueden utilizar métodos de prueba estáticos y dinámicos . Las pruebas dinámicas implican la ejecución del software. Las pruebas estáticas incluyen la verificación de requisitos, la sintaxis del código y cualquier otra actividad que no incluya la ejecución real del código del programa.
Las pruebas se pueden dividir en pruebas funcionales y no funcionales . En las pruebas funcionales, el evaluador verificaría los cálculos, cualquier vínculo en la página o cualquier otro campo que, en función de la entrada, pueda esperarse que dé resultados. Las pruebas no funcionales incluyen pruebas de rendimiento, compatibilidad y aptitud del sistema bajo prueba, su seguridad y usabilidad, entre otras cosas.
Existen varias etapas, que son:
La automatización de pruebas puede reducir o eliminar el costo de las pruebas reales. [5] Una computadora puede seguir una secuencia de pasos repetida más rápidamente que una persona y puede ejecutar las pruebas durante la noche para presentar los resultados por la mañana. Sin embargo, el trabajo que se ahorra en las pruebas reales debe dedicarse a crear el programa de prueba. Dependiendo del tipo de aplicación que se va a probar y de las herramientas de automatización que se elijan, esto puede requerir más trabajo que un enfoque manual. Además, algunas herramientas de prueba presentan una gran cantidad de datos, lo que potencialmente crea una tarea que consume mucho tiempo para interpretar los resultados.
Elementos como los controladores de dispositivos y las bibliotecas de software deben probarse mediante programas de prueba. Además, las pruebas de un gran número de usuarios ( pruebas de rendimiento y pruebas de carga ) suelen simularse en el software en lugar de realizarse en la práctica.
Por el contrario, las interfaces gráficas de usuario cuyo diseño cambia con frecuencia son muy difíciles de probar automáticamente. Existen marcos de prueba que se pueden utilizar para realizar pruebas de regresión de interfaces de usuario. Se basan en la grabación de secuencias de pulsaciones de teclas y gestos del ratón, para luego reproducirlas y observar que la interfaz de usuario responde de la misma manera cada vez. Desafortunadamente, estas grabaciones pueden no funcionar correctamente cuando se mueve o se reetiqueta un botón en una versión posterior. Una prueba de regresión automática también puede resultar engañosa si el resultado del programa varía significativamente.