Quality Assurance

Quality Assurance is the backbone of user satisfaction, and you can help make it happen for KDE software by joining the QA team! Head over to https://invent.kde.org/teams/qa and click the "Request access" link. Additionally, you can join our Matrix room at #quality:kde.org.

The QA team has two primary tools to accomplish this goal:

1. Test Merge Requests on https://invent.kde.org to make sure they work and don't introduce regressions
2. Use pre-release versions of KDE software and report bugs

Test Merge Requests

To test a Merge Request, you'll apply the Merge Request's change to a piece of KDE software, compile it from source, and then test the result. This is described in detail at Infrastructure/GitLab#Testing_someone_else.27s_Merge_Request.

Use pre-release software

By using pre-release versions of KDE software, you'll encounter bugs and regressions before users do. When this happens, file a bug report at https://bugs.kde.org and mark it with the "regression" keyword.

There are a few ways to use pre-release versions of KDE software, and you can choose whichever version works best for you. The following options are ordered from least risky to most risky:

Use nightly Flatpak apps

Nightly builds of all KDE applications are available via Flatpak, using the kde-unstable repo. You can uninstall your distro-provided KDE apps, and reinstall them from the KDE nightly build Flatpak repo instead. This is described at Guidelines_and_HOWTOs/Flatpak. However this will not work for Plasma or system components like KWin; you will have to use another method of using pre-release versions of them.

Build everything from source

This approach entails using the kdesrc-build tool to compile all KDE software from source code, and then you log into your compiled-from-source Plasma session. This has the advantage that you can fall back to your distro-provided Plasma session should something go wrong with the built-from-source software. If you are using a rolling or semi-rolling distro, are also doing development activity, and/or are testing a lot of merge requests, this may be the easiest way to go. If you are using a distro that ships very old software--such as Debian Stable or Ubuntu/Kubuntu LTS versions--another approach may be preferred. This approach is described in detail at Get_Involved/development#Building_software_with_kdesrc-build

Use distro-provided pre-release software

With this approach, you run distro-provided pre-release versions of KDE software for your daily use. This is exceptionally adventurous, but many people do it successfully due to the overall stability of KDE software! KDE Neon Unstable and openSUSE Krypton ship pre-release KDE software by default. Other distros allow you to apply a non-default repo to get pre-release KDE software; a full list can be found at https://community.kde.org/Distributions.