Check back soon
Once posts are published, you’ll see them here.
Combinatorial Testing also known as pair-wise testing.
It is used to eliminate unnecessary testing from being done saving time. It is an efficient method to testing bugs that clash with each other. It is carried out by testing all the different combinations of multiple assets.
Each part is tested with every other combination to ensure none of the parts will bug out with each other. For example if you have multiple assets.
You write out the tests done, so you can see which tests have already been done. Therefore the tests don’t have to be repeated on similar parts.
For example if you cut a cake into 10 slices, and taste one slice, why would the other 9 slices taste the same.
If you are testing how a grenade works in a game you only need to test if it works in one level as there is no reason it won’t work in any other level.
Test Flow Diagram
It is a graphical model displaying the behaviours from the players perspective, breaks the games action into a visual chart.
It is a long winded way to test that states step by step on what happened and as every new part is tested it is added to the Test flow diagram if I bug is found the test flow diagram is stopped and it shows where the problem is, it must be fixed then continued. For example: Pokémon, Enter arena, begin battle, bring health to red, throw poke ball, and catch Pokémon.
Smoke testing:
Smoke testing (also referred to as sanity testing) is a testing period that is design to outline simple but severe issues with the game which could prevent the title from releasing on time. Examples of smoke tests could include basic operations such as “Does the game run” and “Do interaction elements work?” If smoke tests are performed on specific versions of the game, it is also recognised as a build verification test.
White box testing:
White box testing (also referred to as Structural testing) is the testing period which will assess the interior workings of the game (source code). By doing this, testers are able to create and error-free environment after investigation.
Black box testing:
Black box testing is where testers will examine the functionality of the title. This process primarily consists of checking that specific outputs are produced from inputs. Unlike white box testing, the tester does not require a strong knowledge of code as they do not need to know how the software works. Whilst testing, the tester will have a list of inputs to check in order to achieve the ideal outcome that is also listed.
Clean room testing:
Clean room testing is a test phase which is carried out to stabilise the software. This particular test is not designed to remove bugs but rather to stop the bugs from originally occurring. In this phase, testers will be provided with particular parameters in which predictions must be recreated in.
Play testing:
Play testing (also known as QA testing) is a software testing process in which the primary objective is to find and repot issues with the title (bugs). This section of testing will begin as early as when the base code is in place and will escalate as development continues. In some cases such as beta testing, members of the public may be invited to test the pre-release builds of the game in order to obtain opinions from external sources. This is particularly popular with multiplayer games such as ‘Call of Duty’ and ‘The Division’.
Ad hoc testing:
Ad hoc testing is a term used for informal software testing which is executed with no documentation or preparation.
Minor patch:
A minor patch is slight alterations to the current game version. This is similar to a “hotfix” however a minor patch must be downloaded and is supplied with patch notes. An example of a minor patch would be an increase or decrease in the damage a weapon deals.
Major patch:
A major patch is significant amendments to the game. In addition to the content of a minor patch, a major patch typically supplies players with new features. For example, a First person shooter game may introduce new weapons or game modes for players to try out.
Alpha testing
Alpha testing is important to maintain the games stability. Games that are in the alpha phase of development essentially means that it is in extremely early stages, and isn’t anywhere close to being released as a final product. The game still needs to be tested at this stage in the development cycle. This can be done by hiring alpha testers. Alpha video games testers are more important than beta testers in the video game testing industry. They are more involved in the video game testing and of course they get paid much more.
Since alpha testers cost a lot more than beta testers, high budget development companies can afford the alpha testers. This ensures a high quality product because if they released the game ridden with bugs and glitches, it could cost them millions.
Internal beta testing
Internal beta testing is essentially any beta testing that is done by the development company themselves. This doesn’t require them to pay out large sums of money to hire beta testers. This is usually done by smaller companies that don’t have big budgets to spend on developing the game, this includes spending large amounts of money on beta testers.
External beta testing
External beta testing offers the developers a glimpse at how users will actually interact with their game once it is released. Copies of the game get distrusted among these externally sourced beta testers. If the game is sent out, and not played in the development companies studio. Then there will be instructions sent with it. Sometimes there will be questions that the beta testers are given to answer about the game.
Gold testing
Gold testing is where the game is fully tested and has been released to the public, the players now have full access to the game. Although the game has been finished, there are a lot of chances where the player may find defects or even game breaking bugs. At these times, the developers have to release patches of hotfixes to fix them. A good example of this is Battlefield 4. This game was known for its huge game breaking bugs at launch, these were fixed soon after the game was released and is now perfectly playable.
End of certification
End of certification is essentially the same as “Gold testing”
Entry Criteria
Entry criteria is the minimum eligibility or alternatively, the minimum set of conditions that should be met to start the testing work. Entry criteria are documented and noted during the test / planning phase and is then included in the test plans.
Placeholder assets
Very high poly models or detailed assets can take long amounts of time to develop. This, coupled with the fact that there are extreme time constraints when it comes to developing game in this day and age means that placeholder assets are used to generate a rough understanding of the environments layout and structure before the time consuming assets are created. Some developers even say that using placeholder assets cuts the level design stage of production in half.
Regression
When a developer puts a script into a game and then test out the script to see if it runs and if it causes any problems to the game.
Plan and Design Test
Before planning a test, the development team has to review the purpose and requirements of the specific part of a title being tests. Once the base idea of what needs to be tested has been gathered the planning for the test(s) can begin.
This is managed by using a “test plan”. Test plans include the following:
Introduction: Highlights the objectives of the test.
Test items: The “items” being tested
Features to be tested: The list of all features to be tested as well as highlighting the base requirements that need to be incorporated as per the design team.
Approach: What type of testing will be initiated?
Pass/Fail Criteria: The boundaries that define if the test has been successful (everything works fine) or fail (something does not work as intended)
Prepare Test and Perform Test
Sets up the test environment as documented within the “test plan”
The test should be done thoroughly, and strictly abiding by the information and agreed plan of action highlighted within the “test plan”. Any uncovered bugs are duly documented. Often referred to as a “big report”
Report test and re-testing
Upon completion of the proposed testing period and testing team compile a dossier containing all of the key information gathered throughout execution. This highlights any bugs found, the process done to remove bugs as well as noticing any others that are caused due to fixing this bug will go through testing as well. Any bugs found will be reported including what contingency was used to fix it. Upon completion of the testing process and upon providing feedback the testing phase is then repeated to verify the information contained inside the report.