Liderazgo en Pruebas: Herramientas de Pruebas
Nota del editor: Bienvenido a la serie Liderazgo en Pruebas del gurú y consultor en testing de software, Paul Gerrard. La serie está diseñada para ayudar a testers con algunos años de experiencia—especialmente aquellos en equipos ágiles—a sobresalir en sus roles de liderazgo y gestión de pruebas.
En el artículo anterior, examinamos la infraestructura del sitio y cómo probarla. En este artículo, te guiaré por el conjunto de herramientas del tester, cómo elegir entre opciones propietarias y de código abierto, y un ejercicio rápido de selección de herramientas.
Suscríbete al boletín de The QA Lead para recibir notificaciones cuando nuevas partes de la serie estén disponibles. Estas publicaciones son extractos del curso Liderazgo en Pruebas de Paul, que recomendamos mucho para profundizar más en este y otros temas. Si decides hacerlo, usa nuestro código de cupón exclusivo QALEADOFFER para obtener $60 de descuento en el precio total del curso.
Los equipos de software autogestionados utilizan una variedad más amplia de herramientas que nunca. En un equipo típico de desarrollo de software, puede haber veinte o incluso treinta herramientas en uso. Para ayudarte a orientarte entre todas ellas, en este artículo cubriremos:
- Herramientas para pruebas
- Arquitectura de herramientas
- Gestión de pruebas
- Diseño de pruebas
- ¿Propietarias o de código abierto?
- Un ejercicio de selección de herramientas
Primero, veamos los principales tipos de herramientas que utilizarás para las pruebas.
Herramientas para pruebas
Es conveniente dividir las herramientas relevantes para las pruebas en tres tipos:
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
- Herramientas de colaboración: estas apoyan la captura de ideas y requisitos, la comunicación en el equipo con cierta integración con procesos automatizados, a veces bots.
- Herramientas de testing: un gran espectro de herramientas que facilitan la gestión de datos de prueba, el diseño de pruebas, marcos de pruebas unitarias, ejecución de pruebas funcionales, pruebas de rendimiento y carga, pruebas estáticas, diseño de pruebas, gestión del proceso de testing, casos de prueba, registro y reporte de pruebas.
- Herramientas DevOps o de gestión de infraestructura: estas herramientas ayudan en la gestión de entornos y plataformas, despliegues usando infraestructuras como código y tecnologías de contenedores, así como registros, monitoreo y analítica en producción.
The Tools Knowledge Base es un registro en línea de herramientas que se diferencia de la mayoría de los registros en línea en que abarca colaboración, testing y DevOps. Hay más de 1700 herramientas en estas tres áreas. Las páginas de las herramientas están indexadas y pueden buscarse.
El sitio web también agrega e indexa a más de 300 blogueros y más de 52.000 blogs también están indexados y son buscables. Hemos proporcionado URLs a las principales categorías de herramientas y atajos para búsquedas de estas categorías en los blogs.
Hay más de 1700 herramientas que apoyan la colaboración, pruebas y DevOps.
Más adelante en este artículo veremos las mayores preocupaciones que afectan y apoyan la gestión de pruebas.
Arquitectura de herramientas
En el gráfico a continuación, hemos identificado la gama de tipos de herramientas que usan la mayoría de los equipos modernos de software. Hemos separado herramientas que suelen utilizarse en entornos de desarrollo, testing y producción.
Estas herramientas están respaldadas por herramientas de infraestructura que proporcionan plataformas, máquinas virtuales y contenedores para alojar entornos, y herramientas que realizan despliegues automáticos. Las herramientas utilizadas para gestionar despliegues y liberaciones se llaman herramientas de orquestación de lanzamientos y pipelines. La comunicación dentro del equipo, y también con muchos de los procesos automatizados, es gestionada por herramientas de colaboración o ChatOps.
Aunque la tendencia hacia DevOps está impulsando el desarrollo y la adopción de herramientas que apoyan el desarrollo continuo, casi todas estas herramientas son útiles para cualquier equipo de desarrollo de software u operaciones.
No tienes que tener una cultura DevOps para usar herramientas “DevOps”.
Gestión de pruebas
Las herramientas de gestión de pruebas son indispensables en todos los proyectos de cierta envergadura. Los proyectos ágiles suelen adoptar una herramienta para la gestión de incidentes y, en cuanto a las pruebas, confían en el uso de historias de negocio y escenarios para hacer seguimiento de ejemplos clave de, si no de todas, las pruebas. Las herramientas de gestión de pruebas varían en alcance, desde opciones muy simples como Microsoft Excel hasta productos integrales de Gestión del Ciclo de Vida de Aplicaciones (ALM).
En general, el alcance de las herramientas de gestión de pruebas abarca varias áreas:
Modelo de Cobertura de Pruebas: La mayoría de las herramientas de gestión de pruebas permiten definir un conjunto de requisitos contra los cuales mapear casos de prueba y/o comprobaciones en pruebas. Estos requisitos a veces pueden tener una estructura jerárquica para reflejar el índice de contenidos de un documento. Cada vez más, también pueden capturarse otros modelos como casos de uso o flujos de procesos de negocio. Habitualmente, se dispone de informes de cobertura de planificación y ejecución de pruebas.
Gestión de Casos de Prueba: Los casos de prueba y su contenido pueden gestionarse para proporcionar un registro documentado de las pruebas. El contenido de los casos de prueba puede prepararse antes de la prueba o servir como registro de las pruebas ejecutadas. Los casos de prueba pueden tener un formato de texto libre o estructurarse en pasos con resultados esperados. Es común importar documentos e imágenes para asociar a pruebas o pasos.
Planificación de la Ejecución de Pruebas: Las pruebas pueden estructurarse en una jerarquía o etiquetarse para crear una estructura más dinámica. Se pueden asignar pruebas a los miembros del equipo de prueba. Las duraciones planificadas de las pruebas pueden usarse para publicar un cronograma sincronizado de pruebas a realizar en todo el equipo. Se pueden seleccionar subconjuntos de pruebas para cumplir la cobertura de requisitos, ejercitar funcionalidades seleccionadas y volver a ejecutar conjuntos de pruebas de regresión. Las pruebas registradas como no ejecutadas, bloqueadas, fallidas u otro estado también pueden seleccionarse para ejecución.
Ejecución y Registro de Pruebas: A medida que el equipo ejecuta las pruebas, se registra el estado de las mismas. Todas las pruebas ejecutadas tendrán identificado al probador, así como la fecha, hora y duración. Las pruebas aprobadas pueden asignarse como "aprobadas". Los resultados de pruebas fallidas, bloqueadas o anómalas pueden tener capturas de pantalla, resultados asignados y un reporte de incidente asociado. Muchas herramientas ofrecen integraciones con herramientas de ejecución de pruebas que gestionan y ejecutan pruebas, registran resultados e incluso crean borradores de reportes de incidentes.
Gestión de Incidentes: Las fallas de pruebas se registran en el registro de ejecución. Estas suelen requerir investigación adicional, con depuración y corrección si la falla fue causada por un error. Las fallas que requieren investigación suelen documentarse usando informes de incidentes, observaciones o reportes de errores. Los informes de incidentes pueden contener gran cantidad de información de soporte. Usualmente, se asigna a los incidentes un tipo, un objeto bajo prueba, una prioridad y un nivel de severidad. Algunas empresas registran una gran cantidad de información y la asocian con un proceso sofisticado de gestión de incidentes.
Reportes: Informes y análisis de datos de todas las funciones mencionadas según corresponda. La variedad de informes oscila desde la cobertura de pruebas planificada vs. real, el estado de los informes de incidentes para dar seguimiento a investigaciones pendientes, trabajos de corrección y re-prueba, análisis de tiempo de corrección para varios tipos de fallos, por funcionalidad, severidad, urgencia, etcétera.
La herramienta de gestión de pruebas más popular del mundo sigue siendo Microsoft Excel.
Diseño de Pruebas
El diseño de pruebas se basa en modelos. En el caso de los testers de sistema y de aceptación, los modelos típicos son documentos de requisitos, casos de uso, diagramas de flujo o diagramas swim-lane. También se utilizan modelos más técnicos como modelos de estados, diagramas de colaboración, diagramas de secuencia, etc., que brindan una base sólida para el diseño de pruebas.
En muchos proyectos, los modelos se utilizan para documentar requisitos o diseños de alto nivel. Cuando están disponibles para los testers, pueden usarse para rastrear recorridos y extraer directamente elementos de cobertura del modelo. Si no se dispone de modelos así, suele ser útil que el equipo de pruebas capture, por ejemplo, diagramas de flujo de procesos o swim-lane. Esto ayuda a los testers a entablar discusiones más significativas con los interesados, especialmente en cuanto al enfoque de cobertura.
En el ámbito propietario, están surgiendo herramientas que permiten capturar modelos como diagramas de flujo y usarlos para generar casos de prueba rastreando recorridos según algún objetivo de cobertura, por ejemplo, todos los enlaces, todos los procesos, todos los resultados de decisión, todos los pares y todos los caminos. Estas herramientas pueden vincularse con herramientas de gestión y generación de datos de prueba para producir combinaciones de datos de prueba que se utilizarán en pruebas manuales o automatizadas.
También existen herramientas que permiten modelar dentro de herramientas de ejecución de pruebas. Por ejemplo, estas herramientas permitirían al desarrollador de pruebas capturar todos los campos de una página web, crear enlaces que "unan" los campos y crear un modelo de navegación para la página, todo en formato gráfico.
Luego, el modelo se usa para crear rutas de navegación que permitan crear una batería de pruebas que cumpla algún criterio de cobertura, igual que las herramientas de modelado mencionadas antes. Estas herramientas de ejecución pueden crear caminos automatizados de prueba usando criterios seleccionados, o generarlos aleatoriamente, y también reportar la cobertura respecto a estos modelos.
Este es un ámbito muy dinámico en el momento actual: mantente atento a las herramientas de modelado que soportan el diseño y la generación de pruebas, y a las herramientas de ejecución que soportan el modelado del sistema bajo prueba y la selección automatizada de recorridos y generación de informes.
¿Propietario o Código Abierto?
Durante los últimos veinte años, el uso de productos de software libre y de código abierto (FOSS), especialmente para gestionar infraestructuras, se ha generalizado. El coste de las licencias de sistemas operativos y del software de servidor web asociado de Microsoft, junto con la visión general de que Linux/Unix es más fiable y seguro que Windows, hacen que para muchos entornos, Linux/Unix sea el sistema operativo preferido para servidores.
Si bien el artículo expone los pros y contras de las herramientas de código abierto y las propietarias, si buscas específicamente soluciones que se integren bien con Jira, nuestra guía completa sobre herramientas de gestión de pruebas específicas para Jira puede ayudarte a tomar una decisión informada.
Las dos tablas a continuación (actualizadas diariamente en w3techs.com) muestran la popularidad relativa de sistemas operativos y productos de servidores web. Alrededor del 85% de los sitios utilizan los servidores web de código abierto más conocidos, Apache y Nginx.
La popularidad de estos productos de infraestructura FOSS demuestra que el código abierto puede ser tan fiable, o incluso más, que los productos propietarios.
Para un equipo de software que necesita veinte o treinta herramientas para apoyar sus actividades, existen herramientas FOSS y propietarias confiables y funcionales para cada tarea. ¿Cómo elegir entre un producto propietario y uno FOSS?
La siguiente tabla resume algunas de las consideraciones que puedes tener al seleccionar el tipo de herramienta.
| Propietario | FOSS | |
| Disponibilidad | Herramientas disponibles para todas las áreas. | Algunas áreas, especialmente las de desarrollo y herramientas de infraestructura, cuentan con mejor soporte que otras. |
| Coste de adquisición | A menudo costosas, en especial los productos ‘enterprise’. | Gratuitas, o con licencias de uso comunitario a cero costo. Pueden existir licencias comerciales para versiones empresariales o alojadas. |
| Documentación | Normalmente muy buena. | Variable. A veces excelente, a veces inexistente y todo lo intermedio. Suele estar escrita por programadores para programadores, por lo que suele ser menos útil que la documentación comercial. |
| Soporte técnico | Muy bueno, aunque con coste. | Variable. Algunos autores de herramientas ofrecen un soporte excelente e incluso añaden funcionalidades bajo pedido. Muchas herramientas tienen foros en línea – pero pueden ser muy técnicos. Otras herramientas cuentan con un soporte deficiente. |
| Fiabilidad/calidad | Normalmente muy buena. | Variable. Los productos con muchos usuarios, en varios países, y grandes equipos de soporte suelen ser excelentes. Algunas herramientas, desarrolladas por individuos con pocos colaboradores y pocos usuarios, pueden ser inestables. |
| Riqueza de funcionalidades | El conjunto de funcionalidades suele seguir hojas de ruta publicadas y normalmente son completas. | Los productos suelen evolucionar en función de la demanda de los usuarios y del tamaño del equipo de colaboradores. Los colaboradores suelen añadir funciones que ellos mismos necesitan en vez de basarse, por ejemplo, en encuestas a los clientes. |
| Frecuencia de lanzamientos/actualizaciones | Los grandes lanzamientos suelen estar separados por meses o incluso años. Actualizaciones regulares. Los avisos y notas de lanzamiento suelen ser muy completos. | Variable. Los grandes productos de infraestructura FOSS lanzan versiones principales similar a los propietarios. Los productos más pequeños y menos populares suelen lanzar versiones más frecuentemente. Pocos o nulos avisos previos, notas de versión pobres y, en ocasiones, se pierde la compatibilidad hacia atrás. |
Los productos FOSS pueden ser más baratos de obtener, pero otros costes y responsabilidades pueden ser significativos. El factor decisivo entre ambos suele ser una combinación de tu cultura, tolerancia al riesgo y capacidad técnica.
Cuando compras productos propietarios y contratos de soporte, los riesgos asociados con la incompatibilidad (con otros productos), la fiabilidad, la facilidad de uso y el soporte técnico atento suelen ser bajos, aunque a veces costosos.
Con los productos FOSS normalmente tienes que investigar mucho más a fondo antes de comprometerte a utilizar uno. Al fin y al cabo, no hay un comercial con quien hablar y la documentación puede ser funcional pero no tan informativa. Por supuesto, es fácil realizar pruebas piloto y puedes probar tantas herramientas como desees, pero tendrás que investigar más a fondo la capacidad de la herramienta.
Una menor usabilidad y la incompatibilidad con herramientas existentes pueden ser problemáticas, por lo que quizá tengas que desarrollar software de integración o plug-ins, y utilidades de informes o importación/exportación de datos.
Además, tendrás que formarte y formar a tu equipo para ponerse al día y, normalmente, ofrecer tu propio soporte de software. Sin embargo, tu equipo tendrá un conocimiento más íntimo del funcionamiento de la herramienta y será en gran parte autosuficiente.
Una herramienta FOSS puede ayudarte a ganar experiencia con un nuevo tipo de herramienta a bajo coste. Con esa experiencia, estarás mejor preparado para elegir una herramienta propietaria a largo plazo.
Un ejercicio de selección de herramientas
Si buscas una herramienta de gestión de pruebas para apoyar tu proyecto y aplicación actual o uno reciente y conocido. Basándote en las áreas funcionales mencionadas en la discusión de herramientas de gestión de pruebas arriba, haz una lista de 15-20 características que sean:
- Obligatorias
- Deseables
Esto puede incluir capacidades funcionales, integraciones, un enfoque en la facilidad de uso, soporte o una gran base de usuarios o foros en línea/preguntas frecuentes. Si ya tienes una herramienta implementada, no elijas esa.
Usando el texto de tus requisitos, busca en la Base de Conocimiento de Herramientas para encontrar tres herramientas (incluyendo un producto propietario y uno FOSS) que parezcan cumplir tus requisitos. Utilizando la descripción de características de las herramientas, crea una tabla comparativa de las características de los tres productos. Añade una cuarta columna para la herramienta que realmente estás utilizando, para comparar.
- ¿Cómo se comparan las herramientas en cuanto a características?
- ¿Qué características le faltan a la(s) herramienta(s) FOSS en comparación con las propietarias?
- ¿Cuántas herramientas existen que, en líneas generales, cumplen tus requisitos?
- ¿Cuánto tiempo crees que necesitarías investigar herramientas para elaborar una lista corta de, por ejemplo, tres?
Suscríbete al boletín de The QA Lead para recibir notificaciones cuando se publiquen nuevas partes de la serie. Estas publicaciones son extractos del curso Liderazgo en Pruebas de Paul—altamente recomendado para quienes desean profundizar en este y otros temas. Si te interesa, ¡utiliza nuestro código exclusivo QALEADOFFER para obtener $60 de descuento en el precio total del curso!
Aprende de otros testers escuchando nuestros pódcasts o leyendo nuestros blogs. Aquí tienes uno del que creemos que aprenderás muchísimo: CÓMO LAS HABILIDADES EN PRUEBAS ME HICIERON UN MEJOR DESARROLLADOR DE AUTOMATIZACIÓN