The objective of QA in this group is to produce the best game we can, this means have the least amount of bugs and reach all the planned features in each release. Me, Josep Casanovas will supervise the QA process that will involve all the team in different forms, all the team members will do bug tracking every weekend in order to check that week new features. One week before any deliver development will freeze in order to dedicate the full team to QA. On the final stage of the development we will also use external testers to improve the quality of our game.

As we get closer to alpha testing tasks as well as tester amount will increase in order to ensure the product presented on alpha reaches the best quality we can. Before gold presentation most of our efforts will be focused on QA to polish as most as we can our product so we will also use external testers.

#Bug reports

All testers will report any bug using Github issues system following the next template:

• Title: Few words to name the bug or the problem.
• Status: QA lead will mark all reports with a “status” to classify the report, later will focus on this part.
• Category: Which area is involved. AI, UI, art, etc.
• Priority: How important is the problem, there are 4 levels of priority. See below for more information.
• Severity: How does the problem effect, there are also 4 levels of severity. See below for more information.
• Frequency: How often does the issue happens.
• Description: A really detailed description of what’s the problem found.
• Steps: All steps to reproduce the issue.
• Screenshot: As far as it’s possible, take a screenshot of the problem.

 #Status: This is marked by the QA lead and marks the situation of the issue inside all the process:

• New: It passes to QA lead to its approval and assignation.
• Assigned: Issue already into a developer’s hands but still not working on it.
• Working on: The developer is working to solve the issue.
• To verify: The solution must be checked and approved or denied.
• Reopen: Issue not solved and must be solved again.
• Closed: Issue solved properly and now closed.
• Duplicated: In case a duplicated issue is found.
• Wontfix: Issues that will never be fixed.
• Could not reproduce: If QA lead or the developer can’t reproduce it, it returns to the tester or it’s closed.
• Need more info: Description is no clear and passes to tester in order to complete the description or clarify it.
• Rejected: Not actually an issue, only a misinterpretation by the tester.

#Priority: Indicates how urgent to solve is the issue. There are 4 levels of priority:

• Critical: Must be fixed immediately, the entire product is affected by this.
• High: Feature affected is not usable.
• Medium: Noticeable problem that can cause problems.
• Low: Not important issues.

#Severity: This indicates how the issue affects the system. There are 4 levels of severity:

• Crash: Crashes the game. This ones must be also critical priority.
• Major: Functionality not working as should and affects a lot to the gameplay.
• Moderate: Functionality works almost as it should or almost all the times, has not a big impact but sometimes can cause problems.
• Low: Minor errors that doesn’t affect the functionality. Most of them are graphic problems.

Before reporting the bug the tester should try to replicate the bug, if he/she can’t replicate it the tester must add a note in order to notify this and take it into account when assign or discard all reports.

Once the bug is added, the QA manager(me) will check all the bugs and reclassify them if any report is not correct, after that will distribute them with all the team members according to the calendar, the project status and the priority of the bugs. If any bug can’t be replied and weren’t crash or major bugs they will be moved apart.

Once a bug is assigned, it will pass to “In progress” until it’s solved, after that will pass to “To test” in order to replicate it again. If the problem is solved it will pass to “Solved” if not it will get to ”In progress” again.

#QA on production

On production every weekend some of the team members will focus on testing. The number of members will depend on the progress of the game, the areas that need more focus and the functionality added that week. On Monday of next week all issues reported will be checked and processed by the QA lead. During the week fixing tasks will be resolved and the next weekend all “to verify” issues will be checked first and later the new features added.

The testing will be intern during production although we don’t discard using external testers if is needed or we progress really well.

##Alpha QA

At least one week before alpha delivery day, all the team will focus on testing and solving all the issues found. During this time, the reports list will be daily checked and reports will be distributed and tried to solve to assure the best alpha.

During this phase most of the test will be internal but we will try to have some external testers to improve our QA.

##Gold QA

As there’s no beta delivery we will jump directly from alpha to gold so before alpha all main features will be added and during the gap between alpha and gold all efforts will be on testing, solving problems and improving our game.

On this phase of the project and after solving all critical and major bugs we will focus a lot more in lower bugs and problems that are usually ignored in earlier stages in order to have a good looking game.

This is the basic schema of the QA workflow.

Do You want to help us in our development? Now you can help us making issues for the GangBug's QA departament:

• Github GangBug Issues