testinganswers.com - One of the most popular software testing blog with best testing tutorials and interview questions. Latest and complete information on manual testing methodologies, automation testing tools and bug tracking tools.

To be a game tester, you need to be an avid game player. But playing games is not enough, you need to have a flair for finding problems. A computer game is further complex than a usual software application. Mostly games are made up of collection of essential components like rendering engine, database, animations, sounds, special effects etc.

The process and techniques that are normally used for software testing will also be functional for Game Testing e.g. Code Inspection, Path and Flow testing, Incremental Focus Testing etc.

You have to examine each and every part of the game. For example

1. The tester must search and explore the game as much as possible.

2. Menus in the game and their functions.

3. Sounds and the sound effects in the game e.g. music, lip sync and sound in conjunction with animation sequence.

4. Logic of the game and game flow.

5. Objects in the game - terrain, world, texture etc.

6. Frame rate of the animation etc.

7. Scoring in the game.

8. Camera view, Zoom in, Zoom out, replay etc.

9. Attributes of a player, attributes of an action.

10. Different conditions to advance/move to the next level.

11. Any titles or text or fonts in the game scenes, spelling mistakes, legal text etc.

12. Game pause and different options related to it, hints in the game, any easter eggs.

13. Scrolling in the game.

14. Any movie clips in the game etc.

15. Different levels - with increased levels of difficulty.

16. Artificial Intelligence logic (if any).

17. Player movement, positioning.

18. Ease of use.

19. Any special effects.

20. Any other objects in the game - each object separately and how one object interacts with other.

21. Stopping and closing a game at certain level and opening the game at the same place you left it.

22. Test for platform compatibility (if any).

23. Loading time for the game under different scenarios.

24. Test for localization.

25. Networking should be tested thoroughly.

"Black Box" focuses on the functional characteristic of the game e.g. testing the UI – graphics, animations, overall look and feel, and the actual playing part.

"White Box" focuses on the architecture and integration characteristic of the game e.g. the use of a database, tests performed by developers prior to submitting new code for integration with the rest of the game, and so on.

Along with the positive scenarios, negative scenarios in game testing should not be ignored e.g. loading a game with less than required memory etc.

Things to keep in mind while testing games:

- You MUST be familiar with the game rules and then try to test the game against these rules.

- You should always try to check that the game should not crash or freeze in case of minor pauses or the characters should not move out of the bounds at any stage.

Your primary responsibilities as a tester will include bug testing and reporting, game balance and game feature testing. Game testing is fun, but it can be demanding. You'll perform traditional feature testing using testing methodologies that you'll learn on the job, and you'll assist the design team in identifying imbalances in game play. You will be an expert on the game and be able to notice any deviation from the correct design and functionality, no matter how small. You'll be expected to work hard, often focusing on very specific, detailed problems. Excellent written and spoken communication skills are crucial to relay what you found to the rest of the team. Patience and tenacity are important traits to demonstrate, as the job requires you to "isolate" every bug and figure out how to replicate it so that it can be fixed.

Game Career Guide here presents an extract from Luis Levy & Jeannie Novak's book Game QA & Testing, a guide to entering the industry through the "traditional" route -- becoming a game tester. This helpful chapter provides information on how to really get in there and get the job.

I'm going to show 4 approaches how to get lists of UI controls and process them (for example get their count).
As an example, I will work with links on Google Labs page. My goal is to get the list of links and count them.

I use Object property of Page object. It represents the HTML document in a given browser window.
This document contains different collections - forms, frames, images, links, etc.And we use Length property to get the number of items in a collection.

The result is the same as for the previous QTP script:

3. Object QTP property and GetElementsByTagName method
Again, we can get access to the HTML document and use its GetElementsByTagNamemethod.
As the name says, GetElementsByTagNamemethod returns a collection of objects with the specified tag.
Since we are going to get all link, we should use "a" tag.
QTP script is:

Using QTP Object Spy you can get Run-time Object Properties and Test Object Properties.

It's possible to get these properties programatically:

The GetTOProperty and GetTOProperties methods enable you to retrieve a specific property value or all the properties and values that QuickTest uses to identify an object.

The GetROProperty returns the current value of the test object property from the object in the application.

GetTOProperty differs from the GetROProperty method:

GetTOProperty returns the value from the test object's description.Test Object Properties are stored in the QTP Object Repository.

GetROProperty returns the current property value of the object in the application during the test run.
QTP reads Run-time Object Properties from actual objects during the runnins can be read and accessed during the run session.

That means that when you work with objects using QTP Descriptive Programming (DP), you will be able to access run-time object properties only (using GetROProperty function). Test object properties (using GetTOProperty function) will not be accessed, because QTP DP doesn't work Object Repository.

There is a problem with Run-time object properties.In contrast to GetTOProperties (which returns the collection of all properties and values used to identify the test object),GetROPropertiesfunction does NOT exist!Once again - GetROProperties function does NOT exist!

Well, how to get all Object Indentification Properties of an object?
Answer: We can read them from Windows Registry.

The following registry key contains properties of a given test object:

Compare these Link Identification Properties with properties from the registry. They are the same!

So, we can read names of properties.

Next step is to read their values. It can be archived using GetTOProperty or GetROProperty.Also, I'm going to show how GetTOProperty and GetROProperty work for Test Object (located in QTP Object Repository) and Run-time Object (actual object, created during the run session).

As you can see, we got the same Run-time Object Properties both for Test Object and for Run-time Object. I can explain it.During the run session, QTP creates a Run-time copy of Test Object. That's why Run-time Object Properties were the same for Test Object and Run-time Object.