QA/SOP Release Validation Test Event

From FedoraProject

< QA(Difference between revisions)
Jump to: navigation, search
(Created page with '== Introduction == The QA group co-ordinates release validation test events before each Fedora release and pre-release is made, to ensure they reach Fedora_Release_Criteria. ...')
 
Line 56: Line 56:
  
 
[[Category:QA SOPs]]
 
[[Category:QA SOPs]]
[[Category:Install Test]]
 

Revision as of 08:31, 15 April 2010

Contents

Introduction

The QA group co-ordinates release validation test events before each Fedora release and pre-release is made, to ensure they reach Fedora_Release_Criteria. Testing covers installation process and desktop functionality. This page provides the guidance on arranging such a release validation test event. For any concerns, please contact the QA group.

Look up the date

The validation test event is held one or two weeks before the release date for any given milestone. See quality task schedule for specific dates as Test 'version' Test Compose or Test 'Version' Candidate. Then make the following preparations of that.

Create test result page

Test result pages are needed to gather test results of installation and desktop against Fedora Release Candidate builds. Refer to QA:Create_Install_Test_Result_Page for guidance to create an installation result page using QA:Fedora 22_Install_Results_Template. In a similar way, create a desktop result page using QA:Desktop_validation_results_template.

Please note that you can make some special changes to the result pages according to the practical situation, such as immigrating parts of previous results to the new result page, highlighting critical cases, adding important notes etc.

Change current links and IRC topic

One or two days before test event day, update the following redirect links and make sure they point to the pages you created:

Also change the topic of #fedora-qa (freenode) to current test event (if you have the permission).

Make announcement

Currently, we announce validation test events to the test-announce. The announcement mail should provide enough information related to the test focus areas. See an example which generally includes:

  • Introduction of this test event (date, what to test, which release criteria to meet, etc)
  • How and where to add test results
  • Contact information of QA members who are available on test event and can help testers who encounter problems.
  • Others to be emphasized.

Please announce this event on the mailing list at least one or two days in advance. This should give testers sufficient time to arrange their calendars and prepare a test environment. It is also a good idea to send a reminder e-mail the day before the test. Try to take timezones into account, to maximize convenience for testers from different regions or countries.

Provide help during test event

During the test event, many people will participate, including experienced users and new comers. Make sure the QA folks whose contact information was announced to mailing list in this test event are available during the testing period. They will provide assistance to those who encounter issues. QA people should be available at:

  • IRC: #fedora-qa on irc.freenode.net
  • Mailing list: test list
  • Reference of ways to communicate at Communicate

When new candidate available

If a new candidate is available for testing, such as TC2, TC3, RC3, you need send a new announcement for this, like the example and better to explain the differences/fixes between this version and the last one. Then create installation and desktop test result pages for it and repeat the above steps.

Report and Summary

After Test Compose or Release Candidate test event accomplished,give a report to all testers on test list, to let them know the status of this round of testing and what achievement has been made. A report such as the example at least includes:

  • Thanks to all testers.
  • Test status. A summary about what has been tested, what's remaining to accomplish, what issues were faced during test and whether we have achieved testing aim.
  • Reported bugs. List filed bugs and reported issues which were found during test. Bug list including bug id,bug status,bug summary,etc.
  • Some analysis to test result. Analyze the gathered results and mind testers what need further attention in the future.

The following command can help you generate a bug list of current installation test result matrix, and replace Installation to Desktop for a list of Desktop result.

curl "https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test" | grep -o "bugzilla\.redhat\.com.*[=\/][0-9]\{6\}" | sort -u | cut -d= -f 2 | tr '\n' ',' | sed 's|,$||' | xargs bugzilla query --outputformat="%{bug_id} %{bug_status} %{resolution} - %{short_desc}" -b

This command requires the Package-x-generic-16.pngpython-bugzilla package be installed. You may need to weed out any 'false' references to pre-existing bugs which are mentioned on the page for some reason. After you finish the report, please send it to the fedora test list.