Create the Wiki page
This will be the central source of information regarding your Test Day: make sure it's complete, accurate and up to date at all times. Use this Test Day template as a base: copy and paste the source of that page and fill it in for your event. Your page should be given a name of the form Test_Day:(DATE)_(TOPIC) - e.g. Test_Day:2009-05-07_Virtualization . It should be in the Test Days category. You can add your event to the Test Day schedule for the appropriate release. Release Test Day schedules are linked to from the main Test Days page.
As a goal, your Wiki page should provide enough information that someone could perform all the testing and provide their results without any other reference or help.
Create test cases
A test case is simply a precise set of instructions which cause a reliably repeatable operation to occur which allows you to determine some kind of information from the results of the operation. There is a template to be used for creating test cases: if you visit that page, you will see a link which explains how to use this template to create a test case. You can see example test cases in the test case category page. When creating a test case, try to make sure the instructions are explicit enough that anyone who may want to participate in the test day can follow them, and entirely unambiguous so that the user cannot perform the test incorrectly. Don't cram multiple operations into a single test case: create separate test cases for each different operation you wish to test. If possible, try to create the Test Case in such a way that it will be re-usable in the future (ask yourself if someone running an edition of Fedora from five years after you write the test case would still be able to follow it), although this is not always possible.
Link to each of the test cases from the How to Test section of the Wiki page.
Consider a 'how to debug' page
A page describing how to debug the software being tested (if it's software) may be very useful to ensure that testers can file high-quality bug reports when they do encounter an issue. Instead of explaining the standard debugging steps for the software over and over again to every tester who hits a bug, you can simply direct them to the Wiki page, and it will be available for other situations too. Existing 'how to debug' pages that you can use as a template can be found in the.
Set up the results table
The basic format of the results table is a row for each tester (or test system), and columns for each test, along with a column for hardware information if appropriate and one for comments. It helps to provide an example row showing the format that should be used for filling in each column. It also helps to request that longer comments be added below the results table (or as separate pages) with a link from the table, to prevent the table from filling up with long comments and becoming difficult to read.