Liderazgo en Pruebas: Herramientas de Pruebas
Nota del editor: Bienvenido a la serie Liderazgo en Pruebas del gurú y consultor de pruebas 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, revisamos la infraestructura del sitio y cómo probarla. En este artículo, te guiaré a través de la caja de herramientas del tester, cómo elegir entre herramientas propietarias y de código abierto, y un breve ejercicio 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 en este y otros temas. Si lo haces, usa nuestro código de cupón exclusivo QALEADOFFER para obtener $60 de descuento en el precio completo del curso.
Los equipos de software que se autogestionan utilizan una gama más amplia de herramientas que nunca. En un equipo típico de software, podría haber veinte o incluso treinta herramientas en uso. Para ayudarte a navegar por todo esto, en este artículo cubriremos:
- Herramientas para pruebas
- Arquitectura de herramientas
- Gestión de pruebas
- Diseño de pruebas
- ¿Propietario o código abierto?
- Un ejercicio de selección de herramientas
Primero, veamos los principales tipos de herramientas que utilizarás para pruebas.
Herramientas para pruebas
Es útil dividir las herramientas relevantes para las pruebas en tres tipos:
¿Quieres más de The CTO Club?
Crea una cuenta gratuita para terminar de leer este contenido y unirte a una comunidad de CTOs y líderes de ingeniería que comparten marcos, herramientas y conocimientos reales para diseñar, desplegar y escalar tecnología impulsada por IA.
Have an account? Log In
- Herramientas de colaboración: apoyan la captura de ideas y requisitos, la comunicación en todo el equipo con cierta integración con procesos automatizados, a veces bots.
- Herramientas de prueba: un amplio espectro de herramientas que apoyan 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 pruebas, casos de prueba, registro de pruebas e informes.
- Herramientas de DevOps o de gestión de infraestructuras: estas herramientas apoyan la gestión de entornos y plataformas, el despliegue utilizando infraestructura como código y tecnologías de contenedores, así como el registro, la monitorización y la 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 el alcance del registro cubre colaboración, pruebas y DevOps. Hay más de 1700 herramientas en estas tres áreas. Las páginas web de herramientas están indexadas y se pueden buscar.
El sitio web también agrega e indexa 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 accesos directos para buscar estas categorías en los blogs.
Hay más de 1700 herramientas que apoyan la colaboración, las 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 siguiente gráfico, hemos identificado la variedad de tipos de herramientas que la mayoría de los equipos modernos de software utilizan. Hemos separado las herramientas que suelen utilizarse en entornos de desarrollo, prueba y producción.
Estas herramientas están respaldadas por herramientas de infraestructura que proveen plataformas, máquinas virtuales y contenedores para hospedar entornos, y herramientas que realizan despliegues automatizados. Las herramientas utilizadas para gestionar despliegues y liberaciones se llaman herramientas de orquestación de liberaciones y pipelines. La comunicación dentro del equipo, y también con muchos de los procesos automatizados, se gestiona mediante herramientas de colaboración o ChatOps.
Aunque el movimiento hacia DevOps impulsa el desarrollo y la adopción de herramientas para dar soporte al desarrollo continuo, casi todas estas herramientas son útiles para cualquier equipo de desarrollo u operaciones de software.
No tienes que tener una cultura DevOps para usar herramientas “DevOps”.
Gestión de pruebas
Las herramientas de gestión de pruebas son imprescindibles en todos los proyectos a gran escala. Los proyectos ágiles suelen adoptar una herramienta para la gestión de incidentes y, en cuanto a las pruebas, dependen en parte del uso de historias de negocio y escenarios para hacer seguimiento de ejemplos clave o de, si no todos, la mayoría de las pruebas. Las herramientas de gestión de pruebas varían en su alcance, desde las muy simples como Microsoft Excel hasta productos completos 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 asociar casos de prueba y/o comprobaciones en las pruebas. Estos requisitos a veces pueden ser jerárquicos para reflejar una tabla 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. Suele haber disponibles informes de cobertura de plan de pruebas y de ejecución.
Gestión de casos de prueba: Los casos de prueba y su contenido pueden ser gestionados para ofrecer un registro documentado de las pruebas. El contenido de los casos de prueba puede prepararse antes de probar o como registro de las pruebas ejecutadas. Los casos de prueba pueden estar en formato de texto libre o estructurarse en pasos con resultados esperados. Es común importar documentos e imágenes para almacenarlos con pruebas o pasos.
Planificación de la ejecución de pruebas: Las pruebas pueden estructurarse en una jerarquía o etiquetarse para proporcionar una estructura más dinámica. Los miembros del equipo de pruebas pueden tener pruebas asignadas. Las duraciones planificadas de las pruebas pueden usarse para publicar un calendario sincronizado de pruebas a ejecutar en todo el equipo. Se pueden seleccionar subconjuntos de pruebas para lograr la cobertura de requisitos, ejercitar determinadas funcionalidades 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 su ejecución.
Ejecución y registro de pruebas: A medida que las pruebas son ejecutadas por el equipo, se registra el estado de las mismas. Todas las pruebas ejecutadas tendrán identificado el responsable y la fecha/hora y duración anotadas. Las pruebas pasadas pueden asignárseles un estado simple de aprobado. 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: Los fallos en pruebas se registrarán en el log de ejecución. Normalmente requieren una investigación adicional, depuración y corrección si la falla es causada por un error. Las fallas que precisan investigación suelen registrarse mediante incidentes, observaciones o reportes de errores. Los reportes de incidentes pueden contener gran cantidad de información de soporte. Por lo general, a los incidentes se les asigna un tipo, un objeto bajo prueba, una prioridad y una severidad. Algunas empresas registran una enorme cantidad de información y la integran en un proceso sofisticado de gestión de incidentes.
Informes: Informes y análisis de datos de todas las funciones anteriores según corresponda. El rango de informes varía desde la cobertura de pruebas planificada vs real, el estado de los reportes de incidentes para hacer seguimiento de investigaciones pendientes, correcciones y re-pruebas, análisis del tiempo de corrección para distintos tipos de fallos, por funcionalidad, severidad, urgencia, etcétera.
La herramienta de gestión de pruebas más popular del planeta sigue siendo Microsoft Excel.
Diseño de pruebas
El diseño de pruebas se basa en modelos. En el caso de los testers de sistemas y de aceptación, los modelos más frecuentes son documentos de requisitos, casos de uso, diagramas de flujo o diagramas de carriles (swim-lane). También modelos más técnicos como los de estado, diagramas de colaboración, diagramas de secuencia, etc., aportan una base sólida para el diseño de pruebas.
En muchos proyectos, los modelos se emplean para capturar requisitos o diseños de alto nivel. Cuando están disponibles para los testers, pueden utilizarse para trazar rutas y cubrir elementos directamente del modelo. Si no se dispone de este tipo de modelos, a menudo resulta útil que el equipo de pruebas capture, por ejemplo, diagramas de flujo de proceso o diagramas de carriles. Esto ayuda a los testers a mantener discusiones más significativas con interesados, especialmente en lo relativo al enfoque de cobertura.
En el entorno propietario, están apareciendo herramientas que permiten capturar modelos como diagramas de flujo y usarlos para generar casos de prueba siguiendo rutas de acuerdo a algún objetivo de cobertura, por ejemplo, todos los enlaces, todos los procesos, todos los desenlaces de decisión, todos los pares y todos los caminos. Estas herramientas pueden conectarse con herramientas de gestión y generación de datos de prueba para obtener combinaciones de datos a usar en pruebas manuales o automatizadas.
También existen herramientas que permiten modelar directamente en las herramientas de ejecución de pruebas. Por ejemplo, permiten al desarrollador de pruebas capturar todos los campos de una página web, crear enlaces para relacionar los campos, y modelar la navegación de la página, todo en formato gráfico.
Luego, el modelo se utiliza para crear rutas de navegación que generen una batería de pruebas que cumpla con ciertos criterios de cobertura, similar a los modelos mencionados antes. Estas herramientas de ejecución pueden crear rutas de pruebas automatizadas usando criterios seleccionados, o generarlas aleatoriamente, además de informar la cobertura respecto a estos modelos.
Actualmente este es un ámbito muy dinámico: mantente atento a las herramientas de modelado que ayuden en el diseño y la generación de pruebas, y a herramientas de ejecución que soporten el modelado del sistema bajo prueba y la selección y reporte de caminos de prueba automatizados.
¿Propietario o de código abierto?
En los últimos veinte años, el uso de productos de software libre y de código abierto (FOSS), especialmente para operar infraestructura, se ha extendido ampliamente. El costo de las licencias de sistemas operativos y del software de servidor web asociado de Microsoft, así como la visión generalizada de que Linux/Unix es más confiable y seguro que Windows, han hecho que para muchos entornos, Linux/Unix sea el sistema operativo preferido para los servidores.
Si bien el artículo analiza los pros y los contras de las herramientas de código abierto y propietarias, si busca 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 ayudarle a tomar una decisión informada.
Las dos tablas siguientes (actualizadas diariamente en w3techs.com) muestran la popularidad relativa de los sistemas operativos y los productos de servidores web. Alrededor del 85% de los sitios utilizan los productos de servidores web de código abierto más conocidos, Apache y Nginx.
La popularidad de estos productos de infraestructura FOSS demuestra que el software libre puede ser tan confiable, o más, que los productos propietarios.
Para un equipo de desarrollo que necesita las veinte o treinta herramientas de software necesarias para respaldar 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 podría tener al seleccionar un tipo de herramienta.
| Propietario | FOSS | |
| Disponibilidad | Herramientas disponibles para cada área. | Algunas áreas, particularmente las herramientas de desarrollo e infraestructura, están mejor soportadas que otras. |
| Costo de adquisición | A menudo costosas, especialmente los productos ‘enterprise’. | Gratis, o licencia de uso comunitario sin costo. Puede haber licencias comerciales para versiones empresariales u hospedadas. |
| Documentación | Usualmente muy buena. | Variable. A veces excelente, a veces inexistente y todo lo intermedio. Con frecuencia escrita por programadores para programadores, por lo que es menos utilizable que la documentación comercial. |
| Soporte técnico | Muy bueno, pero tiene un costo. | Variable. Algunos autores de herramientas ofrecen soporte excelente e incluso añaden funciones a pedido. Muchas herramientas tienen foros online, pero pueden ser muy técnicos. Otras herramientas tienen poco soporte. |
| Confiabilidad/calidad | Usualmente muy buena. | Variable. Los productos con muchos usuarios, en diversos países, y equipos de soporte grandes tienden a ser excelentes. Algunas herramientas hechas por individuos, con pocos colaboradores y pocos usuarios, pueden ser poco confiables. |
| Riqueza de funciones | Los conjuntos de funciones suelen seguir hojas de ruta publicadas y suelen ser completos. | Los productos tienden a evolucionar según la demanda de los usuarios y el tamaño del equipo de colaboradores. Los contribuyentes tienden a agregar funciones que ellos mismos necesitan en lugar de basarse, por ejemplo, en encuestas de clientes. |
| Frecuencia de lanzamientos/actualizaciones | Los lanzamientos principales suelen demorar meses, a veces años. Actualizaciones regulares. Las advertencias y notas de lanzamiento suelen ser muy buenas. | Variable. Grandes productos de infraestructura tienen lanzamientos principales similares a los propietarios. Los productos más pequeños y menos populares suelen hacer lanzamientos con mayor frecuencia. Poca o ninguna advertencia, notas de lanzamiento deficientes y en ocasiones pérdida de compatibilidad hacia atrás. |
Los productos FOSS pueden ser más baratos de adquirir, pero otros costos y responsabilidades pueden ser significativos. El factor decisivo entre ambos suele ser una mezcla de la cultura de su organización, su apetito por el riesgo y su capacidad técnica.
Cuando compra productos propietarios y contratos de soporte, los riesgos asociados con la incompatibilidad (con otros productos), confiabilidad, facilidad de uso y soporte técnico atento suelen ser bajos, aunque a veces costosos.
Con productos FOSS, normalmente debe realizar una investigación mucho más exhaustiva antes de comprometerse a utilizar alguno. Después de todo, no hay un vendedor con quien hablar y la documentación puede ser funcional en vez de informativa. Por supuesto, es fácil configurar un periodo de prueba y puede probar tantas herramientas como quiera, pero tendrá que hacer una investigación más completa sobre la capacidad de la herramienta.
Una menor usabilidad y la incompatibilidad con sus herramientas existentes pueden presentar problemas, por lo que puede que deba escribir software de integración o plug-ins y utilidades de reporte o de importación/exportación de datos.
Además, tendrá que capacitarse usted mismo y a su equipo para ponerse al día y normalmente brindar su propio soporte de software. Sin embargo, su equipo tendrá un conocimiento más profundo del funcionamiento de la herramienta y será en gran medida autosuficiente.
Una herramienta FOSS podría ayudarte a adquirir experiencia con un nuevo tipo de herramienta a bajo costo. 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 actual o uno reciente y familiar, o una aplicación. Basándote en las áreas funcionales mencionadas anteriormente sobre herramientas de gestión de pruebas, haz una lista de 15-20 características que sean:
- Obligatorias
- Deseables
Esto puede incluir capacidades funcionales, integraciones, enfoque en facilidad de uso, soporte o una gran base de usuarios o foros/preguntas frecuentes en línea. Si ya tienes una herramienta en uso, 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. Usando las descripciones de características de las herramientas, crea una tabla de comparación de 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 términos de características?
- ¿Qué características faltan en la(s) herramienta(s) FOSS en comparación con las propietarias?
- ¿Cuántas herramientas existen que, en líneas generales, cumplen con tus requisitos?
- ¿Cuánto tiempo crees que necesitarías dedicar a investigar herramientas para elaborar una lista corta de, por ejemplo, tres?
Suscríbete al boletín de The QA Lead para recibir avisos cuando nuevas partes de la serie estén disponibles. Estas publicaciones son extractos del curso Liderazgo en Pruebas de Paul—muy recomendado para quienes desean profundizar en este y otros temas. ¡Si te interesa, utiliza nuestro código de cupón exclusivo QALEADOFFER para conseguir $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 DE PRUEBAS ME CONVIRTIERON EN MEJOR DESARROLLADOR DE AUTOMATIZACIÓN
