From Fedora Project Wiki
(Created page with "{{Template:Associated_release_criterion|Alpha|updates}} {{Template:Associated_release_criterion|Beta|updates}} {{Template:Associated_release_criterion|Beta|update-notification...")
 
(drop from category membership, this is a personal draft page)
 
(3 intermediate revisions by one other user not shown)
Line 4: Line 4:


{{QA/Test_Case
{{QA/Test_Case
|description=This test case tests whether yum and PackageKit can check for, offer, and install package updates. Note: if doing desktop validation testing, the results for this test case are split into two in the table. One entry, at Alpha stage, is for the ability to perform updates: the parts of this test case which test whether you can in fact install updates relate to this entry. The other, at Beta stage, is for update notification: the parts of this test case which test whether the desktop notifies you of available updates relate to this entry. Please put pass, warn or fail notes in the appropriate entry for the parts of the test case in question.
|description=This test case tests whether PackageKit can check for, offer, and install package updates. Note: if doing desktop validation testing, the results for this test case are split into two in the table. One entry, at Alpha stage, is for the ability to perform updates: the parts of this test case which test whether you can in fact install updates relate to this entry. The other, at Beta stage, is for update notification: the parts of this test case which test whether the desktop notifies you of available updates relate to this entry. Please put pass, warn or fail notes in the appropriate entry for the parts of the test case in question.
|actions=
|actions=
# Clean boot the Fedora you wish to test: this could be a system installed from a particular snapshot, pre-release, or release, or a live image. It should be an image for which updates will be available
# Clean boot the Fedora you wish to test: this could be a system installed from a particular snapshot, pre-release, release or live image. It should be an image for which updates will be available.
# Check whether the system checks for updates, notifies you of their availability, and offers to install them. You can do this simply by waiting while observing whether the 'checking for updates' and then 'updates available' icons appear in the notification area. To ensure this happens in a reasonable amount of time, see the tip below
# Check whether the system checks for updates, notifies you of their availability, and offers to install them. You can do this simply by waiting while observing whether the 'checking for updates' and then 'updates available' icons appear in the notification area. To ensure this happens in a reasonable amount of time, see the tip below
# If testing in the live environment, stop at this point; testing installation of updates in the live environment is not desired
# If testing in the live environment, stop at this point; testing installation of updates in the live environment is not desired
# Otherwise, open a console, and run the command {{command|yum update}} as root. If you have any difficulty opening a console in the normal fashion from the desktop you are testing, note this, but continue with the test. Complete the update process. If you encounter dependency problems, ensure a bug is reported for the issue, and try again with the --skip-broken parameter
# Launch the software installation application (e.g. Activities Overview -> Software). Switch to the updates page and run through the update process.
# Wait for more updates to become available, manually downgrade some packages so updates for them are again available, or re-install
# Wait for more updates to become available, manually downgrade some packages so updates for them are again available, or re-install
# Launch the software installation application (e.g. Activities Overview -> Software). Switch to the updates page and run through the update process.
{{admon/tip|Tip for shortening the waiting time to the updates notification|You can run the following commands to shorten the waiting time:  
{{admon/tip|Tip for shortening the waiting time to the updates notification|You can run the following commands to shorten the waiting time:  
<pre>
<pre>
Line 21: Line 20:
|results=
|results=
# When booted live, updates should not be actively offered to the user. When booting an installed system, available updates should be offered to the user
# When booted live, updates should not be actively offered to the user. When booting an installed system, available updates should be offered to the user
# Both CLI and graphical update applications should complete the update process with no errors
# Graphical update applications should complete the update process with no errors
# Both should check the appropriate repositories for the release when testing for updates, with no manual configuration required
# Graphical update applications should check the appropriate repositories for the release when testing for updates, with no manual configuration required
# Both should list the number and details of available updates and await confirmation before proceeding with the actual update process
# Graphical update applications should list the number and details of available updates and await confirmation before proceeding with the actual update process
# Both should correctly install all available updates when you confirm that you wish to do so. Note that a failure caused by problems with the packages in the repositories, rather than yum or PackageKit misbehaving, should be reported against the offending package(s) and considered a 'warn', rather than 'fail', if you are performing desktop validation testing
# Graphical update applications should correctly install all available updates when you confirm that you wish to do so. Note that a failure caused by problems with the packages in the repositories, rather than yum or PackageKit misbehaving, should be reported against the offending package(s) and considered a 'warn', rather than 'fail', if you are performing desktop validation testing
}}
}}
[[Category:Desktop_Acceptance_Test_Cases]]

Latest revision as of 16:53, 12 May 2022

Associated release criterion
This test case is associated with the Basic_Release_Criteria#updates release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion. If so, please file a bug and nominate it as blocking the appropriate milestone, using the blocker bug nomination page.
Associated release criterion
This test case is associated with the Fedora_42_Beta_Release_Criteria#updates release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion. If so, please file a bug and nominate it as blocking the appropriate milestone, using the blocker bug nomination page.
Associated release criterion
This test case is associated with the Fedora_42_Beta_Release_Criteria#update-notification release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion. If so, please file a bug and nominate it as blocking the appropriate milestone, using the blocker bug nomination page.


Description

This test case tests whether PackageKit can check for, offer, and install package updates. Note: if doing desktop validation testing, the results for this test case are split into two in the table. One entry, at Alpha stage, is for the ability to perform updates: the parts of this test case which test whether you can in fact install updates relate to this entry. The other, at Beta stage, is for update notification: the parts of this test case which test whether the desktop notifies you of available updates relate to this entry. Please put pass, warn or fail notes in the appropriate entry for the parts of the test case in question.


How to test

  1. Clean boot the Fedora you wish to test: this could be a system installed from a particular snapshot, pre-release, release or live image. It should be an image for which updates will be available.
  2. Check whether the system checks for updates, notifies you of their availability, and offers to install them. You can do this simply by waiting while observing whether the 'checking for updates' and then 'updates available' icons appear in the notification area. To ensure this happens in a reasonable amount of time, see the tip below
  3. If testing in the live environment, stop at this point; testing installation of updates in the live environment is not desired
  4. Launch the software installation application (e.g. Activities Overview -> Software). Switch to the updates page and run through the update process.
  5. Wait for more updates to become available, manually downgrade some packages so updates for them are again available, or re-install
Tip for shortening the waiting time to the updates notification
You can run the following commands to shorten the waiting time: 
$ gsettings set org.gnome.software check-timestamp $(date '+%s' --date='18:00 yesterday')
$ gsettings set org.gnome.software install-timestamp $(date '+%s' --date='08:00 week ago')
$ sudo touch --no-create --date='08:00 week ago' /var/lib/PackageKit/offline-update-competed
You should reboot or log out and back in after changing these settings. The notification should now appear within ten minutes, but it's best to give it a bit longer to be sure.

Expected Results

  1. When booted live, updates should not be actively offered to the user. When booting an installed system, available updates should be offered to the user
  2. Graphical update applications should complete the update process with no errors
  3. Graphical update applications should check the appropriate repositories for the release when testing for updates, with no manual configuration required
  4. Graphical update applications should list the number and details of available updates and await confirmation before proceeding with the actual update process
  5. Graphical update applications should correctly install all available updates when you confirm that you wish to do so. Note that a failure caused by problems with the packages in the repositories, rather than yum or PackageKit misbehaving, should be reported against the offending package(s) and considered a 'warn', rather than 'fail', if you are performing desktop validation testing



Retrieved from "https://fedoraproject.org/w/index.php?title=User:Roshi/QA/Testcase_Desktop_updates&oldid=644223"