[[BackLinksMenu]]

[[TicketQuery(summary=PLATFORM_STANDARDS_MANUAL_TESTS_R2, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|)]]

= Analysis =

== Overview ==
Since testing is started, clear standards should be put.
== Task requirements ==
Update PLATFORM_STANDARDS_MANUAL_TESTS
 * Create PLATFORM_STANDARDS_MANUAL_TESTS/Bugs and link it here, in PLATFORM_STANDARDS_MANUAL_TESTS in Important docs and in [report:32] description
 * Describe bug reporting. Correct PLATFORM_STANDARDS_ANALYSIS#BugFix section 
 * Describe the whole bug fixing process
Create a zip in the repository with all of the supported frame contents for manual and auto tests. 
 * Supported image files
 * Supported audio files
 * Supported video files
 * HTML files
 * PDF
 * Script
 * Create a book with all resources (embedded book too) and add it to the zip for embedding.
 * All of these with exotic filenames. See http://en.wikipedia.org/wiki/Filename#Comparison_of_file_name_limitations
 * Discuss where to put this in the repository (in Design section)
 * Link the zip in the integration page [wiki:Integration]
== Task result ==
 * Wiki page linked where needed
 * Zip with resources
== Implementation idea ==
See bugs page. Discuss with integrators

== Related ==
PLATFORM_STANDARDS_MANUAL_TESTS all revisions

== How to demo ==
Show the new standards and the zip. Explain what is zipped.

= Design =
[attachment:TestResources.zip] contains files that are currently supported. [[BR]]
[attachment:TestResourcesSpaces.zip] contains the same files, but renamed to have spaces in filenames. This is related to some issues with spaces in filenames of audio and video files.

Skeleton of PLATFORM_STANDARDS_MANUAL_TESTS/Bugs
Bugs are described and fixed in tickets
 * Analysis of bugs: Reporting an issue is the analysis of the bug
  * Summary: 
   * ''May start with "Crash:", "Tweak", "Unexpected behavior:". Crash means that the report form is evoked. Error report is needed as an attachment''
   * ''"TLID:" testlink id, if the bug can be reproduced by executing a testcase''
   * Short summary, custom text, what exactly happens in few words
  * Type: bug
  * Priority: determine the priority of the bug.
  * ''Keywords - fill in related keywords, for example "text"''
  * ''Components - fill in component if you can determine the component''
  * reporter: devid , automatically added by trac
  * Milestone - current milestone
  * ''cc: a reminder to someone''
  * Analysis_owners: your devid
  * Description: contains more detailed description and steps to recreate in order to reproduce the bug.
  * ''Attachments: you may add attachments to your ticket (screenshots, crash logs, books) reffering to an attachment named "filename.ext" is done by ![attachment:filename.ext]'' 
When you create the ticket, move it's status to analysis finished.
 * Design
  * Design can be described in a comment of the ticket. If the space isn't enough (the fix is not trivial), the designer may create a wiki page named BUG_<number> to put his design section there. This page should be linked in the description field of the ticket. Bug pages are created using bug page template. When design is finished, the status should be updated and implementation may start without a design review. Same goes for the implementstion.
 * Implementation: Implementation changeset should be linked. The ticket status is moved to implementation finished.
 * Test: Test is performed by the reporter. If the bug is not present, the ticket is closed. 

Reviews and resolutions:
 * Analysis
  * The description describes the problem and the bug can be reproduced by following the instructions there - 3p
  * The ticket contains crash report +0.5p
  * The ticket contains attached books, screenshots, etc +0.5p (+1p)
  * The ticket contains linked test case +1p
  * The ticket contains links to related bugs, tasks, external links +0.5p
Design and implementation are usually reviewed at once
 * Design
  * Explanation how it will be fixed
   * Methods
   * New classes if needed
  * What caused that issue?
 * Implementation 
  * Lame implementation (bad code) and hacks are not allowed 
  * Should follow the design
 * Test

= Implementation =
^(Describe and link the implementation results here (from the wiki or the repository).)^

= Testing =
^(Place the testing results here.)^

= Comments =
^(Write comments for this or later revisions here.)