Debemos trabajar en la base de pruebas desde que nos llega la documentación de un proyecto. Revisar documentación, procesar contenidos, enumerar los puntos claves. Sin olvidar las sesiones de trabajo con desarrollo, con el cliente o internas con el equipo de calidad. Sin embargo, todo ese trabajo se desperdicia si no ponemos foco en lo importante: La cobertura. Hay que discriminar lo esencial. Parece fácil, ¿no?. Pero, ¿cómo lo hacemos? En los próximos párrafos explicaré qué debes tener en cuenta.
La importancia de la base de pruebas
La base de pruebas se define como «el conjunto de casos de prueba que se obtiene de la especificación del proyecto o derivados de la estructura interna de un componente para asegurar que será alcanzado el 100% de un criterio de cobertura concretado.»
Necesitamos tener un conjunto de casos de prueba principales, de forma que se garantice la validación de todos esos puntos que conforman la necesidad del cliente. Para ello se desgrana ese requerimiento para conocer cada detalle del mismo y saber como abordarlo para validar que se ha desarrollado correctamente. La maestría reside elaborar esa base de pruebas de forma que sea lo más completa posible, abordando cada uno de esos puntos destacados, sin olvidar los «puntos muertos».
Sabemos que nunca se puede asegurar que no existirán errores en nuestro software. Sin embargo, el objetivo principal de la base de pruebas es alcanzar el 100% de la cobertura.
Pautas a seguir para la creación de la base de pruebas
Para obtener un conjunto de pruebas «core» con amplia cobertura es recomendable seguir los siguientes puntos que enumero a continuación:
Repasar la documentación
En primer lugar, se debe disponer de la versión más actualizada de la documentación para poder revisarla minuciosamente. Lo ideal, es que se realiza una buena gestión de la documentación, unificando toda la información, y llevando un control de versiones. Aunque la realidad, es que no siempre se hace así. En otras palabras, debido a la agilidad necesaria en el día a día, y en la poca relevancia que se le da a estas, a veces no es posible disponer de una documentación formal.
En tal caso es necesario recopilar toda la información del requerimiento y unificarla. Posteriormente, una vez tenemos claro cuáles son los puntos a tener en cuenta en nuestro proyecto, procederemos a leer y analizar esa documentación. Después de eso se recomienda marcar (o subrayar) los puntos clave.
Divide y vencerás
Ya tenemos la información leída y subrayada. El siguiente paso es preparar un listado resumen donde se enumeren todos estos puntos a tener en cuenta. En este listado que puede ser formato que mejor le venga a tu organización, por ejemplo: tipo tabla, se listarán cada uno de los elementos a tener en cuenta en el desarrollo. La mente procesa la información de forma distinta al leer, escribir o incluso al escribir a mano y a teclado. En conclusión, es importarte dedicar un tiempo a este análisis y transcripción de los requisitos, lo que nos permite enfocar la información desde diferentes perspectivas.
En segundo lugar, dividiremos el contenido de cada párrafo obteniendo un conjunto de cáusticas que se transformaran más adelante, en nuestros casos de prueba.
Prepara tus preguntas por adelantado
Llegamos a uno de los momentos claves de los proyectos. Las sesiones de trabajo conjuntas con los equipos de desarrollo y cliente. Es recomendable tener preparadas el listado de preguntas que han surgido al repasar la documentación. No debemos escatimar en palabras. Redactemos la pregunta al completo, junto con la página del documento o referencia al correo donde fue localizada, así podremos optimizar las reuniones. Todos sabemos que con el pasar de los días, si no especificamos bien una duda, puede que la olvidemos. Seamos prácticos y anotemos exactamente lo que necesitamos saber para ir a tiro echo.
Una vez nos han resuelto las dudas, es recomendable formalizar esas respuestas en una pequeña acta que se debe enviar por correo. Es importante dejar constancia de las respuestas, sobre todo para permitir una corrección temprana en caso de no haber entiendo bien alguna cuestión.
Nota: Seguramente, en las fases posteriores nos surgirán nuevas dudas, que podremos resolver de forma ágil, quizás enviando un correo electrónico, o en alguna conversación. Estas preguntas serán añadidas al acta anterior, para ir completando su contenido.
Segunda parte: Casos base y refinameinto
Lista los casos básicos para hacer una base de pruebas
Ya tenemos nuestro listado de puntos claves, y nos han resuelto las dudas que teníamos. Es el momento de comenzar a listar nuestros casos de pruebas. Para ello repasando el listado de puntos importantes, procederemos a enumerar los títulos de los casos de prueba que serán nuestra base. Debes ser lo más concreto y preciso posible. Para saber como definir esos títulos puedes consular:
No olvides los casos negativos
Recuerda que debes leer entre líneas, ya que en medio de la documentación te puedes encontrar con casuísticas que validen lo que no debe ocurrir. Por tanto, debemos validar el correcto comportamiento del sistema para las excepciones. Se debe verificar la calidad del desarrollo para el control de introducción de valores no válidos o comprobar cómo se comportan el sistema frente a situaciones no habituales. Es frecuente que estos casos queden fuera de la base de prueba, sin embargo tienen una gran importancia.
Revisa el listado de casos con otros equipos
Los distintos perfiles del equipo y los distintos puntos de vista son los que enriquecerán nuestro desarrollo y como no, el plan de pruebas. Por ello, se debe poner en común el esqueleto del plan de pruebas con nuestros compañeros del equipo de desarrollo. Ellos, nos dirán si se nos ha pasado por alto alguna casuística, y nos ayudaran a definir la prioridad de cada uno de los casos.
Pero sobre todo, lo ideal, es tener alguna sesión de trabajo conjunta con el cliente y poder repasar brevemente nuestro planteamiento del plan de pruebas, y confirmarlo o corregirlo según proceda.
Conclusión: Es muy recomendable preparar a conciencia la base de pruebas
Si sigues cada uno de esos puntos repasados anteriormente conseguirás alcanzar una buena cobertura de pruebas. Recuerda que no podremos garantizar que nuestro software está libre de fallas, pero si cuidamos el procedimiento de preparación de los casos «core» de pruebas, estaremos más cerca de lograrlo. Dedica un tiempo amplio a la preparación de una buena base de pruebas, y podrás asegurar que la calidad de ese proyecto sea muy alta.
Quizás te puede interesar
