The playing is just starting...

Category: Game Development

66 Software Quality Assurance, QA interview questions and answers – Part II

Hello! Good Morning! How are you guys today?
So, as said before, note the Part II of the 66 Questions of Quality Assurance, from and thank you to Rohit Srivastava.
If you want to check the SOURCE of the text, just click here. But if you do want to help me and access the blog and reading my comments and everything, stay tune for the next episodes. 🙂 I try to break on small posts so it would be one huge post – I really don’t like big posts because sometimes people feel like “Oh, my, I do have to read ALL of it?” or maybe you only have a few minutes from lunch to read it and don’t want to start all over…. whatever.
It is also pretty interesting that most of the questions are related to a products than to Softwares, but I do believe that this is also important to know. Knowledge is never enough!
So, here we go! Enjoy!

66 Software Quality Assurance, QA interview questions and answers – Part II
QA interview questions and answers – contributed by Rohit Srivastava

Q21. What are test driver and test stub and why we need them?


  • The Stub is called from the software component to be tested. It is used in top down approach.
  • The driver calls a component to be tested. It is used in bottom up approach.
  • Both test stub and test driver are dummy software components.
We need test stub and test driver because of following reason:
  • Suppose we want to test the interface between modules A and B and we have developed only module A. So we cannot test module A but if a dummy module is prepare, using that we can test module A.
  • Now module B cannot send or receive data from module A directly so, in these cases we have to transfer data from one module to another module by some external features. This external feature used is called Driver.


Q22. What is Monkey testing?

Monkey testing is a type of Black Box Testing used mostly at the Unit Level. In this tester enter the data in any format and check the software is not crashing. In this testing we use Smart monkey and Dumb monkey.
  • Smart monkeys are used for load and stress testing, they will help in finding the bugs. They are very expensive to develop.
  • Dumb monkey, they are important for basic testing. They help in finding those bugs which are having high severity. Dumb monkey are less expensive as compare to Smart monkeys.
Example: In phone number filed Symbols are entered.


Q23. What is Bug Triage?

Bug triage is a process to:
  • Ensure bug report completeness.
  • Analyze and assign bug to proper component.
  • Assign bug to proper bug owner.
  • Set appropriate bug priority.
  • Adjust bug severity properly.


Q24. What is Traceability Matrix?

Traceability Matrix is a method used to validate the compliance of product with requirements for that product. The requirement is written in a row of the matrix and the columns of the matrix. Now they are used to identify how and where each requirement has been addressed.
It is in the form of table that correlates two base lined documents that require a many-to-many relationship. It is used with high level requirement and detailed requirement of the software product to the matching parts of high level design, detailed design, test plan, and test cases. The relationship to the source documents is required for both backward traceability and forward traceability.


Q26. Explain paradigms for interfacing module.

The paradigms for interfacing modules:
  • Procedure Call Interface: A procedure from one module calls to procedure of another module. The caller can pass data to the called procedure while calling and also the called procedure can pass data to the caller while returning control back to the caller procedure.
  • Shared Memory: When a block of memory is shared between two modules. The memory block may be allocated by one of the two modules or third module of the same application.
  • Message Passing Interface: One module generates a message and sends the message to another module. It helps in building up the communication between different process or modules.


Q27. What are the factors responsible for the estimation of system integration test cycle and total integration time?

The number of system integration test cycle and total integration time are determined by the following parameters:
  • Number of modules in the system.
  • Relative complexity of the modules.
  • Relative complexity of the interface between the modules.
  • Number of modules needed to be clustered together in each test cycle.
  • Whether the modules to be integrated have been adequately tested before.
  • Turnaround time for each test-debug-fix cycle.


Q28. What are the things the tests ensure?

Test must ensure that:
  • The number of parameters sent in a message agrees with the number of parameters expected to receive.
  • The parameter order in the message match the order expected.
  • The field sizes and data type match.
  • When a message is generated from stored data prior to being sent, the message truly reflects the stored data.
  • When a received message is stored, data copying is consistent with the received message.


Q29. What is random testing?

When test inputs are selected randomly from the input domain of the system, this is Random Testing. Random testing involve following procedure:
  • The input domain is selected.
  • Test inputs are selected independently from the domain.
  • The system under test is executed on these inputs. The inputs constitute a random test set.
  • The results are compared to the system specification. The test is a failure if any input leads to incorrect results, otherwise it is a success.


Q30. What are the benefits of Automated Testing?

The benefits of Automation Testing are below:
  • Test engineer productivity.
  • Coverage of regression testing.
  • Reusability of test cases.
  • Consistency in testing.
  • Test interval reduction
  • Reduced software maintenance cost
  • Increased test effectiveness


Q31. What is Agile Testing?

Agile Testing means to quickly validation of the client requirements and make the application of good quality user interface. When the build is released to the testing team, testing of the application is started to find the bugs. As a Tester, we need to focus on the customer or end user requirements. We put the efforts to deliver the quality product in spite of short time frame which will further help in reducing the cost of development and test feedbacks will be implemented in the code which will avoid the defects coming from the end user.

Q32. Describe Use Case Testing.

Use Case: A use case is a description of the process which is performed by the end user for a particular task. Use case contains a sequence of step which is performed by the end user to complete a specific task or a step by step process that describe how the application and end user interact with each other. Use case is written by the user point of view.
Use case Testing: the use case testing uses this use case to evaluate the application. So that, the tester can examines all the functionalities of the application. Use case testing cover whole application, tester performs this testing in step by step process to complete one task.


Q33. What type of tests you perform on the web based application?

For web application we perform following time of test:
1. Functionality Testing.
2. Usability Testing.
3. Navigation Testing.
4. Configuration and Compatibility testing.
5. Reliability and Availability Testing.
6. Performance Testing.
7. Load and Stress Testing.
8. Security Testing


Q34. What is Gantt Chart?

A Gantt Chart is used to represent a project schedule that includes duration of individual tasks or phases, their dependencies and ordering.
  • It displays the start and end points of each task and the percentage of completion of each task
  • It allows the planner to assess the duration of a project, identify the resources needed, and lay out the order in which tasks need to be performed.
  • It is useful in managing the dependencies between tasks.
  • Using Gantt chart each team member can view the product development schedule.


Q35 How to find all the Bugs during first round of Testing?

There could be several reasons for not debugging the entire bug in the first round of testing process. Debugging the showstopper in the first or second build is almost impossible. A found defect can cover up the other defects in the application. The thread which leads to on defect could be redirected to another defect, as the tester find the bug and lock that bug in report and after fixing of those bugs new bugs may also arises. It is difficult to keep testing on a known defective application. That is the reason we cannot find all the bug in first run and also we cannot perform Exhaustive testing.


Q36 How can u prepares the Test Plan without SRS?

We can prepare a test plan directly without having SRS, When the Requirements and URD(User Requirement Document )are available to us. URD is very helpful to determine the requirement of the user. The SRS document only contains the requirement of the user, but tester can also determine the requirement form the product. Without having SRS document we cannot estimate the Testing effort and cost of testing if we do not have SRS. SRS tell us on which platform our software is going to be used and on basis of this we perform the test on the application. Some time end user want to know what type of testing we are going to execute on the application for this we can send our test plan to the client.


Q37. What is the purpose of test strategy?

We need Test Strategy for the following reason:
1. To have a signed, sealed, and delivered document, where the document contains details about the testing methodology, test plan, and test cases.
2. Test strategy document tells us how the software product will be tested.
3. Test strategy document helps to review the test plan with the project team members.
4. It describes the roles, responsibilities and the resources required for the test and schedule. 
5. When we create a test strategy document, we have to put into writing any testing issues requiring resolution.
6. The test strategy is decided first, before lower level decisions are made on the test plan, test design, and other testing issues.


Q38. What are the dimensions of the Risks?

The dimensions of the risk are described below:
Schedule: Unrealistic schedules. to develop a huge software in a single day..


Client: Ambiguous requirements definition, requirement and not clear, changes in the requirement etc. 
Human Resources: Non-availability of sufficient resources with the skill level expected in the project.
System Resources: Non-availability of procuring all critical computer resources either hardware and software tools or licenses for software will have an adverse impact.
Quality: Compound factors like lack of resources along with a tight delivery schedule and frequent changes to requirements will have an impact on the quality of the product tested.


Q39. How to Estimate Testing effort ?

Time Estimation method for Testing Process:

Step 1 : count number of use cases (NUC) of system 
Step 2 : Set Avg. Time Test Cases(ATTC) as per test plan 
Step 3 : Estimate total number of test cases (NTC) 
Total number of test cases = Number of Use Cases X Avg. Test Cases per a use case 
Step 4 : Set Avg. Execution Time (AET) per a test case 
Step 5 : Calculate Total Execution Time (TET) 
TET = Total number of test cases * AET 
Step 6 : Calculate Test Case Creation Time (TCCT)
usually we will take 1.5 times of TET as TCCT
TCCT = 1.5 * TET
Step 7 : Time for Re-Test Case Execution (RTCE) this is for retesting
usually we take 0.5 times of TET
RTCE = 0.5 * TET
Step 8 : Set Report generation Time (RGT
usually we take 0.2 times of TET
RGT = 0.2 * TET
Step 9 : Set Test Environment Setup Time (TEST)
it also depends on test plan
Step 10 : Total Estimation time = TET + TCCT+ RTCE + RGT + TEST + some buffer.


Q40. How to create requirements test matrix template?

For a requirements test matrix template we perform following step:
Step 1: Find out number of requirements.
Step 2: Find out number of test cases.
Step 3: Create a table based on these. Let we have 10 requirements and 40 test cases, then we create a table of 11 rows and 41 columns.
Step 4: On the first column of table copy all your 10 requirement numbers, and paste them into rows 2 through 11 of the table.
Step 5: Now copy all 40 test case numbers, and paste them into columns 2 through 41 of the table.
Step 6: Examine each of your 40 test cases, determine which of the 10 requirements they satisfy.


Q41. Can you perform regression testing performed manually?

Yes we can perform regression testing manually, but it requires lots of effort. To choose the way of doing the regression testing is totally depends on the initial testing approach. If the initial testing approach was manual testing, then the regression testing is usually performed manually. In case, if the initial testing approach was automated testing, then the regression testing is usually performed by automated testing. Automated regression testing is very easy task.


Q42. You are a tester. Now How will you choose which defect to remove in 1000000 defects?

First thing testers are not responsible for fixing the bug they are only responsible for debugging the bug and prioritizing those bugs. These bugs are now reported in bug report template with the severity and priority of the bug. Tester assigns severity level to the defects depending upon their impact on other parts of application. Every bug has its severity and priority values assign by tester. If a defect does not allow you to go ahead and test the product, it is critical one so it has to be fixed as soon as possible. We have 5 levels as:
  • Critical
  • High
  • Medium
  • Low
  • Cosmetic


Q43.How do you perform integration testing?

Integration testing is black box testing. Integration testing focuses on the interfaces between units, to make sure the units work together. For integration testing we ensure that all units testing of the each component is performed earlier. Integration testing begins only after the unit testing. The purpose of integration testing is to ensure different components of the application interact with each other. So that, components work as per the customer requirements. Test cases are developed with the purpose of exercising the interfaces between the components. Integration testing is considered complete, when actual results and expected results are same.


Q44. What is the testing lifecycle?

There is no standard testing life cycle, but it is consist of following phases:
  • Test Planning (Test Strategy, Test Plan, Test Bed Creation)
  • Test Development (Test Procedures, Test Scenarios, Test Cases)
  • Test Execution
  • Result Analysis (compare Expected to Actual results)
  • Defect Tracking
  • Reporting

Q45.What is good code?

A good code is code that works. The good code must not contain the defect or bug and is readable by other developers and easily maintainable. Organizations have coding standards all developers should follow, and also every programmer and software engineer has different ideas about what is best and what are too many or too few rules. We need to keep in mind that excessive use of rules can decrease both productivity and creativity. Peer reviews and code analysis tools can be used to check for problems and enforce standards.

Q46. What are the main attributes of test automation?

The main attributes are discussed below:
Maintainability: For each new release need to update the test automation suites.

Reliability: Accuracy and repeatability of the test automation.
Flexibility: Ease of working with all the different kinds of automation test ware. 
Efficiency: Total cost related to the effort needed for the automation.
Portability: Ability of the automated test to run on different environments.
Robustness: Effectiveness of automation on an unstable or rapidly changing system.
Usability: Extent to which automation can be used by different types of user.

Q47. What could go wrong with test automation?

Followings things may be go wrong in test automation:
  • Ignoring automation, while planning the development phases.
  • In design Phase not choosing the right technology.
  • In coding Phase not automating the right test cases.
  • Tool selection might go wrong.
  • Test script not be updated when application is continuously changing.
  • Test data should be unique, if the same data is available on the application then the application will not accept the data that we are going to add via automation.

Q48. What tools are available to support testing during development of application?

Following tools can be used to support testing during development of application:
  • Test management tools example: Quality Center, JIRA.
  • Defect management tool example: Bugzilla, Test Director.
  • Project management: Sharepoint.
  • Automation tools: QTP, RFT, WinRunner.

Q49. What are the tests activities that you want to automate in a project?

The following testing activities can be automated:
  • Functional tests: Identify some P1 and P2 cases which are most critical for project success and operations and automate them. After every new build, these scripts will assure the fixes does not broke any of the critical functionality.
  • Regression test suites: Test the need to be run after each build.
  • Performance tests: Identical test the need to be run on different browser.
  • Stress tests
  • Load tests

Q50. What is the difference in responsibilities of Programmers and QA analyst?

The differences in responsibilities are listed below:
  • QA is concern for Process Quality and Programmers are concern for Product Quality.
  • QA ensure that the processes used for developing the product of high quality where as programmers used these processes so that end product is of good quality.
  • Processes are decided by QA. Programmers are supposed to follow the processes so that they can produce a good quality product.
  • Any issue found during execution of process by the programmers is communicated to the QA so that they can improve the process.

66 QA interview questions and answers – quality Assurance – Part I

Hello, my fellow readers! How are you guys tonight?
I am sorry to take that long to be back and right again, but I just moved to Canada. That’s right! I was in Brazil a few days ago and now I am in Canada searching for dream inside the game industry. Right now I’m looking for a job, but if I have time, I’ll write something about my research and stuff. I know that, back in Brazil, many people want to move to Canada to chase their dreams, study, work and more.
Alrightttt! Let move on and talk about, what. GAMES and QA. This is why you are here, right?
I found out this really interested info at (didn’t know the website until now) and it talks about 66 QA interview questions and answers (Dã, right! its on the title! Come one!). So I hope you enjoy the reading as always just like I did and leave a comment with your opinion.
QA interview questions and answers – contributed by Rohit Srivastava
Q1. What is difference between QA, QC and Software Testing?
Quality Assurance (QA): QA refers to the planned and systematic way of monitoring the quality of process which is followed to produce a quality product. QA tracks the outcomes and adjusts the process to meet the expectation.
Quality Control (QC): Concern with the quality of the product. QC finds the defects and suggests improvements. The process set by QA is implemented by QC. The QC is the responsibility of the tester.
Software Testing: is the process of ensuring that product which is developed by the developer meets the user requirement. The motive to perform testing is to find the bugs and make sure that they get fixed.


Q2. When to start QA in a project?
A good time to start the QA is from the beginning of the project startup. This will lead to plan the process which will make sure that product coming out meets the customer quality expectation. QA also plays a major role in the communication between teams. It gives time to step up the testing environment. The testing phase starts after the test plans are written, reviewed and approved.


Q3. What are verification and validation and difference between these two?
Verification: process of evaluating steps which is followed up to development phase to determine whether they meet the specified requirements for that stage.
Validation: process of evaluating product during or at the end of the development process to determine whether product meets specified requirements.
Difference between Verification and Validation:
  • Verification is Static Testing where as Validations is Dynamic Testing.
  • Verification takes place before validation.
  • Verification evaluates plans, documents, requirements and specifications, where as Validation evaluates product.
  • Verification inputs are checklist, issues list, walkthroughs and inspection, where as in Validation testing of actual product.
  • Verification output is set of documents, plans, specifications and requirement documents where as in Validation actual product is output.


Q4. What is difference between Smoke testing and Sanity Testing?

The difference between smoke and sanity testing is described below:
  • Sanity testing is performed when new build is released after fixing bugs where as smoke testing is performed to check the major functionalities of the application.
  • Sanity is performed by the tester or the developer but smoke testing can be performed by the tester or developer.
  • Smoke testing is performed earlier where as sanity is performed after the smoke testing.
  • Sanity testing is narrow and deep approach of testing and smoke testing is focused testing based on major functionalities.


Q5. What is destructive testing, and what are its benefits?

Destructive testing includes methods where material is broken down to evaluate the mechanical properties, such as strength, toughness and hardness.
For example, finding the quality of a weld is good enough to withstand extreme pressure and also to verify the properties of a material.
Benefits of Destructive Testing (DT)
  • Verifies properties of a material
  • Determines quality of welds
  • Helps you to reduce failures, accidents and costs
  • Ensures compliance with regulations


Q6. What is Testware?

The testware is:
  • The subset of software which helps in performing the testing of application.
  • Testware are required to plan, design, and execute tests. It contains documents, scripts, inputs, expected results, set-up and additional software or utilities used in testing.
  • Testware is term given to combination of all utilities and application software that required for testing a software package.

Testware is special because it has:
1. Different purpose
2. Different metrics for quality and
3. Different users


Q7. What is difference between Retesting and Regression testing?

The difference between Retesting and Regression testing are below:
  • Retesting is done to verify defects fixes where as regression is perform to check if the defect fix have not impacted other functionality that was working fine before doing changes in the code.
  • Retesting is planned testing based on the defect fixes listed where as regression is not be always specific to any defect fix. Also regression can be executed for some modules or all modules.
  • Retesting concern with executing those test cases that are failed earlier whereas regression concern with executing test cases that was passed in earlier builds.
  • Retesting has higher priority over regression, but in some case retesting and regression testing are carried out in parallel.


Q8. Explain bug life cycle.

Bug Life Cycle:
  • When a tester finds a bug .The bug is assigned with NEW or OPEN status.
  • The bug is assigned to development project manager who will analyze the bug. He will check whether it is a valid defect. If it is not valid bug is rejected, now status is REJECTED.
  • If not, next the defect is checked whether it is in scope. When bug is not part of the current release .Such defects are POSTPONED.
  • Now, Tester checks whether similar defect was raised earlier. If yes defect is assigned a status DUPLICATE.
  • When bug is assigned to developer. During this stage bug is assigned a status IN-PROGRESS.
  • Once code is fixed. Defect is assigned with FIXED status.
  • Next the tester will re-test the code. In case the test case passes the defect is CLOSED.
  • If the test case fails again the bug is RE-OPENED and assigned to the developer. That’s all to Bug Life Cycle.
CHARTER Provided by the Author of the blog (I tried!)


Q9. What is severity and priority of bug? Give some example.

Priority: concern with application from the business point of view.
It answers: How quickly we need to fix the bug? Or How soon the bug should get fixed?
Severity: concern with functionality of application. It deals with the impact of the bug on the application.


How much the bug is affecting the functionality of the application?
  • High Priority and Low Severity:
    Company logo is not properly displayed on their website.
  • High Priority and High Severity:
    Suppose you are doing online shopping and filled payment information, but after submitting the form, you get a message like “Order has been cancelled.”
  • Low Priority and High Severity:
    If we have a typical scenario in which the application get crashed, but that scenario exists rarely.
  • Low Priority and Low Severity:
    There is a mistake like “You have registered success” instead of successfully, success is written.


Q10. What are the common problems with software automation?

Software problem are listed below:

1. Purchasing the license of tool (QTP, selenium, QC, LR) 
2. Lack of skilled Tester to run the tool
3. Expectation that automated tests will find a lot of new defects
4. Maintenance of automated tests
5. Technical problems of tools


Q11. What is the role of QA in a project development?

QA stands for QUALITY ASSURANCE. QA team assures the quality by monitor the whole development process. QA tracks the outcomes and adjusting process to meet the expectation.
The role of Quality Assurance is discussed below:
  • QA team is responsible for monitoring the process to be carried out for development.
  • Responsibilities of QA team are planning testing execution process.
  • QA Lead creates the time tables and agrees on a Quality Assurance plan for the product.
  • QA team communicated QA process to the team members.
  • QA team ensures traceability of test cases to requirements.


Q13. What is the difference between build and release?

BUILD: is a number given to installable software that is given to testing team for testing by the development team. Build number assigned are incremental and sequential.


RELEASE: is a number given to installable software that is handed over to customer by the developer or tester.


The information of build, release and version are displayed in software help page. Using this build and release customer can let the customer team know which release version build thet are using.


eg “” (Release Number.Version Number.Build Number.Patch Number)


Q14. What are the key challenges of software testing?

Following are some challenges of software testing.
1. Application should be stable enough to be tested. 


2. Testing always under time constraint. 


3. Understanding requirements, Domain knowledge and business user perspective understanding.


4. Which tests to execute first? 


5. Testing the Complete application. 


6. Regression testing. 


7. Lack of skilled testers.


8. Changing requirements.


9. Lack of resources, tools and training.
Q15. Why you choose automated testing over manual testing?

The reasons for choosing automation testing over manual testing are following:
1. Frequency of use of test case


2. Time Comparison (automated script run much faster than manual execution.)


3. Reusability of Automation Script


4. Adaptability of test case for automation.


5. Exploitation of automation tool.


Q16. What is the basis for choosing the SDLC model for development of software?

The choice of SDLC depends on the various factors, how stable are the requirements:
  • When the requirements are very clearly know, documented and not subject to change then we can follow the waterfall model.
  • Most of the companies follow the V mode for the development because this model includes both verification and validation activities and testing is involved in earlier phase.
  • Iterative model can be used to build application where requirement changes after a period of times or application features or added on with smaller release. When the client is ready for the delivery of the product in parts or phases.


Q17. Explain bug leakage and bug release.

Bug Leakage: When customer or end user discovered a bug which can be detected by the testing team. Or when a bug is detected which can be detected in pervious build then this is called as Bug Leakage.
Bug release: is when a build is handed to testing team with knowing that defect is present in the release. The priority and severity of bug is low. It is done when customer want the application on the time. Customer can tolerate the bug in the released then the delay in getting the application and the cost involved in removing that bug. These bugs are mentioned in the Release Notes handed to client for the future improvement chances.


Q18. What is regression testing?

Regression Testing: When changes in the code of the software are made to fix the previous bug. Then testing needs to be perform to ensure that it will not generate a new bug in the application and it works as specified and that it has not negatively impacted any functionality that it offered previously. Regression Testing is important because of following reason:
  • That the application works even after the alteration in the code were made.
  • The original functionality continues to work as specified even after doing changes in the software application.
  • The alteration to the software application has not introduced any new bugs.


Q19.What is data driven testing?

Data Driven is an automation testing part in which test input or output values, these values are read from data files. It is performed when the values are changing by the time. The different data files may include data pools, csv files, Excel files. The data is then loaded into variables in recorded or manually coded scripts. For data driven testing we use Parameterzing and Regular expression Technique.
Ex: To evaluate login functionality, we use different user name and password combinations, variables are used to access different username and password. The list of username and password are stored in a data table or excel sheet.


Q20. What is alpha and beta testing?

Alpha testing: is performed by the IN-House developers. After alpha testing the software is handed over to software QA team, for additional testing in an environment that is similar to the client environment.
Beta testing: It is performed by end user. So that they can make sure that the product is bug free or working as per the requirement. IN-house developers and software QA team perform alpha testing. The public, a few select prospective customers or the general public performs beta testing.
Yeah! I know I promised you 66 QA questions – and I will posted – is just because I need to read them first, understand and them post it. Somethings I can add something (like the charter on this one) and can help newcomers.
Thank you for reading so far and hope you can come back for part II.
Drive Safe!

Interview with Heather Chandler by CCAPS

Hello, everybody.
Today I am posting an interview with Heather Chandler, founder and President of Media Sunshine, Inc. It is an amazing interview with a lot of information and I how everybody could enjoy it!


IMPORTANT: This interview was made by CCAPS and you can check the PDF version and their website here. All the credits belong to them for this wonderful opportunity.
Heather is the main author of two books that I also mentioned before in my other post at the blog.
The Game Production Handbook and The Game localization Handbook
Thank you very much!
Learning from the Best
An interview with Heather Chandler, founder and President of Media Sunshine, Inc. and author of The Game Localization Handbook and The Game Production Handbook.
CCAPS: You have worked in the game industry since 1996. How much of your past and recent work is directly related to G-localization (a.k.a. the GILT industry)?
CHANDLER: When I worked as a producer, localization was just one of my responsibilities. For each game I worked on, I organized all the assets for translation, managed the translation process, integrated localized assets and coordinated the testing. This required planning during pre-production so there were no surprises during the actual localization phase. I also worked with the production team to make sure localization issues were accounted for during game development. Oftentimes, localization is the last thing on a game developer’s mind, because they are so focused on finishing the primary version of the game (usually for the US market). If localization is left until the end of the project, you run the risk of having a localization pipeline that is difficult and time-consuming to work with. For example, the game text may be hard-coded, which means the text that needs to be translated is located within programming files that should only be manipulated by a programmer. You may also find that graphic files contain embedded text, instead of having the text on a separate layer, making it very time consuming to alter the graphic for other languages. You may also find that the product you are working on is so specific to a single country that it is hard to modify it for other countries. For example, a game about Monster Trucks would not appeal to many people outside the United States.
CCAPS: Now that you are working as a consultant and have your own company, how would you say that your present activity differ from the times you worked for companies like Ubisoft, Electronic Arts, Activision and New Line Cinema?
CHANDLER: For me, the main difference between working for a company and being a consultant is that, as a consultant, I can work on several different projects. For instance, I can spend my time teaching, writing or working with others — and these activities are not all directly related to game development. I also have the freedom to pick and choose which projects I work on. It is nice being your own boss and focusing on what you enjoy doing and are good at. Because my main expertise is production management, I also have a wide variety of services I can offer. For example, I can manage a voiceover shoot from start to finish, work with a developer on defining a localization-friendly production pipeline, teach game development classes, help small technology businesses grow, create game pitches or any other number of production-related services. While I did enjoy working as a Producer at various companies, I could only work on one project at a time. Oftentimes, these projects lasted one year or more.
CCAPS: To date, you have worked on more than 30 games, including Ghost Recon: Advanced Warfighter, Ghost Recon 2, Civilization: Call to Power, Heavy Gear, Apocalypse, Vigilante 8, Shanghai: Second Dynasty, and Zork: Grand Inquisitor. Which was more fun to develop? And the most complicated?
CHANDLER: Of the games listed above, Shanghai: Second Dynasty (S2D)was the most fun for me. Shanghai is a tile-matching game where the player must match up tile pairs in order to clear them from the board. This game is also known as Mah Jong to some people. S2D had several game variations on the tile matching, as well as 4-player Mah Jong. It was fun because I learned so much about game production while working on it. The producerdirector, Tom Sloper, had several years of game development and design experience and really knew the process of creating a game from the inside out. He was one of my first mentors and taught me about writing design documents, managing internal and external teams, play-testing, marketing and project management. I had a range of different responsibilities with the game, including creating the installer, approving art assets, working
with the composer and creating the gold master candidates. Localization of Shanghai was also a learning experience. Not only did I have to coordinate the translations, I also had to integrate the translated assets, manage the testing, etc. — all for three different languages (including Japanese). One of the most complicated games I worked, at least from a localization standpoint, was Civilization: Call to Power. This was a very text heavy PC game, and the plan was to release all the languages at the same time as the English version. This was my first experience working on simultaneous shipment localization. The development team worked very hard to get the game finished and localized into five different languages. We had to put together special tools for the translators to make the process easier — they had over 50,000 words to translate for each language.
CCAPS: You also have a lot of hands-on experience with game localization, correct? What was the localization process like for Shanghai: Second Dynasty?
CHANDLER: The localization process for Shanghai: Second Dynasty was pretty straightforward. The game was released in German, French and Japanese. First, all of the in-game text was centrally located in easy to access text files. I simply had to get these files and send them off for translation. When the translations were completed, I replaced the text files with the appropriate localized files. For the voiceovers, the script was sent off to be translated and then a voiceover recording session was planned for each language. Once the recordings were finished, the localized VO files were sent to me so they could be added to the game. Once all the assets were added, we began testing. There are two types of testing — functionality testing and linguistic testing. Functionality testing is where you check the game for any crash bugs or game play issues. Linguistic testing involves the verification of
all the game’s language assets. The testers looked for text truncations, grammatical errors, missing text, untranslated text, etc. I can’t remember the exact word counts, but I do remember it took about eight weeks to localize the game into thee languages. The languages were determined by projecting how many copies of the game would sell against the cost of making the localized builds. These types of decisions are handled by the sales, marketing and finance departments, and sometimes they decide to localize a title into 10 languages, while other titles only get localized into two languages.
CCAPS: In The Game Localization Handbook, you dedicate an entire chapter to “Localization Production Pitfalls.” What are these pitfalls and what would be the ways to avoid them?
CHANDLER: The major production pitfalls discussed in the book are:
Poor Planning – if localizations are left until the last minute, it is likely that the game code will not be localization-friendly. This makes it difficult to create international versions in a timely fashion. If planned for in advance, localizations do not need to be a burden on the development team. When planning for localizations, have a good idea of how many assets need to be translated, their format, how they will be organized for translation and howquickly the translations can be integrated into the assets. Achieving Simultaneous Release – Simship of numerous languages is possible, but only if planned for. If the team is thinking about localizations well in advance, they are more likely to achieve simship. 
Linguistic and Functionality Testing – Testing is a very time-consuming aspect of localization. In many cases, the testing is not planned or well organized, which only adds to the time needed. If you are testing five languages, you need to determine a standardized way for the translators to report linguistic bugs and then find a reliable way to track these fixes in the game.
Quality of Translations – Some translators will do a straight translation of text and will not adapt it to fit within the game universe. For example, if a humorous game has very dry translations, a lot of the humor is lost in the localized versions. This can be remedied if the translators have a chance to play a version of the game (even an English one), so they fully understand how to convey its entertaining qualities.
CCAPS: Speaking of pitfalls, did your team manage to avoid these when localizing the games above or did you gather the information for the book by learning from your own mistakes and those of your colleagues?
CHANDLER: That’s a great question! I honestly have to say that I have experienced most of these pitfalls. However, when talking with my colleagues, I find that most of them have experienced these same pitfalls as well.
CCAPS: What countries are the most important players in the entertainment software industry? And where are the best markets located?
CHANDLER: Germany and France have always been big game markets. Italy and Spain have also had a presence, but not as large. Asia is also becoming a very large market — in particular Korea and Japan. Other emerging markets are Eastern Europe and the Netherlands.
CCAPS: Finally, what would be your advice for those who want to enter the entertainment software localization industry?
CHANDLER: I think it is important that you play the games and have an understanding of how the interactive medium is structured. In my experience, translators who understand and play games are more effective in this area of localization. They have a better understanding of what needs to be adapted in order to keep the tone of the game consistent with the English version.
Heather Maxwell Chandler graduated with honors from Vanderbilt University and received an M.A. from the USC School of Cinema-Television. Prior to the creation of MSI, a company that provides consulting services for game developers, publishers and vendors, she served in various production positions at Ubisoft, Electronic Arts, Activision and New Line Cinema. She agreed to give us this interview in between diapers and safety pins, busy with her son Jack, born last December.
Well, even knowing that it is from 2005 and still think that those are pretty good tips and for the ones who are trying to get into this market and is searching for information (as me) this is great! 🙂 Once more, I would like to thanks CCAPS Translation & Localization for this opportunity and if you want to know more about this brazilian company, please check their website here.
Keep reading the blog and hope to see you later!

Talking about Books… Part II

As I promissed, here we go with the second part of “Talking About Books”. If you miss part One, click here.

Once again, thanks to Tom Sloper for the quite selection of literature.

Serious Games: Games That Educate, Train, and Inform
by Sande Chen & David Michael
Publisher: Course Technology PTR; ISBN: 1592006221
Book Description “Serious Games: Games that Educate, Train, and Inform” will help you learn how to take what you’ve learned in making games for fun and apply it to making “serious games”: games for education, training, healing, and more. It will provide an overview of all of the major markets for serious games. This overview will include examples of what has been done with video games in these markets, and what is anticipated in the future, including market scope, goals of each emerging market, game types offering greatest potential, the shortest route to market by category, development budgets by category, and barriers for developers to consider.
(Blog’s Author: As we are talking about Serious Games, do not forget to check my Final Paper about a Serious Game inside the Foreign Trade Area – check it out here)

 Game Design Workshop: Designing, Prototyping, and Playtesting Games
by Tracy Fullerton
Publisher: Morgan Kaufmann; 2nd edition (February 8, 2008)
ISBN-10: 0240809742
ISBN-13: 978-0240809748
The publisher of 1st edition says: Master the craft of game design so you can create that elusive combination of challenge, competition, and interaction that players seek. This design workshop begins with an examination of the fundamental elements of game design; then puts you to work in prototyping, playtesting, and redesigning your own games with exercises that teach essential design skills.
Andrew Rollings and Ernest Adams On Game Design
by Andrew Rollings and Ernest Adams (duh)
New Riders; ISBN 76092-02300.
What people are saying about this book: “This book sets the record straight as to what ‘game design’ is and why it’s important.” – Tom Sloper; President, Sloperama Productions.
Also see Ernest Adams’ website, at
 Game Design by Bob Bates
Thomson Course Technology ; ISBN: 1-59200-493-8

The publisher says: A behind-the-scenes look at how a game gets designed and developed – from the day the idea is born to the day the box hits the shelves.


 Rules of Play: Game Design Fundamentals

by Katie Salen & Eric Zimmerman
The MIT Press ; ISBN: 0-262-24045-9
The publisher says: A much-needed primer for this emerging field. A unified model for looking at all kinds of games, from board games and sports to computer and video games.


The Indie Game Development Survival Guide

by David Michael
Publisher: Charles River Media; ISBN: 1584502142.

Ok, not much to say about this last book, but Google is there for a reason. 🙂

Go for it and enjoy the reading!

I will keep posting the other books during the week. So, stay tuned! for part III!

See ya!

Talking about Books…

Good Morning everyone!

When we talk about the game biz, we have to understand – as I Always say – that it is an industry as all the other and you will work in a real JOB. Yeah, JOB, work, duties, tasks, etc. And like any other job, you have to keep developing yourself to build a great career and a great resume, with a lot of experience and knowledge.

I don’t know if you remember, but in an older post I said that you have to be an avid reader. And that is true. Not only about worlds of fantasy, technology, medieval or character, but about the industry itself and how it works. Or you plan to be a tester for the rest of your life???

My point is, you have to study, and study a lot. Read a lot, talk with people, discuss, and ask, research. No knowledge will come to you out of the blue.

So that’s why, once more, Tom Sloper, gives us the opportunity to make our professional life better. He listed at his site a few books that he consider recommended reading for Aspiring Game Designers and more.

Here we go with this list. Hope you guys can have the opportunity to check them all, because here in Brazil is kind of hard and most of the books we can only have access through Amazon and in the original language. (Just to let you know. Still, not a problem to be, by the way. rsrs)

Enjoy the reading!


NOTE: these lessons are primarily aimed at aspiring game designers, but many of the concepts described herein also apply to those who aspire to other types of jobs in the game industry.[…]

Game designers are creative. So I list books on creativity — and I list creative novels about games to spark the reader’s creative thinking.

Game designers work in industry. So I list books about how to survive in industry.

Game design is intricately interwoven with what producers do (well, sort of – but I’m a designer and producer). So I list books about how to manage, and about projects.

Games do not exist in a vacuum — players use a “language” which was developed in earlier games. So I list books about the history of the game biz.

Programmers are designers too — one or two books in this list may be addressed to the more technically-minded “designers” of games.


Introduction to Game Development

Edited by Steve Rabin

Charles River Media; ISBN: 1-58450-377-7

Reviewer says: An introduction to all aspects of the theory and practice of game development, design, and production. The book, which can be used as a text for introductory courses or as a comprehensive reference for game developers and designers, is divided into seven independent parts. 27 leading game developers have contributed chapters. […]

Game Design Perspectives

Edited by Francois Dominic Laramee

Paperback – 401 pages, with CD (May, 2002)

Charles River Media; ISBN 1-58450-090-5.

Book Description: This unique compilation of design articles provides designers with insight into how their colleagues approach game design, where they have stumbled, and how they have succeeded. The articles are written by a diverse group of designers with a wide variety of game backgrounds. The topics covered range from proper design documentation, user interfaces, design theory, characters and storytelling, to quality management, platform- and genre-specific design issues, relationships between designers and the user community, and game development project management. If you are just beginning in game design, you’ll find new ideas to complement and compare with your own designs. Producers and managers will also benefit from The User Community and Managing a Game Development Business sections.

Secrets of the Game Business

Edited by Francois Dominic Laramee

Paperback – 338 pages (March, 2003)

Charles River Media; ISBN 1-58450-282-7.0

Book Description: Explore the inner workings of the game development and publishing industry through the experiences and insights of industry experts. These publishing executives, developers, veteran producers, designers, owners of independent studios, and academics have written a unique collection of articles that really delves into the intricacies of the business. A must-have resource for anyone interested in starting a game development studio or improving an existing one.

David Perry on Game Design; A Brainstorming Toolbox

by David Perry, Rusel DeMaria

Charles River Media ; ISBN-10: 1584506687. ISBN-13: 978-1584506683

The author says: It’s the biggest book on game design ever written, at over 1,000 pages long. It’s designed to help students & designers come up with innovative new ideas, and also to expand current ideas.


The Game Production Handbook

by Heather Chandler

Publisher: Charles River Media; ISBN: 1-58450-416-1

Book Description Written by a veteran game producer, The Game Production Handbook is the ultimate industry reference. It answers the questions new leads, managers, and producers have, and it gives the pros new insights and valuable tips to improve their existing processes.
(Blog’s Author: Man, as the post goes through more than 14 pages, I will slip this post.

See you guys later with the 2o part of Book tips for the Game Biz)

Tip for a Game Testing Book

Good Evening!
If you are, for some reason, reading this article is because you may be looking for some information on how to become a Game Tester or maybe looking for more information to develop your work today.
Either way, I found out at Amazon an amazing book that will surely help you develop or learning something about Game Testing.
The authors, Charles P. Schultz, Robert Bryant and Tim Langdell, PHD, are some big masters in what they do and work. Charles is an Operations Manager for Motorola’s Global Software Group and works on software testing and mobile gaming. Robert is currently Studio Director at videogame publisher Crave Entertainment, where he also served as QA Manager and Executive Producer. Tim, a veteran of the game industry, is full-time faculty in the USC Viterbi School of Engineering’s Information Technology Program where he chairs the Game Curriculum Sub-Committee, and teaches game design and game testing.
This is just the start so you can understand how great is this book….
Ok. Authors are good but what will I learn with the book?
Here is your answer. With this book, you will learn about the roles and responsibilities of a game tester, including how to best apply software test engineer methodologies to the game industry. This knowledge can be applied by testers to help create staffing plans and schedule test tasks, as well as generate thorough and effective test cases for games. Topics include how games are made, how testing fits into the production cycle of a game, testing fundamentals, test automation, and how to test different games genres.
The book is also divided into five parts, each consisting of multiple chapters as below.
Part I – “About Game Testing” introduces the reader to game testing in terms of culture, philosophies, and the contribution testing makes to the final game release.
Part II – “Making Games” reveals how an individual contributes to the overall game project. Also includes different kinds of roles and responsibilities that are required of testers through various stages of the development and production of game software.
Part III – “Testing Fundamentals” introduces testing concepts and practices from a formal software engineering approach.
Part IV – “Testing Techniques” is a set of tutorials on different methodologies for producing tests for your game.
Part V – “More Effective Testing” addresses ways to make the most out of your limited time and resources to reach new heights in the quantity and quality of the test you can produce and run.
So, if you want to know more – and also know from where I took the text above – check out the book!
See you around!

How QA works?

I found out this really informing video from Trendane Sparks in youtube and he describes, in 3 videos, what is to be a QA Tester.  Think you should check it out.
Still, here are some few notes about the video that I made – if you are really lazy to see the videos. =) – of what I found out to be important.

* First thing that he says is that: “Playing video games is different from testing video games”.
* He also talks about the blackbox tester / Ender user tester.
* Expectation of quality.
* What does it takes to be a good QA?
– Be able to communicate.
– Attention to details.
– Know the perspective of other (clients/bosses/workers).
– Find where the games goes from good to better to worst and go into the details to make it better.
– Patience.
– Give positives lines about the game and stuff not only what is bad or wrong.
– Thick skin – Someone will get mad about what you said, start screaming and point fingers at you.
– Courage.
– Gamers generally understand what makes a game fun.
– Keep a list of all the bugs you found.
– They will ask you to sign a document saying that the game is ready to release. If you say no, have a great backup. Bug database.

There are two kinds of bugs.
– Subjective bugs, which are just opinions.
– Objective bugs, based upon facts.
Tell people about the bug.
Bug is something that pulls you out of your game experience.
If you find a bug and there was already reported by many other people, it may not be written well. Read it and see if all of them have the same core/context.

Do not use the word ¨should¨ or ¨shouldn´t¨. You are not the game designer. Write what you expect to happen. Be objective.
Notes: Place where you can express your opinion.
No game goes out perfect and ok. There will be always bugs.
Well, for me, as a beginner in this kind of area, I found really interesting and some good stuff that can make you think. Also, is a different point of view of what a QA Tester does and what it shouldn’t.

Page 2 of 2

Powered by WordPress & Theme by Anders Norén