Good info for in case you find master copies or similar. ----------------------------------------------------------------- SCEA 3rd Party Test Procedure (Rev 1.5) NOTE: The software submitted to the 3rd Party Test Department must have been previously designed and tested by the Developer and -- to the best of their knowledge and ability --be free of bugs. If there are several (but not more) outstanding or known bugs, these must be documented by the developer -- with a description and intended action -- and submitted to SCEA as an attachment to the SCEA Submissions Checklist. Additionally, SCEA reserves the right to refuse the release of any product containing any class “A†or “B†bugs (including system and content standards) -- and potentially class “C†and “D†bugs -- if they are deemed to have a major impact on the success of the product. 1) The Submission Package is received by the 3rd Party Project Coordinator, who logs in the date and other appropriate information. The Submission Package consists of the following: a) 8 Sony Mastering CDs (available from SCEA) b) SCEA approved and provided checklist c) Test Report Response list (if re-submission) d) VHS video tape demonstrating all different aspects and features of the game e) Game text and manual f) ESRB Rating Form g) Memory Card with game cheats or written list of controller accessible cheats (this helps to expedite our checking process) h) Symbol List Display files created with Sony provided developer tools NOTE: Re-submissions require only the first 3 items (A, B, C), unless otherwise needed (because of changes, etc). 2) The CDs are then put through the following checking procedures by the Technical Coordinator: a) Master ID check. b) Memory Card Manager test (if applicable) c) Error Checker test d) Symbol List Display verification e) Copyright/Licensing verification 3) 5 CD’s are then given to the Test Department Manager, who assigns them to the Lead Analyst for the project. The 3 remaining Master CDs are kept by the Technical Corrdinator. NOTE: All testing and evaluation is videotaped. 4) The Lead Analyst and other team members will then check the software against a general checklist. This list is, if needed, modified for each title. Items on the checklist include: a) Hardware and Software Standard Requirements b) Software Content c) BIOS compatiblility d) Edurance testing e) Manual checked for grammer and accuracy. 5) The Lead Analyst fills out an evaluation form, which includes a scoring system for the game. This process will typically be performed by several other testers as well. If the game scores below a certain number, the game is pulled out of Test, and a Recommendations Report is completed. This report is given to the Account Coordinator and/or Account Executive, who delivers it to the Developer. If the title passes the evaluation, the game continues to step No. 6. 6) The Lead Analyst allocates different parts of the software to other project analysts, to check for product quality. We are not responsible for software bugs that exist, but if any bugs are found during this process, they will be entered into a Test Department database, and rated. If an excessive number of bugs are found, the game will be pulled out of Test, and a report stating this will be submitted to the Account Coordinator, who will pass it on to the developer. The Developer must then Test and De-Bug their game, and resubmit items A, B, and C of the Submission Package. 7) The Lead Analyst completes a Test report, based on a rating system that classifies problems into one of the following categories: a) A -- Fatal Bug: Any bug that debilitates gameplay enough to prevent the user from continuing, and requires a game reset, or PSX power cycle. Some examples would be a screen freeze, graphics disappearing from screen, turning it black, etc. We also classify Standard and Content violations as class A bugs b) B -- Major Bug: A problem that is obvious and/or important enough that it must be fixed. Such problems would typically negatively affect gameplay. An example would be a floor disappearing from under a game character. c) C -- Minor Bug: A problem that is noticeable, but has no real negative effect on gameplay. This type of bug should typically be fixed, as it will have an effect on the overall appearance of the game. An example would be a graphic glitch. d) D -- Comment/Suggestion: This is typically a suggested enhancement to the game, and can include both minor and major issues. Examples would be: changing the color of an item in the game, or introducing an entirely new level or concept to the game. The analysis report is then reviewed and edited (if needed) by the Test Department Manager, after which it is signed by the Lead Analyst, Test Department Manager, and Account Executive. 8) A hard copy of the report is then given to the Account Coordinator and/or Account Executive, who delivers it to the Developer. Developer Support also receives a copy of the report. 9) The 3rd Party Developer must fix all class “A†bugs. It is also suggested that as many of the class “B,†“C†and “D†bugs as is possible, be addressed to ensure a clean and quality oriented product. Additionally, the Developer must respond -- in written form -- to all Test Report items, listing what action has been taken and, if not, why? This Response Report must be submitted to the 3rd Party Project Coordinator for inclusion in our files, whether or not there is another submission. 10) If there is to be another Submission, the Developer is responsible for thoroughly testing the product before re-submission. 11) If any bugs exist (primarily, but not limited to, class “A†and “B†bugs) and the developer wishes to release the game in its current state -- even though SCEA advises against it -- they must sign an Accountability Form provided by SCEA. A decision will then be reached by SCEA, as to whether or not to continue with the Release Process. If SCEA elects not to continue, then the bugs and/or comments must be addressed by the Developer, and resolved to the satisfaction of SCEA.
