- Compare con la automatización de pruebas .
La prueba manual es el proceso de probar manualmente el software en busca de defectos. Requiere que un evaluador desempeñe el papel de un usuario final mediante el cual utilizan la mayoría de las funciones de la aplicación para garantizar el comportamiento correcto. Para garantizar la integridad de las pruebas, el evaluador a menudo sigue un plan de prueba escrito que lo guía a través de un conjunto de casos de prueba importantes .
Descripción general
Un paso clave en el proceso es probar que el software se comporta correctamente antes de su lanzamiento a los usuarios finales.
Para los esfuerzos de ingeniería a pequeña escala (incluidos los prototipos), las pruebas exploratorias pueden ser suficientes. Con este enfoque informal, el evaluador no sigue ningún procedimiento de prueba riguroso, sino que explora 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 dominio del evaluador, porque la falta de conocimiento conducirá a que las pruebas no estén completas. Una de las ventajas clave 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 se basan en 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 generalmente implica los siguientes pasos. [1]
- Elija un plan de prueba de alto nivel en el que se elija una metodología general y se identifiquen y adquieran recursos como personas, computadoras y licencias de software.
- Escriba casos de prueba detallados , identificando los pasos claros y concisos que debe tomar el evaluador, con los resultados esperados.
- Asigne los casos de prueba a los probadores, quienes siguen manualmente los pasos y registran los resultados.
- Cree un informe de prueba, detallando los hallazgos de los evaluadores. Los gerentes utilizan el informe para determinar si el software puede lanzarse y, de no ser así, los ingenieros lo utilizan para identificar y corregir los problemas.
Un enfoque riguroso basado en casos de prueba suele ser tradicional para grandes proyectos de ingeniería de software que siguen un modelo Waterfall . [2] Sin embargo, al menos un estudio reciente no mostró una diferencia dramática 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 declaraciones 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 probadores de caja negra no tienen acceso al código fuente. Las pruebas de caja gris se refieren a ejecutar el software mientras se comprende el código fuente y los algoritmos. [ cita requerida ]
También se puede utilizar un enfoque de prueba estático y dinámico . Las pruebas dinámicas implican ejecutar el software. Las pruebas estáticas incluyen la verificación de los 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 probador verificaría los cálculos, cualquier enlace en la página o cualquier otro campo que, en una entrada determinada, se pueda esperar. Las pruebas no funcionales incluyen probar el rendimiento, la compatibilidad y la aptitud del sistema bajo prueba, su seguridad y usabilidad, entre otras cosas.
Etapas
Hay varias etapas. Ellos son:
- Examen de la unidad
- Esta etapa inicial de la prueba normalmente la lleva a cabo el desarrollador que escribió el código y, a veces, un par que utiliza la técnica de prueba de caja blanca.
- Pruebas de integración
- Esta etapa se lleva a cabo en dos modos, como un paquete completo o como un incremento del paquete anterior. La mayoría de las veces se utiliza la técnica de prueba de caja negra. Sin embargo, a veces también se utiliza una combinación de pruebas de caja en blanco y negro en esta etapa.
- Prueba del sistema
- En esta etapa, el software se prueba en todas las dimensiones posibles para todos los propósitos y plataformas previstos. En esta etapa se utiliza normalmente la técnica de prueba de caja negra.
- Pruebas de aceptación del usuario
- Esta etapa de prueba se lleva a cabo con el fin de obtener la aprobación del cliente del producto terminado. Un "pase" en esta etapa también garantiza que el cliente haya aceptado el software y esté listo para su uso.
- Prueba de lanzamiento o implementación
- El equipo in situ irá al sitio del cliente para instalar el sistema en el entorno configurado por el cliente y comprobará los siguientes puntos:
- Si SetUp.exe se está ejecutando o no.
- Hay pantallas fáciles durante la instalación.
- Cuánto espacio ocupa el sistema en el disco duro
- ¿El sistema está completamente desinstalado cuando se optó por desinstalarlo del sistema?
Ventajas de las pruebas manuales
- Operación de bajo costo ya que no se utilizan herramientas de software
- La mayoría de los errores se detectan mediante pruebas manuales.
- Los humanos observan y juzgan mejor que las herramientas automatizadas
Comparación con las pruebas automatizadas
La automatización de pruebas puede reducir o eliminar el costo de las pruebas reales. Una computadora puede seguir una secuencia de pasos de memoria 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, la mano de obra que se ahorra en las pruebas reales debe gastarse en la creación del programa de prueba. Dependiendo del tipo de aplicación que se probará y 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 puede crear una tarea que requiere mucho tiempo para interpretar los resultados.
Cosas como controladores de dispositivos y bibliotecas de software deben probarse con programas de prueba. Además, las pruebas de un gran número de usuarios ( pruebas de rendimiento y pruebas de carga ) generalmente se simulan en 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. Hay marcos de prueba que se pueden utilizar para pruebas de regresión de interfaces de usuario. Se basan en la grabación de secuencias de pulsaciones de teclas y gestos del mouse, luego las reproducen y observan que la interfaz de usuario responde de la misma manera cada vez. Desafortunadamente, es posible que estas grabaciones no funcionen correctamente cuando un botón se mueve o se vuelve a etiquetar en una versión posterior. Una prueba de regresión automática también puede ser engañada si la salida del programa varía significativamente.
Ver también
Referencias
- ^ ANSI / IEEE 829-1983 Estándar IEEE para documentación de prueba de software
- ^ Craig, Rick David; Stefan P. Jaskiel (2002). Pruebas de software sistemáticas . Casa Artech. pag. 7. ISBN 1-58053-508-9.
- ^ Itkonen, Juha; Mika V. Mäntylä; Casper Lassenius (2007). "Eficiencia de detección de defectos: prueba basada en casos frente a pruebas exploratorias" (PDF) . Primer Simposio Internacional sobre Ingeniería y Medición de Software Empírico : 61–70. doi : 10.1109 / ESEM.2007.56 . ISBN 978-0-7695-2886-1. Archivado desde el original (PDF) el 13 de octubre de 2016 . Consultado el 17 de enero de 2009 .