Test Procedures

This page covers the essentials of the testing procedures for both factes of development.

Implementation Testing
To the side of this page, found on Unity's tutorials, is a video that runs through the basics on testing in Unity. This includes unit testing, assertions and integration testing. These test facilities use visual components, to quickly test scripts without the need for additional script writing.

A basic rundown of the video guide follows:

Implementation Testing
Microsoft has provided tutorials on the testing of ASP.NET projects, all team members should follow these guidelines as they test their code.

Acceptance Testing
As this project is intended for assessment purposes only, it is of secondary importance to thoroughly test for user opinions. Instead, it is up to the joint decisions of team members to decide on the appropriateness of design decisions, as well as the supervisor to express their opinions on such choices.

At some instances during development, the team may elect to conduct surveys or questionairres with people not involved in the project, or involved with others, in order to decide on designs and game mechanics. It is important to note with such gathered information that people who are working on other projects (or with prior experience in our fields of development) will have different responses and criticisms to those that only understand how to use the products they are given (or not at all, if poorly designed).

Information gathered should therefore record details on:
 * Gender
 * Age
 * Area of Expertise / Occupation
 * Appraisals of product
 * Criticisms of product

Fun Factor and Game Balancing
Taking into account the opinions and observations of play-testers, developers may propose to the rest of the team a change to the game design or code, in order to improve the general 'enjoyability' of the game. This is not a formal process, as the developer will simply confer with the team to assess whether the team accepts these changes.

Test Logs
The implementation of all tests should be documented and stored appropriately, by following the organization of source code files. Testing procedures can be stored as a .txt file (or .doc if preferred by the team member) and are used to describe all tests written within the directory they are stored in

Put succinctly, each file that describes tests in the source code must be


 * titled 'Test_Description' (with file extension at the end, after "Description")
 * stored in the same folder as the files they describe.
 * follow the general structure depicted below.

Structure of Test Logs:

 * TEST PROCEDURES  Note: this is the title at the top of the file


 * 


 *   (Assertion, integrated or unit test)


 * 


 * 


 * 


 * Add new test type and description if more tests are in the same file




 * Add new file and test types and descriptions if there are more files with tests in the same directory