Reyes Sánchez García/ noviembre 25, 2021/ Gestión de la calidad/ 0 comentarios
Tiempo de lectura: 4 minutosUno de los puntos claves para realizar un correcto diseño de pruebas es estructurar un plan de pruebas de forma adecuada. No existe una técnica mágica que permita hacer la estructura más óptima de manera estándar. En otras palabras, en función de las características del proyecto se debe efectuar un enfoque u otro distinto.
¿Quieres saber cómo? Sigue leyendo.
Índice de contenidos
Estructurar un plan de pruebas por bloques funcionalidad
En primer lugar, tomaremos un enfoque por bloques funcionales. Se debe realizar un análisis de la documentación y dividir e identificar cuáles son los bloques que se deben probar. De esta forma tenemos listados todos los puntos a tener en cuenta y los «atacamos» en conjunto. Por ejemplo, vamos a imaginar que necesitamos probar una mejora en una tienda online. El desarrollo consiste en incorporar una nueva funcionalidad: la lista de deseos. ¿Dónde tiene impacto esta funcionalidad? Pues, se me ocurre que en los siguientes puntos:
- Un nuevo apartado dentro de mi área privada: el Listado de deseos.
- Opciones para gestionar las listas de deseos: cambiar nombre, compartir, editar las opciones de visualización.
- Crear, editar, y eliminar una lista de deseos.
- En la ficha de producto, se debe añadir el botón «Añadir a lista de deseos».
- Notificaciones cuando los productos de mi lista de deseo tienen bajadas de precio.
A partir de ahí, podríamos identificar los siguientes bloques de pruebas:
- Visualización Mi lista de deseos.
- Crear lista.
- Editar lista.
- Eliminar lista.
- Compartir lista.
- Editar opciones de visualización.
- Botón ficha de producto.
- Notificaciones de bajada precio.
Dentro de cada bloque funcional se realizarán las pruebas necesarias con distintos navegadores, dispositivos e idiomas
Enfoque por idiomas para estructurar un plan de pruebas
Otras veces, el proyecto o evolutivo en cuestión va más enfocado a las modificaciones a nivel visual o de literales. Imaginemos, partiendo del ejemplo anterior que trabajamos con desarrollos iterativos. En otras palabras, una vez implantada la nueva funcionalidad de la lista de deseos en español, se incorpora esta misma funcionalidad a los distintos idiomas. De esta forma, al enfocar la estructura del nuevo plan de pruebas nos centramos en probar las traducciones y visualizaciones en esos lenguajes.
En conclusión, damos un enfoque por idiomas y revisamos las distintas pantallas de todas las funcionalidades validadas en su momento. Aunque, ahora, nos centraremos en validar los literales y su correcta maquetación para los nuevos idiomas que vamos a incorporar. A veces, es interesante añadir una distinción en cuanto a bloques funcionales, para una división mayor. Siguiendo el ejemplo anterior, tendríamos:
- Inglés de Área usuario.
- Inglés de Gestión de listas.
- Inglés de Ficha producto.
- Inglés de notificaciones.
- Portugués de Área usuario.
- Portugués de Gestión de listas.
- Portugués de Ficha producto.
- Portugués de notificaciones.
- Francés de Área usuario.
- Francés de Gestión de listas.
- Francés de Ficha producto.
- Francés de notificaciones.
Dentro de cada uno de estos bloques, tendríamos los casos de pruebas que afectas a los distintos navegadores y funcionalidades contenidas en ese segmento.
Estructurar un plan de pruebas por navegador y/o dispositivo
En tercer lugar, se puede dar la circunstancia de que nos interese enfocar los bloques de pruebas por distinto navegador y dispositivo. Quizás a la hora de ejecutar nos encontramos que se van a repartir los bloques de pruebas entres distintos miembros del equipo. Cada cual es especialista en validar los casos de pruebas para un dispositivo y/o navegador distinto.
Del mismo modo, en este caso, volviendo al ejemplo de la tienda online, supongamos la situación de que se va a cambiar el estilo de la página web. Se ha trabajado en una nueva plantilla de diseño y debemos estructurar un plan de pruebas enfocado por dispositivos y navegador. De esta forma, tendríamos, los siguientes bloques a probar:
- Google Chrome (PC)
- Google Chrome (Móvil)
- Google Chrome (Tablet Vertical)
- Google Chrome (Tablet Horizontal)
- Mozilla Firefox (PC)
- Mozilla Firefox (Móvil)
- Mozilla Firefox (Tablet Vertical)
- Mozilla Firefox (Tablet Horizontal)
- EDGE (PC)
- EDGE (Móvil)
- EDGE (Tablet Vertical)
- EDGE (Tablet Horizontal)
- Safari (MAC)
- Safari (IOs)
- Samsung (Android)
- Samsung (Tablet Vertical)
- Samsung (Tablet Horizontal)
- Opera (PC)
- Opera (Android)
- Opera (Tablet Vertical)
- Opera (Tablet Horizontal)
- IE (PC)
- UC Browser (Android)
- UC Browser (Tablet Vertical)
- UC Browser (Tablet Horizontal)
Aunque, también podremos, probar los distintos tamaños de tablets o de móviles, o con distintos tipos de pantallas con una u otra resolución. Podemos entrar al detalle tanto como deseemos, y según los recursos que tengamos para realizar el diseño y la ejecución de pruebas. En este sentido, es importante consultar las visitas de la web en google analitycs, para saber que navegadores o dispositivos son los más utilizados por nuestros usuarios. O también, puedes consultar las estadísticas de visitas actuales en internet, por ejemplo en el enlace.
Conclusión: Estructurar un plan de pruebas en función de tus necesidades
Como adelanté al principio, no hay una fórmula mágica que nos permita estructurar un plan de pruebas. Pero debemos dedicar unos minutos a analizar y definir los ciclos de pruebas de la forma más óptima para su ejecución. Seguro que no acertarás a la primera. No obstante, si practicas y vas cogiendo experiencia, cada vez tendrás diseños más enfocados a asegurar la calidad del proyecto con el menor esfuerzo.
¿Conoces alguna técnica para que tu estructura del plan de pruebas sea la mejor? Déjame un comentario y hablamos de ello. O si lo prefieres suscríbete al blog y esta´ras al tanto de todas las novedades.