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.
Track image creation tickets
Find relative image creation ticket from tickets list and add yourself to the cc. Then keep tracking this ticket until the images are available. If the images are not posted on time as scheduled or have a critical bug, please inform the rel-eng team about this by adding comments to the ticket.
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 42_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.
Download links should not be contained in the announcement, since in general there are several download options, and these are already documented on the Install and Desktop test pages. The announcement should direct people to go to these pages for download instructions.
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, and it is better to separate the bug lists by release (Alpha, Beta, Final) and into 'warn' and 'fail' groups.
- 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} - %{blocked}" -b
This command requires the 
python-bugzilla