TUS Testing de OpenOffice
El equipo de 101 Ingenieros decidió que como Trabajo de Utilidad Social iban a colaborar con una aplicación de software libre propuesta en el campus virtual, OpenOffice.
OpenOffice ofrece distintos aspectos en los que colaborar, como son la traducción de documentación, el arreglo de errores, o la propuesta de nuevas características. El equipo, debido al poco conocimiento que tenían sobre el código de OpenOffice, en seguida descartaron los aspectos que tenían que ver con la corrección de errores a nivel código. En un primer momento, consideraron la traducción de documentación, debido a su facilidad; pero al final decidieron ayudar con el testeo de la aplicación y la búsqueda de bugs, ya que a casi todos les parecía más atractivo que traducir.
Contenido
Motivación
La motivación para llevar a cabo este Trabajo de Utilidad Social fue principalmente el porcentaje de puntuación que aportaba para la nota final de la asignatura de Ética, Legislación y Profesión. Sin embargo, la motivación para elegir el tema del Trabajo de Utilidad Social en concreto, el testeo y la búsqueda de bugs en la aplicación de OpenOffice, se debe principalmente a la necesidad de contar con aplicaciones de software libre fiables que permitan editar texto, crear hojas de cálculo, presentaciones, etc., ya que, a día de hoy, las aplicaciones más utilizadas para este tipo de actividades son privativas, con licencias bastante caras.
El equipo entendió que el público en general prefiera aplicaciones privativas, porque han sabido expandirse en el mercado y conseguir ser las aplicaciones por defecto, haciendo que la gente se sienta incómoda cuando usa cualquier otra aplicación. También entienden el poco atractivo que tienen este tipo de aplicaciones de software libre ya que, tanto su interfaz gráfica como su funcionalidad, dejan mucho que desear. Es por esto que decidieron aportar nuestro granito de arena y testearon la aplicación para poder guiar a los desarrolladores en la corrección de ciertas funcionalidades que fallan, o de aspectos que pueden resultar poco intuitivos a los usuarios.
Qué se ha hecho
En primer lugar, se informaron de cuál era el método para reportar bugs a OpenOffice. Descubrieron que, al igual que LibreOffice, OpenOffice hace uso de la plataforma Bugzilla para el reporte de bugs y errores.
Después de ver esto, cada miembro del equipo se creó una cuenta en Bugzilla, para reportar aquellos bugs que encontraran en el proceso. A continuación, decidieron repartirse el proceso de testing.
OpenOffice está formado por seis aplicaciones que son: Documento de texto, Hoja de cálculo, Presentación, Dibujo, Base de datos, y Fórmula. Para ser más efectivos, decidieron repartirse estas aplicaciones, de forma que cada uno se centró en el testeo de sólo una de ellas. El reparto quedó como sigue:
➔ Base de datos → Adrian Sanchez
➔ Dibujo → Laura Jiménez
➔ Documento de texto → Victoria Barylak
➔ Hoja de cálculo → Rafael Hernández
➔ Presentación → Manuel Pastor
Debido a que no eran suficientes miembros en el equipo, se quedó descolgada la aplicación de Fórmula. Esto se hizo intencionadamente, ya que todo el equipo pensó que, dentro de las aplicaciones de OpenOffice, esa era la menos prioritaria y la que menos utilizaría el usuario medio.
Después de realizar el reparto de aplicaciones, se crearon una serie de “casos de test” base que servirían a todos como ejemplos a seguir a la hora de documentar los tests que realizaran. Por último, acordaron reunirse todos los domingos a las 6 de la tarde para hablar sobre los bugs que encontraran y lo que habían probado en general durante la semana.
Miembros del equipo y su trabajo
El equipo de 101 Ingenieros está formado por cinco miembros: Victoria Barylak, Rafael Hernández, Laura Jiménez, Manuel Pastor, y Adrian Sanchez.
Como se ha explicado en el apartado anterior, a cada miembro se le asignó una aplicación que probar, y acordaron realizar 30 casos de test cada uno, sobre la aplicación que les había tocado.
Cabe mencionar la diferencia entre bug y caso de test; un bug es un comportamiento erróneo del programa, mientras que un caso de test es una representación o documentación de la prueba o test que se ha llevado a cabo. De este modo, todos los bugs serán encontrados por casos de test, pero no todos los casos de test darán lugar a un bug. En un principio pensaron que sería interesante marcar el límite con el número de bugs encontrados, es decir, proponer que cada miembro del equipo encontrara 30 bugs en su aplicación respectiva. Sin embargo, esto les pareció un tanto excesivo, ya que hay 4 aplicaciones que han recibido mayor soporte que otras, en las que sería más complicado encontrar bugs.
Por todo esto, acordaron que cada miembro del equipo llevaría a cabo 30 casos de test, y los documentaría en tablas con el siguiente formato:
- ID: ID asignado al caso de test
- Nombre: Nombre descriptivo de lo que se está probando
- Objetivo: Cuál es el objetivo del caso de test
- Precondición: Acciones necesarias a realizar antes de poder llevar a cabo el test
- Pasos: Pasos del test con su resultado esperado
- Resultado obtenido: Resultado final del test, ya sea correcto o no
- Enlace del bug reportado: Enlace al bug en Bugzilla
En el repositorio de GitHub cuyo enlace está al final de este documento se pueden ver los casos de test llevados a cabo por cada miembro del equipo.
Cómo utilizar el trabajo
Debido a que cada miembro del equipo documentó los casos de test como se ha explicado en el apartado anterior, se tiene una constancia de qué aspectos de las distintas aplicaciones se han probado, y cómo se han llevado a cabo esas pruebas (ya que cada caso de test incluye los pasos a seguir). Gracias a esto, si alguien quiere continuar testeando las aplicaciones de OpenOffice, para evitar repetir trabajo, podría echar un vistazo a los tests que ya se han realizado, y probar aspectos y funcionalidades que no se han probado todavía.
Además, debido a que cada bug encontrado viene acompañado del enlace al reporte que se ha realizado en Bugzilla (del equipo o por otro usuario que ya había encontrado el bug antes), puede acceder a él y votarlo en el caso de que le parezca un bug importante de arreglar, para que el bug gane prioridad y los desarrolladores lo atiendan antes.
Cómo mejorar el trabajo
El trabajo que hemos realizado es muy sencillo de continuar y mejorar. Simplemente, aquellas personas interesadas, deben echarle un vistazo a los casos de test ya realizados, y llevar a cabo ellos mismos casos de tests distintos a los ya documentados.
Conclusión
Gracias a este trabajo todos los miembros de equipo pudieron experimentar una faceta de lo que es trabajar y colaborar en proyectos de software libre. Aún no habiendo sido una colaboración de larga duración, ya que ha sido de apenas unos meses, pudieron darse cuenta de los aspectos que funcionan y de aquellos que se podrían mejorar.
Por supuesto, debido a que sólo pudieron colaborar testeando y buscando bugs en las distintas aplicaciones de OpenOffice, estos aspectos no tienen por qué afectar a otras facetas de la colaboración con proyectos de software libre (como pueden ser la traducción de documentación, o el desarrollo de código).
Como punto positivo pudieron ver la inmensa comunidad que hay detrás de proyectos de software libre como el de OpenOffice, que se puede apreciar mediante la plataforma para el reporte de bugs Bugzilla. A la hora de reportar aquellos bugs que encontraron, pudimos ver que muchos de ellos ya habían sido reportados, lo que les hizo pensar dos cosas:
En primer lugar, vieron la importancia que podría tener un trabajo como el suyo en proyectos de software libre ya que, al contar con un registro de aquellas características que ya han sido probadas, no se repetirían tests inutilmente y, por lo tanto, no hubieran intentado reportar bugs que otros usuarios ya habían encontrado antes que ellos.
En segundo lugar, pudieron apreciar la cantidad de usuarios que utilizan parte de su tiempo libre para mejorar estas aplicaciones. No sólo eso, sino también la cantidad de características distintas que dichos usuarios habían probado, que a ninguno de los miembros de equipo se les ocurrieron. Esto les hizo darse cuenta del potencial que tienen los proyectos de software libre debido a que no sólo están siendo probados y desarrollados por un número relativamente pequeño de usuarios (aquellos contratados por la empresa para realizar dicho testeo o desarrollo), sino que reciben el apoyo continuo de una comunidad compuesta por miles de personas y, como todos sabemos, “dos cabezas piensan más que una”.
En cuanto al método seguido para el reporte de bugs, la plataforma de Bugzilla, también tuvieron sus reflexiones. Pudieron experimentar que, aunque este tipo de comunidades suelen ser muy agradecidas y user friendly, no pueden decir lo mismo de Bugzilla. Varios de los bugs encontrados que reportaron fueron cerrados debido a que “no eran reproducibles” o “no suponían un bug”. De hecho, cuando se reportaron bugs con respecto a funcionamientos poco intuitivos, es decir, aquellos que podían inducir a error dependiendo de la perspectiva con la que se viesen, se les respondió con que antes de reportar bugs, debían echarle un vistazo al manual de usuario, para no confundir comportamientos normales con bugs.
Como última reflexión, el equipo pensó que OpenOffice debería darle máxima prioridad a la experiencia de usuario en sus aplicaciones (que sean más intuitivas y fáciles de usar), antes que intentar añadir funcionalidades que resultan cada vez más difíciles de utilizar.
