Category: QA

Earlier this week we talked to LibreOffice’s quality assurance (QA) engineer, Xisco Fauli, about how the QA team works, what they’re involved with at the moment, and where they need help. Let’s now look at how regular LibreOffice users can get involved: even if you can only spare a little bit of time each week, you can really make a difference to strengthen and improve the software.

LibreOffice’s QA team is comprised largely of volunteers. The team works through bug reports submitted by LibreOffice users, checking them for accuracy, reproducing them (where possible), and assigning them to the appropriate developers or projects.

Reporting bugs

Bugzilla is used for tracking bugs, and it’s a very versatile tool that may look a bit daunting initially. But once you’ve submitted a couple of bug reports it becomes easier to work with. To submit a bug report, you need to be logged in there – so click “New Account” at the top to set up an account.

Now, let’s say you’ve found a bug in LibreOffice and want to report it. The process goes as follows:

1. Click New at the top of Bugzilla, choose LibreOffice, and you’ll end up on this page
2. Many bugs have been reported multiple times already, so scan through the list to check your issue isn’t already being dealt with
3. Also, try typing some keywords associated with your bug (eg “docx import” or “PDF crash” in the box under the list, and click “Find Similar Issues” to check if someone else has submitted the bug already
4. Otherwise, click “My issue is not listed” and fill in the form
5. Provide as much information as possible: the component of LibreOffice affected (eg Calc), what hardware you’re using, and LibreOffice version
6. Provide a short summary and detailed description with as much useful information as possible
7. Add steps to reproduce, the results you get, and what you expected
8. For the “severity” part, only choose a high ranking if it’s extremely serious (like, it can cause major data loss

Once your bug has been submitted, a member of the QA team will check it and ask for more information if required. Also see this page for more information on submitting good bug reports.

Confirming and triaging

But what happens if you bug has already been reported? It still helps the QA team if you confirm it as well, especially if you’re using a different operating system or version of LibreOffice. In that way, the QA team can narrow down the cause more quickly. So it’s worth taking the time to confirm even if a bug report from someone else already looks detailed enough.

If you’d like to get more involved in the QA team, maybe to build up experience for a future career in QA, you can help by triaging bugs. This is the process of confirming and prioritising bugs so that developers know what to work on. As it’s a large and complex piece of software used by tens of millions of people, LibreOffice receives many bug reports, so it’s important that they are organised correctly.

Then there are Easy Hacks you can help with, which help the QA processes and team. These vary from improving the QA infrastructure to more creative topics like making a video to assist newcomers. Have a look at the page – something is bound to take your interest!

Join the Bug Hunting Session

On Friday October 21, from 08:00 UTC to 22:UTC, a big testing effort to fix bugs in the upcoming LibreOffice 5.3.0 release will take place. There are many new features in this next version of LibreOffice, so your assistance in making it rock-solid is very much appreciated. Here’s how to get involved:

• Download LibreOffice 5.3.0 Alpha from here (it will be available when the session starts, and can be installed alongside a stable release like 5.2)
• Test some of the new features in 5.3, especially those which change the interface
• Found a bug? Join the QA team on IRC chat (#libreoffice-qa on Freenode) who will then help you through the process of reporting it

See the wiki for more information on the Bug Hunting Session – and thanks in advance for any help you give. Millions of LibreOffice users around the world will benefit from your efforts, and free and open source software on the desktop will keep getting stronger!

Having covered development and documentation, we’re now into our third LibreOffice Community Week: Quality Assurance (or just “QA” for short). QA is an essential element of the LibreOffice development process, and affects the suite in many ways. For the benefit of end users, QA helps to identify and fix bugs – whether they’re glitches in the behaviour of the office suite, or problems that arise when importing certain files, or just issues with the user interface.

But QA is an integral part of new feature development as well. When a LibreOffice developer adds something new to the office suite, QA processes ensure that it doesn’t impact other features, and that the rest of the software continues to be stable and robust.

LibreOffice has an active QA community that works on tracking, reproducing and fixing bugs, and The Document Foundation (the non-profit entity that backs LibreOffice development) recently hired a dedicated QA engineer, Xisco Fauli. We caught up with him to see how the QA process works and how newcomers can help out.

What is your role in the QA team?

My role is to act as a middle-man between the QA community and other teams, such as participating in the Engineering Steering Committee (ESC) meetings for instance.

I’m also in charge of organizing the QA meetings, which take place every other Tuesday, and organizing the bug hunting sessions, the next one being on Friday October 21 for LibreOffice 5.3 Alpha. I also spend time maintaining Bugzilla, our bug-tracking tool, updating the wiki, helping other users on IRC, and triaging and reporting bugs. Lately I’ve been working on collecting stats from Bugzilla so that they’ll help us to analyze the status of bugs and users in the platform.

How did you get involved?

I started working for The Document Foundation just one and a half months ago, in the beginning of September, so I’m a newbie here. However, I had already contributed to the LibreOffice project in the past, mostly doing bibisections in QA or working on Easy Hacks and small fixes in development. Besides, I participated in the Google Summer of Code in 2011, converting some Java wizards to Python.

What does your typical workday look like?

So far I think no two days have been alike for me, so I’ll try to summarize it as much as possible! Normally, the first thing I do when I get connected is check the email and the IRC history. Then I take a look at the new changes in Bugzilla (new unconfirmed bugs, new bibisectRequest bugs, etc.) and eventually I work on the main task I have planned for the day. In case I have a meeting, I also spend some time getting things ready beforehand.

What areas in QA are working well, and what needs to be improved?

Definitely the best part of QA is the volunteers themselves, who expend their own time on the project, keeping the unconfirmed bugs low, triaging bugs, providing backtraces, etc. as this would be impossible without them.

I also find tools like the bibisect repositories really great for triaging regressions. On the other hand, as the amount of bugs in Bugzilla is quite high, I believe we need to improve how duplicated bugs can be identified more easily, as well as finding ways of attracting new volunteers to the team and encouraging them to stay in the project.

How can normal (non-developer) LibreOffice users help out?

One of the best ways a normal day-to-day Libreoffice user can help out is by reporting clear and detailed bugs when they find a problem, making the chances of getting the bug triaged, and subsequently fixed, much higher. A good bug report must have:

• Operating system and LibreOffice version
• Enumerated reproducible steps
• Simple attachments where appropriate
• Observed or expected results

Besides, they can also help to confirm bugs or retest bugs that might be fixed.

Finally, participating in the next Bug Hunting Session on Friday October 21 is a good way to start helping out. Newcomers can contact us on IRC (#libreoffice-qa on Freenode) or via the mailing list if they have any questions.

Thanks Xisco. So, that’s an overview of the QA team and what it does – later this week we’ll show you exactly how to get involved, confirm a bug report, and help to make LibreOffice stronger and more robust for everyone.

Help to fix bugs in the next version of LibreOffice, and make it the best yet! As we mentioned last week, we are holding a Bug Hunting Session on Friday 24 June, from 07:00 to 20:00 UTC, and everyone is welcome to take part. All you have to do is:

• Download the latest development version of LibreOffice 5.2 (see the prerelease section at the bottom)
• Join our libreoffice-qa IRC chat channel on Freenode
• Try the new features in LibreOffice 5.2, as covered in the technology preview video
• If you find a bug, tell us about it on IRC, so that we can investigate more

And as thanks for your help, if you find or confirm a bug we’ll award you a shiny Badge that you can proudly show on your website, blog or social media. For more details, see the full Bug Hunting Session wiki page.

We hope to see you on Friday, at some point between 07:00 to 20:00 UTC – and thanks in advance for your help!

A new release of LibreOffice is coming up – so help to make it the best version ever! LibreOffice 5.2 is due to be released at the start of August, and developers are busy working on new features and updates. With so many changes in the next version, we’d really appreciate your help finding bugs so that we can squash them!

To this end we’ll be holding a Bug Hunting Session on Friday 24 June, from 07:00 to 20:00 UTC. Anyone can take part at any time – it’s simple and fun! All you have to do is download the latest development release, try out the new features, and report bugs on our IRC chat channel. Even if you can only spare half an hour of your time, it’s a great help to make LibreOffice better than ever before – and you can show off a badge like the one above!

So mark the date in your calendar: Friday 24 June. We’ll post more details on this blog soon, so stay tuned…

LibreOffice is approaching the 5.2 release season with the first bug hunting session, on Friday, April 22, 2016. Tests will be performed on the Alpha version of LibreOffice 5.2, which will be available on the pre-releases servers a few days before the event. Builds will be available for Linux (DEB and RPM), MacOS and Windows, and will run in parallel with the actual installation.

Mentors will be available on April 22, 2016, from 8AM UTC to 10PM UTC. Of course, hunting bugs will be possible also on other days, as the builds of this particular Alpha release (LibreOffice 5.2.0 Alpha) will be available until the end of May.

During the day there will be two dedicated sessions: the first to chase bugs on the four main LibreOffice modules – Writer, Calc, Impress and Draw – between 3PM UTC and 5PM UTC, and the second to test the top 10 features between 5PM UTC and 7PM UTC. The list of the top 10 features will be decided during the week before the session, and will be added to the wiki page.

During the dedicated sessions, we will concentrate all efforts to chase and reproduce the bugs, in order to confirm and file them in a more comprehensive way. Of course, the more comprehensive will be the bug report, the easier will be for the developers to solve the bugs in time for the final release.

As usual, there is a page on the wiki with all the details about the bug hunting session. You should visit the page before April 22, 2016, as further details will be added while getting closer to the date of the event.