Testing de Software (parte 1)

El testing del software es una práctica habitual y que es llevada día a día por miles de testers y especialistas de QA. Pero en la actualidad, el despliegue de pipelines #DevOps obligan a integrar el #testing como parte de los pipelines CI/CD.

Developer free icon

Por eso, hacemos esta entrada para adentrarnos en temas de pruebas de #software.

Esta es una lista de los tipos de pruebas existentes:

Prueba Unitaria

La prueba unitaria nos facilita el test de una parte de código que está realizando alguna acción determinada. Durante la prueba unitaria solamente probamos esa porción de código. Por ejemplo, si estamos haciendo una llamada a una base de datos, posiblemente aun no tengamos la base disponible y emulemos la prueba para saber si el código funciona.

Para esta prueba existen herramientas para los lenguajes mas habituales. En pruebas Java tiene JUnit , Python tiene PyUnit o PyTest , JavaScript tiene Mocha entre otros, .NET tiene xUnit, etc.

Prueba de Integración

En este caso, la prueba de integración nos permite hacer el test sobre varios componentes juntos. Siguiendo con el ejemplo de la prueba unitaria, en este caso, la diferencia sería que la llamada a la base la probaríamos haciendo la llamada realmente a la base destino.

El propósito de este test es justamente probar la interacción entre los diferentes componentes de la app, las relaciones y comunicaciones de los mismos.

Pruebas E2E (Extremo a Extremo)

En este caso las pruebas de Extremo a Extremo, hacen referencia a la ejecución de test sobre toda la aplicación. Seria el broche final de las Pruebas Unitarias y las Pruebas de Integración. En el test E2E, se ejecuta desde principio a fin toda la aplicación y muchas veces es el mismo usuario solicitante el que se encarga de ejecutar este tipo de prueba. Aplicaciones como Cucumber o Postman suelen ser herramientas amigables para la ejecución de estas pruebas.

Las 3 pruebas mencionadas hasta aquí suelen ser probadas en un ambiente aislado, con la función específica de conocer el comportamiento de las nuevas piezas de software.

Prueba de aceptación

En este caso, la prueba de aceptación nos lleva a un bloque de pruebas orientado a recibir la aceptación formal de un Cliente o Usuario, confirmando que los requerimientos solicitados fueron cumplidos tal como fueron pedidos.

Debido a la adopción de metodologías ágiles y de testing como TDD, las pruebas de aceptación suelen ser mas cortas que antaño, ya que el usuario suele estar involucrado durante las fases de desarrollo y el testing se va ejecutando como parte del proceso desarrollo (al igual que las pruebas de seguridad y de performance)

Pruebas de Humo (Smoke Testing)

Este tipo de pruebas, tiene vital importancia durante la configuración de los pipelines CI/CD, ya que las pruebas de humo permiten saber si la compilación del software implementado es estable, a partir de la ejecución de un conjunto mínimo de pruebas al azar que se corren en cada compilación para probar las funcionalidades del software.

Este tipo de testing suele llamarse Test de Confianza y como se mencionó anteriormente, agregar este nuevo bloque de pruebas en el pipeline proporcionará una validación de que la aplicación pasó todos los casos de prueba. 

En otra entrada vamos a continuar con testing focalizados a la Performance y la Seguridad.