Quality Assurance: Difference between revisions
No edit summary |
(Mention Plasma beta review days, and link to the relevant page) |
||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
[[Category:Testing]] | |||
[[File:Mascot konqi-app-utilities.png|right|x250px|]] | [[File:Mascot konqi-app-utilities.png|right|x250px|]] | ||
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. | 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 [https://matrix.to/#/#quality:kde.org #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: | |||
# | |||
# | # http://en.wikipedia.org/wiki/Software_quality_assurance | ||
# http://en.wikipedia.org/wiki/Software_testing | |||
# http://www.thebraidytester.com/downloads/YouAreNotDoneYet.pdf | |||
The QA team employs a variety of tools to accomplish this goal: | |||
== Test Merge Requests == | == 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 | 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 == | |||
== Use | |||
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. | 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. | ||
| Line 19: | Line 24: | ||
==== Build everything from source ==== | ==== Build everything from source ==== | ||
This approach entails using the <tt>kdesrc-build</tt> 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 | This approach entails using the <tt>kdesrc-build</tt> 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 ==== | ==== 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! | 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]]. | |||
Once you're all set up, make sure to participate in [[Schedules/Plasma_5_BetaReviewDay|Plasma beta review days]]! | |||
== 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 == | |||
# [[Get_Involved/Quality/Tutorial| Quality tutorial]] | |||
# [[Get_Involved/Extra_Mile|"Extra Mile" initiative]] | |||
# [[Get_Involved/Quality/Plasma_Applet_Quality_Guidelines|Plasma applet quality guidelines]] | |||
# [[Quality/Brainstorming|QA ideas]] | |||
Latest revision as of 21:22, 25 January 2023
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:
- http://en.wikipedia.org/wiki/Software_quality_assurance
- http://en.wikipedia.org/wiki/Software_testing
- http://www.thebraidytester.com/downloads/YouAreNotDoneYet.pdf
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.
Once you're all set up, make sure to participate in Plasma beta review days!
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.