The Lubuntu Testing Checklist can be found here or for Lubuntu 24.04 LTS and later here
In this post I will talk about some of our various testcases. Most I hope are pretty easy to work out, and won’t need this explanation, so feel free to read only the portions you may find interesting.
Installer Tests
The document starts with a list of dates which will be amended (added to etc) as necessary.
Next is a list of packages, eg.
calamares: 3.2.41.1-0ubuntu1
lubuntu-default-settings: 21.10.2
casper 1.465
The significance of these are, if any of these packages change, all install tests must be done again.
Install tests
These should be pretty easy to understand, put simply it’s four test installs for each of three categories
- BIOS box (old type boxes)
- uEFI box (more recent boxes)
- Secure uEFI box (recent box with higher-level of boot security)
with combinations of the settings of
- encryption / no-encryption
- internet / off-line
- swap (yes / no)
If QA testing Lubuntu 24.04 LTS (or later) you’ll be using this checklist which has additional options
- updates (yes / no)
- third.party (yes / no)
As 24.04 & later have many more options, the yes/no format has been altered to a single letter abbreviation for swap/updates/3rd.party (S for swap, U for updates, 3 for 3rd.party) following by a Y for yes or N for no.
Lubuntu 24.04 LTS also has three install types which are described here
Full Install - All applications in the Normal Installation and all extra third party packages listed (on screen) will be installed (24.04 & later)
Normal Install - Web browser, utilities, office software, games, and media players. This is the default install of Lubuntu 23.10 and earlier (on 24.04 & later)
Minimal Install - Only the desktop environment (on 24.04 & later).
The tester puts their name, the date it was tested (your local date is fine) and importantly the ISO date.
(all ISOs have a date on them, if you head /etc/apt/sources.list you’ll see a line at the top of any box (assuming it wasn’t removed) that gives the date of the install media used)
The pc.detail is a very-shortened form of the hardware used to perform the tests. Ideally as many different boxes will appear in this column; but it’s limited to whatever boxes we have ready access to.
Other install types
Install Alongside: I hope is self-explanatory; it’s called “autoresize” in most testing QA as that’s the terminology used by the ubiquity installer used by Ubuntu Desktop and many flavors. Lubuntu uses calamares where it’s a install alongside. This type of install shrinks a partition making space for a new partition for the new install. Tests of this cannot be expected to work if it’s impossible (eg. if using a DOS/MBR partition table and 4 primary partitions already exist - you cannot expect the installer to create a 5th given there is a maximum of 4 primary partitions possible). You need to check all systems boot normally here (ie. not just the new Lubuntu install)
Replace partition: Again I hope it’s self-explanatory; but whatever was on that partition will be formatted and a new system installed there. It’s another menu selection in the calamares installer so nothing special is required here. If the box has multiple OSes installed; you should ensure all boot correctly; not just your new Lubuntu install. Newer versions of calamares can cope with separate /home partition too here.
Install using existing partition:
This may not be self-explanatory, and it’s the one the writer of this personally loves (about Ubuntu installers). If you break your system because you made some packaging mistakes - this is a quick & easy fix. It’s also a great fix if a release-upgrade goes wrong, or even if you don’t have sufficient time to let it run (this install is far faster!)
Boot the live media and select “Manual Partitioning”, You need to select your existing partition(s) but ensure you don’t format them (esp. the / partition); as it’s the no-format that triggers this install type. The installer will
- take note of your manually installed packages
- erase system directories
- install the new system
- if internet is available install the extra packages noted earlier
- ask to reboot (and won’t touch any user files unless you formatted)
To perform this test you need a pre-installed system, eg. a prior Lubuntu install, which you’ll install over (or using the existing partition). You’ll want it to include some user files (they shouldn’t be touched, eg. I use music), and have at least one package you’ve added (to ensure something gets re-installed; eg. I use clementine as it’s my preferred music player so I can play my music as I perform post-install checks!)
Perform the install, reboot (checking any other OSes installed still boot as well) and check to make sure you have a fresh system (I usually jump to terminal & look at file/directory dates), but user files aren’t touched (ie. you have music to play), and your additional packages got installed (ie. you have clementine to play that music). If you have playlists on your box; clementine should continue where it last was before the install - ie. a successful test 
Note: I’m using clementine as example but it can be any package(s) found in
- Ubuntu repositories
- not included by default with a new Lubuntu install
eg. I usually use boxes where my terminals open with the machine name piped thru figlet (echo $HOSTNAME | figlet), and show a fortune piped through cowsay … ie. when I use CtrlAltT to open a terminal I get confirmation that multiple packages were re-installed + hopefully a good joke with just three keys, but again this is example only.
Non QA-test note: this type of install won’t fix any user config issues that exist, as none of that is touched. It’s useful in real life to fix package problems (corruption etc) generally as system directories get erased, then new packages installed. Because user files aren’t touched, any user config issue will remain even after this type of install.
Custom partitioning with separate /home: I’d hope pretty clear; two partitions at minimum are required here (sorry I’m not counting the ESP which is created & necessary if using a uEFI/GPT box so you may have 3 not 2; legacy boxes can be two only still) You use “Manual Partitioning” and need
- / partition
- /home partition
- /boot/efi (optional but maybe mandatory too)
Install, check any other OSes on your box boot, then checkout the new install.You don’t need to format the /home partition in this QA-test, just use one (but it’s far better if you use calamares to create both partitions - ie. make it a really useful test!). If you don’t format /home, on login your old system configuration should survive install but if you create a new partition (or format) you’ll have a new looking Lubuntu system. 
Custom partitioning on XFS/BTRFS: This is just a simple testcase where XFS or BTRFS are used for the / partition. The /home can be a separate partition, or the same and need not be file-system used by / if you don’t want it to be. No special options are used meaning it’s not a thorough testing that an enterprise would want before they’d use it for a server install. These install tests can also be performed using the drop-down (Erase Disk file-system choice) selection menu of calamares (if available) for both XFS or BTRFS, and post-install checks can use whatever tool you like, but blkid will show fs of partitions.
Some install cases that can be ticked off with another install: another language & auto-login.
Install using another language:: Much of the development team use english as their native language; so this is just an install using any non-english language. You can tick this category off at the same time as any other install type.
Auto-login after install: You’ll note there is an auto-login checkbox; this is another special case that should be linked with any other install, the only difference is the box should auto-login (meaning you won’t see the greeter/login page (ie. sddm); but if it’s encryption install - you still need to enter encryption keys of course)
For Lubuntu 24.04 LTS (& later) the optional install options of Element, Thunderbird, VM.Manager, or Krita can be included with another install type too, but please be aware you’ll need to be running a ‘with internet’ test to install element/thunderbird/vm.manager/krita, and a full install should already include all of these optional Element/Thunderbird/VM.Manager/Krita apps.
General advice:
If your box has multiple OSes installed; and they weren’t overwritten, they should continue to work after your install just as they did before you installed. To prevent data loss; it’s best if you use a test box for these installs; or if you use a system you do actually use; ensure you have great backups prior to starting any QA-test installs.
When QA-testing it’s easy to setup & do exactly what the testcase requires (esp. if we repeat the test a few times), however that’s not always what real people do. I often make mistakes (picking the wrong option for example, waiting a little simulating changing my mind) then correct the mistake, or what I believe real end-users would do in real life. You’re welcome to act as you believe a real user would (choosing experienced, beginner, hesitant - you create the user in your mind) do, but in my experience don’t push the installer too hard; it doesn’t seem to like ditherers and has its limits.
Additional testcases:
Here we get to the release-upgrade testcases (ie. not installs). You need a system to upgrade; it also needs to be of the correct release (eg. latest stable release)
TUI = textual user interface; ie. performed from a text interface, eg. CtrlAltF4 to switch away from a GUI and to a text interface. You’ll use the command
do-release-upgrade -d
(the -d option is necessary as the release is still in development)
GUI = graphical user interface; ie. LXQt for Lubuntu. This is performed via opening a virtual terminal (eg. CtrlAltT) and then executing the command
do-release-upgrade -d -m desktop -f DistUpgradeViewKDE
(The Qt5 interface just uses the name KDE; it’s not KDE specific)
The rows from “prior release” mean from say 21.04 to 21.10, where as the LTS to next LTS will mean 20.04 to 22.04.
We may change the LTS to LTS to be “from LTS” which would mean from 20.04 to 21.10 for example, but currently that’s not QA-tested by Lubuntu here
If you’re new to launchpad, testcases or making a one line summary of your machine, you may find some clues at the Lubuntu Impish Indri Beta Testing Week page. You’ll also find more on reporting bugs, and getting help from Lubuntu team members there too
If you have any questions, or need clarification on anything - please just ask