Poco a poco el término “Shift-Left Testing” ha entrado en el día a día de ingeniería de software. Pero ¿qué significa eso? En inglés simple, significa realizar más pruebas de software durante la fase de desarrollo de software, adelantar las pruebas a la fase de desarrollo.

Este tipo de pruebas busca mayor envolvimiento de los developers durante la fase de desarrollo, en un esfuerzo por detectar defectos lo antes posible, antes de entregar el software o la aplicación al equipo de QA para realizar pruebas mas extensas. La mayoría de las veces, significa desarrollar y ejecutar pruebas más automatizadas de la interfaz de usuario y las API.

Sin embargo, hay algunos pasos básicos y esenciales de prueba de software que todo desarrollador de software debe realizar antes de mostrarle a otra persona su trabajo, ya sea para pruebas integrales, UAT o simplemente llamar a un colega para darle un vistazo rápido al desarrollo. El objetivo de estas pruebas básicas es detectar los errores obvios que aparecerán inmediatamente. De lo contrario, se perdería tiempo enviándolo a pruebas por el equipo de QA y regresándolo al encontrar los defectos. El tiempo es dinero.

Las recomendaciones a los developers antes de pasar su aplicación al equipo de pruebas son:

Pruebas de funcionalidad básica

Comiencen asegurándose de que todos los botones de cada pantalla funcionen. También debe asegurarse de que puede ingresar texto simple en cada campo sin problemas. No tiene que probar todas las diferentes combinaciones de clics y caracteres, o condiciones limites, porque eso es lo que hacen sus equipos de QA. El objetivo aquí es este: no permita que el software llegue con defectos básicos al siguiente nivel, al suceder esto recurrentemente se generara desconfianza en el equipo de desarrollo. Si la app está diseñada para acceder mediante una API, debe ejecutar pruebas para asegurarse de que la funcionalidad básica de la API funcione antes de enviarla para pruebas más intensivas. Si su prueba de funcionalidad básica detecta algo que no funciona, está bien. Solo coméntanos que no funciona, que lo sabes y que no nos molestemos en probarlo. Puedes arreglarlo más tarde, simplemente no dejes sorpresas allí XD.

Revisión del código

Otro par de ojos que miran el código pueden descubrir problemas. 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 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. Pueden usar herramientas de análisis de código estático para aplicar estándares de codificación y configurar esas herramientas para que se ejecuten automáticamente como parte de la compilación.

Prueba unitaria

Los desarrolladores ejecutan 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 (CI), 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 su máquina de desarrollo.

Los desarrolladores también trabajan con objetos simulados y servicios virtualizados como responders, para asegurarse de que sus unidades se puedan probar de forma independiente.

Pruebas de rendimiento standalone

Algunos equipos de desarrollo tienen pruebas de carga y rendimiento integradas en su proceso de integración continua y ejecutan pruebas de carga tan pronto como se genera el código. 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 correctamente cuando solo un usuario está 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, si identifican altos tiempos de respuesta y retrasos en la carga de recursos, hay que comenzar a revisar el performance antes de liberar la aplicación para pruebas.