Bogdan Buzea: Nuevo analista de Control de Calidad en The Document Foundation

Bogdan Buzea: Nuevo analista de Control de Calidad en The Document Foundation

Hay algo que suele pasar desapercibido detrás de cada nueva versión de LibreOffice: antes de llegar a millones de escritorios alrededor del mundo, el software atraviesa un enorme proceso de pruebas.

Y, aun así, ningún programa de semejante tamaño puede anticipar todas las combinaciones posibles de sistemas, documentos, configuraciones y formas de trabajar. Ahí es donde entra en escena el equipo de Control de Calidad (QA, por sus siglas en inglés).

Para reforzar esta tarea, The Document Foundation (TDF) incorporó a Bogdan Buzea como nuevo Analista de QA. Bogdan llega con una particularidad interesante: durante años trabajó como contador en Rumania y, paralelamente, dedicó su tiempo libre a colaborar como voluntario en el control de calidad de LibreOffice.

Ahora, esa experiencia pasa a formar parte de su trabajo cotidiano.

Ocho años mirando LibreOffice con otros ojos

Cuéntanos un poco sobre ti.

Trabajé como contador durante prácticamente toda mi vida, aquí en Rumania. Como hobby, durante los últimos ocho años participé como voluntario en el equipo de Control de Calidad de LibreOffice.

Mi trabajo estuvo especialmente ligado a LibreOffice Writer, que utilizaba habitualmente en mi actividad como contador. Quería que las cosas funcionaran cada vez mejor y, de a poco, empecé a involucrarme en el proceso para conseguirlo.

Cuando “algo no funciona” es apenas el comienzo

¿Cuál es tu nuevo rol en TDF y en qué vas a trabajar?

Desde mediados de septiembre de 2026 trabajo como Quality Assurance Analyst.

Una parte importante de mi tarea consiste en revisar los errores reportados en Bugzilla y hacer su triage: analizar cada reporte, determinar qué información tenemos, qué falta y cuál debería ser el siguiente paso.

Porque un reporte de error puede significar varias cosas.

Hay un bug real

Algunos reportes efectivamente encuentran errores de LibreOffice. En esos casos, desarrolladores de todo el mundo trabajan día a día para solucionarlos.

Más del 30% de los bugs reportados terminan siendo corregidos.

A veces falta una pieza clave

Otras veces recibimos un reporte que simplemente no tiene suficiente información para reproducir el problema.

Por ejemplo:

“Cuando busco algo, LibreOffice se cierra”.

Es un comienzo, pero no alcanza.

  • ¿Había caracteres con diacríticos?
  • ¿Había varios documentos abiertos?
  • ¿Se utilizaba una versión reciente o una más antigua?
  • ¿El problema ocurre siempre?
  • ¿También ocurría en versiones anteriores?
  • ¿Apareció recién con la versión nueva?

Cuantos más datos tengamos, más rápido podemos reproducir el problema, encontrar su causa y trabajar en una solución.

Por eso es importante seguir las recomendaciones sobre cómo reportar correctamente un bug.

El mismo bug puede aparecer muchas veces

También están los duplicados.

A veces alguien reporta un problema que ya fue registrado anteriormente. En ese caso, el nuevo reporte se cierra como duplicado del original.

Y esto es importante: que tu reporte sea marcado como duplicado no significa que hayas perdido el tiempo.

Al contrario. Si muchas personas informan exactamente el mismo problema, eso nos indica que el error afecta a muchos usuarios y que merece especial atención.

Así que, si alguna vez te ocurre, no te desanimes: tu reporte puede haber ayudado a demostrar que ese problema es más importante de lo que parecía.

Cuando el problema no es un bug

Hay otro tipo de reportes que tienen que ver con usuarios que están intentando hacer algo de una manera que LibreOffice no espera.

En esos casos también ayudamos, pero muchas veces existen lugares más adecuados para encontrar una respuesta:

La comunidad mantiene estos recursos constantemente actualizados, con artículos y documentación que reciben aportes de voluntarios de todo el mundo.

Y hay una recompensa especialmente agradable cuando esto funciona. Muchas veces un usuario vuelve y dice:

“¡Perfecto, ahora funciona! No sabía que podía hacerlo de esa manera”.

Para que esto ocurra cada vez más, también trabajamos en mejorar la documentación y agregar tooltips que orienten al usuario mientras trabaja.

Y hay una regla sencilla: si una función no deja claro cómo debe utilizarse, eso también puede ser un bug. En ese caso, vale la pena reportarlo.

La pista está en lo que dejó de funcionar

Otra parte de mi trabajo consiste en detectar regresiones.

Imaginemos que una determinada función funcionó correctamente durante muchas versiones y, de repente, deja de hacerlo después de una actualización.

En esos casos investigo qué cambio en el código pudo haber provocado el problema.

Encontrar exactamente qué modificación produjo la regresión permite a los desarrolladores concentrarse rápidamente en la parte del código responsable y, en consecuencia, acelerar la solución.

Es un poco como reconstruir la escena de un accidente: saber qué cambió entre el “antes” y el “después” puede ser la pista más importante.

¿Quieres ayudar a mejorar LibreOffice?

Hay muchas maneras de hacerlo.

La más directa es reportar un bug cuando encuentres uno. Pero un buen reporte hace toda la diferencia: incluye toda la información que pueda ayudar a reproducir el problema.

También hay tareas de QA que cualquier usuario puede realizar.

Por ejemplo, puedes buscar en Bugzilla errores que todavía tienen el estado Unconfirmed. Si consigues reproducir el problema en tu sistema, puedes marcarlo como New.

También puedes probar versiones anteriores de LibreOffice para descubrir si se trata de un problema reciente o de uno que lleva mucho tiempo presente.

Y existe una tarea un poco más avanzada: hacer un bibisect, un proceso que permite identificar el commit exacto del código que introdujo el problema. La documentación sobre Bibisect explica cómo hacerlo.

QA es solo una de las puertas de entrada

No todo el mundo disfruta buscando bugs, reproduciendo errores o siguiendo pistas dentro del código. Y está perfecto.

LibreOffice es un proyecto comunitario enorme y necesita muchos tipos de colaboración diferentes.

Si querés participar, pero QA no es lo tuyo, podés descubrir otras formas de contribuir a LibreOffice.

Porque detrás de cada versión de LibreOffice no solo hay código: también hay personas que lo prueban, lo documentan, lo traducen, lo usan, encuentran sus límites y ayudan a hacerlo un poco mejor.

 

Artículo original (en inglés)

Written by:

Colaboro de manera voluntaria con The Document Foundation desde el año 2011, me ocupo de mantener el sitio en español, de este blog y también de canalizar las consultas de usuarios a los canales apropiados. Soy, además, uno de los administradores del grupo hispano en Matrix (libreoffice_es:matrix.cuates.net) y en Telegram (https://t.me/libreoffice_es).
View All Posts
Follow Me :

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Acepto la Política de privacidad