Liderazgo en las pruebas: herramientas de prueba

• Herramientas de colaboración: permiten recopilar ideas y requisitos, así como comunicarse dentro del equipo, con cierta integración con procesos automatizados y, en ocasiones, bots.
• Herramientas de pruebas: un amplio espectro de herramientas que respaldan la gestión de datos de prueba, el diseño de pruebas, los marcos de pruebas unitarias, la ejecución de pruebas funcionales, las pruebas de rendimiento y carga, las pruebas estáticas, el diseño de pruebas, la gestión del proceso de pruebas, los casos de prueba, el registro de pruebas y la generación de informes.
• Herramientas de DevOps o de gestión de infraestructura: respaldan la gestión de entornos y plataformas, el despliegue mediante infraestructura como código y tecnologías de contenedores, así como el registro, la monitorización y el análisis 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 porque su alcance abarca la colaboración, las pruebas y DevOps. Hay más de 1700 herramientas en estas tres áreas. Las páginas web de las herramientas están indexadas y se pueden buscar.

El sitio web también recopila e indexa a más de 300 blogueros, y también hay más de 52.000 blogs indexados y disponibles para búsqueda. Hemos proporcionado URL 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 respaldan la colaboración, las pruebas y DevOps.

Más adelante en este artículo analizaremos las principales preocupaciones que afectan y respaldan la gestión de pruebas.

ÚNETE A LA COMUNIDAD

Mejora tu bandeja de entrada con más sabiduría sobre liderazgo tecnológico para ofrecer mejores programas y sistemas.

Create Free Account

Have an account? Log In

Arquitectura de herramientas

En el gráfico siguiente, hemos identificado la variedad de tipos de herramientas que utilizan la mayoría de los equipos de software modernos. Hemos separado las herramientas que suelen utilizarse en entornos de desarrollo, pruebas y producción. 

Estas herramientas se sustentan en herramientas de infraestructura que proporcionan plataformas, máquinas virtuales y contenedores para alojar entornos, además de herramientas que realizan despliegues automatizados. Las herramientas utilizadas para gestionar los despliegues y las versiones se denominan herramientas de orquestación de versiones y canalizaciones. Las comunicaciones dentro del equipo, así como con muchos de los procesos automatizados, se gestionan mediante herramientas de colaboración o ChatOps.

Aunque el avance hacia DevOps está impulsando el desarrollo y la adopción de herramientas que respaldan el desarrollo continuo, casi todas estas herramientas son útiles para cualquier equipo de desarrollo de software u operaciones.

No es necesario tener una cultura DevOps para utilizar herramientas de «DevOps».

Gestión de pruebas

Las herramientas de gestión de pruebas son imprescindibles en todos los proyectos de cierta envergadura. Los proyectos ágiles suelen adoptar una herramienta para la gestión de incidentes y, en lo que respecta a las pruebas, confiar en cierta medida en el uso de historias y escenarios empresariales para realizar un seguimiento de ejemplos clave de todas las pruebas o, al menos, de algunas de ellas. Las herramientas de gestión de pruebas varían en alcance desde opciones muy sencillas, como Microsoft Excel, hasta productos integrales de Gestión del Ciclo de Vida de las 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 con los que se pueden vincular casos de prueba o comprobaciones en las pruebas. En ocasiones, estos requisitos pueden ser jerárquicos para reflejar el índice de un documento. Cada vez más, también pueden capturarse otros modelos, como casos de uso o flujos de procesos empresariales. Normalmente, están disponibles informes de cobertura de la planificación y la ejecución de pruebas.

Gestión de casos de prueba: Los casos de prueba y su contenido se pueden gestionar para proporcionar un registro documentado de las pruebas. El contenido de los casos de prueba puede prepararse antes de las pruebas o como registro de las pruebas ejecutadas. Los casos de prueba pueden estar en formato de texto libre o estructurados en pasos con resultados esperados. Es habitual importar documentos e imágenes para almacenarlos junto con las pruebas o los 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. Es posible asignar pruebas a los miembros del equipo de pruebas. Las duraciones planificadas de las pruebas pueden utilizarse para publicar un calendario sincronizado de las pruebas que se ejecutarán en todo el equipo. Se pueden seleccionar subconjuntos de pruebas para lograr la cobertura de requisitos, probar funciones seleccionadas y volver a ejecutar conjuntos de pruebas de regresión. También se pueden seleccionar para su ejecución las pruebas registradas como aún no ejecutadas, bloqueadas, fallidas o con otro estado.

Ejecución y registro de pruebas: A medida que el equipo ejecuta las pruebas, se registra su estado. En todas las pruebas ejecutadas se identifica al probador y se anotan la fecha, la hora y la duración. A las pruebas superadas se les puede asignar un simple estado de aprobadas. Los resultados de pruebas fallidas, bloqueadas o anómalas pueden incluir capturas de pantalla, resultados de pruebas y un informe de incidentes. Muchas herramientas ofrecen conexiones con herramientas de ejecución de pruebas que gestionan y ejecutan pruebas, registran resultados e incluso crean borradores de informes de incidentes.

Gestión de incidentes: Los fallos de las pruebas se registrarían en el registro de ejecución. Normalmente, requieren una investigación adicional, con depuración y corrección cuando el fallo se debe a un error. Los fallos que requieren investigación suelen registrarse mediante informes de incidentes, observaciones o errores. Los informes de incidentes pueden contener una gran cantidad de información complementaria. Por lo general, a los incidentes se les asigna un tipo, un objeto sometido a prueba, una prioridad y una gravedad. Algunas empresas registran una enorme cantidad de información y la relacionan con un proceso sofisticado de gestión de incidentes.

Informes: Informes y análisis de los datos de todas las funciones anteriores, según corresponda. La variedad de informes abarca desde la cobertura de pruebas planificada frente a la real y el estado de los informes de incidentes para realizar un seguimiento de las investigaciones, correcciones y nuevas pruebas pendientes, hasta análisis del tiempo necesario para corregir distintos tipos de fallos, por función, gravedad, urgencia, etc.

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 probadores de sistemas y de aceptación, los modelos habituales son documentos de requisitos, casos de uso, diagramas de flujo o diagramas de carriles. Los modelos más técnicos, como los modelos de estados, los diagramas de colaboración, los diagramas de secuencia, etc., también proporcionan una base sólida para el diseño de pruebas.

En muchos proyectos, los modelos se utilizan para capturar requisitos o diseños de alto nivel. Cuando están disponibles para los probadores, pueden utilizarse para rastrear rutas y seleccionar directamente elementos de cobertura del modelo. Si no se dispone de modelos de este tipo, suele ser útil que el equipo de pruebas capture, por ejemplo, diagramas de flujo de procesos o diagramas de carriles. Estos ayudan a los probadores a mantener conversaciones más significativas con las partes interesadas, especialmente en lo relativo al enfoque de cobertura.

En el ámbito de las herramientas propietarias, están surgiendo herramientas que permiten capturar modelos como diagramas de flujo y utilizarlos para generar casos de prueba mediante el rastreo de rutas según un objetivo de cobertura determinado, por ejemplo, todos los enlaces, todos los procesos, todos los resultados de decisiones, todos los pares o todas las rutas. Estas herramientas pueden vincularse con herramientas de gestión y generación de datos de prueba para generar combinaciones de datos de prueba que se utilicen con pruebas manuales o automatizadas.

También existen herramientas que permiten realizar el modelado en 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 para «conectar» los campos y crear un modelo de navegación para la página, todo ello en formato gráfico.

A continuación, el modelo se utiliza para crear rutas de navegación y crear un conjunto de pruebas que cumplan determinados criterios de cobertura, al igual que las herramientas de modelado anteriores. Estas herramientas de ejecución pueden crear rutas de pruebas automatizadas utilizando criterios seleccionados o generarlas aleatoriamente, y también informar sobre la cobertura de estos modelos.

Actualmente, este es un ámbito dinámico: mantente atento a las herramientas de modelado compatibles con el diseño y la generación de pruebas, y a las herramientas de ejecución compatibles con el modelado del sistema sometido a pruebas y la selección y generación de informes automatizadas de rutas de pruebas.

More Articles

• Ciclo de vida de las pruebas de software: fases, herramientas y mejores prácticas
• Diseño de Pruebas: Una Habilidad Esencial en Control de Calidad
• 5 beneficios de las pruebas Shift-Left para reducir costos hoy

¿Propietarias o de código abierto?

Durante los últimos veinte años, el uso de productos de software libre y de código abierto (FOSS), especialmente para ejecutar infraestructuras, se ha extendido ampliamente. El coste de las licencias de sistemas operativos y del software de servidor web asociado de Microsoft, junto con la opinión general de que Linux/Unix es más fiable y seguro que Windows, hace que, para muchos entornos, Linux/Unix sea el sistema operativo preferido para los servidores. 

Aunque el artículo analiza las ventajas y desventajas de las herramientas de código abierto y 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 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 servidor 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 como los productos propietarios, o incluso más.

Para un equipo de software que necesita entre veinte y treinta herramientas de software para respaldar sus actividades, existen herramientas FOSS y propietarias fiables y funcionales para realizar cualquier tarea. ¿Cómo se elige entre un producto propietario y uno FOSS?

La tabla siguiente resume algunas de las consideraciones que podrías tener en cuenta al seleccionar un tipo de herramienta.

	Propietario	FOSS
Disponibilidad	Hay herramientas disponibles para todas las áreas.	Algunas áreas, especialmente las herramientas de desarrollo e infraestructura, cuentan con mejor soporte que otras.
Coste de adquisición	A menudo es elevado, especialmente en el caso de los productos «empresariales».	Gratuito, o con una licencia de uso comunitario sin coste. Pueden existir licencias comerciales para versiones empresariales o alojadas.
Documentación	Por lo general, muy buena.	Varía. A veces es excelente, a veces inexistente, y hay todo tipo de situaciones intermedias. A menudo la escriben programadores para programadores, por lo que es menos utilizable que la documentación comercial.
Soporte técnico	Muy bueno, aunque tiene un coste.	Varía. Algunos autores de herramientas ofrecen un soporte excelente e incluso añaden funciones bajo petición. Muchas herramientas tienen foros en línea, pero pueden ser muy técnicos. Otras herramientas cuentan con un soporte deficiente.
Fiabilidad/calidad	Por lo general, muy buena.	Variable. Los productos con muchos usuarios, configuraciones regionales y equipos de soporte grandes tienden a ser excelentes. Algunas herramientas escritas por personas individuales, con pocos colaboradores y pocos usuarios, pueden ser inestables.
Amplitud de funciones	Los conjuntos de funciones suelen seguir las hojas de ruta de productos publicadas y normalmente son completos.	Los productos tienden a evolucionar según la demanda de los usuarios y el tamaño del equipo de colaboradores. Por ejemplo, los colaboradores suelen añadir las funciones que necesitan, en lugar de basarse en encuestas a clientes.
Frecuencia de lanzamientos/parches	Los lanzamientos principales suelen producirse con meses, y a veces años, de diferencia. Se publican parches con regularidad. Las advertencias y las notas de la versión suelen ser muy buenas.	Varía. Los lanzamientos principales de productos de infraestructura grandes son similares a los de los productos propietarios. Los productos más pequeños y menos populares suelen lanzar versiones con mayor frecuencia. En ocasiones hay pocos avisos o ninguno, notas de la versión deficientes y pérdida de compatibilidad con versiones anteriores.

Los productos FOSS pueden ser más baratos de adquirir, pero otros costes y responsabilidades pueden ser considerables. El factor decisivo entre ambos suele ser una combinación de tu cultura, tu tolerancia al riesgo y tu 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 un soporte técnico atento suelen ser bajos, aunque en ocasiones resulten costosos.

Con los productos FOSS, normalmente tienes que realizar una investigación mucho más exhaustiva antes de comprometerte a utilizar uno. Al fin y al cabo, no hay un vendedor con quien hablar y la documentación puede ser funcional, en lugar de informativa. Por supuesto, es fácil configurar un periodo de prueba y puedes adoptar tantas herramientas como quieras, pero tendrás que investigar más a fondo las capacidades de la herramienta. 

Una peor usabilidad y la incompatibilidad con tus herramientas existentes podrían ocasionar problemas, por lo que quizá tengas que escribir software de interfaz o complementos, además de utilidades para generar informes o importar y exportar datos. 

Además, tendrás que formarte y formar a tu equipo para que se pongan al día y, por lo general, encargarte de tu propio soporte de software. Sin embargo, tu equipo tendrá un conocimiento más profundo del funcionamiento de la herramienta y podrá desenvolverse en gran medida de forma autónoma.

Una herramienta FOSS podría ayudarte a adquirir experiencia con un nuevo tipo de herramienta a un coste reducido. Con esa experiencia, estarás en una mejor posición para elegir una herramienta propietaria a largo plazo.

Un ejercicio de selección de herramientas

Si estás buscando una herramienta de gestión de pruebas compatible con tu proyecto y aplicación actuales o con proyectos y aplicaciones conocidos y recientes. Basándote en las áreas funcionales tratadas anteriormente en el análisis de las herramientas de gestión de pruebas, haz una lista de entre 15 y 20 características que sean:

• Obligatorias
• Deseables

Esto puede incluir capacidades funcionales, integraciones, un enfoque en la facilidad de uso, soporte, una gran base de usuarios o foros en línea y preguntas frecuentes. Si ya tienes una herramienta implementada, no elijas esa.

Utilizando el texto de tus requisitos, busca en la Base de conocimientos de herramientas tres herramientas (incluidos un producto propietario y uno FOSS) que parezcan ajustarse a tus requisitos. Utilizando las descripciones de las características de las herramientas, crea una tabla comparativa de características de los tres productos. Añade una cuarta columna para la herramienta que realmente utilizas, a modo de comparación.

• ¿Cómo se comparan las herramientas en cuanto a características?
• ¿De qué características carece la herramienta o las herramientas FOSS en comparación con las herramientas propietarias?
• ¿Cuántas herramientas existen que cumplan en líneas generales tus requisitos?
• ¿Cuánto tiempo crees que necesitarías dedicar a investigar herramientas para elaborar una lista final 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 de Liderazgo en pruebas de Paul; lo recomendamos encarecidamente a quienes quieran profundizar en este y otros temas. Si lo haces, ¡utiliza nuestro código de cupón exclusivo QALEADOFFER para conseguir un descuento de 60 $ sobre el precio completo del curso!

Aprende de otros profesionales de las pruebas escuchando nuestros pódcasts o consultando nuestros blogs. Este es uno del que creemos que aprenderás muchísimo: CÓMO LAS HABILIDADES DE PRUEBAS ME CONVIRTIERON EN UN MEJOR DESARROLLADOR DE AUTOMATIZACIÓN