UploadWizard/Test plan

This is the test plan for the Extension:UploadWizard. Wikimedia Foundation is collaborating with Calcey to test this feature. See Extension:UploadWizard/WMF project information for more information.

Background information about MediaWiki uploads

• MediaWiki is the software that runs the sites of Wikimedia Foundation, such as Wikipedia and Wikimedia Commons. So:
  • Wikimedia Commons is a web site
  • MediaWiki is the software running that site
  • Wikimedia Foundation is the organization operating that site

• When a media file is uploaded to MediaWiki, several things are created.
  • The file is placed on a server, accessible over the web.
  • A wiki page ("article") is created for the file. All the meta information about this file goes into the article. This article title will always start with the special "File:" prefix, which will also be incorporated into the URL, such as http://somesite.org/wiki/File:Some_file.jpg.

• Thumbnails are generated on demand for a file, by invocation of a special URL specifying the width or other paramters.

• There are a number of pain points we have tried to address with MediaWiki. If we've done our job, it should be easy for you to avoid all the problems below.
  • In MediaWiki, files *must* have an appropriate extension, even in the title.
  • In MediaWiki, File titles, Article headlines, and URLs, are all based on the upload title. In some contexts underscores are swapped for spaces and vice versa.
    • So if you go to: http://somesite.org/wiki/File:Some_file.jpg, the article headline will be "Some file.jpg", and it will link to a file like http://somesite.org/images/a/ab/Some_file.jpg.
  • Because URLs are based on file names, uploaded filenames must be unique. You cannot upload two files both called "test.jpg". (UploadWizard gives the users a chance to fix this.)
  • MediaWiki also prefers not to allow you to upload two files with identical content. (This is usually an indication that the user is making a mistake; the user should instead revert a file).
  • Amazingly, you can't get around both the above filename restrictions by deleting old files, because MediaWiki actually stores all versions of all files, and stores a database of content signatures, forever.

Test files

Test files can be found:

• in this Flickr set: Golden Gate Bridge photos
• among recent uploads on Flickr under a free license (example)
• with google images, by selecting "advanced search" and selecting files that can be used commercially and modified (example)

Depending on whether or not we leave InstantCommons enabled, and how many files are needed, I can provide links to specific files.

URL

Please use http://commons.prototype.wikimedia.org/uwd/Special:UploadWizard .

Note this is slightly different from other URLs you might have already seen. Make sure the URL contains /uwd/.

Test plan

The test plan is broken down into three parts

• High priority tests - high-frequency tests
• Medium priority tests - at least once a cycle
• Low priority tests - tests that will be run only if there is extra time

High priority

These tests will be run very frequently. The total of all tests in this section should take an experienced engineer no more than a few hours to run. These tests are prime candidates for automation.

Smoke test: typical single file upload

1. Obtain a JPEG file that has never been uploaded to the wiki before
2. On Upload step, use the Upload Wizard to upload the file
3. On Release Rights step, accept the license default
4. On Details step, enter a description
5. Obtain File: URL from Use step, load the URL in a browser, and examine the page:
   1. Title should be as expected for image (note: underscores are translated to spaces)
   2. Should have an scaled image of the JPEG, appropriately sized for the page
   3. Should have file information representing description entered
   4. Should have template information representing the default license
6. Obtain direct link from Use step, and download the file
7. Ensure that it is identical to original uploaded file

Medium priority

These tests should be run at least once over the course of the release. They are still important, but are much lower priority for automation. It's helpful to provide an estimate for how long this section will take, but there's no strict upper bound on the amount of time this section should take other than the time available in the overall development schedule.

Upload File Type Validation

(Calcey id #1)

Reject file with identical content to a previous upload

1. Upload a file, say "file1.jpg", and complete the upload
2. Copy the file locally to a different name, say, "file2.jpg", and attempt to upload that
3. An error should be encountered an the "Upload" step once it has been fully received, and you should not be able to proceed to the next step with this upload.

Accept Common Image File Types

1. Upload file of type jpg, png, or gif

(Calcey id #1.2)

Bulk File Upload

1. Upload multiple files at the same time

(Calcey id #1.5)

Mixed Status Bulk Upload

1. Upload multiple files; some that should have expected problems, others that won't. Example; upload 2 JPGs and a ZIP archive which has a ".jpg" extension.
2. Upon upload completion, the ZIP archive should show an error, and drop out of the list of files
3. User should be allowed to proceed to the next step(s), but will only see the good uploads

Large File Upload

1. Upload a file larger than 20 MB (probably a video file, but could be a large JPG)

(Calcey id #1.6)

Set Release Rights

In general, it should be impossible to proceed to the next step without picking a license. (Calcey id #2)

My Own Work Settings

1. Signature should be prefilled with User's name.
2. Should be impossible to proceed without a satisfactory "signature".
3. Should be impossible to proceed without satisfactorily filling out Source and Author, or picking a license.

(Calcey id #2.1)

Not My Own Work Settings

1. Should be impossible to proceed without satisfactorily filling out Source and Author, or picking a license.

(Calcey id #2.2)

Describe File

(Calcey id #3)

Basic information

(Calcey id #3.1)

Attempt to advance without required information (description)

1. Upload a file
2. Advance to the "Describe" step
3. Attempt to advance to the next page without giving a proper description
4. Should not allow this to occur, and will show the missing field in red

Attempt to upload file with bad filename

1. Upload a file with a filename similar to autogenerated filenames from cameras, like DSC_123.jpg
2. The upload should succeed
3. Advance to the "Describe" step
4. The title should be pre-highlighted as being improper
5. It should be impossible to advance to the next step without fixing it
6. Once fixed, the error highlight and message should disappear immediately

Attempt to upload file with reused filename

1. Upload a file with a particular filename (pick randomly), and complete the upload
2. Attempt to upload a file with different content, but the same filename
3. Results should be similar to "upload with bad filename"; cannot advance until unique filename chosen

Use File

(Calcey id #4)

Access it externally through URL

1. Check that URL works
2. Check for properly-escaped URLs (files with non-ascii in their titles, for instance)

(Calcey id #4.1)

Insert as Wiki File

1. Create an article on the wiki you are testing, or just use your own User talk page
2. Edit the page
3. Insert the wikitext provided for the file
4. Save the article and see if the file renders properly, with appropriate caption and alignment.

(Calcey id #4.2)

Low priority

These tests are still documented, but are only run if time is available. A release should not be held if there isn't time to run these tests. This section will probably start off empty, with some medium priority tests moved down to this section as priorities are set.

Reject Zero-length file

1. Obtain a file of zero length
2. Upload
3. Error message should result; should not be able to proceed to the next step with this upload

Reject Invalid File extensions

1. Obtain a file of extension 'html', 'php', 'exe', or 'dll'
2. Upload
3. Error message should result; should not be able to proceed to the next step with this upload

(Calcey id #1.1)

Reject Invalid File mime type

1. Obtain a Zip archive file. Rename it to have the extension ".jpg"
2. Upload
3. Error message should result; should not be able to proceed to the next step with this upload

Reject file with type / extension mismatch

1. Obtain a file with an accepted extension, but whose content does not match the file. Example: a simple text file with the extension .jpg
2. Upload
3. Error message should result; should not be able to proceed to the next step with this upload

Accept Common Audio File Types

1. Upload file of type .oga (Ogg audio)
2. Note if any issues encountered, particularly thumbnailing or linking

(Calcey id #1.3)

Accept Common Video File Types

1. Upload file of type .ogv (Ogg video)
2. Note if any issues encountered, particularly thumbnailing or linking

(Calcey id #1.4)

Categories: adding prefilled

Many (but not all) categories have been already preloaded onto the test server (http://commons.prototype.wikimedia.org)

1. Typing into the "add category" field should give predictive-text suggestions
2. Pressing add should create a new category, visualized as text immediately above the "add category" field, with its own "remove" icon (an X)
3. Hovering over the category should highlight it and its removal-X
4. Clicking the category should open a Category page in a new window or tab
5. Pressing the X should remove the category

Categories: checking translation to wikitext

1. Whatever set of categories is eventually chosen, should be reflected in the final File: page.
   1. add no categories; check final result
   2. add one category
   3. attempt to add the same category twice (should fail)
   4. add several categories
   5. adding a bunch of categories, then removing all; check that none are in final result

Other information: text

1. In particular, test if it is possible to inject javascript or other badness via the Other information text.

(Calcey id #3.2)

Other information: date locale

1. Calendars and dates should be rendered according to user's locale and preferences, for example:
   1. If using a French locale, weeks in the calendar start with a Monday.
   2. If using a French locale, the date rendered after being selected is in appropriate French format.

Other information: date prefilled with current date

1. If file did not have EXIF information, the date field should default to the current date

Other information: date prefilled with EXIF

Pictures shot with modern digital cameras often have creation dates embedded in the metadata

1. Obtain a file with a known EXIF creation date (use exiv2 or online tools, such as Jeffrey's EXIF viewer to ensure this)
2. Upload file
3. Proceed to details step
4. Date should be prefilled to that EXIF creation date

Other information: dates in other eras

1. Should be possible to add dates from antiquity (1 CE) to the present day.

Other information: invalid date

1. Should be difficult, or impossible, to add an invalid date (e.g. 2010-02-31) without turning Javascript off