Quality Assurance

Quality Assurance is the backbone of user satisfaction, and you can help make it happen for KDE software!

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

To help accomplish this goal, you can:

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. The following options are ordered from least risky to most risky:

Use nightly Flatpak apps

Nightly builds of some KDE applications are available from the KDE nightly flatpak repository. You can uninstall distro-provided KDE apps, and reinstall them from the KDE nightly flatpak repository instead.

However this will not work for Plasma or system components like KWin; another approach will be required.

Use distro-provided pre-release software in a VM

With this approach, you run distro-provided pre-release versions of KDE software in a virtual machine, allowing complete segregation from your normal system.

A list of distros providing this can be found at Plasma/Live_Images#Ships_the_latest_Plasma_release

Build everything from source

This approach entails using the kde-builder tool to compile all KDE software from source code, and then logging into the compiled-from-source Plasma session. This has the advantage that you can fall back to the distro-provided Plasma session should something go wrong with the built-from-source software.

If you're using a rolling or semi-rolling distro, are also doing development activity, and/or are testing a lot of merge requests, this is probably the best way to go. If you're using a distro that ships an older version of Qt, such as Debian Stable or an LTS version of Ubuntu/Kubuntu, another approach may be preferred.

This approach is described in detail at Get_Involved/development.

Use distro-provided pre-release software on your computer

With this approach, you run distro-provided pre-release versions of KDE software for daily use. This is exceptionally adventurous, but many people do it successfully due to the overall stability of KDE software!

A list of distros providing this can be found at Plasma/Live_Images#Ships_the_latest_KDE_release

Report issues you found during testing

It goes without saying that a bug only you know about is not very useful. Go to Get_Involved/Issue_Reporting to learn how to submit actionable bug reports.

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.