[b][h3]Hello Ylanders! [/h3][/b] Do you ever wonder what happens to the bugs which we at the QA department find in the game and submit into our system? Today we'll take a look at their journey! If something in the game doesn't work or doesn't match the way it was designed, we'll mark it as a bug. This can be a whole range of things - from a badly rotated block to the game crashing completely. [img]{STEAM_CLAN_IMAGE}/28068198/ae2779e1c4d4163ea7caf2b9047fc7a893dc2d59.jpg[/img] Let's say, for example, we're entering the incorrect block. We assign it the proper priority, "epic" (what feature or group of tasks it belongs to), component (which areas of the game it applies to), and which version of the game it belongs to. Then it is important to determine a "fix version" in other words, when we want to have the issue fixed. For example, if we want the bug to be fixed by the next update we assign a fix version with the next update number. If it's an issue that isn't as pressing, we assign it a Backlog fix version and then such bugs are solved when the person they are assigned to has time. This brings us to the last step in the issue creation and that is the "assign" part. We use it to determine who is in charge of fixing the issue. [hr][/hr] In the case of our poorly rotated block, we will assign an issue to someone from our art team who takes care of the visual parts of the game. So the issue landed on a graphic designer in a "To Do" status. Our graphic designer will fix the bug by rotating the block to the correct position and sending it back to QA. They do this by switching the bug to the "Prepared for testing" phase and assigning it to the QA lead. They must also remember to fill in the revision (the version of the game) on which the issue can be retested. QA then waits until the revision is built and at that point it can start testing if the block is rotated correctly and if it's been fixed on PC, Android and also iOS mobile devices. The "Prepared for testing" state is then changed by the tester who is testing the issue to "In test". This is how the others can tell that a tester has started working on the issue and we avoid two people testing the same thing at the same time. [hr][/hr] Now we are at the stage where either the issue is fixed or we have some reservations about it. If it is fixed on all devices we can close it (switch to "Done" state). If we are still not satisfied with the solution (for example the block is turned in the right direction but too much) we add a comment to the issue, fail it and send it back to the graphic designer who fixed it, they fix it again and send it back to QA and this is how it goes on until we are satisfied with the fix. However, there may be cases, and it is very common, where fixing one issue causes a new issue or several new issues. For example, the moment our block is turned around correctly, a problem with the integrity of Blueprints may occur. By changing the pivot of something we break the Blueprints of the people who used that block in their Blueprints - because it also gets rotated in their Blueprints. So we submit a new issue and link it to the one already fixed. [hr][/hr] When testing, it's important to remember that every fix can have consequences, and just because we fix something doesn't mean it won't break something else. Game development is a very lively and dynamic process. It's made up of many pieces and there is room for error in each of them, so it's important to not only test individual parts, but also the whole. Therefore, please be forgiving and if you find something that doesn't work, report it to us. Now you know what path your issue will take and that it's a winding road. Have a great day, enjoy playing and Stay Classy!