GIT NOTES.txt

GIT NOTES

Chapter 1 Software Testing

• Testing is the process of executing a program with the intent of finding errors.

• Software testing is a process where the software is evaluated to determine that it meets the user needs (validation) and that the process to build the software was followed correctly (verification).

Software Testing Cycle • Validation - You build the right thing • Verification - You built is right/properly

Main purpose of a tester • Find bugs • Replicate them • Report them • Verify that the bugs have been fixed • Make sure the game is fun

Why software testing is important? • No amount of testing eliminates all errors in the code. Testing is critical to make sure that the software has appropriate quality and works correctly.

Bad product causes • Potential customers delay purchase and look for alternatives • Business suffers financial loss and reputation

ISTQB(International Software Testing Qualifications Board)

Principle 1 - Testing shows presence of defects • Testing reduces the probability of undiscovered defects remaining in the software

Principle 2 - Exhaustive Testing is impossible • Testing everything is not feasible except for trivial cases. risk analysis and priorities should be used to focus testing efforts

Principle 3 - Early Testing • testing activities should be started as early as possible in the software or system development life cycle (SDLC)

Principle 4 - Defect clustering • Testing effort shall be focused proportionally to the expected and later observed defect density of modules.

Principle 5 - Pesticide Paradox • test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to find potentially more defects

Principle 6 - Testing is Context Dependent • Testing is done differently in different contexts

Principle 7- Absence of errors fallacy • Finding and fixing defects does not help if the system built is unstable and does not fulfil the user’s needs and expectations

Testing Rules • A necessary part of a test case is a definition of the expected output or result • A programmer should avoid attempting to test his or her own program • A programming organization should not test its own programs • Test cases must be written for input conditions that are invalid and unexpected, as well as for those that are valid and expected • Avoid throwaway test cases unless the program is truly a throwaway program • Do not plan a testing effort under the tacit assumption that no errors will be found • The probability of the existence of more errors in a section of a program is proportional to the number of errors already found in that section • Testing is an extremely creative and intellectually challenging task

Chapter 2 Types of Game Testing

Unit > Integration > System > Acceptance

Unit Testing • It is the execution of a complete class, routine or small program that has been written by a single programmer or team of programmers, which is tested in isolation from the more complete system • To test the smallest units or software components in a program • Tested individually and independent of each other • Each unit should work according to specifications • Done by the developer using development tools in his Integrated Development Environment

Advantages of Unit Testing

Provides confidence that a method behaves as expected
Serves as documentation for new people learning the code base (unit tests make for great teaching)
Forces you to write code in a testable way
Helps you isolate bugs faster and fix them quicker
Prevents future updates from adding new bugs to old working code (known as regression bugs)

Disadvantages of Unit Testing

Writing tests can take longer than writing the code itself
Bad or inaccurate tests create false confidence
Requires more knowledge to implement correctly
Important parts of the code base might not be easily testable
Some frameworks don’t easily allow private method testing, which can make unit testing harder
If tests are too fragile (fail too easily for the wrong reasons), maintenance can take a lot of time
Unit tests don’t catch integration errors
UI is hard to test
Inexperienced developers might waste time testing the wrong things
Sometimes, testing things with external or runtime dependencies can be very hard

Test Suite • A class file that holds unit tests • A test suite is where you logically divide your tests • A test suite houses all unit tests related to a logical grouping of functionality

Integration Testing • It is the combined execution of two or more classes, packages, components, or subsystems • Reveals interface problems as well as conflicts between integrated parts • Validates how modules of code work together • Top-down Integration - Top level components created first • Bottom-Up Integration - Low level components created first • Ad-Hoc Integration - Integrated in the order in which they are finished • Backbone Integration - Skeleton is built and components gradually integrate into it

System Testing • Execution of the software in its final configuration • Tests for security, performance, resource loss, timing problems that can't be tested at lower levels of integration • Checks if integrated product meets specified requirements • Tests system as a whole • Quality of the data used should be consistent, complete and up-to-date as possible

Acceptance Testing • Created during design phase and actual testing is done after system is fully developed and tested • To evaluate and validate that the system functionality meets the customer's requirements, standards and business needs. • Done by customer and end-users before they sign off and accept it • Beta Testing • Ensure the software meets the requirements

Non-Functional Categories of Testing • Stress Test • Load Test • Performance Test • Volume Test • Security Test • Stability Test • Robustness Test • Compatibility Test • Configuration • Usability Test • Documentation Checks • Maintainability Checks

Static Testing

Code Inspection(Static Testing) • 4 People(Moderators) • Avoid outside interruptions • Optimal duration 90 to 120 minutes • Egoless and positive results should be confidential Benefits

Programmer gets feedback
Other participants gain by being exposed to programmer’s errors and programming style
Identifies most error-prone sections of program

Walkthrough(Static Testing) • Uninterrupted meeting (1-2 hours) • Participants simulate how a computer would execute the code. • 3-5 People(Moderator, Secretary, Tester, Programmer) • Comments about program • Most errors found during questioning instead of test cases

Desk Checking(Static Testing) • 1 Person • Reads programs, checks with an error list and walks test data through it • Done by anyone except the programmer

Peer Ratings(Static Testing) • Code reading • Evaluate anonymous programs in terms of overall quality, maintainability, extensibility, usability and clarity • Provides programmer self-evaluation • 6-20 participants of similar background • Each program randomly distributed

Black Box Testing • Test from the user's perspective • Test the system against external factors responsible for software failures • Focuses on the input that goes into the software and the output that is produced • Does not cover details such as code, server logic and development method • Based on the requirements and checks the system to validate against predefined requirements • Usability Issues, Performance, abrupt application failure and response time of the system

White Box Testing • Exercise the source code directly • Extremely difficult • Performed before submitting new code • Testing code modules that will become part of a reusable library • Essential parts of middleware or a game engine product

Regression Testing • One or more units of work that once worked • Rerun your tests to make sure the previous units of work still works

Load Testing • Test heavy activity and whether the application is able to function properly under load

Multiplayer Testing • Find out whether all connectivity methods work

Mobile Game Testing • Testing for Apk(Android) and Ipa(Ios)

Chapter 3 Game Debugging

Low Priority Bug > Medium Priority Bug > High Priority Bug > Critical Bug

• Track reported software bugs in game development projects • Bug tracking systems are integrated with other project management software

Low Priority Bug • Hardly matter and makes no difference whether they are fixed or not

Medium Priority Bug • Should be fixed as it annoys the player but not affect gameplay

High Priority Bug • Must be fixed as they seriously affect gameplay • A game that ships with high bugs is a bad game or has been rushed to the market

Critical Bug • Very special bugs that demands immediate attention which can cause crashes, freezes and data corruption • Must be fixed at all costs and game is sent back to developer if spotted by publisher

Bug Categories • Visual • Audio • Level design - Badly constructed game level • Artificial intelligence - pathfinding and npc behaviour • Physics • Stability - Predictability of the code • Performance - Speed with which the hardware processes the code • Networking - Server-client connectivity and bandwidth issues • Compatibility - Relate to how a game runs on certain hardware

Ideal Testing tool • Issue tracking • Wiki • Forum

Bug reporting system status • Open • Assigned • Resolved • Verified • Closed

Quality Assurance Teams • Producer - Oversees the game after months of development • QA Manager - Assesses the situation and considers how to plan • Lead Tester • Floor Lead - Unofficial leader tester

Chapter 4 Source Code Management

Version Control System • Records changes to a file or set of files over time • Keep every version of an image or layout • Allows you to revert selected files or the entire project back to a previous state

Benefits of Version Control System

Backup and Restore
Sync with multiple computers
Working in a team
Safely create and test new features
Ownership / Credits / Blame

VCS Terminologies • Repository - Database where files are stored • Server - The computer storing the repository • Client - The computer connecting to the repository • Working copy -Your local directory of files • Trunk/Main - Master location for code in the repository • Head - The latest revision in the repository • Add - Place a file under version control • Check in - Send local changes to repo • Check out - Download from a repo to your working copy • Ignore - Allows files to exist in your working copy but not in the repo • Revert - Throw away your working copy and restore last revision • Update/Sync - Update your working copy to the latest revision • Diff / Change - Specific modification to a document • Branch - Duplicate copy of code used for feature development • Merge - Integrate changes from two different branches • Conflict - Inability to reconcile changes to a document • Resolve - Manual fixing of conflicted document changes • Locking - Prevents other developers from making changes

Local Version Control System • A simple database that keeps all changes to files

Centralised Version Control System • Need to collaborate with developers • A single server that contains all the versioned files • Everyone can check what everyone else on the project is doing to a certain • Administrators have fine-grained control • Lose everything if the central database on the hard disk becomes corrupted

Distributed Version Control System • Fully mirror the repository including its full history • If any server dies, any of the client repositories can be copied back up to the server to restore it • Every clone is a full backup • Deal well with having several remote repositories • Allows several types of workflow setups

GITHUB • Modified - Changed the file but have not committed to database yet • Staged - Marked a modified file in its current version into your next commit snapshot • Committed - Data is safely stored in your database

Unity Version Control System

Perforce VCS vs Plastic SCM • Perforce Supports remote activity but PlasticSCM does not

Chapter 5 Test Plan

• A document describing the software testing scope, approach, resources and schedule of intended test activities • Product Description • Software Requirement Specification (SRS) • Use Case Documents • What to test • How to test • When to test • Who to test

Components of a Test Plan Document • Test plan Identifier - Provide a unique identifier for document • Introduction - Provide an overview of the test plan, specify the goals/objectives and specify any constraints • References - List the related documents with the links, project plans • Test Items - Software products and their versions • Features to be tested - List the features of the software to be tested • Features not to be tested - List the features of the software not to be tested • Item pass/fail criteria - Specify the criteria that will be used to determine whether each test item has passed or failed testing • Test Deliverables - Test plan, Test cases, Test Scripts Defect/ Enhancement logs and Test report • Test Environment - Specify the properties of test environment: hardware, software, network and list any testing and related tools • Estimate - summary of test estimates and provides a link to the detailed estimation • Schedule - summary of the schedule, specifying key test milestones, and provide link to the detailed schedule • Staffing and Training needs - Role and required skills • Responsibilities: Team, role and individual • Risks: List the risk that have been identified • Approvals: Specify the names and roles of all persons who must approve the plan

Test Case • A set of conditions or variables under which a tester will determine whether a system under test satisfies requirements or works correctly

Good Test Case • Detects an as yet undiscovered error • Shows that a program does not do what it was designed to do • An unsuccessful test case is one that causes a program to produce the correct result without finding any errors

Characteristics of a good test case • Only test one thing in a test case • Should have an exact and accurate purpose • Should be written in a clear and easy to understand language • Should be relatively small • Should be independent • Should not have unnecessary steps or words • Should be traceable to requirements or design • Should be repeatable • Use consistent terminology and identification of functionality

Test Case Generation • Normal - Typical Input • Extreme - Empty Arrays • Nulls - Negative Numbers, characters • Strange - Reverse Sorted Arrays, Already Sorted Arrays

Chapter 6 Game Testing Disciplines

Balance Testing • Ensures that gameplay is fair to both human and AI player alike • Multiplayer games need to be balanced or all matches will be skewed

Compatibility Testing • Game is tested with different hardware configurations • Game is full compatible with parts and peripherals found on the market • Need to be proficient in PC assembly and troubleshooting

Soaking • A sub-discipline of testing, leaving the console or computer running for extended periods of time • It is necessary when memory leaks or rounding errors might hurt the game stability in the long run

Compliance Testing • Game has to go through certification before being sold on the market and is conducted by hardware developers • PEGI (Pan European Game Information) • ESRB (Entertainment Software Rating Board)

Localisation Testing • Involves converting a game from one region to another • Translation mistakes are a bad sign for a foreign game

Play Testing • Involves going over all possible varieties of play and making sure all of them are fun • Watch for gameplay mechanics

Chapter 7 Playability Test

• To provide feedback to allow us to improve the product for the players who will play this game • It is the degree to which a game is fun to play and usable, with an emphasis on the interaction style and plot-quality of the game and gameplay • It is affected by the quality of the storyline, responsiveness, pace, usability, customizability, control, intensity of interaction, intricacy, and strategy, as well as the degree of realism and the quality of graphics and sound • Includes the usability test • Starts during the design phase. The designer would design the interfaces with some mock-up screenshots and have it reviewed and approved by others

Usability Test • Process of observing user's reactions to a product and adjusting the design to suit their needs • Gameplay mechanisms need to make sense and be easy to use

Purpose of Playability Testing • Identify issues with the layout and errors • Identify broken links • Evaluate the content • Check user reaction • Includes the actual testing and also the collection and analysis of the data to improve the quality of the game

Evaluators • Age • Experience • Gender • Education • Prior Training • Technical Expertise

Mock-up/Prototype • Used to allow clicking, inputting of data, moving between screens to get a feel of how the game would work • Verify that the interfaces are working as designed and comfortable and intuitive to the user once functionality is completed and stable • Checklist - Items to test based on requirements and standard ease of use criteria • Survey - Questionnaires with a rating for different aspects of interaction and usability • Scenario - Testing tasks to test the typical interaction of user with the game

Evaluating player enjoyment in games • Concentration • Challenge Player Skills • Control • Clear goals • Feedback • Immersion • Social Interaction

Hueristics to evaluate the playability of games • Gameplay • Game Story • Game Mechanics • Game Usability

Types of Playability Test • Functional Playability - Ability to explicitly attempt to do something in the game • Structural Playability - Measure of if the gameplay is sufficiently demanding to engage • Sensory Playability - Information presentation and availability • Social Playability - Measure of how well the gameplay facilitates a certain type of social interaction practice

Goal or Task(Levels of Complexity) • Give as much information as needed for the tester and provide task descriptions without steps

Detailed Scenario(Levels of Complexity) • Describes the user characteristics that the user interface should be designed for

Full Scale Scenario • Has exact steps to acommplish the task that needs to be followed and tested

When conducting a playability Test • Keep the users as comfortable as possible and put them at ease so that they remain objective • Eliminate stress from the environment so that they can concentrate on using your game • Separate your observers from the test subjects • Legal rights and permission to use any materials gathered during the study for presentations and reports • Confidentiality. (Often a Non-Disclosure Agreement needs to be signed by the users)

Alpha testing • Find defects before the code is released to key customers during the beta test or general population • Ensure that majority of the most common tasks and scenarios work well

Beta Testing • Closed Beta - Selected group of customers, company works closely with them during the test • Open Beta - Software is available on request