Reyes Sánchez García/ octubre 10, 2022/ Gestión de la calidad/ 0 comentarios
Tiempo de lectura: 5 minutosUno de los puntos claves del testing es una buena selección de datos para ejecutar pruebas. Sin embargo, no siempre es una tarea fácil. Nos podemos encontrar con diferentes dificultades que nos impiden ejecutar lo necesario para garantizar una cobertura adecuada de nuestro plan de pruebas. En este post enumeraré los problemas que nos podemos enfrentar y las situaciones que se pueden presentar.
¿Quieres saber cuáles son? Sigue leyendo.
Índice de contenidos
¿Por qué no tengo los datos necesarios para ejecutar pruebas?
En primer lugar, debes tener en cuenta que hay varias causas por las que no se tendrá los datos disponibles para ejecutar: porque no sabemos que los necesitamos, no se han seleccionado esos datos para probar o, por último, porque aunque se han identificado esa tipología de datos, no se han podido obtener. Profundizaré más en cada una de esas situaciones.
No se conoce la existencia de esos datos para ejecutar pruebas
En primera instancia, se da la situación de que no se sepa siquiera que ese dato lo necesitamos. En otras palabras, estamos tan felices con nuestra selección de datos que «cumple» las condiciones de prueba, pero no somos conscientes de que nos falta algo. Esta situación es una de las más inconvenientes, porque al no saber que tenemos un «problema», no podemos hacer nada para resolver la situación.
No se selecciona el dato al identificar las condiciones de prueba
A continuación, nos encontramos con la situación en la que se conoce la existencia de esa tipología de dato, pero no se ha seleccionado para la prueba. Pongamos, por caso, que puede ser debido a que no ha identificado como condición a cumplir específicamente o porque ha sido necesario recortar las pruebas a realizar por cuestiones de tiempo y esfuerzo requerido. En cualquiera de las dos situaciones, no tendremos esos datos para ejecutar pruebas.
No es posible obtener esos datos para ejecutar pruebas
En tercer lugar, está la situación más frecuente en muchos proyectos. Se ha identificado la condición de prueba, se ha incluido en el plan de prueba, se ha solicitado el dato, sin embargo, no tenemos el dato. Eso puede ocurrir por sistemas inestables, donde la volatilidad de los datos es alta. También, por la dificultad de coordinar a distintas áreas o equipos implicados en el proyecto. Sea como fuere, la realidad es que en el momento de validar el desarrollo implementado, no tenemos el dato necesitado.
¿Qué escenario me puedo encontrar si no tengo los datos para ejecutar pruebas?
Por cualquiera de las 3 situaciones anteriores, o por alguna de ellas, nos podemos encontrar ante las siguientes decisiones a tomar. Muchas veces, no dependerá del Equipo de QA, sino de loas líderes del proyecto elegir la dirección a seguir.
Se acepta el riesgo. Se promociona el código sin probar esa condición.
Cuando no ha llegado el dato, o cuando no se ha seleccionado ese dato para la condición de pruebas, se es consciente de que existe un riesgo. En este punto, hay veces en las que se toma la decisión de subir a producción, aceptando el riesgo.
¿Qué puede ocurrir entonces? Puede que todo vaya bien, o que, por el contrario, más adelante se identifique un defecto en producción. Si este segundo ocurriera, nos encontramos con una incidencia qué una vez aplicada la corrección se podrá probar con ese dato seleccionado. Inicialmente, se tendrá ese dato, ya que se ha detectado el defecto, y se contará con él para validar la solución.
No se acepta el riesgo. Se retrasa la implantación.
En segundo lugar, no encontramos que ante la situación de no poder disponer de esos datos para ejecutar pruebas, se opta por no implantar en el momento planificado. En otras palabras, somos conscientes de que hay un riesgo, y debido a la posibilidad de ocasionar una incidencia en producción, se opta por esperar a poder validar esta condición aplazando la implantación en producción.
¿Qué puede pasar a continuación en este caso? Dos situaciones: primero, que llegue el dato finalmente y se pruebe esta condición de prueba. O, por el contrario, que no llegue el dato y finalmente se opte por validar la solución directamente en producción. Sí, sabemos que no es la solución más adecuada, pero a veces, no hay más alternativa por las trabas de entornos previos y la prioridad de implantar algunos evolutivos o correctivos.
No se conoce el riesgo. Provoca una incidencia en producción.
En tercer lugar, cuando no conocemos la necesidad de probar una tipología de datos, seguramente, se promocione un defecto a producción que será difícil de identificar. Sabemos que asegurar el 0% de defectos no es una realidad.
La ventaja de esta situación es que si tenemos unos buenos procesos implantados en el proyecto o equipo de trabajo, podremos sacar partido de esta situación. ¿Cómo? Pues, identificando este tipo de dato, incluyendo esta casuística en la documentación, bitácora de pruebas e histórico del proyecto, para tenerlo en cuenta para futuras evoluciones o correcciones sobre el mismo.
Conclusión: Pon cariño a la selección de datos para ejecutar pruebas
Está claro que si no conocemos una condición de prueba no podremos disponer de los datos para ejecutar pruebas. Sin embargo, debemos de hacer todo lo posible para tener claras las circunstancias de pruebas con las que nos encontraremos y los datos implicados en nuestro proyecto.
Mis consejos para lograr el máximo de cobertura son:
- En primer lugar, debemos analizar bien la documentación del proyecto e identificar todas estas condiciones de datos.
- Crear y actualizar de una base de conocimiento donde se registren todas las necesidades de datos que se identifican en el proyecto.
- Coordinar bien la obtención de los datos para que estén disponibles en la fecha planificada.
Si llevas a cabo estos puntos, estarás más cerca de lograr el objetivo de unas pruebas con 100% de datos disponibles para ejecutar.
Si te ha gustado este post, por favor, suscríbete al blog para estar al tanto de las novedades. Además, tanto si te ha gustado como no, puedes dejar un comentario y hablamos al respecto.