What is a Lubuntu 'Live Session' test

What is a Lubuntu Live Session test?

The test case lists

Test-case Live Session Start

Boot up the image
Lubuntu boot screen is displayed
Select "Start Lubuntu" and wait for the Live session to start
The default desktop is displayed

Test-case Live Session Usage

Use and execute the default applications found for the desktop enviroment being run
All applications should function without error

A live test can consist of the following :

  1. Just boot the image, that tests it works for the hardware combination you’re using. Please remember to record a brief summary of your hardware in the comments section of the testing report on iso.qa.ubuntu.com

  2. What the actual test case mentions, “Use and execute” the default applications. In this case I just methodically go through all menus and open each program. Once opened I usually open the next one until I’ve opened all in that menu grouping (eg. all Accessories). If they execute I consider that a pass. I usually start my ‘all items’ on one box, get so far, note it in the comments, then close up test. Start another test on another box, and continue opening programs starting from where I got up to in the last test.

  3. Use the live session for normal tasks. This is a most useful test, as we all use different programs, and those programs in different ways to others. The test could go for as long as you’ve got available; a lunch time, to most of of a day. All testing is helpful.

Live tests don’t require installation, so can be used to test on many different boxes. I often do it on borrowed equipment. The only effect/problem I’ve encountered, is on some boxes the system clock gets switched to UTC/UST time, meaning the owner of the box may need to adjust their clock (if a windows user) if I forget to correct for it. I always warn the owners that it may occur, but it’s only an issue for some hardware I’ve found.

If you’ve got other ways you perform live tests, please reply in comments :slight_smile:

4 Likes

Is it possible to pin this or at least make it “sticky” so that people can see this when they visit the forum?

I mean it can be pinned, but why? I wouldn’t consider this the canonical place for documentation on testing.

Common tasks I perform in live testing

  • firefox; stream local news in window, maximized & using f11 & fullscreen on each display of box (I assume most users will do this on their machines sometime). This is often left running in the background as I work on my primary box… allowing a check that the screensaver will kick-in etc
  • drag windows around, maximize, minimize, tile & what I call general user play (we’ll all do this differently, but I treat it as if it were my main box at times, other tests do things I’d never do)
  • change look, appearance, openbox settings (more user type play) to something more like what I have, or more commonly something very unlike what I use, add or change panel etc
  • using the file manager (pcmanfm-qt) navigate to an installed user directory on the box, and open found files using installed apps (ie. txt, pdf, mp3, avi, odt, ods or whatever other files I find locally).
  • I also have a directory of test files that I open if it exists on the machine, it’s available on a network share (NFS so it requires nfs-common to be added, but I’ll scp it to the live session if I want but usually use whatever’s on the box). The files are just random assortment of txt, pdf, mp3, odt, mkv etc
  • create at terminal, or edit a text file that will be just text (CSV format for calc), which I can then ‘import’ into libreoffice calc/writer (if created in featherpad, I usually leave it open), if it imports correctly :slight_smile: so then I make changes & save that (to a new file), perusing later from terminal to ensure results are good (view contents, file etc responds appropriately…). The reason for leaving featherpad open, is if I re-write the changes featherpad gives a nice warning that the file contents have changed :slight_smile:
  • if laptop, connect charging cable & monitor for changes in panel icon, disconnect charging cable etc… Monitor the battery indicator during the test, looking for it to discharge/charge appropriately for that laptop (laptops will respond differently, as will batteries be they healthy/average/poor etc)
  • volume media keys work, switching workspaces, brightness keys work; these are mostly upstream kernel functions (not Lubuntu specific) but if they stop working on all boxes it maybe a specific Lubuntu issue
  • open muon & pick a random package, install & test it opens
  • open discover & pick a random package, install & test it opens/runs
  • I only run through all menu items occasionally, if I’m not doing that today I just select random apps and open. On these days I try and operate the app a little (if it’s libre office writer for example, type some text, make some characters bold, change fonts etc), save the file, then at terminal inspect the file is what I consider it should be (viewing contents, file etc), close & re-open app and have it re-open the file
  • on some boxes I suspend, (wait ~15 secs) & resume the live session, but many uEFI boxes don’t allow this, so you have to know your box will allow this to function before you use it.
    …

These are just a few examples.

it’s best if you have your own files, or even better, your own methods of testing; more appropriate to what you think a real user (ie. you) would do. We all use our systems differently, so your testing should reflect how you use a computer :slight_smile:

3 Likes