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.

We test our software to make sure it behaves as expected, meets user need, and doesn't regress as code is changed. For more information, see:

The QA team employs a variety of tools to accomplish this goal:

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 verify that it does what it says it will, doesn't regress anything else, and the result is an improvement. 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 old software, such as Debian Stable or a version of Ubuntu/Kubuntu that is not the latest, another approach may be preferred. This approach is described in detail at Get_Involved/development.

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!

Some distros ship pre-release software by default, and most allow you to apply a non-default repo to get pre-release KDE software; a full list can be found at Plasma/Live_Images.

Triage Bug Reports

An essential part of the testing process is to know what bugs exist and need testing! Therefore, bug reports must be up-to-date and actionable. This is the job of application maintainers and bug triagers, and members of the QA team can help out here too! For more information about bug triaging, see Guidelines_and_HOWTOs/Bug_triaging.

Write tests

When a bug is fixed, it's good practice to write a small test that tests that the fix really works. This way, any proposed code change that would re-introduce the bug will cause the test to fail, and people will notice and fix the proposed code change. If you have any programming skills, writing good tests is a hugely impactful way to improve software quality! For more information, see Guidelines_and_HOWTOs/UnitTests.

Historical information