If you are able to read and write English, (even not very well, most of us are not native English speakers), then you'll be able to manage our bug database. The database is open to every one, if you find a bug in our product, you'll be able to report it. But, it's not the best way to deal with it if you've never done it. The most important thing is to understand a bug life cycle. A graph is better than a speach, you'll find it here: http://wiki.documentfoundation.org/File:BzLifecycleold.png. Now that you've understand how to kill a bug, let's begin!

The first place to be when you're a beginner in QA is to participate to bug triage. It's not a difficult task, you read the bug description and you try to reproduce it on your plateform, that's all!. Then, well, you've various decisions to make depending on the results of your tests. To help you make this decision, we have documentation here: http://wiki.documentfoundation.org/BugTriage_InProgress, there is also the IRC channel on #libreoffice-qa and of course, the mailing list where you can subscribe here libreoffice-qa <at> lists.freedesktop.org. You see, you're never alone.

Now that you feel comfortable with bugs from others, you might want to report yours. To help you, we have designed an assistant: https://www.libreoffice.org/get-help/bug/. It will guide you all along the way. If you prefer to proceed by yourself, here is a description of all the part to fill in Bugzilla: http://wiki.documentfoundation.org/BugReport_Details. Now if you want to report a crash, an I/O error or a memory corruption, you can provide more information for developers using respectively backtrace, strace, or valgrind see: http://wiki.documentfoundation.org/BugReport#Providing_extra_information_for_the_developers. If you don't feel at ease with all this, come to the QA list or channel and we will help you. The more accurate information you provide when filling a bug, the less extra work will be needed from our volunteers or our developers. And you know their time, as yours, is precious :)

We don't deal only with bugs, we also work hard to prevent them. For each release, we are running tests at different levels. We have different builds available too, the released build, the pre-version corresponding to beta or rc and the daily builds. For each of them, we are running regression tests under the form of automated tests. Those tests are written in C++ mostly, so if you are a developer, you can help writing and running them, the information to write them are here: http://wiki.documentfoundation.org/QA/Testing/Automated_Tests. If you're not a developer, you can still help by running these series: http://wiki.documentfoundation.org/Development/Unit_Tests_By_Non_Developers. We need more of them, so don't hesitate to add your tests, and again if you're not sure of the process, we are here to help you.

Another way is to bibisect, it means binary bisect and is intended to help tracking regressions. It's however dedicated to Linux. Everything is explain here: http://wiki.documentfoundation.org/QA/HowToBibisect. And you even have a nice video how-to on Youtube.

Well all this is a bit technical, and may be manual tests are more adapted to what you want. This is an area that we are exploring, there is not so many tools to manage those tests in an efficient way and we are currently evaluating Moztrap. However, your help, as usual, will be highly appreciated. It's really not difficult to write tests see the process here: http://wiki.documentfoundation.org/QA/Testing/Test_Case. How does it look? easy no? Moztrap has been designed for end users, easy to access, easy to manage and it provides a good overview of what has been done. This page will give you a tour of the tool. My only reservation to use it more widely currently, is that it's English only when I would like it to be accessible to the overall community. But it needs some development to be localized (UI and tests). But however, if English is not an issue for you, you're very welcome to use it, enhance the tests and create some new ones.

It told you that there will be two parts in this section, here come the second. I will base it on what we are doing in the FR community because most of the members have the will and all the needed skills to participate, but... but they don't read or write English. You know that our community is open to all and language must not be a barrier that prevent whoever to participate. So we have to adapt our processes, our tools, everything needed that will allow them to get involved. This is why we have mailing lists for the native-language communities.

You have read that we have different releases available at the same time. If you are using a released build and find a bug. The best is to discuss it on the discuss list of your language community (or the qa dedicated mailing list if it exists). Describe step by step how to reproduce your problem, give information on your OS and the version you are using. Other member will try to reproduce the bug on the same OS or on the other OS. More experienced QA members will be able to narrow the problem and give more precise information. At the end one of them able to deal with Bugzilla will search for duplicates, comment or confirm the bug if it already exists or create it if not. You see, your feedback is always useful for the overall community even if you don't speak English, because you belong to a group who is acting together, each one using his own skills to help each other.

But you can go even further, for each RC or beta we are doing tests. I told you about Moztrap, but for the moment localization is a real issue and makes it not so friendly for the native-language community. So we proceed by using the tests but without the tool. You can run the manual tests on your version and report the issue you may find on the list. The same process as the one I described above will be applied, the only difference is the time frame. Beta and RC depend on our release process so we only have a given time to tests them.
Another way to tests this builds is to use a set of documents that you usually work with. The interest here is that you know the normal behavior of this document and even a tiny difference will be an evidence for your. The most difficult task in tracking bugs is to review all the possible use case. Your documents are covering this (but please work on a copy, not on the original!).
We also organize bug tracking sessions on the French IRC channel. It's a very nice way to work together and an efficient way to learn more about QA. For that we translate the new features page and the release notes. You pick a new feature, you test it and you report your findings on the list. We know that this feature has been tested, on which OS and in what way. If you don't want to participate to QA, you can still participate by translating the pages ;-)
Another thing about QA of localized builds. It's always good to test a version in your language. On very rare case we found specific bugs because of the language, but if like me you're alone to do the localization of the UI and the help, the reviewing by others will be a great help for you and will enhance the quality of the version you deliver in your language. A very important step for all us, the more the translation is precise, the easier the functionality will be to use.

Concerning Bugzilla, I mostly spoke about bug triage, but there is other tasks you can achieve on the database. For example checking for a fix in a daily build, the feature tests page will give you directions, close the bug when it's implemented and verified to be fix in the version.
Also there is not only the community bugtracker, but one for Ubuntu, Suse or Redhat, check with the QA members on which tracker you want to report your bug.

So so, voila I'm sure now, the only thing you wish is to become a QA contributor :-)