En los últimos años hemos oído a muchas personas preguntarse ¿Qué es una testing manual? Se trata de un término que solo parece ser conocido por los expertos desarrolladores de Software.

Sin embargo, no dejes que el nombre te asombre o te asuste, la verdad es que se trata de algo más simple de lo que puedes pensar. En el siguiente post no solo te lo explicaremos sino que además te daremos los pasos a seguir para que sepas cómo hacer testing de Software Manual.

El testing de Software Manual a menudo se usa para llevar un mejor control durante la fase de desarrollo de un sistema en un esfuerzo por detectar defectos lo antes posible. La mayoría de las veces, esto significa desarrollar y ejecutar pruebas más automatizadas de la interfaz de usuario y las API. Estas pruebas son muy importantes, y a continuación te diremos qué son, cuáles son sus tipos y sus objetivos.

Qué es el testing manual

Un testing manual o prueba manual es un tipo de prueba de software donde los probadores ejecutan manualmente los casos de prueba sin usar ninguna herramienta de automatización.

La prueba manual es la más primitiva de todos los tipos de prueba y ayuda a encontrar errores en el sistema de software. Cualquier aplicación nueva debe probarse manualmente antes de que esta pueda automatizarse. La prueba manual requiere más esfuerzo pero es necesaria para verificar la viabilidad de la automatización.

Dicho de una manera más simple, la prueba manual significa probar una aplicación manualmente por un humano para garantizar que un sitio web o una aplicación funcionen correctamente según las diversas condiciones que se escriben en los casos de prueba.

El objetivo de un probador de software es verificar el diseño, la funcionalidad y el rendimiento de la interfaz de usuario del sitio web haciendo clic en varios elementos pero también es intentar corromperlo para ver si existe algún punto ciego que se pueda considerar como una vulnerabilidad.

Tipos y Objetivos del Testing Manual

Los siguientes son los objetivos de los testing manuales:

• Garantizar que la aplicación esté libre de errores y que funcione de conformidad con los requisitos funcionales especificados. 
• Garantizar que los conjuntos de pruebas o casos, estén diseñados durante la fase de prueba y que tengan una cobertura de prueba del 100%. 
• Asegurar que los defectos informados sean reparados por los desarrolladores, y que los probadores hayan realizado una nueva prueba en los defectos corregidos.
• Finalmente verificar la calidad del sistema y la entrega de un producto libre de errores al cliente.

Dicho esto podemos seguir con los tipos de testing

• Prueba de caja negra: La prueba de caja negra significa que el probador no tiene ningún conocimiento sobre la estructura de codificación interna de la aplicación o el sitio web. El probador interactúa con la aplicación y prueba el comportamiento funcional y no funcional de la aplicación.
• Prueba de caja blanca: La prueba de White Box significa que el probador conoce la estructura de codificación interna de la aplicación. Los desarrolladores lo usan para realizar pruebas unitarias.
• Prueba de caja gris: Gray Box es la combinación de las pruebas Black Box y White Box. Identifica los errores y defectos debido a la estructura o al uso incorrecto de la aplicación.
• Prueba de sistema: La prueba del sistema es el tipo de prueba para verificar un producto de software completo y totalmente integrado. Estas pruebas del sistema garantizan las pruebas funcionales / no funcionales y los requisitos del usuario final.
• Pruebas de integración: La prueba de integración se realiza después de completar la Prueba unitaria. Esta se hace en interfaces entre diferentes módulos o componentes las cuales se combinan o integran. El propósito principal de las pruebas de integración es verificar las pruebas funcionales y no funcionales entre los módulos que están integrados.
• Test de aceptación: La Prueba de aceptación es la prueba que realizan los usuarios antes de poder aceptar el producto de software. La prueba de aceptación es un tipo de técnica que se realiza para determinar si el sistema cumple con sus requisitos específicos o no. Es la fase final de la prueba antes de trasladar el producto de software al mercado.

Cómo hacer testing de Software Manual: Pasos

Estos son los pasos esenciales de prueba de software que todo ingeniero de software debería realizar antes de mostrar o entregar su trabajo.

Pruebas de funcionalidad básica

Comienza asegurándote de que todos los botones de cada pantalla funcionen. También debes asegurarte de que puedes ingresar texto simple en cada campo sin bloquear el software.

No tienes que probar todas las diferentes combinaciones de clics y caracteres, o condiciones de borde, porque eso lo harán tus evaluadores, y ciertamente ellos buenos en eso.

Si la característica está diseñada para acceder mediante una API, debes ejecutar pruebas para asegurarte de que la funcionalidad básica de la API funcione antes de enviarla para pruebas más intensivas. 

Revisión del código

Si tu metodología de codificación requiere una revisión por pares, realiza este paso antes de entregar el código para la prueba.

Sin embargo, recuerda hacer tu prueba de funcionalidad básica antes de la revisión del código.

Análisis de código estático

Existen herramientas que pueden realizar análisis en código fuente o bytecode sin ejecutarlo. Estas herramientas de análisis de código estático pueden buscar muchas debilidades en el código fuente, como vulnerabilidades de seguridad y posibles problemas de concurrencia.

Usa herramientas de análisis de código estático para aplicar estándares de codificación y configura esas herramientas para que se ejecuten automáticamente como parte de la compilación.

Prueba unitaria

Los desarrolladores escribirán pruebas unitarias para asegurarse de que la unidad (ya sea un método, clase o componente) funcione como se espera y realizarán pruebas en un rango de entradas válidas e inválidas.

En un entorno de integración continua, las pruebas unitarias deben ejecutarse cada vez que se realiza un cambio en el repositorio de código fuente, y también debe ejecutarlas en tu máquina de desarrollo.

Por otro lado, los desarrolladores también trabajan con objetos simulados y servicios virtualizados para asegurarse de que sus unidades se puedan probar de forma independiente.

Si tus pruebas unitarias fallan, corrígelas antes de permitir que otra persona use tu código. Si por alguna razón no puedes solucionarlos en este momento, avísale a la otra persona qué ha fallado, para que no se sorprenda cuando se encuentren con el problema.

Pruebas de rendimiento para un solo usuario

Algunos equipos tienen pruebas de carga y rendimiento integradas en su proceso de integración continua y ejecutan pruebas de carga tan pronto como se registra el código.

Esto es particularmente cierto para el código de fondo. Pero los desarrolladores también deberían observar el rendimiento de un solo usuario en el front-end y asegurarse de que el software responda cuando solo están usando el sistema.

Si se tarda más de unos segundos en mostrar una página web tomada de un servidor web local o emulado (y, por lo tanto, sensible), averigua qué código del lado del cliente está ralentizando las cosas y corrígelo antes de permitir que otra persona lo vea.