En este artículo explicamos cómo hacer un plan de pruebas mínimo en ingeniería de datos. Hablamos de la importancia de asegurar la calidad de los procesos con un plan de pruebas detallado y documentado: qué, cómo y por qué probar.
¿Se puede programar sin errores?
Sabemos que es imposible programar sin errores. Para evitar esto, quienes desarrollan software —antes de pasar el programa a las personas usuarias— deben hacer todas las pruebas necesarias para asegurarse que funcione bien.
Es importante probar que el software funcione de forma correcta, sin embargo, esto no siempre sucede. En el mejor de los casos, las pruebas que se realizan son suficientes. Pero, también es frecuente que los programadores o no prueben lo suficiente o lo hagan mal.
En ingeniería de datos se agrega una complejidad más: además de probar el software, hay que probar los datos. La responsabilidad de probar adecuadamente es de los equipos de ingeniería de datos. Sin embargo, no solo es importante probar sino también dejar evidencia de que lo hicimos.
La importancia de dejar evidencia en pruebas de ingeniería de datos: garantía de calidad para equipos y clientes
Dejar evidencia de las pruebas que hacemos en ingeniería de datos es importante por dos motivos principales:
- Para nosotros: Para demostrar que realmente hicimos las pruebas. Hay que tener en claro que, si no dejamos esa constancia, la prueba no existe.
- Para los demás: Si un líder/cliente/colega tiene la evidencia de las pruebas y después ocurre alguna falla, esa persona podrá entender qué pruebas hicimos, cuáles no y esto le permitirá circunscribir las razones del problema para accionar en consecuencia. Esto hace más simple y rápida su corrección.
¿Cuál es la diferencia entre “caso de prueba”, “pruebas” y “probar que probamos”?
Estos tres conceptos pueden parecer similares, pero no lo son. A continuación, explicamos la diferencia entre cada uno:
- Caso de prueba (en inglés, test case) es el conjunto de condiciones o variables bajo las cuales se determinará si una aplicación, un proceso o una característica o comportamiento resulta (o no) aceptable. Es decir, un caso de prueba es aquello que tenemos que probar.
- Probar: Es la acción de verificar el correcto funcionamiento de una aplicación o procesos y puede incluir uno, ninguno o varios casos de prueba previamente definidos.
- Probar que probamos: Es dejar evidencia concreta de las pruebas que realizamos.
La diferencia entre estos tres conceptos parece sutil, pero es enorme. El primero nos indica qué debemos probar, el segundo es la ejecución de las pruebas y el tercero es poder demostrar qué pruebas hicimos y qué resultados tuvieron. De nada sirve definir los casos de prueba y probar, si no dejamos evidencia que lo hicimos.
La frase “cuando lo probé funcionaba” es muy común en ingeniería de datos. Puede que esto sea efectivamente así, pero, si no hay evidencia de que lo probamos, será la palabra de una persona contra los hechos. Y, reiteramos, es responsabilidad del ingeniero/a de datos dejar constancia que efectivamente realizó las pruebas.
¿Cómo hacer un plan de pruebas en ingeniería de datos?
Un buen plan de pruebas supone planificación. Dejar evidencia, nos obliga a que —antes de realizar la prueba— tenemos que pensar qué vamos a probar. A continuación, damos algunos ejemplos de lo mínimo que un plan de pruebas debería tener:
1) Todo tablero (visualización) y desarrollo de ingeniería de datos deberá tener su plan de pruebas mínimo ejecutado y documentado.
2) Cada prueba deberá documentarse adecuadamente, capturando la pantalla, el resultado del query o alguna otra forma que deje constancia verificable que la prueba se ejecutó y que pasó exitosamente.
3) En caso de que una prueba falle, deberá solucionarse el problema y volver a ejecutarse la totalidad de las pruebas (consistencia integral).
4) El documento con la evidencia deberá adjuntarse a la tarea (DevOps/Jira/Trello/etc.) para documentar su ejecución.
5) La ejecución del “Plan de pruebas mínimo” no exime que se realicen otras pruebas para asegurar la calidad del producto terminado.
6) El/la ingeniero/a de datos es responsable de la calidad del producto que entrega, debiendo realizar todas las pruebas adicionales que considere necesarias para garantizarla.
7) En caso de detectarse un error posterior a la entrega o de realizarse cambios en los reportes o procesos, se deberán ejecutar la totalidad de las pruebas nuevamente.
Elementos clave de un plan de pruebas en ingeniería de datos.
El plan de pruebas se puede armar incluso en una planilla de Excel, de Google Sheets o similar a la que todos los miembros del equipo tengan acceso. Obviamente, contar con herramientas específicas para esto es mucho mejor. Este documento debe indicar:
- Qué pipeline vamos a validar, quién lo hizo y la fecha de las prueba.
- Describir del control que hicimos, por ejemplo: si leímos/entendimos las definiciones de negocio, si los valores de las métricas coinciden con los de la fuente de datos, si existen (o no) valores fuera de rangos lógicos (outliers), etc.
- Cuál fue el resultado de la prueba -> “OK”, “falló” o “N/A”.
- Dónde quedó documentado.
- Quién lo ejecutó.
- Una columna para dejar cualquier observación.
A continuación, les dejamos un ejemplo de cómo documentar un proceso de ingeniería de datos:
Ejemplo de plan de pruebas mínimo
Conclusión
Hay un viejo dicho que dice: “no solo hay que ser honesto, también hay que parecerlo”, y con el tiempo, eso se abrevió en: no sólo hay que ser, sino parecer.
Probar que probamos es el recurso que en ingeniería de datos tenemos para ser y parecer. No sólo somos responsables de que funcionen los procesos, sino que también tenemos que garantizar que los datos sean correctos.
Dejar evidencia que hicimos las pruebas es fundamental. Si hay casos de prueba, los usamos, si no hay, definimos un conjunto de pruebas mínimo que consideramos adecuado y dejamos evidencia de que las hicimos.
Ese conjunto de pruebas puede ser acordado con el equipo, con el líder, con la persona que usará los datos o con uno mismo. Lo que seguro no puede pasar, es que no hayamos probado o que no podamos probar que probamos.
Esta es una de las mejores prácticas que podemos aplicar en ingeniería de datos. Tener un buen plan de pruebas nos sirve para evitar fallas que implican pérdida de confianza en lo que hicimos. Tengamos en cuenta el rol central que los datos ocupen en las empresas: si la información que le proveemos al negocio está mal, se pueden tomar decisiones erróneas.
Por eso, no importa el cliente o el proyecto, no importa si nos lo pidieron o no, hay que probar y dejar evidencia clara de que hicimos esas pruebas y salieron bien. Siempre.
