From Fedora Project Wiki

(clarify some issues with the test)
Line 4: Line 4:
# 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, or release, or a 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. This should happen within half an hour of boot
# 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. This should happen within half an hour of boot
# 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 testing in the live environment, stop at this point; testing installation of updates in the live environment is not desired
# If you are testing a live image, reboot. If you are testing an installed system, either wait for more updates to become available, manually downgrade some packages so updates for them are again available, or re-install
# 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
# Wait for more updates to become available, manually downgrade some packages so updates for them are again available, or re-install
# Launch the graphical update application (e.g. system menu > System > Administration > Software Update). Run through the update process
# Launch the graphical update application (e.g. system menu > System > Administration > Software Update). Run through the update process
|results=
|results=
Line 12: Line 13:
# Both should check the appropriate repositories for the release when testing for updates, with no manual configuration required
# Both 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
# Both 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
# 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
}}
}}
[[Category:Desktop_Acceptance_Test_Cases]]
[[Category:Desktop_Acceptance_Test_Cases]]

Revision as of 21:02, 16 August 2010

Description

This test case tests whether yum and PackageKit can check for, offer, and install package updates.


How to test

  1. 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
  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. This should happen within half an hour of boot
  3. If testing in the live environment, stop at this point; testing installation of updates in the live environment is not desired
  4. Otherwise, open a console, and run the 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
  5. Wait for more updates to become available, manually downgrade some packages so updates for them are again available, or re-install
  6. Launch the graphical update application (e.g. system menu > System > Administration > Software Update). Run through the update process

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. Both CLI and graphical update applications should complete the update process with no errors
  3. Both should check the appropriate repositories for the release when testing for updates, with no manual configuration required
  4. Both should list the number and details of available updates and await confirmation before proceeding with the actual update process
  5. 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