Unity for Game Testers: Complete masterclass for beginners

1. Introduction: Hello, everyone. I'm glad to welcome you to the Unity QA course. My name is Maxim. I am a senior game DQ engineer, and for the last five years, I have lived in breezed the architecture of virtual worlds. My journey through the industry hasn't been a straight line. I have worked across the entire spectrum of game development from the raw creative energy of small India performers to the massive complex ecosystems ofA titles. But regardless of the scale, one thing because my passion for the constructing how these worlds are built. I have spent thousands of hours inside the Unity engine specialized in its quirks, its power, and it's hidden pitfalls. I created this curse because I want to share this specialized knowledge with you. I'm not here to teach you how to play games for living. I'm here to teach you how to outdid them like an engineer. Now you might ask, why is masterinnity so vital in 2026? The answer is simple. The line between development and testing has completely vanished. In today's landscape, unity isn't just an engine. It's the global backbone for everything from hyperalistic mobile experiences to the latest frontiers in external reality and driving environments. In 2026, studios are not looking for button pers who only report symptoms. They are looking for specialists. Can navigate the universal render pipeline, understand the logic and the buck, real time systems on the fly. As the industry moves towards more complex tdural and AI integrated worlds, your ability to speak unity is no longer just an advantage. It is your survival kit. Most testers operate in what we call black box. They see a buck on the screen, they report the symptom, and they hope developer knows how to fix it. In this course, we are breaking the box open. We will start by mastering the unit architecture. You want just look at the character. You will understand the relationship between them objects and components. Master Dan Spector learning to use Tibug mode to expose the hidden variables developers often tuck away from the surface. We will use the scene hierarchy as our map to navigate the local logical structure of any project. Once we understand structure will move to the forensic toolkit. We'll dive deep into the physics metrics, solving the mysteries of why objects pass through each other legos or a simple pickup acts like a solid brick wall, but a game that works in only half the battle, it has to perform. I'm going to show you how to weaponize the UIT profiler. You will learn to read CPU spikes and memory leaks with surgical precision. You would not just report the game slide. You will point to the exact script or asset that's killing the frame rate. You will be the person who brings the solutions, not just problems to prove your skills. We will perform a full rebox audit on a sabotaged first person shooter project. Personally hidden five critical logic failures in this build. You will solve the Sonic crouch by audit and arithmetic. You will fix the plane guard by catching hard coded value arts. You will notice the inverted barred by identified mass errors, the UI scripts. This is where you move from testing to root cause analysis. By the end of this course, you won't just be a tester. You will be a technical partner to developers. Someone who speaks their language understands that 2026 tech stack and earns their respect. If you are ready to stop guessing and start deconstructing, let's get to work. Welcome to the course. 2. The Role of QA: Hi. In this lesson, we'll talk about something very important. Why a que engineer should even bother learning unity? At first glance, it might feel like your job is just to test the build, run the game, and gauge box. So why open the engine, dig into SNS components and the console? Let's start with the context. Unity is one of the most popular game engines in the world. It's used for mobile games in the projects on steam, Apps, and even simulations and educational products. You're aiming for a career in in depth, chances are pretty high that at least one of the projects you will work will be made in unity. Unity is not just a program where things move on the screen. It's a whole ecosystem, themes, prefabs, components, scripts, logging, profiling, test runners. And a QA who can navigate all of that instantly becomes much more valuable for any team. To make it clear, let's compare unity to Unreal engine. Unreal is used more often in large projects and AAA games where you need top tier graphics and very complex materials. The entry barrier is higher. There are tons of settings, and usually the team has dedicated technical people working with the engine. Unit, on the other hand, is more about speed and flexibility. It's easier to start with, easier to find open source projects, examples, plugins and tutorials. For QA, this means, you can relatively quickly learn how to open real projects, see how they're built and even reproduce bugs without any magic. Now, the most interesting part, what kind of unity specific box QA can catch if they understand the engine a bit. Example, the play button in the game does not work. A tester with no unity knowledge might just write. Play button doesn't work. A QA who can open the thin, check the canvas, and the inspector might notice that the button has missing script or the onclick event is not configured. Then another example is the player falls through the floor. A less experienced QA might say physics is broken, but a QA who understands the structure will open the project and check if it has a collider, if it is on the right layer, and if the physics settings are correct. You see pink models or pink squares instead of textures. That's a unity classic missing or broken shader material. Instead of the graphics are broken, you can immediately point out that it is shader material issue. What does this give to the team? First, you save developer's time. Instead of age it doesn't work. You provide a more precise description where exactly the problem is and under which conditions it appears. Second, you can better prioritize box. You understand where the critical object is and where it just a visual glitch that doesn't block the player. On top of that, Unity gives QA access to powerful tools. The console logs, the profiler for performance, data strunner for automated tests, addressables, for checking, content loading, and much more. We'll go through all of this in the course, but the main idea is simple. A QA who knows Unity stops being the person who just clicks through the game and becomes a real part of the technical team. In this course, our goal is to turn you into exactly that kind of specialist. And we will start with the basics. Installing unity, creating your first project, connecting it hub, and setting up a working environment. You can use practice throughout the course. In the next lesson, we will move from theory to practice. We will install Unity Hub and Unity Editor and create the first project we'll use later. 3. Installing Unity Hub: All right, let's move to the practice. In this lesson, we'll go step by step through installing Unity Hub, adding the right version of Unity Editor, and creating your first project. We'll start with the Unity Hub. Unity Hub is a kind of manager for engine versions and projects. You will rarely launch the editor directly. Almost everything goes through the hub. First of all, you need to open your browser and go to the official Unity website to the download section. We're looking for Unity Hub. Download the Installer and run it just like any other application. After the successful installation, just open it. This is your first time, it might ask you to sign in. You can create a free Unity account that will be more than enough for learning and the most IT projects. Next, we need a Unity version. In the Install step, click Install Editor. For learning, we'll use a LTS version. For example, Unity 2021 0.3 LTS, LTS stands for the long term support, stable branch without some experimental features. A, this is perfect. Few surprises. Before installation, the Hub will suggest died modules. This part is important for testers. You need to make sure that you select Windows Build support or the platform you build for. If you plan to test mobile builds at Android Build Support right away. This will save you time in the future lessons. After that, simply click Install and wait. Depending on your Internet speed and your PC, it might take a few minutes. Once the editor is installed, we'll create our first project. In Unity Hub, go to the project step, click New Project or New. Choose a template. For this course, we'll use three D core template, a basic project without extra systems. Give your project a clear name, for example, Unity QA demo and choose a folder where it will be stored. Unity will import the initial files and open the editor window. You will see the interface, scene, game, arch inspector project. We'll explore each of these in more detail in the next sections. But for now, there is one key thing. The project has been created successfully. You can hit the play button to make sure the scene runs. At this stage, check if there are any red errors in the console, if the scene runs without crashes, if the interface looks normal. This is already your first small test of Unity project. In the next lesson, we will let another important part of your working environment. You will see how K uses git, track changes, and why it's important even if you're working alone. Now I'm going to show you how to open the project. Once you have installed the Unity version, create project. You simply click on your project name and run it. Once the unit you will boot your project, you will see here the ERRchy, the game theme, project, console, inspector Profiler, and many other. We will dig into them in the fuser lessons. But for now, you just need to select some scene, for example, menu, click Play and play. That's it. 4. Adding Unity project: Come back. In the previous lesson, we successfully installed Unity Hub and created a blank template. However, as you might have noticed at the very end of that video, I launched a fully finished working project to demonstrate the engine's capabilities. You might be wondering where it came from. Today, let's figure out exactly how I did it. In the real world, you will rarely start with a blank screen. Usually, you join a project that already exists. So in this lesson, you will learn how to get an open source project from GitHub and launch it correctly on your machine. First, a quick word about projects live. Developers don't pass games around on USB drives or via Google Drive. Code lives in repositories. For a Q engineer, this is critical. You need to know how to get the latest version of the game to test it. We will be using Github. It's the industry standard for Weston code. Think of it as a library where all the versions of the game are stored. For this course, I have prepared a link for Demo project. Check the lesson description. On the repository page, look for the green code button. You have two main options here to download deep. This simply downloads the project as an archive. Or to clone. Clone is the professional method using I commands to link your computer to the seller. To keep things simple for now, let's select download Zip. Download T and unzip to the folder computer. And one crucial tip, make sure the folder pass does not contain non Latin characters like Kirilk or special symbols. Keep the past simple. For example, Unity demo. Now let's feed this project to the Unity Hub. Open the Hub. I already have it open it. I go to the project step. Instead of clicking a new project like we did last time, click Add Ad Project from Disc. And locate the navigative folder, you just unzipped. Important. You need to select the specific folder that contains assets and project settings folder inside of it. If you select a folder level too high or too low, Unity would not recognize it as a valid project. Once selected, the project will appear in your list. Now, look at the editor version column. It is located here. In QA, this happens all the time. The version of Unity installed on your PC is different from the version the developer used to make the game. You might see a worrying icon. If you have the exact version installed, that's great. If not, Unity Hub will suggest opening it with your current version. Click on the project name, it will ask change version or upgrade. For our learning purposes, click Change version and select the one you installed in lesson two. But please note in real job, upgrading the engine can break the game, but for now, it's fine, you will see something like that window, and you can select any version you would like. But it is better to stick to the version of the build. As you click on the title of your project, the engine will be launching. It looks like that. The first time you open a downloaded project, it will take significantly longer than usual. Unity needs to import assets, convert textures, and compile scripts. You might see window saying resolving packages. This is normal. Just wait a bit. If you see a window called safe mode, it means that there are compilation errors in the code. This is a major red flag for a tester, but if the project opens normally, you are good to go success. The project is open. Check the console tap at the bottom. Are there any red error messages? Next step will be finding the scene in the project window here, look for the scenes folder and open the main file. Usually, it's called level one, game or main. In that case of that project, you can taboo clic condemn you. And it will open the starting scene. Then just hit the play button at the top. And if the game runs, the character moves and nothing crashes. Congratulations. You have successfully set up a working environment. You know how a live working project with real code and graphics, not just an empty template, but looking at the screen, it can be overwhelming, arch, vector, project window. What do all of this do? In the next lessons, we will take a tour the Unity interface, specifically from a QA perspective. We will learn where to look for box and how to navigate this complex tool, see you there. 5. Adding Unity project via Fork: Come back in the previous lesson, we downloaded our project is a simple Zip file. That was the quick and dirty way. And today, we're going to download the exact same project again. But this time, we'll do it in a professional way. We're going to clone it. Why? Because the loading Zip is a one time thing. Cloning creates a live link to the server. If the developers update the game tomorrow, the deep user has to unload everything again. The clone user just clicks on button to get the updates. To do this, we need a Git client. I will be using Fork. This is fantastic tool for Windows and Mac that visualizes the history of the project. If you haven't started yet, pause the video and unload it now, it's free for evaluation and perfect for our needs. Let's go back to the GitHub page of our open source project. Look for the green button that says code as we did in the previous lesson, click it. You see here some link. You need to copy it. This is DDPs link on the server which contains the code for that project. Let's open the fork again and clone that project. Here in the file tap, you can see clone button, simply click it, and the program will automatically detect your clipboard. Then just select the destination folder. You would like, put the name, but I suggest not to change it and click Clone here, the fork will start automatically downloading on the project in the mentioned folder. You will see something like progress bar and the words sets that loading some scripts downloading, et cetera. Just wait a bit. This project is not too complicated and overloaded, so download should not take more than 5 minutes. Fork is not just downloading the files, but the entire history of the project. Every change the original developers ver made, once it finishes, you won't see just a list of files. You will see a commit history like here, this is a beautiful graph son who changed it, what and when. This is why we use fork. As a QA, if your back appears, you can look at this graph to see what changed recently. Once the project has been loaded, just check the folder on your computer that you set. You should see the assets folder, the product settings folder, and some files like GIT, never touched ID files because they are the brain of your repository. If you delete them, the link to the server will be broken. After all, you should launch the Unity Hub, click again at from repository. Let me get to the folder you just downloaded, created, and run the process again. Your project will appear here in a few seconds and you will be able to run it. And we are in. You now have the exact project I showed you, but connected to the real repository via work, you are now set up like a real developer. In the next lesson, we will have a small practice. You will be needed to run everything we did to have the same project that I have. So in the fuser lessons, we are able to be on the one wave. 6. Assignment: Have covered a lot of ground. I need to help editors, Hub, fork, and cloning. Now it's time to stop watching and start doing. In the lesson, your assignment is to replicate exactly what we have done so far on your own computer. This is critical because you cannot learn K. Just by watching videos, you need to build muscle memory. What you should do Install Git download and install the common line tool. This is a backbone of your reversion control. Then install client like fork that I mentioned in the previous lessons. Ensure Unity Hub is up and running. This is your gateway to managing unity editors projects. Go to the Github page of the open source project. Check exactly which the project requires to avoid compatibility issues. Unity Hub, install that specific editor version that project requires, and remember to include Windows build support that will be needed in the fuser lessons. Then colon the repository using fork. Try to evodTip and load method. You want to practice the professional overflow, add the project to the Unity cup and launch it. If the project opens and you can press without crashing, you have succeeded. 7. Main Unity elements: Welcome to the Section two. We're going to explore the Unity interface using our D platform or project. Looking at these panels can feel overwhelming. But every window here has a specific job. As a QA engineer, you not need to be an artist or a corder to use them. You just need to know which window gives you the data you need. First, the big window in the middle is the scene view. This is your three D or two D workspace. It shows the game world exactly as it is built, including things the player cannot see. The main goal of it is visual inspection and navigation. This is where you fly around to check level design, find invisible barriers or look at enemies that are waiting off screen. Move your mouse into the scene view, called right click to pen around. Find the snowman and ice box. Notice the white box outlines around them. Those are colliders, invisible to the player, but visible to you here. Move to the left side, the ear arch window. What is it? This is a text list of every single object that currently exists in the open scene. Main goal of it is locating objects. If you can find the coin in the visual chaos on the sinew, you search for it here by name. You can simply type a player and find the exact player. He exact location in the scene. You can expand now, look to the right, the inspector window. This is the property panel. It shows all the settings, numbers, and logic attached to the object you selected. Main goal of it is verification and manipulation. This is where you check if the hell actually 100 or if gravity is enabled. Use this to change values while the game is running test box. Let's select Ice box, and with Ice box selected, look at the components. Transform, shows position, x that. This tells you exactly where the object is, what coordinates have. Spread renderer shows the image. You can test it by changing the color, let's say to the red and see that ice cube has changed. And let's move to the rigid body. It shows physics. You can uncheck the simulated or change mass. If the box feels too heavy in the game, you check this number to prove it. Now look at the bottom, the project window. This is your file browser. It shows every file sitting on your hard drive for this game, each script, sound, image, or prefab. The main goal feed is asset management. Unlike the ERRch which shows what is in the level. This shows what is available to use in general. For example, let's open prefabs. Use here ice box that we change it. Snowman and to trees. If the level feels empty, you can drag a tree one, let's say, from here into a scene to verify if it's a level design issue or a technical issue. And finally, click the tab at the top code game. This renders the game exactly as the player will see it. Main goal of it is simulation. This is where you test UI placement, camera spector ratios, and what actually visible on screen versus what is hidden. Switch between SN and game taps. Notice how the zone box disappears in the game view. That's because the game hides the bucTolsT the cap. SN is where you look around. Erchin is the list of what's alive. Inspector shows you details and settings. The project window is the library of your files, and the game tab is the final output. In the next lesson, we will dive deeper into game objects and components to understand how a player is actually built. 8. Object and Inspector: Back in Unity, everything you see the fox, the coins, the ground is called a game object. But here is the secret. A game object is really just an empty container. Think of it like a cardboard box. By itself, it can't move. It can be seen, and it has no physics. To prove this, select the ice box in the hierarchy and look at the inspector. See the name at the top. That's just a label on the box. To make this box actually do work, we have to put things inside of it. These things are called components. Every single game object has one mandatory component, the transform. Basically, this component answers the question. Where am I? Is main goal is positioning at sizing. Without it, the object wouldn't exist in the universe. See it in action. Look at the transform component of the ice box, find the position Y value, hover your mouse over the Y label and track it left and right. You see the box moving up and down in the scene. You're directly changing its coordinates. Why does a QA care? Well, when a player reports a bug, saying, the crate is floating in the air, you don't guess. You looked right here. If the Y value is incorrect, you know it's a placement bug. Now, how do we actually see the box? That is the job of the sprite renderer. This component handles the visuals. It tells Unity exactly which image file paste onto our cardboard box. Look to the inspector again. You see the sprite fields, says ice box. That's the image file. Tread this. Click the small checkbox next to the names Bright renderer to turn it off. The box vanishes. But notice the game object is still selected, the container is still there, but the paint is invisible. Here is the QAus case. Invisible enemy box happened exactly like this. The object is still running, the enemy is still attacking, but the renderer got disabled. Now you know where to check. So we have a box and we can see it. But does it feel real? That is the job of the reheat body today. This component as physics simulation, specifically mess and gravity. Check the settings. The mass is set to one. If you change this to 100, the box becomes incredibly heavy and our fox might struggle to push. Also look at gravity scale. It is set to one. If you set this to zero, the box will float away into space like a ghost. Let's check this. You see that the ice box it just disappear because as I said, it just float away into space. For QA, this kind of knowledge is critical. If an object falls to the floor or acts weirdly, taking the rigid body is your first step. Usually someone forgot to turn on simulate it on. Finally, let's talk about relationships. Game objects can actually hold other game objects inside of them. This is called parenting. Go to archy and find the player. Oh Fox. Click the arrow to expand it. See those objects inside. The ground check, light to D footsteps impact effect. The fox is the parent, and these are the children. The main goal here is grouping. Wherever the parent goes, the children follow, try moving the player object. Notice that light to D moves perfectly with him. This is huge for QA. If you see a buck where a weapon is floating ten feet behind the character, it means the child object that moved away from the parent. The link is technically working, the offset is wrong. So to the game object is the container. The transform places it and the render throws it. The rigid body moves, the object, and the parenting glues them together. Now that you know how objects are built in the next lesson, we will perform some digital surgery to break them intentionally. 9. Character details: Hello again. In the last lesson, we build an object. Today we're going to do the opposite. We're going to perform digital surgery on Fox character. As a queue engineer, you don't usually build the game. Your job is to dissect it to find out why it's broken. We're going to take our fox and disable his vital organs one by one to see exactly how specific box happen. First, press play. Let the fox settle on the ground, then play pose. Select the player in the ear arch. And look at the transform. This component is the object GPS. Is main goal to track location. Let's mess with it. Hover over the position viable and drag it to the right. See the fox float into the sky. Now pause, he falls back down. Here is the QAuse case. When you write a bug report like player stuck in the wall, never just say stuck. Look at this component. If you write player stuck at coordinates X, then Y three. You just save the developer 15 minutes of searching, give them the exact map coordinates of the bug. Now let's look for the visuals. You might notice the player object itself doesn't have a picture attached. Into the games, developer often put the art on a child object. Expand the player arrow. We have already expanded and select the child named SR, which stands for sprite renderer. This components only job is to throw the fox and check the box next to sprite renderer. The fox disappears, but look at the game view. The camera is still moving, right? The logict is alive, but the ghost is invisible. Let's turn it again and eat here. Q scenario is the invisible enemy bug. If you get attacked by nothing, it means the enemy exists, but the specific component failure to load. So you can simply find in the Ear arching the enemy. For example, check its sprite renderer if it's a turn one. Now please reenable sprite so we can see him and select the player parent again. Find the capsule collider to you see that green outline around the box in the scene view, that is his solid physical shell. While the game is playing, I checked the clutter component, and he falls straight through the floor into the void. If you ever see a buck where a player walks through the lock door or falls through the ground, 99% of the time the collider component was accidentally disabled or resize it to be too small to show you exactly what is the capsule collider, you can move to the scene, navigate zoom in to your fox player and turn off capsule collider. This green thing is actually your collider. It will be set up by developers or artists, so you could not never touch it. Just check whether it appears or not. Finally, let's look at the brain. Find the script component, likely named as player controller or moment. We can see here player controller. This is where the developer exposes the game rules. Find the arable like move speed. Currently, it's set to eight. Change it to be 40, right around the game. Um, at first, you need to stop the game, set 14, and run it again. Now, you will see the extremely high speed of the fox. These can be called small stress testing. Can the players keep the entire level if they move too fast? Does the game crash, I jump force is set to zero, you test these limits right here in the inspector. And finally, to recap our surgery, you can check transform for coordinates a cup, renderer for visibility of your object, collider for solidness, and scripts for game balance. Next up, we look at the prefabs, the blueprint system that let us create an army of snowmen without building them one by one. 10. Basics of Prefab: Bag, imagine that our level has 50 trees. The game designer decides. These trees are too small, make them double size. If we didn't have prefabs, the developer would have to click 15 different trees and resize them one by one. That's a nightmare. Instead, Unity uses prefabs. Think of Prefab as a master rumbertmp. You change the stamp once every single stamped image the game updates instantly. For QA, that means that fixed in level one can accidentally break level five because they share the same stamp. Do you know if an object is a prefab? Look at the text color. As you can see, some text is black or white. This means this is unique object. It exists only here, for example, point to the snowman. The text is blue, blue means linked. It means that object is just a clone of a file on your hard drive. Give a warning. If you see an object that should be a prefab, you're 100% sure it's a prefab, but the text is black or gray. It means the link is broken, the enemy would not get any future updates. Call this unpacked. So where is the master file? Select the snowman in the ER archie. Look at the top of the inspector. See the line says Brief up. Yeah, right here. Click the button and say select. Unity jumps to the project window and highlights the snowman file. This file is real object. The Van scene is just a ghost. And the use case for you is like if you find a bug in the Snowman'sE art, check this file. If the file is wrong. Every snowman in the game is wrong. Now let's do some magic. Double click the Snowman file in the project window. The background turns blue. We are now in the pre filed mode. Select the snowman here. And change its scale to, let's say, two, two, and two. Now click the B icon here and see that every snowman now is a giant. This is how regression box happen. A developer changes a prefab to fix a specific level, but forgets that the same prefab is used on ten other levels where that change breaks the game, and your mission is to catch such box. But what if you want just one specific snowman to be tiny? Select one specific snowmen in the scene, change the skill back to one, one, and one. Look at the Spector numbers. They are a they was. But if we put new numbers, they are bold. This is called override. It means I'm still a prefab. But for this specific setting, I'm ignoring the master. Use case here is, if developer says I fix the boss health points, but the boss in the level three still has the old HPA. Check if the HP number is bold. Someone might have manually overridden in the specific level blocking the update. To recap, blue is a prefab. That's good. But black is unpacked, risky thing. Both numbers or text is an overwrit local thing. 11. Search Bars: Welcome Inter Lesson five. In real project with thousands of files, you can just scroll through lists. You need to use the compute tools to find exactly what you need. Today, we will master the search bars and the secret TBC mode. Let's start with the Erg. Click the search bar at the top of it and type Ice. Not just that ice box remains bright, but everything else turns gray. This is the fastest way to check level content. Imagine the designer says, I put 50 coins in this label. Instead of counting them, just type coin. If the list shows only 40 items, you know, ten are missing immediately. Now let's see the project wn go. This is your file atabase. You can search by name, but as a QAP, you should search by type. Click search bar and type exactly type Prefab. The window instantly filters to show only the blue cups, ice box, no man, trees, it hides all the scripts, sounds, textures, and other things. This is in amazing tool for the asset audit. If you need to find every single sound file or prefab to check for Samson, you simply type as we did. Type prefab and see all prefabs that project has. Now the coolest trick debug mode, select the player object. Look at AIDS inspector. You see the nice clean sliders developer build. But sometimes data is hidden. Click the tiny three dots at the very top right of the inspector tab. Select Debug mode. The inspector changes. The nice sliders disappear and you see raw variables. Look at the rigid body to D. You can now see internal physics data like velocity that was hidden before. Sometimes the fox refuses to move, but you don't know why. Switch to debug mode. If you see the velocity is not a number, you know, the physics engine has crashed. Let's check the console. Click the button called error pose. This is your kind of trap. If you enable error pose, the moment a red error happens, the game will freeze frame automatically. This is perfect for crashes or some start bucks. If the game breaks, the instant pound, error pose catches the exact frame it happens so you can see what's went from. We will talk in detail about the console in the next lessons, but this is kind of light recorder that you can use to catch some crashes. 12. Additional debug features: Welcome back student. As a QA, you have two eyes. One eye looks at the game view. This is what the player sees. The nice art and the fox, the other eye looks at the scene view. This is the matrix, you to the logic, the invisible valves, and the traps. Today, we learn to switch between them to catch visual box. Let's start in the scene view as we are. Select the snowman in the Ear arch. Now imagine this level is huge and you can't find him. Hower your mouse over the SNU and press F key. The camera snaps instantly to the nomen. F stands for focus. This case could be like this is your Teleport button. If a buck report says gleich on coin number 45, you don't search for it. You select coin 45 and hierarchy, press F, and order. Now let's look at the Kell Zone box at the bottom. It might be hard to see. In the sinew Tubb, click the Kismus button. The small globe suddenly outlines appear. You can see the green box around the player colder and the red box for the zone. This is how you find invisible wolves. If the fox is hidden something in the empty air, turn on Gizmus. You will likely see a straight green box floating there. Also, by highlighting the Gizmus, you can simply move the objects. The center and move. Now the whole object moves with your cursor and now switch to the game you. This is the player screen. Look at the toolbar. It probably says free aspect. Click the drop down. This allows you to simulate different screens. Select full HD. This is kind of standard monitor. Now, select let's say 16 to nine. You will simulate another aspect, and use case for you could be, for example, you have the game with a coin count, I you see it is cut off the screen. First of all, you can try changing the aspect ratios different. To verify that the buck is with the aspect. Let's check some kind of ultimate debugging tool. And you hit the play, make the fog jump by pressing spacebar and immediately press Pause and now click the button next to pause the step button. Click it a few times. The game advances one single frame at a time. Why this could be handsome for you. If you see a glitch, like the animation popping or feed clipping through the ground, and this is how you prove it. You catch the buck in a slow motion, and to recap everything we spoke about, you can use F to teleport kisms to see invisible walls and move items then resolution settings to check the UI. 13. UI. Canvas: Welcome to the Section three. We're moving from the game world Fox and Snowman to the interface. Score buttons and menus. In unity, UI doesn't just float in the air. It lives on a specific object called the canvas. Think of the canvas as a giant sheet of glass placed in front of the camera. Everything painted on the glass is UI. If you don't have a canvas, you can't have a single button. Look at your ear arch. You see the object named Canvas, select it. I already did this, so on the screen, you can see the canvas opened. You see scene view, Canvas. Now let's look at this scene view. You might be confused. The canvas looks like an enormous thing compared to the outer level. That's normal. Look at the inspector component called canvas. The random mode is set to screen space overlay is located here. As I'm pointing out, this means that I don't care where the fox is. I don't care about TD space. I will simply page this I directly onto the player's screen. Here we can have use case. This is a standard for menus and hats. If a B report says this menu is clipping the walls, it means render mots room. It should be overlay which puts it on top of everything. Let's see how it looks in the game. Here, you see these hearts, these coins, and here it is just like that. So it simply overrides the scene and places on top of our game. In some cases, you want the UI to have three D depths like particles flying in front on the menu. For that, developers use screen space camera. So we can simply change. And if you switch to this mode, you need to ask which camera? You need to track here main camera. In this open source project that we are learning on, we don't have camera. So you can try this by downloading some another project which will contain some scenes and render camera. You will see here Sandro Domino and you can select here the main camera or camera or something called camera. Slot. And the case for the QA would be like if the UI suddenly disappears or gets covered by game objects, for example, Trepan in front of the score can check if the developer used camera mode, but probably forgot to assign some camera. It is a common missing reference back. Also we have here the third option world space. This threads the oil like a normal object in the game. It gets small, it rotates and the fox can walk past it. We use this for health bars that float above the enemy's head. Some kind of QU case would be if you see a float in the space that is huge or upside down, it's WorldSpace canvas with a patterns form. For now, let's switch back to the overlay. Because we want our coin counter to stay stuck on the screen. In conclusion, the canvas is the root. If you disable the canvas object, the entire UA vanishes. Let's try this out. We have here canvas games in. If we turn it off, we see that our coins and hells bars just disappear. 14. Rect Transform: Come back. Let's select the player, the Fox. As you can see, he has a transform position X, Y, that. Now let's select a UI element like let's say $1, a coin. As you can see, it has wrecked transform, not regular transform. It's just because UI doesn't have a position, it has a width, height, and the most importantly, anchors. Why do we need anchors? Let's imagine you place a coin counter in the top right corner of your PC monitor, and now you play the game, let's say on iPad or Smbile. The screen is shorter. The coin counter might end up of screen or floating in the middle. That's why anchors are important thing to maintain before the release, let's say. For example, you have set your anchors to zero. Now let's switch to free aspect. It's gone. It's go off screen. You see it is changing its position because it's not linked to some point, let's say, on some iPad or mobile device or even strange aspect ratio, this icon could just be off screen. Your task as a tester is to verify that encores are set up and on different resolutions, you can see the icon placed where it should be by design. To check if the anchor is set in direc transform, you can click in that square, select Center, for example, and also for the image, and try to change aspects. As you can see, it is not going off screen, but on the free aspect, it's still kind of upper by height by position. So you should verify with the designer where it should be. The thing you should remember is that standard transform is for the games itself for the levels, for the characters, for the ice cubes, no man, coins placed on the level, et cetera. But wrecked transform is for the UI, and encores keep things from drifting away. In the next lesson, let's look at the actual elements, text and images. 15. Buttons, Icons, Text: Finally, let's talk about the pattern. To find it, you should go to the scenes, open the menu scene and see that two dial Ma platformer play and cute two buttons in the Ear arche, select play and see here the pattern. Button is usually just an image with a script attached. As you can see, here is the button component and image. We have no image, no spread attached, so it just filled with white square. As you can see, try a lot of states of the button. Like normal color, highlighted color, pressed color, selected color, disabled color, some multipliers fades and other things. Now we see the normal color. We can change, let's say, highlighted color to be red and pressed color to be green. And now we should see when you highlight the red. And when you press, I press my left mouse button. Green color. So it simply changes the colors, handles all the colors here in the button script. Kind of Kuse case would be if you disable a button, but it still looks clickable. Check the disabled color. It should be gray. If it's still white, the user will be confused. So simply we have disabled color and gray. Let's stop the play mode. Let's change it to kind of blue to differentiate. And to make this date like disabled, just click that interactable button. If you uncheck this field, it means that button is not interactable. So it is disabled, it touches disabled color as we decided it would be blue. So now if you will run the game, you will not be able to click this button at all. To wrap up what we said above is images. They show art. Text shows data, buttons, handle clicks. But what happens if you have a button, but clicking it does nothing. It might be blocked by ghost. Let's talk about recast in our next lesson. A object is usually just an empty rectangle until we had an image component. Select one of your taller objects in the canvas. I selected this one. This one. Let's look at the inspector. As you can see, here is source image. In this slot, the coin sprite leaves. You can change it on any kind of sprite you have in the object. But let's keep taller one. And let's look at the image tag setting. It's a bit lower. As you can see this ton, we have simple sliced, tilted and filled. Simple, it just draws the picture. Slice it. Used for buttons, so borders don't get blurry and stretched. And field is used for health bars. Kind of DIU case would be if the health bar isn't draining, you need to check if the developer forgot to set the type to field. If it's set too simple, scaling it will just squish the image. Let's look at some examples of image types. So as I said, simple, draw the picture. Slice it is used for buttons. So in such case, it would not be visible. It should fix the borders so they don't get blurry and stretched. As for the tilted, you can see that it throws some kind of pixels per unit. Increasing the value will increase the amount of in icons placed inside of this slot, and the last one is filled. This one does some field amount like radial field. You just see we can do like half the icon or full icon or any kind of another solution. Now let's select a text object, go and pick up text in the arch. You see it highlighted, so let's type in the text field some long sentence. Let's say, square 099999. The text in this scene might just disappear or get cut off. This is controlled by horizontal or vertical overflow. This setting. As you see, by changing the method of overflow, the text is showed by another truncate. Let's say just cuts the text that isn't in the box, like hides it. Yeah. The overflow does nothing. The ellipsis shows like dots mentioning that some text is hidden and many other things does the same. Use case here is localization issues. If the game is translated, let's say to German words are really long, the text might break the UI. You can test this by typing some long random string into the inspector, into this field, like I did to see if the UI explodes or not, and by changing some overflow settings, you can also verify this is a B. 16. Raycast: Welcome into lesson four. How does Unity know you clicked the button? It's simple. It shoots a laser or recast from your mouse cursor to the screen. The first v element, it hits, it clicks. But here's the tanger. Some transparent items can block that laser. Let's verify that. On the same scene menu in the scene view, select the play button. Here you can see on the image, under the image recast target with two states checked and unchecked. If it's set to checked, it means that I can be clicked, I block the mouse. If unchecked, I'm a ghost. The mouse passes through me. QS scenario is imagine, you have a level complete screen that fades out. If the screen is invisible, like Alpha set to zero, but Recas target is still checked, it acts like an invisible glass wall. You won't be able to click anything in the game. If you ever report a box saying, I can't click the Starkm button, do this, look at the ERT. Is there panel or text below the button in the list? Like we have Play button. Here we have text and verify if, does that object have recast target checked? You select text, you move to the inspector, extra settings. Recast target. Yeah, it is checked. In some cases, that could be the blocker. The button is fine, but it's been covered by some invisible shield. So q rule, any image that doesn't need to be clicked, like in I context, you should usually have recast target unchecked to improve performance and prevent box. So the recast target determines if an object is solid to the mouse, but who actually calculates the click? That's the job of the event system about which we will talk in the next lesson. 17. Event System: Hello, look at your ER arch. You see an object called Even system. It usually sits there quietly ignored. But the object is the power cord of your UI. It has components like standalone input model. It listens to your mouse, keyboard, and touchscreen. Let's see what happens if you lose it. Select the even system, press delete, and press Play. I'm clicking the Play button, cute button. So another clicks. That doesn't work. Nothing happens. The jo is dead, like the visuals are there from canvas, but the brain is gone. The Ius case is if you lower the level and none of the buttons work, check the ararta D developer accidentally delete the even system, or maybe they have two even systems fighting each other. Now just press control that to undo our deletion. And look what we have here. We have here horizontal lexis vertical lexis some other things. And let's talk short about horizontal axis and vertical xs. These things, they are mapping the UI navigation to your WASD keys or controller joystick. And the use case here might be if a player says, I can't navigate the menu with my Xbox controller. You can check here. Is the input model set up correctly? Are all of the headings are present? Also, this object handles touch input for the mobile. Without it, tapping the screen dust mask. This one. So you need to check the Sandal input model if everything is here. Let's recap a bit. The event system is kind of simple. You need exactly one. No more, no less. Canvas holds the UI, anchors keep it on screen, Recast target blocks the mouse, and even system listens for clicks. Now you are ready to test the front end of any game. In Section four, we will start digging into the code. See you there. 18. Player Controller: Welcome to the Section four. Up until now, we have treated the game like a black box. We click buttons and hope they work. Now we're going to open the box, select your player object in the ER arch. And find the player controller script. This is the brain. It tells the fox how fast to run, how high to jump, and when to die. To a developer, this is a text file. To you, it is a control panel. Look at the settings exposed here. We have more speed, jump force, double jump force, and many others. These are the public variables. Developer intentionally created these sliders so you can tune the game. Let's use them to break things. Let's press play Let's change, move speed. Let's say two T, press Enter, and try. The fox zooms across the screen instantly. That's because we just changed one variable. This is kind of stress test in this case. You might ask, if the player gets speed boost power up, will the eclipse the walls? You don't need to ask Dev to make a power up. You just simulate it right here by changing simple variable. Look further down in the setting called control mode. I now is set to PC. Click the drop down and you can see the mobile. This variable is NAM. It acts like a switch. If you're testing the mobile UI on your computer, don't just guess. Switch this to mobile. The script will see this change and enable the touch screen options. If you report, mobile controls don't work on PC Editor, check these settings at first. But what about the logic? You cannot see. In this script in the code, there is a variable called I grounded bull. The game uses is to decide if you're allowed to jump. But look at the inspector. It is missing. That's because it is private. What if you have a buck where the fox refuses to jump? You need to know if the game thinks is he grounded. Here is the trick. You can switch to the debug mode and see that it exists. You can see that it is great out and you cannot change anything here. As I said, it is a private variable, so you cannot work with it, but you can use it like Xray. If you play the game you can see it became checked. It is because you are standing on the platform that accommodates you as you are grounded. It allows you to stay on it. One last check. Look at the player Anim and footsteps. If these slots ever say none or missing, the game will crash the moment you try to run. A rule is to always check for none in the script slots before you press play. These kind of properties that are set by designers or developers. So you should not tie them, but you can simply check if they are assigned in their slots, not causing the errors in the console. Let's recap a bit. Public variables let you kind of stress test the game. Debug mode reveals hidden logic like we had is grounded bull. In the next lesson, we will look at the code file itself to understand when these checks happen. 19. Player Script: Come back in lesson two. In the last lesson, we changed variables in the inspector. Now let's look at when these changes actually happen. Let's open your player controller script. You can do it either by finding script in the project right here, or if you have inspector open it, you can write Mouse button, click Edit script. And it will open. It will ID. Please know that you should have some ID on your device so it can be processed. When you installed Unity, there was a check mark to install Visual Studio. If you haven't done that, you can simply move to your Unity Hub, proceed to install the installs and install Visual Studio or just download on Microsoft website. Find in this script private void star. This is the setup phase. You need to run this block exactly one time. The framed object is created. Look at the code inside. This means that the script is gathering its tools. It grabs the physics and the particle system. Here is the QAS case. If the game crashes immediately when they level loads with a no reference exception, it's usually here. It means the fox tries to grab his footsteps particle system, but it wasn't there. If the crash happens instantly, look at the start. Basically, you might not even look at this. You can just describe this in your bug report to navigate the developer at exact point. This will save time for him to fix these. Now let's look at private void update. This is the game loop. This code runs every single frame. If your game is running at 60 FPS, this code triggers 60 times per second. Look at what is inside. It is constantly asking, are we on the ground? Did the player press jump? As case here is where performance box hide. If a developer puts a heavy calculation here, the game will lag because it tries to do it 60 times per second. So if you see an error in the console that counts up like crazy, one, two, 100, 1,000, the error is inside update. Let's trace it back. Look at lines inside update. Is grounded bull can double jump equals true here. This logic says, if we are touching the ground, a recharge stable jump. Imagine a box where the player can jump infinitely. You would look here, is this property getting stuck as true. If so, the game things you're always on the floor, so it keeps giving you infinite jumps. Let's look at a dead code. Scroll down to the public void hoot. This code is commended out with slash this means that shooting system is not working in the game. If you press the shoot button and nothing happens, Junior QA might say button is broken, but Senior QA looks at the code and says the logic is commented. The feature is not implemented yet and you just saved an hour of debugging. Let's recap if you look at start, it means that the game runs once. Crashes here happen on lot. If you look at update, it runs forever. Errors here, samdiconsPublic functions, controls exposed to the UA. In the next lesson, we will look at the stack trays. The treasure map that tell us exactly which line of d exploded. 20. Console functionality: The last lesson, we looked at the code. Now let's talk about what happens when the code breaks. When unity crashes or throws an error, it doesn't just scream help. It leaves a detailed map of exactly where the crime happened. This map is called the stack trace. To understand it, we're going to intentionally break our fox with a fake error. Open your player controller script. Scroll up to the void start function. Avoid start function. We're going to add a line that forces Unity to report the failure. Inside of brackets of start between these two, you need to add deadline the budt Log error, some texts BQA test system failure, and press Controls to save these changes. Then let's go back to Unite. You need to play the game, press Control R to update old scripts, then press Play again. And immediately, you will see a red error appear in the console. You can pause the game or just continue looking at it without pausing. Let's look at the console interface. You have here clear collapse, error pause, and to drop down. Clear. This button wipes the history. Use it if you have old errors confusing you. Collapse. If you click this, identical errors stack up into one line. If you see a number like 999 plus, it means that happen in every frame, likely in the update, and error pause button. If you turn this on, the game will freeze the exact millisecond and error happens. Let's click on the red error message to highlight it. Look at the text box at the bottom of the console. This is a tag trace. You read it from top to bottom, the message. The top line says, QATest system failure. This tells you what exactly happened, the location, and look at the end. It says the root, the place where that error happens. Exactly at the line 53, let's open the Visual Studio, Line 53, where we place at our loc error, a small hint. You can double click the red error line in the console. And it will open the exact line of code where the issue happens. In the real crash, this line might be where the mass failed or where the game tries to load missing file. You don't need to fix the code. You just need to screenshot that line, screenshot Console or anything related to this, just to show the developer exact issue where it where it is located and its name. That should be enough. Before we finish, let's go back to the script and delete that debug, so our game works again. Simply remove it. Control S, and pose control. I reloads the script. We can play again. Yeah, no errors. Nice. So to wrap up everything we spoke about, read text in the console. That's error. File name number is the exact location. If you double click, you do report to the exact line of code. And in the next lesson, we will learn the big three exceptions, specific errors, names like no reference that you will see like 90% of the time. 21. Decoding Unity Errors: Welcome back. In the last lesson, we saw how to read an error map. Now let's learn the names of the monsters you find there. As a QA, you will see hundreds of different errors, but 90% of them will be just three types. No reference exception, the missing link, unassigned reference exception, the empty slot, and index out of range exception, the last overflow. And today, we're going to summon the king of all errors, the null reference. Select your player object and look at the player's controller component. Find the slot named footsteps. Currently, it holds a particle system. This is the link. The code expects to find a particle systems here to play dust effects when you run. Let's break it. Click the tiny circle. It's a selector and choose none. The slot should now say non particle system. We have just stolen the fox shoes. Now press Play button. Oh, you see a lot of red errors here. What does this translate to? It means the coat tried to touch something, but it crasped and thin air. In our specific case, the start function tried to grab the emission settings on the footsteps, but since we remove them, it grabbed no or nothing. You cannot change the settings of nothing. This is the most common Bu report. If you see no reference, your first instinct should be check the inspector slots. True. So you basically stop the game, look at the player controller, and if you see the empty slot, that's the issue. Probably it is here. You can try to select some let's say properties, assign them, and check if the game runs without issues. From the experience, you will be working with the more complex projects than our. So probably it is better to deliver this work to the developers. So the main goal is just to validate that nothing in the inspector has none. If something has none, probably it's the cause of the issues in the console. You can do. You can capture the screenshot of the issue of the console. You can screenshot the place where none exists and deliver this in your bug report for developer. The second type is index out of ranch exception. This happens with lists or inventory systems. It means trying to grab item number five from a bag that holds only two items. Our fox doesn't have a list. So let's fake one. Open your player controller script in the start function, add these two lines of code. A back and trying to grab. Save this and return back to Unitiu. Run the game, press pause, go to top. Here it is index out of range exception. So the logic count is wrong. Usually this happens when developer tries to load level ten, but the array of levels only goes up to nine. This is a common issue, and the third one is unassigned reference exception. This is the polite cousin of null reference. It happens when you need to check the slots before the code runs. DC this error. It means the exact same thing as null reference. You forgot to dig something into the inspector. However, this specific error usually tells you the variable name in the error message like variable, let's say packed effect has not been assigned. It is literally telling you which slot is empty. You can simply read the error, find the slot with that name and fill it. Here how it looks like. I did none for the impact effect, started the game. And receive assignment reference exception, variable has not been assigned, which means that impact effect in the player controller has none. To recap everything. No reference means that slot is empty while run time. An assigned reference simply the same slot is empty, but it's just an editor check, and index out of range tries to access a list item that does not exist. 22. Errors Sorting: Come to the final lesson of Section four. We already know that red means error, the games broken. But sometimes the console talks to you in white or yellow. This is the traffic light system. The white lock means that I'm working correctly. The yellow is warning. Be careful. Something is weird. Red, as you already know, like I crashed. Let's modify our code to see this in action. Let's open player controller again. Let's navigate to the start function and add two lines of messages that Cancel system will just print for us. Please add these two lines, Debug clock with something debugged lock warning. Save this script, go back to Unity, press play. Now you see that you have white, yellow and red. Let's go back to the top of the console. Here it is. The white message says QA status player is ready. Like developer use this to track logic, like player spun, do open it, score edit. So nothing critical here. The yellow message says Q warning. This is test warning this is crucial. A warning means the game did not crash, but something is wrong. Maybe a sound file is missing or texture is too big, and hint here is never ignore yellow. It might not break the game now, but it could cause lag or memory issues later. You should speak with the developers asking whether this yellow error means something critical right now and log that to your back tracking system. A big project, the console can get spamming. You might have 5,000 of different logs. Look at the top right corner of the console window. Here you can see three icons, white yellow and red. If you click, one of the means it just disappears. It hides. It hides from the console. So you can create you can show only say red errors or only yellow errors or only white errors. This can be handy if you're hunting for, let's say, crash. You can simply turn off white, yellow, and turn non red. So you work only with the crashes errors, no references, and many others. Don't forget to get back to your script and delete those to the bug lines and others if you have. So we keep our code clean. To recap Section four, the inspector is gray box testing and variable check. Stack trace is the map to the crash. No reference is the missing link, and the ox warnings are the health monitor of your project. See you in the Section five. 23. Game Manager: Welcome to the Section five. We're leaving the actor, the Fox and meeting the director. In almost every game, there is one invisible object that controls ruse, the game manager. It doesn't run, jump, or shoot. Instead, it counts points, decides when the game is over, and tells the UI what to display. Select the game manager in your ER arch. Look at the inspector for the game manager object. As you see, it acts like a switchboard. It connects the logic to the UI. Here you can see coin text. This tells the manager where to write the score. Level complete panel. This is the screen that pop ups when you win. Player controller, it knows where the fox is. But what happens if these cables get unplugged? Let's try it. Let's in level complete panel, switch to none. Now let's play the game. And let's try to finish it. You see what happens? The game stops, but nothing appears. The screen is frozen. You cannot click next level, exit or any kind of buttons. This is called a soft lock. The game logic worked, but the UI logic failed. It tried to show a panel that didn't exist. Soft locks are the high severity box. Whenever you find one, checking the game manager's reference is your first step. Also, during the session, we'll earn some coins. But what if we start game again? We see zero here. This game currently has no safe system. It uses session state. The game manager holds the coin count in a private variable that lives only as long as the game is running. So it is like if you start the app and your coins are gone, this is correct behavior for this project. But if you had a safe system using player preps, the coins would stay. As a QA, you must always ask the designer should this data be persistent, saved somewhere or transistent session only. But for this game is transistent. Finally, reconnect your level complete panel so the game works again. To recap, the game manager is a single referee. If it loses a reference, the game soft locks. In the next lesson, we will look to test inputs, specifically, how to trick the game into syncing PC is a mobile phone. 24. Simulator basics: QA. You often need to test mobile features on your PC. What if your Unity editor doesn't have a phone view? First, let's check your toolbox. Go to Window General. If you see device simulator, you're safe. If you don't see it, you need to go Window package manager, select here Unity registry and search for simulator devices. Yes, it is. And click Install. I have it installed, so just if you don't see it under the window general, do these steps. Now, let's test the input logic. Select the player object. Look at the control mode. Here now we have PC, let's switch it to mobile and press play. Now, if you will try to move your fox with WHD buttons, you cannot. This is the correct behavior. You successfully verify that the code that is related to control mode changes and working. You switch it to logic flag and the PC controls now gone. Even if you don't see on screen buttons yet, you confirm that input lock works. Now stop the game as when you see what the players is. In your game view here, switch here. We need to see what the player see. So we should switch from game to simulator. And your game now is inside the tablet frame. You can switch here to any device you would like. For example, iPhone 12. Let's run the game. You can rotate, landscape and portrait mode. And by this, you can verify that the notch is not covering any UI. Everything looks good. The most quick cases here might be like the notch covering score, that rounded corner, cut off the pause button, exit button, and does the game like not going out of the borders. We are in the simulator mode in mobile mode, we should see the touch buttons. It might be that in that project, we don't have them implemented, so we might not see them. But usually in the mobile games, if you test them using your PC in Editor, you should see here the buttons like on real device. And this is a very good case for QA to find such high priority back. Like mobile controls are active in logic, but UI buttons are invisible. So you simply do all actions as we did and verify whether the buttons are active or not. Don't forget to switch your game back to the game, return to the scene, return control mode to PC, so we can move our fox again. Finally, to recap, package manager installs missing tools like in the window, package manager can find something or you can simply check all the list with everything Unity needs to work properly. It depends on your project. Many of these you might not even need control mode as we did from PC to mobile switches the internal logic and simulator. It reveals layouts, mobile layouts with which we can find bugs like the Notch bug. 25. Creating the build: Back, you probably know how to click the build button because we did that in Section one. But do you know what are you building? In QA, we deal with two types of builds release build and development build. Release built, this is for the players. It is optimized fast and secure. But as a development build, this is for us, for our internal testing. It allows us to connect diagnostic tools and see errors. Today, we're going to configure a proper Kiwa build. Let's navigate to the file, build settings. And look what we have there. Let's look at the white box at the top. Scenes in build, you see scenes Mullah menu on the right. He number zero. Level, number one. This is a critical moment. When a developer writes code like to load scene one, they are trust in this list. So if you ever test a game where clicking Start accidentally reloads the menu instead of the game, you should check this list. Usually, the scenes are in the wrong order. Level is zero, menu is one, you should always ensure the splash screen or menu scene are at index zero. Now let's look at the settings on the bottom right. Find the checkbox, label it development Build. Check it. Notice that some of the options became active. Why does a QA should care about this? If you report it back saying the game feels laggy, the developer will ask, Did you capture a profile? Cannot capture data from a normal build? You must request a development build. It essentially leaves the hood of the car open so you can inspect the engine while driving. Also, let's look at the architecture drop down. Suggest as Intel 64 bit and Intel 32 bit. If you are testing for kind of very old office computers, you might need 32 bit. But if you try to run 64 bit game on 32 bit Windows, it crashes instantly on Fung. So be way to select the correct one. By default, it says 64 bit. As we will need some logs in the lesson five, I suggest you to run the build right now with development build tick. So just select your folder under the project folder. Don't save anything. Verify that you have checked Bs scenes and let Unity build the game for you. 26. Performing Smoke test: Come back. You have just built another version of the game. Now, let's answer the question. Do we spend 8 hours testing every single all collision? Now, first, we perform a smoke test. The term comes from plumbing. You pump smoke into a pipe system. If you see smoke leaking out, you don't bother fixing the smoke cracks yet. You know, the whole system is broken. In QA, a smoke test is a ten minute pass to answer one question. Is build stable enough to start testing. The game crashes on line or the started button doesn't work, we simply reject a built immediately and send it back to the developer. Let's run our test. Double click on your dot xle to deplatform. Check number one, doesn't launch. It sounds silly, but crash on startup is very common thing. If you see the unit display screen, you pass step one. Check number two, resolution and UI. First, look at your main menu. Since we left the default settings, the game likely launched in the full screen. Three pressing O plus Enter. That's a switch to Window mode. In the editor, the UI always look perfect because you said the resolution manually. In a standalone build, the game has to guess the player's monitor size. If the start button is cut off or off screen, fail the smoke test. Now let's click the Play button. Does the scene change from menu to level. We confirmed in the build settings that menu is zero and level is one. If this button does nothing, it means the scenes list is empty or the button isn't hooked up. This is a blocker. You cannot test the gameplay if you can't enter the level. Once in the game, do some actions like run, jump, move the eblock, collect money, et cetera. Like we see that inputs work, that's great. Here is an example of test that you can only do in the build focus loss. While running, press T plus Tap to switch to your desktop or browser. While I'm doing this combination, the fox like freezing. If I click on the window, everything became okay. The main questions here could be, did the game crash? Did the music loop? Did the fox fall through the floor while we were tapped out? Robot game should autopause or at least handle losing focus gracefully. If taping breaks the physics, a specific standalone build back. Finally, how do you te? In the editor, we press the stop button. But in the build, you don't have that. If your project, don't have any exit buttons, you're stuck. You have to use force cut out plus a four. For a PC game, missing Cute button is a valid bug. So you should discuss this with your designers, developers, whether it already has that cute button or not. Because if you agree that cute button should be and you don't see it, that's a bug. Main idea of smoke is, if you have the game that launches, plays, closes without crashing, without freezes, this means that smoke test is passed. You can work with that build, test it, and tent and lock any other box you may observe. 27. Logfile of the build: In the last lesson, we run our game as an executable. But imagine this you send a built to a tester, they double click it and easily closes. They observe a crash. They ask you what happened. But you can say, check the console because there is no console in the build game. However, Unity always writes down what happens. It just hides. This is called the player log. Let's find that player log. This requires some detective work on Windows, but on the video, you could see the full root. It's like hard drive C users, your username, app data, Lolo default company, to the platformer. You are now in the hidden storage of your computer. Let's open this log. Simply open it with your notepad. You will see a lot of words here, a lot of lines of something. Let's see what is it. This look familiar to the Unity Console. You can see here something like initial sense inversion, some information about your PC, some driver things. Your log that you created during previous lessons, some new back information, et cetera. Simply, it's a clone of Unity console, but made with TixtFle. So if you ever observe some crashes, free slacks during development build testing, you should navigate to this player that log file, inspect it, find no reference or another type of issue, screenshot it or copy paste into your bug report, and that's all. Important thing is that Unity overwrites this file every time you launch the game. So if the game crashes, and then the user reopens it to see if it works, the crash lock is deleted and replaced by new. So you should, after the crash, immediately navigate to this file, copy and paste it in case not to lose everything. 28. Basics of folder structure and cheats: Many junior testers make a classic mistake. They copy the dot file to bet, give to a friend, and say, Here is my game, and it fails immediately. Why this happens? Because dot is just a brain. The body, textures, sounds, levels, they live in a separate folder. If you open our two Dipo former Unity, build folder, you may see there are some folders, file, and others. Our body lives in dip former data folder. If you open it, you could see here levels and other assets that we have in that project. This also could be a part of smoke testing when you have built from Unity. We can open that folder and validate everything is here because if this folder would be empty, this simply means that you would need to rebuild from Unity to restore the files. Tomson was corrupted during the build. One more important thing for QA is to have a lot of development flex or easily to say the Buck cheat panel because QA needs some tools to test faster, like wood mode, speed up, money cheat, and others. Playing the game at normal speed is too slow. QA doesn't have much time to test the whole game without hits, and it's normal to have a lot of cheats during the development phase. The main idea is not to pass them into the release build. Means that you should not hesitate to ask your developers to provide you with some cheat panel or even simple lines of code that will simplify your life, and you will simply press some hot key that will make some things in the project that basically will speed up the testing process. 29. Introduction to performance indicators: Come to the Section six. We are now entering the world of performance testing. Before we open the heavy machinery, we need a simple speedometer. Look at your game view in the top tool bar, click the stats button. This gray box is your dashboard. Right now, your game is running at roughly 66 FPS. This is good. A smooth game typically aims for 60, but look at the number next to it. To a developer, this milliseconds number is actually more important than FPS. Why do we care about the milliseconds? Imagine that you have a budget of 16 milliseconds to draw one frame. Your game is currently using 15.1 0.3. You're very close to the limit. If you just two more milliseconds of heavy coat or pig explosions, your game will drop below 60 FPS and start to statter. As a QA, you don't just report low FPS. You should report the spike in milliseconds, like game runs at eight milliseconds normally, but spikes to 25 milliseconds when the bot for example. That tells the deaf exactly how much optimization they need. Look at batches, 29. Think of a badge as a conversation. Every time unity wants to draw something, it has to pick up the phone and tell the graphics card, draw this snowman. That is one badge. If you have 1,000 objects, you don't want 1,000 phone calls, that's slow. The oportunity to bundle them up and say, draw these 50 trees at once. Look at saved by patching 2029 batches is excellent for mobile. If this number was 2000, your phone would melt. A sudden jump in batches usually means dynamic batching broke. Look at trees and words. These are the complexity of your art. Of triangles is nothing. Modern forms can handle 1,000 hundred easily. However, if you import a three D model of car that wasn't optimized well, this number could jump to 5,000 hundred. If the game lacks only when you're looking at specific object like detailed statue, you should check this number. If trees jumps from two K to 2000 K, you found issue an unoptimized asset. By this, your baseline is set 15 milliseconds and 29 batches. Write this down. In the next lesson, we will open the profiler, the Deep diagnostic tool, and we will record a spike to see what pushes us over the 16 milliseconds budget. 30. Profiler: In the last lesson, we used the stats window, our speedometer. Now, we use the profiler. It is inside the code. Let's open it. Find Windows, Analysis, profiler. Open it here. Look at this. The colorful graph moving from right to left, this is kind of hard pit of your computer. What we have here, something green. It's rendering or graphics, something blue that are scripts or logic and yellow. That's sync or waiting. If the graph is flat, the patient is stable. If you see a giant spike, the patient just had a heart attack. Look at the top tool bar of the profiler, attached to player. I should say play mode. This means we're testing the game inside of the editor. Record. The red circle button. It must be clicked to capture the data. You can stop or start De profile. You should leave this off. It makes the game run extremely slow and isn't needed actually for general QA. Let's do a short test. Click inside of your game view and make the focus jump or collect coin. For example, let's move. Let's collect them. Let's make some jump, slide the ice, more jumps, more movement, more coins. Watch the graph. Did the blue or green line jump slightly? That are the computer thinking. Now, let's freeze time. While the game is still running, click the stop or pause button on the Unity Editor. The profiler graph stops moving. You can now scroll back and forth on the timeline. Click on the highest spike you can find, for example, this one. When you click a frame, a vertical bland appears. Now look at the ER arch view at the bottom half of the window. This list tells you exactly what happened in the 16 milliseconds. A junior QAs panic, CPU is 100% yellow. Is the game broken? The answer is no. Yellow usually stands for VCN technology or wait for target FPS. It literally means the game is running so fast the CPU is waiting for the monitor to catch up. If you see high yellow, your game is actually optimized. If you see high blue or green, that is lag. You now know how to freeze a frame, but how do you create a real expec test? In the ex lesson, let's try it. 31. Spike catching: Welcome to Lesson three. In real job. You would not write Le code, but you'll find it to learn what it looks like. We have attached a script code Leg generator to our fox. It has one job. When I press L Hotkey, it forces the CPU to do 5 million mess problems instantly. This simulates an optimized code, like a developer trying to calculate the best of 500 enemies in a single frame. Now I will do this experiment. Since I already attached the script named Leg generator to the player object, now I press Play Game. And when they run and press L, look what happens. The game freezes for a second, but see what happens in the profiler. Let's suppose. There are some blue stacks in the ear arch at the bottom. You may see here the cause of that blue he scrapper, L generator update. That's what I added. And by this, you have just traced the leg back to the specific function that caused it. In a real report, you would write spike of the 281 milliseconds detected. Profile indicates lag generator script is the cause. Pretty simple. Also, as you see, the color is blue. As I said before, blue means scripts. If spike was green, it would mean rendering, something related to texture, shadows or something. As a QA, differentiating between bad code and bad art is the most valuable hint you can give to the theft team. But what happens when the game runs out of memory. In the next lesson, we look for garbage collector, the silent killer of mobile performance. 32. Garbage Collector: Far we have talked about the CPU, the brain. Now let's talk about the RAM, the memory. Think of your game memory like a dinner party. Here we have the allocation. It means every time the game bounces an enemy or creates text message, it takes a clean plate from a cupboard. The garbage is when the enemy dies, the plate is now dirty and left on the table, and the garbage collector or GC means that eventually the table is full. The game freezes completely while degenitorGC. Is to watch the plates. The lack that this is like leg Spike. As a KA, your job is to identify when the enemy is making too many dirty plates. We not need to write code to see this. We just need to configure too. Let's get back to the profiler. Look at the bottom half we know the Arch list. To remember you, you can switch from timeline to Archie here. By default, you see columns like time millisecond, self millisecond. Right click on that bar and make sure that you see a lock is turned on. This is your trash meter. Measures garbage collection allocation. How many bytes of treasure create in this specific frame. Now let's press play and record a few seconds of gameplay, doing some jumps, collecting coins, and something else. Jumping, collecting coins, more jumping. My nice. Pause the game. Let's click on some frame. Let's select this one, for example. Look at the GC log column. In a perfectly optimized game, during normal gameplay, the number should be zero bytes or very close to it. Basically, zero bytes mean that the game is clean and no trash is being made. 20 bytes is acceptable, probably some score update. If we have 1 kilobyte plus, it's warning sign that something is incorrect, or even if we have 1 megabyte plus, this is critical back. This means that the game is dumping a massive around amount of trash every frame. Example, at that moment, we have 1.6 kilobytes. That's a warning that something happened during the player loop with some script, some update thing, some UI thing, et cetera. So you can just gather this information, attached to your B report saying that something is happening here, what create some press. Basically, if you see a game that lags every five or 10 seconds, read Nic. This means that something is not okay. So garbage appear, and you just need to investigate here by looking at the frames, doing short profile session, capturing screenshots of places where the GCA lock is high, and shib this to the developer, saying that probably we have a memory leak or just hig JC location here and here, and developers will take a look. 33. Client and Server: Welcome to the Section seven. We are leaving the safe world offline gaming and entering the complex world of networking. Today, we're answering the biggest architectural question in GMQA. Who is the boss? Is it declined or is it a server? Is this lesson? We will learn the concept of server authority versus client authority. Discuss why you can g this Unity project, but you can hug for example, word craft, review the critical QA scenarios involving data synchronization and look at real world bugs are declined and server is agreed. Why does it matter? We have two main architectures, the client and server. The client is how our current project works right now. The code simply runs on your PC. If you use, for example, a two heat engine or some another to change your progress or coins or sales. The game accepted without any verification from server or another instance. There are pros and cons. The pros are that this way could be developed fast and works of fun. There is no need in any Internet connection. The biggest con is that everyone can cheat. So probably it would not be interested to play game that could be hacked in a minute. The server alterative is how games like Clash of Clans Word for Craft and another's work. When you try to buy a sword, your game doesn't say, I have a sword. Your game sends a request. May buy a sword. The server checks your wallet. If you have the money, the server says, yes, you know have a sword. You have your memory to say to swords, please, the server says, Let's try, but we actually have zero purchase dent, and the most box in the games happen because the client thinks it has authority. But the server says, no, now that we understand the architecture. Let's talk how to break it. You don't need fancy tools for this. You just need your phone or PC and some creative timing. Here are three most critical tests you need to perform to any network game. First, we have the expensive download test. Imagine player is on a bus using their expensive mobile data plan. Open your game and it's silently starting download, 500 megabyte update in the background. By the time they get home, they have lost $10 in data charges. They will likely reach and leave one star review. To test this, you need to turn off your Wi Fi and connect strictly to four G or five G. Launch the game and try trigger download. Your goal is to verify that the worrying pop up appears. Asking the user like you are not on the Wi Fi. Do you want to download some amount of data? If the game downloads without asking, that's a bug. Second, here's the network handover. This happens constantly in real life. A player starts a match in their living room on Wi Fi, but then they walk out in the front door to catch a bus. Their phone has to switch from Wi Fi to FD while the game is running. To test this, you can simply start a match on Wi Fi, and in the middle of direction, simply turn off your rotor or toggle the WiFi switch on your phone. Would happen. The game should pause for a second, maybe show some reconnecting spinner and then resume exactly where you left off. What often happens in the game panics? The session ID from the WiFi Match doesn't match the IP address and the FG connection and the server kicks the player out to the main menu. Your job is to ensure the transition is seamless. And finally, we have the version mismatch test. This is a logic test. Every Tuesday games usually get a server update. Let's say the server is now on the version 1.1, which includes a new fires word. However, the player hasn't gone to the app store yet. They're still playing on the version 1.0, which doesn't know what is Fire's word. If the old client tries to talk to the new server, the game will likely crash because it receives data it doesn't understand. To test this, you intentionally install an old version of the app and try to log in to the live server. The expected behavior is a hard stop. A Pop up that says update required and the button that takes you to the app store. If the game lets you play twel version, you have a critical compatibility back. And let's talk about real box found in production that cost companies millions. The first bug example is the infinite exploit. The bug was that in earlier shooter game, the code for decrease MO was on the client. So the hackers just deleted that line in their local files, and in the result, they could shoot forever. The server never checked. They actually had pallets. It just excepted, like, I shot you message. The nice fix for that might be to move MO counter to the server. Second buck example, the ghost item or desynchronization. The buck is like when player picks something, let's say potion, the client plays the sound and removes the potion from the ground, but the Internet packet was lost. And the result, client thinks that I have a potion, but the server sees that the potion is still on the ground, and when the player tries to trink it, nothing happens. Or worse, another player walks by and picks up the invisible potion. The last example is the offline purchase for free stuff. The player clicks example by 100 games. The game adds the games immediately, then tries to talk to the app store. Player turns on airplane mode, clicks by, get the Jams and closes up. So in that case, the poster never gets the request for money, and the company see zero revenue. That's a critical. Now, you understand what is the client server, the difference and why it is important to store some things on the server and some on the client. In the next lesson, we will simulate latency. We're going to intentionally break our threat connection to see how the game handles lag and repo banion. 34. Possible network issues: Welcome to the lesson too. We know that the server is the boss, but the boss lives far away. When you press jump, the signal has to travel to the server and back. This delay is called latency or pink. In this lesson, we'll simulate bet connections, visualize pink, and learn how games use lack compensation to hide delays. Let's visualize this delay. I have modified the log generator file we created recently. You may do the same. I will share in the description, the code. You may pass in the x simulator and try the same. After changes, please press Play. Press the space and observe the painful delay that happened. After pressing space. That is actually the latency, how it happens in modern multiplayer games. Let's talk more about the physics of the Internet to have more explanation about. When you press a button, that signal has to travel through copper wires and fiber optics to a server halfway across the world, and then come all the way back. This round trips takes time, and we call that time latency or pink. If your pink is 20 milliseconds, the game feels instant. But if your pin is 300 milliseconds, you're living in the past. To hide this, developers use a trick called Black compensation. The game clan guesses where the enemy should be and draws them there. If the guess is wrong, you see the enemy port or snap into new position. We call this Rubber bending, and it feels awful to the player. So how do we test this? We can't just hope for bad Internet. We have to simulate it. First, you need to test the high pin limit. Game has a breaking point. You may use a tool like Clumsy or Unity like simulator to force a 500 milliseconds delay and watch at your character. Does the moment become jerky? Or if your project contains bullets, do they go through enemies without hurting them? At some point, the game should essentially tell the player your connection is to pull the play. Next, you need to test for Jitter. Constant lack is annoying, but random lack is worse. This happens when your pin jumps from 50 milliseconds to 500 milliseconds and back again in seconds. This confuses the prediction code. You want to see if the physics engine explodes. Sometimes these spikes can cause players to fall through the floor and the packet loss. This is when the data doesn't arrive at all. Set your simulator to drop 5% of packets. In a shooter game, this looks like shooting a full clip of EO but doing zero damage. You need to verify if the game attempts to resend that information, or even just ignores the action entirely. Let me share with you one real world back from production. In the famous racing game, the lack compensation was too aggressive. If a car had a bad connection, the server would guess where it was going. But when the real data arrived, the server realized that guess was wrong and snapped the car back 50 meters. This caused cars to look like they were vibrating or reporting across the track. 35. Game Persistence: Welcome to the Lesson Tree. So far, every time we close our game, the fox forgets everything. It forgets the coins we collected and the level we reached. This is because the game's prey is currently living in our session memory. It gets wiped the moment the app closes. For a game to matter, it needs persistence. It needs to write a letter to the hard drive saying here is where the player stopped. As a QA, you are the guardian of this memory. If a player loses, they say file, they don't just lose data. They lose hours of their life. They will never forgive the name and they will likely delete it immediately. In this lesson, we're going to explore how games save data, the difference between simple local saves and complex cloud saves and how to verify that your game doesn't accidentally wipe its own memory. Deep Dive theory, how saving actually works. Let's look under the hood. The game usually starts safe with something called serialization. Imagine your game status is a messy room full of objects, cloth bars, inventory items, quest flax. Can't just stub that room into a file. You have to pack it into boxes. Serialization is the process of turning that messy room into a neat text string so the computer can write to a disk for simple data like sound volume or a high score. Developers use something like player press on Windows, save to the registry. On mobile, it's a simple a Mali file. It's fast, easy, and totally insecure for complex data like an RPG inventory with 500 items, developers use JSON or binary files. These are the structured language that looks like a list. And here is the danger version. Imagine the game saves a file, says, HAS, mana, gold, then you update the game to version two. The new code expects file to say health stamina, mana and gold. If the game tries to read the old file using the new map, it gets confused. It might treat mana as stamina and suddenly the player logs in and has zero mana because the data shifted on each to the left. And this is called Emigration failure, and it is the most common reason for data wipes after an update. Since we are you find a Nicole today, let's focus entirely on how to test this. You don't need to be hacker. You just need to be destructive. First, you must master the to a loop. First time user experience. This is the most important part of a game, tutorial. To test this, you need to simulate a brain vibe on mobile, for example, you can go to upsetting storage click data on PC, you might have to delete a file in your documents folder. Test is simple. Place the tutorial, wipe the data, let it again. What are you looking for? Static variables? Sometimes lazy developers stores the tutorial complete flag in the calls temporary memory, not the safe file. So when you wipe the safe file, the game still thinks you finished tutorial. You log in the fresh user, but the welcome pop ups never appear leaving you confused and stuck. Second is the migration test. This is critical before any update. What you should do is to install the old version, which is life on the store. Play it, earn some coins, buy something. Do not uninstall it. Then install the new version. The test built over the old one. And launch the game. Did your sword that you bought or whatever you want, disappeared? Did your coins reset to zero? This confirms if the Immigration logic correctly updated your old safe file to the new format. If this fails, you cannot release it. The third case is the corrupted safe simulation. Happens if the phone laptop battery dies exactly while the game is showing the saving icon. You can verify the game's safety by manually breaking a SA file. For example, open the save file on your PC, delete something from it, save it, and now watch the game. Good optimized game we'll see the file is broken and restore a backup from Cloud, but not optimize it or the game in development, we try to read the broken text, panic and crash. Let's talk about the real world box. The most famous one is the update vibe. Some popular Mobile ar PG released an update where the developer accidentally changed the capitalization of safe file. The game started looking for saved that capitals, but the old file was the lowercase S. On iPhones, that didn't matter, but on Android, the file names are sensitive, so millions of Android players logged in to find their level 50 characters, and they were completely gone, simply because the game couldn't see the old file. Another scary one is the cloud conflict. This happens when a player plays offline on their tablet earning coins and then later plays line on their iPhone. When they reconnect, the server sees two different files, different timestamps. Poorly written system will simply overwrite the newer file with the older one, effectively stealing the progress made on the phone and reverting the account back in time. In the next lesson, we will learn what is Tison, how it looks like, and what we can test. 36. JSON: Welcome to the Lesson four. We have established that the client talk to the server, but what language do they actually speak? They don't speak English and they usually don't speak in complex binary code. They speak JSON or Javascript object nation. It might sound technical, but JSON is essentially just a text message. It is the standard format for almost every game on the market. When you open a loot box, the server doesn't send you a sword. It sends you a text file that says that you've got a sword. As a QA you will often hear developers ask something like, did you check the payload or is the API returning the right Jason? In this lesson, we're going to demystify this. Learn how to read this language, why it is so fragile and how a single missing comma in a text file can crash $1 million game. Let's visualize what happens when you log into a game. Your game sends a request. Who am I? The server replies with a JSON file. It looks remarkably simple, almost like a grocery list. It relies on two things, keys and values. The key is the label, for example, user name and the value is the data. Example, Fox player, why is this popular? Because it is human readable. You can open a resonFle in not pAD and you don't need to be coder to understand it. You can clearly see, for example, that gold amount is 500 and understand that the player has 500 gold. However, this simplicity hides a massive risk strictness. Computers are incredibly dump. They rely on the key names matching 100% perfectly. If the server sends a reward, label it as AMT, 50, but the game client code is looking for the world amount, 50. The client would not find it. It won't try to find something similar. It will simply panic and assume the value is zero. This is the API contract. The server team and the clienteam must agree on the exact spelling of every single word. A QA, if you see a buck where UI element is empty or score is zero, your first instinct should be, did the error change the spelling of a key? Let's talk about use cases. First, the parsing error. This requires perfect grammar. It needs curly braces to start and end and commas between every item. Server has a hiccup and sends a message missing a single comma, the game client will fail to parse or read it. How to spot it? Usually, the game handles this gracefully by showing a generic connection error pop up. But sometimes the game will just freeze on a odon spinner because it is waiting forever to understand the message that makes no sense. If you see AJSOPaseEception, in the logs, you know, the server sent bad grammar. Is a data type mismatch. In code, number 50 is very different from a word 50. Imagine the shop expects a number, so it can do some mess. If the server suddenly starts sending the number as a string, the game tries to do mass on a word. You can subtract ten from the world 50. Spot it. This often results in none or not a number, appearing in the UI or the game crashing when you try to buy something. The third one is the null or empty field. What happens if you have no Klan? The server might send Klan is null, but some developer might try to display your clan name without checking if it exists first. How can you spot it? You might see the actual world Null appear in the player profile, or the game might through a null reference exception. There's the profile page. You must always test accounts that have empty data without friends without items, without clans to verify that the game handles the emptiness correctly. Jason bugs are silent killers that often result in a funny but destructive outcomes. Take the billionaire bug for example, a server was sending the GOT amount as a text string. Someone on the server team accidentally added a space at the end of the number, so it sent 1,000 space instead of 1,000. When the game tried to convert the text into a number, it failed because of the space. Instead of defaulting to zero, a logic error caused it to default to the maximum possible integer the computer could hold or 2 billion. Players locked it to find themselves infinitely rich during the game economy overnight. Another classic example is date format. The set was sending dates in the United States format, months, day or February 1. But the clad in Europe was built to expect day months on February 1. The European clients read the date and thought it was January 2. This caused daily log in streks to reset randomly for thousands of European players leading to the flout of support tickets because they just lost their progress. Mostly sons look like that the name and the key, probably some arrays might appear with something with a lot of IDs. For example, we have some food storage app and the doughnut has different types. So they are marked with different IDs that are related to the doughnuts. Another thing is topping, a lot of toppings still related to donuts, but they are another array. In the next lesson, let's talk about remote config, which allows us to change the game without any updates. S 37. Remote config file: Welcome to the Lesson five. Remote Config allows us to change the game without any updates. We can tune difficulty or tune on events from the server. Today, we will build a config system and test fullback values. First of all, we need to create game Config. Let's do it. Create Sear Sharp Script. Game Config. Amazing. Let's open it. After you successfully created a C Sharp script, you should copy and paste the code that will be provided in the description to this lesson. Then run the game. Notice the speed on the fox. Let's change it using our code here in the player's bit. This one is some kind of JSON string. In the production, the massive games, it will be dedicated JSON file in which you or developers will change the values. Let's have here 100 safe, get back to Unity, control error to reload. Let's press play again. As you can see the speed has changed. So we just simply change the Fox speed using JSON, not touching nothing in the player controller in the unity. So as I said, on the production, you will work with real JSONs using, for example, NopaD and you will actually not you, but developers, designers will simply change their values, but you will be able to look at them to compare them and to find some box. Why this one is crucial for us, because it allows for AB testing and stage outs, we can tell the server to give 50% of players card mode and 50% easy mode to see which is better. It is also a safety switch. If you launch a new feature and it crashes, we can disable it remotely. For everyone instantly without doing any updates to the game. What could be the Qaus cases? First, you should test the fallback or offline lunch. What happens if the server is down? The game must save some default values. If the server doesn't send a speed value, the game shouldn't set speed to zero. It should be default set by Unity. On the mobile, it's easily to test in airplane mode. But on the PC, you will need to turn off Wi Fi or unplug desernt cable. Second, you can perform the extreme value test. Config are typed by humans. If a designer accidentally types 1,000 instead of ten, that's the game crash. The code should have clamping logic to keep numbers within safe limits. The last one, you can test the live update scenario. Some games update config while you play. If gravity changes mid jump, the player might glitch, should verify that new configs are applied only at safe moments like in the main menu. One very common bu in production is decimal point. Designer in Europe set the price to four comma 99. The system expected a dot four dot 99. The system just dropped the coma taking the price 499. Players were amazed with this change. So you should test pretty tough thing because it may produce unexpected bugs in production, making players furious. As we touched a bit AB testing, let's talk about it in the next lesson. 38. AB Testing: Welcome to Lesson six. Have you ever noticed that sometimes your friends version of the game looks slightly different from yours? Maybe their shop button is green, but yours is blue, or maybe the tutorial is shorter for them. You are likely participants in AB test. AP testing or split testing is how modern game studios make decisions. Instead of guessing is level one to hart, they run an experiment. For example, group A, they place normal game, but group B, they play a version where enemies have 50% less heals. Developers then watch the data. If group B plays for longer hours and spends more money, the studio knows the easy mod is better, and they roll it out to everyone. But for QA, AB tests are a nightmare. You aren't just testing one game anymore. You are testing two or more different versions of the game simultaneously. If you don't know which group you are in, you might report about textually an intentional experiment. In this lesson, you will learn how the servers playing buckets the golden rule of user identity, how to organize your testing, and what happens when experiments go on. Does the game decide who gets the blue button and who gets the green one? It uses a system called bucketing. Imagine every new player is given a random ID number. The server looks at the last digit or at ID. If the digit is 0-4, it receives group A. If the digit is five to nine, then it's group B. This leads us to the most critical concept in this entire lesson, sticky buckets. Sticky means consistent. Once a player is assigned to group B, they must stay in group B forever or until the experiment adds. Imagine if you were in the easy difficulty group on Monday, you love the game, but on Tuesday, you log in and the server accidentally switches you to the hard difficulty group. Suddenly, you can beat even level one. You get frustrated and te the game. The data scientists looking at the logs will be confused. Why did the player te? Was it the easy mode or hard mode? Because the bucket wasn't sticky, the data is corrupted. As a QA, very fine stickiness is your number one priority. Testing experiments requires a methodical approach. You can't just play around. Here are three mandatory tests. Test number one is the fresh install roll or simply very fine randomization. Your goal is to ensure that new players are actually being split up. What you can do is to install the game, check which group you're in, then delete tab and wipe all data to reset your ID. Then reinstall, check the group again, repeat this ten or 20 times. The past criteria is that you should see a mix of blue and grip shops, something like 50 50. It will fail if you do this 20 times and always, you will get a blue shop or let's say group B. It means that an optimization is broken, or the experiment is turned off. So always verify that with your managers, team leads, design team, and others. Test number two is the persistence check, verifying that stickiness. You should ensure that player never switches group accidentally. Actions are to log in and confirm that you are in group B. Then close the app, simply restart it, turn off any Internet, still restart it, update the app, the new version, restart it. The ps criteria is that your shop will stay green every single time after you close the app, fail your connectivity or update the app to new version. You still see the green one or group B, as we agreed. But the fail if it sometime will revert to blue or group A, that means you have a leaky bucket, not sticky. The test number three, you can do is the cross platform identity. You should ensure that the experiment follows the account but not the device. You should log in sample on your phone and see that you are in group A, and then you log in with the same account data, for example, on tablet or PC or Console, and you should see that another device you choose also shows group A. So if you see group B, it means it failed, you should create a bug. Why this actually a bug? Imagine that group A sells some magic word that exists only in group A, Group B doesn't. You buy it on your phone where you are in the group A, then you will decide to switch to your tablet or PC, which is group B. The Gipe might simply crash because it doesn't know what that item is. Let's look at the production horror stories or real word Bx. When IB tests fail, they don't just break the game. They often cause community scandals. The first one is the price discrimination. Pyramid was then YM Studio wanted to see if players would pay more for items. They put group A on the standard prices, let's say, $5 and group B on inflated prices, $10 for the exact same item. They didn't hide this well. Players talk to each other and screenshots hit read it immediately, like, why is my friend paying half of that? What I am. The lesson should be never be test pricing unless you ate well and you are pretty careful to release that. The second story is the broken tutorial variant. The experiment was to remove the tutorial group B to speed up the gameplay. The logic that gave players their starting weapon was inside the tutorial fade. And the result, group A played normally, but group B skipped the tutorial, but also skipped in their weapon, they enter at Level one with empty hands, could not attack and got slaughtered. Retention for group B was 0%. The lesson is that you always regress all the passes in your game the same as the main pass. You now understand that it works on my machine is not enough. You have to ask which version of the machine or which version of the built. This concludes Section seven. You have mastered working Theta, JS fix and experiments. Next up is Section eight integrations. We will look at the two so we didn't write decays, and analytics. 39. SDK Basic: Welcome to the Section eight. We have built a game with our own code, and it works perfectly. But in the real world, your boss will talk and say, we will add Facebook login or we need Google ads to make money. Now, do our developers sit down and write the code to talk to Facebook servers from scratch? No, that would take years. Instead, they just unload a suitcase of code provided by Facebook. This suitcase is called an SDK or software development kit. Don't install this developers do, but you are the one who has to deal with the mess when they break. And this decay is like inviting a stranger into your house. They bring their own furniture, their own roofs, and sometimes they break your windows. In this lesson, you are going to learn how to locate these hidden files, understand why we call them black boxes, and explore the nightmare known as dependency hell. Do we call SDK the necessary evil? First, think of them as a black box. When a developer writes a moment script, we can open it and fix the tipo. But when we import the Facebook is decay, it comes as a pre compiled file like dot TL. We cannot see inside of it. If it crashes, we just get a generic error. Your strategy here isn't to fix the code. It's to act like a detective. You need to look the crash log and ask. This crash happening in let's say my game dot cs or inside Facebook is DK. If it's inside SDK, you cannot fix it. You just had to the developer to update the SDK version. Second, there is the nightmare of dependency hell. Maging ATS SDK needs a specific file called support Library version one. But then Analytics SDK needs support Library version two. When Unity tries to rebuild the game, it sees two different versions, the same file and panics. The build fails immediately. AQA, if a build fails right after developer merges and use decay, this is almost always the reason. SDK are the most fragile part of mole development, and when they break, they break hard. The most famous example is the Facebook rash of 2020. Book updated a configuration on their servers one afternoon. Thousands of apps used the Facebook SDK for login. The SDK didn't know how to handle this new server change and crashed instantly on launch. The scary part crashed the apps for everyone, even users who didn't use Facebook login because the SDK inlays automatically when the app started. Here is how you test these invisible tools. Start with the race condition. Or in a serization test. Asks take time to wake up, usually a few seconds after the game launches. If you click the watch at button, the millisecond the game starts, the Dame might not be ready yet. Poorly written code will crash because it tries to talk to an SDK that is still asleep. You should stress test this by launching tap and tapping buttons instantly. Finally, test the offline SDK. Most of the case assume you have the Internet. If you launch the game in airplane mode, that's the Analytics SDK hang the entire game because it's trying to connect forever. A third party tool should never break your main game. Look just because the WiFi is off. Next, try the permissions blocker. Many SDK, like the camera or microphone need permission from the. Happens if they say no, uninstall the app, reinstall it. And when the Pop up asks a camera, click the Ni. Then try to use this feature. App should show a polite error message, but if it freezes or crashes, because it assumes you said yes, sets fail, another common issue is below that build. The developer red at SDK, but forgot to remove the demo assets that came with it. The game sign tramped from 50 megabytes to 150. Because the decay include four K video examples hidden deep in the folders. This hurts download rate significantly, and it's absent Q should always catch by checking the final size of the build. 40. What is analytics: Welcome to the lesson two. How do developers know if level one is too hard or if players are ignoring the shop? They don't guess. They use analytics. Analytics are invisible spies in the game that report back to a dashboard. They track a funnel. Player starts, player plays, player wins. You must verify that these spies are telling the truth. If the level completely went fires when the player actually died, the data is corrupted and designers will make bad decisions based on lies. In this lesson, we will learn how to verify events in logs and how to spot data pollution. Are we actually looking here? First, the event name. This is the label like item purchased. At QAU need to be a spelling teacher. Level start from capital and levels start from minimized letter are two completely different events to the computer. Developer changes the case in halfway through development, the data history is broken because the computer things, it's a new separate event. Second, we have the funnel. This is a sequence of events like steps in a recipe. Step one, step two, step three. Your job is to try and break the sequence. If you fail step two, that's step three still fire. If so, that's a back. The data will tell the designers that everyone is finishing the tutorial, but in reality, everyone is skipping it. Here are the three ways you can ruin the data scientists day and how to prevent it. First, check for the double fire or spam bug. Walk into the level finish line, then walk back out, then walk in again. That's the event, let's say level complete fire twice. If so, the data will report that you beat the level two times. This inflates numbers and makes the level look more popular than it is. The code should have a flex to ensure it only fires once. The second, test the timing mismatch. Try to die the exac same moment you touch the finish line. I see both level fail and level complete at the same time. This confuses the analytics engine. Did the player win or lose? Logic states should always be mutually explosive. And third, verify the offline queue. Analytics are vital, and we can't lose them just because the user is in a subway tunnel. Off your Internet play level and then turn the Internet back. A good analytic system will cache or save the events while offline and upload them in a badge when the connection returns. If those events are lost forever, you have a data gap. Bad data is often worse than no data. A serious legal example is DDPR violation. In Europe, you must get user consent before taking them. A buck occurred where the analytics Day started tracking before the user clicked, I agree. Even though they eventually agreed, tracking them for those first 2 seconds was illegal and resulted in a funny side, there was a null item. A developer tracked item bought, but forgot to attach the name of the item. The monthly report showed 1 million purchases of null. The gym knew people were buying Samson, but they had no idea what, so they couldn't optimize the 41. ADS in games: Welcome to the lesson. Let's talk briefly about the ads. This is mostly the topic for bio testing, which will be extended in another course. But still, let's take a look at it. In free to play games, the rewarded video is a contract. The player gives us 30 seconds of their time, and we give them 50 coins. This involves a complex handshake between the game and the net work. Number one buck we face here is the callback failure. If the reward comes too early, players will exploit it. If the rewards never comes, player will age. So what can go wrong in this simple loop? The most common issue is the pause back. When an ad plays, it covers the screen, but the game is often still running underneath. If the developer forgets to set some property, your director might be getting attacked by zombies while you are watching Shampoo commercial. You will hear the sounds on the background, which is terrible user experience. Then there is a concept of at waterfall. Games don't just ask one at provider. They ask a list like, Hey, add mop. Do you have an ad? No, hey, Unity you? Yes, this process takes time. Sometimes five to 10 seconds. The Watch Ed button should be great out during this search. If it's clickable while the game is syn in, click in with White Cash App. And here are the money tests you must run on every release. First, the airplane trick. Click watched, wait for the video to start and then immediately toggle airplane. When the video finishes, the SDK tries to tell the server success, but it can't reach the Internet. Poorly written games will hang go on the black screen forever. The correct behavior is a polite error message saying reword cannot be verified. The second is the mesh test. Since lodging and takes a second. Try tapping the watch at button ten times rapidly with two fingers. If the quote isn't safe, you might launch two ds on top of each other. This confuses the logic. You might watch two ds, but get zero rewards or watch one t and get ten rewards. And third, the resume crash. Click Watch at then immediately minimize the app, press home button, for example, and open five another heavy apps like Instagram or Maps. Then go back to the game. The operating system might have killed the ad process to save memory. But does the game resume gracefully or it does crash because it lost the connection to that. Talk about some real world bugs. Let's say that AD bugs are usually marked as critical because they involve real money. One famous exploit was the infinite gold glitch. Developer accidentally put give reward line of code before the show ad. Players realized that could click the button, get the coins instantly, and then force closed worth watching the video. Head the game, economy was reined within hours, another annoying bug is the mute. Ads often take control of the phone audio focus to play their sound. After the head finishes, they are supposed to give that control back to the game, but often they don't. The player returns to the game in total silence and has to restart the app to get their music back. 42. Compatibility testing: Welcome to the Lesson four. Testing on mobile is actually hard, but testing on PC is the hardest. You might ask why. I would say that because on a console, every let's say, PS five, ps four is the same. But on PC or mobile, every player has a different setup, especially on the PC. Example, player A has a four k monitor and runs at 1.44 Hertz. Player B has tiny laptop and uses a touchpad. As a QA, you must verify that the game works on both of them. In this lesson, we will discuss the fragmentation of the PC Ecosystem, specifically focusing on aspect ratios, inputs, and frame rate. Why is PC compatibility so fragile? One major reason is expect ratios. Most games are built for standard resolution like 16 to nine, but PC gamers love ultra vite monitors 21 to nine. If you don't test this, your game will look stretched like characters are short and fat or the U elements might float in the middle of the screen instead of the corners. Then there is a refresher. Console games often to 60 FPS. PC gamers might play at 144 FPS or even 240 ps. There is a classic back where game physics are tied to the frame rate. If games code, say move 1 meter per frame, a player at 60 FPS moves 60 meters, but a player at 144 Ps moves 144 meters. The high NPC player literally runs faster than everyone else. Also, when we talk about DC compatibility, we focus on the big three. First is a GPU or your graphics card. This is the heart of games visuals. In Q, we look for VRAM limits. If our game uses, let's say, 6 gigabytes of textures, but the player only has 4 gigabytes video the game will swap data to the slow hard drive causing starters. You need to know if your game supports integrated graphics or if it requires a dedicated card. Second, is the CPU, the brain. The CPU handles the physics, the EI, logic, all scripts, et cetera. A common back here is thread optimization. If your game is single threaded, it might run poorly even on high end machine. As a que, we monitor CPU usage to see if the game is choking the processor. The third is RAM or system memory. If the game leaks memory, meaning it takes RAM but never gives it back, the player's computer will eventually run out leading to a hard crash to the disk clock. This is why we always keep text manager open during PC testing. But what are the most QAS cases you can do while doing that compatibility tests. Here are the must pass test for N EPC game. First, the ID tap stress test. Players usually multitask play the game in the exclusive full screen mode, then press Alt plus step to go to the desktop or another open application in the Bground then click back to the game. You can do this ten times rapidly, and what can happen is that bad optimized games, they will crash with some graphics device lost error or some sounds may disappear or even in multiplayer game, your server might lost connection with you. Second, you can check for ghost input. This happens when a player has a joystick plug, for example, for some flight simulator or racing game, but he's playing your game with a keyboard. Sometimes the game detects the joystic slide drift and paritizis over the keyboard causing the character to walk left or right constantly. Must ensure that the game respects the last active device. The third thing is the four k scale. On a four k monitor, pixels are very small. If the developer set the text size to 20 pixels, it looks fine on standard screen, but on four k, it will be microscopic and unreadable at all. We need to verify the US scales up to remain readable on high resolution displays. The next thing is how do we actually test for millions of different BCC taps? We use the hardware tiers. First, the minimum specs stress test. You should always have potato PC in the office, a machine that barely meets the minimum requirements listed. If the game crashes or drops below 30 FPS on this machine, the minimum specs on your store page RLI. You must report this. Second, is the resolution and aspect ratio outdid. BC gamers, as I said before, use everything from square monitors to massive ultra white displays. If your UI is hard coded for ten ATP, it will stretched or float in the middle of the screen on ultravt. You must erify that UI anchors correctly across all instions. And the last one is the high refresh rate physics. Some players have 144 hertz or 240 hertz monitors. If your game physics are tied to the frame rate, the player with 144 hertz monitor might only run. Let's see some real world bugs. BPC birds are legendary for their bugs. One of the most infamous was the physics speed up in flout 76. The physics engine was tied to the frame rate. Players realized that if they looked at the ground, which is easy to render, their frame rate would shoot up and they could run at sonic speeds across the web. Include the lesson. As a QA professional, you should use different PC setups to verify that both potato PCs and high end machines work as they should. Also, checking different UIs, different skiing options, resolution options. Applications and refresh rates are crucial to make sure that each player is satisfied with graphics, game overall balance, and other things. See you in the next lesson. 43. Wrappers: Come to the Lesson five. When you play a game on steam, you are not just running the file. You're running the game inside the steam client. This rapper provides critical features. For example, DRM or digital rights management. Check in if you actually own this game. It also provides you achievements. These pop ups when you kill a boss or doing some first finish race game or another, and the overlay, the menu that appears when you press Shift tab. SQ these are crucial things to check before the launch. If the overlay posses the game, but not the inputs, player may lose all their progress in 1 second. If the RN fails, pirates will steal the game on day one. Let's talk about the overlay. When the user opens the overlay, the game technically loses focus, but it is visibly steal on the screen. The buck happens when the game things, you are holding down the double key because you are walking and you press Shift tab. You enter the chat but character keeps walking into a wall or into a cliff. The game should actually pause everything if you open the overlay, if you're talking about the single player story games. Because of course, in the multiplayer games, it is not possible to stop for you everything, but you should assume this. Then there is a DRAM. When the game boots, it asks team does this user have a valid ticket? Valid pass? If you don't test this, you might release a DRM free version by this is simple. You should close Team completely and try to run the game directly from the folder. It is installed. Launches without opening steam gland, you have failed a DRM check. That's it. Let's talk about some use cases. First, the offline mode to test. Steam allows playing without Internet. If you go to steam and then go offline, you can play the game and unlock an achievement. Then close the game and go online, and your achievement should pop up retroactively. If it is lost forever, that's actually back. The second is the cloud conflict. Let's say PC one has aa file with hundred coins, and PC two has a safe with 200 coins. You can play on PC one offline, then PC two online. And when you reconnect PC one, steam should show a cloud conflict dialog asking, which file you would like to keep. At bet integration will simply overwrite the newer file with the older one without asking you, which might do refund from player. The third thing is a four gut. Players often for skewed games. Can earn achievement and immediately press T four. Did the achievement unlock on the server side, but the game didn't save locally. This creates a logic mismatch where you have to finish the game achievement, but the last checkpoint is still active in your Safe file. Storing decoration box are public and embarrassing. A classic is the broken text achievement. The developer may forgot to upload the text to the achievement to the stem dashboard. So players might unlock achievement name some test name. For example, as it here on real example, ACH, 001 name. This is achievement in the real game, which is released and players or some achievement received this achievement with placeholder name. This looks incredible and professional. So don't be shy to use at least cheats to cover all achievements in your game if it is not possible to create them manually. Also, as we talk, you should verify DRM because there was a case named review bomb in Steam. A game edit a complex DRM that checked the server every 5 minutes. But if the players Internet flickered the gamepost because it was not able to verify that the player owns this game. And this game got mostly negative reviews due to this light integration of DRM. So you should do as we talk with you. Simply close Team, run the game from the folder see if it launches, who is opening, steam client or without. That's it for Section eight, and let's move to the Section nine in which we will talk more about the reports, some test cases, the plans, and other documents and the box they keep. Because, of course, documentation also should be written correctly, so we will see what are the most crucial parts to keep with professional and what things should be reviewed at first. See you the next section. 44. Example of good bug report: Welcome to the Lesson one of Section nine. If a Jira ticket is the currency of quality assurance, then the summary is the face of that coin. A good summary is like a newspaper headline. It must be scannable. Developers often look at last of 100 bucks at once. If your title is the Fox falls, you have wasted their time. A professional summary uses the formula like feature in brackets, plus what happened, plus under what condition? For our Fox game that looks like physics, player falls room platform if game is posed while platform is in motion. In this let's say ten words, developer knows the system which is broken, the object, and the trigger. Now let's talk about the two most misunderstood fields in severity and priority. Severity, actually, is a technical measure of how much the game is broken. There are four gradations like S one, it's a blocker. The game won't even start. S two major, it breaks core gameplay. Some core feature like jumping, saving I know coins, capturing is broken. S three, it's minor. Small bleach, some design bug, and as for Smetic some kind of tipo in the credits. Thing that is well hidden and amount of players will notice it. And actually, it does nothing to acre gameplay and overall filling of the game. But the priority is a business measure of how fast we need to fix it. Imagine tipo on the main buy button in the shop. Technically, the severity is as for because the game works fine. That's actually lower than minor ratio. The priority might be immediate, B zero or B one, because it makes the company look untrustworthy and stops people from spending money. Conversely, imagine a crash that only happens if a player stays in the credit screen for 4 hours. The severity is as one, it's crash, but the priority is low. It's a P three, because almost nobody will ever see it. Nobody will stay in the credit screen for 4 hours. Learning to separate technical impact from business urgency is what separates junior from senior one. Next we have environment. It's actually the build on which we notice the bog. It is the platform on which was testing inputs used there might be some CPU used, GPU used if you use BC compatibility testing. Amount of AM you have some specific examples version, et cetera. This is especially crucial thing if, as I said, you are doing BC testing because on the console, it might be simple maybe platform, BS five inputsens Imput you will just type the build. Next thing is steps to reproduce. This must be kind of robotic number, at least. No stories of love. If you tell developer I was jumping around and then something happened, they have to recreate your entire play session. But if you say one, for example, launch level to then navigate to some moving platform, or even if you can find Unity, which name object has, that would be amazing. Then do some action, do some action, and last action. So they can process this. They can do step by step easily and create the book in let's say seconds, not hours by plane entire session. So you should keep it actually simple and pretty easy to read. Then we define the actual versus expected results. You were saying that I saw something, but the design document promised it another thing. This prevents developer from replying. It's not a Betsy feature. If the expected result is grounded in the game's design, the box stays open until it is fixed. So if we see that let's say platform continues its movement, but player loses its collision and fall through the platform. But our game design document or designer says that player should remain parented to the platform and stay on the surface when the game resumes. Means that it should be like this, and we are confirming this by writing here, the expeded result. So developers know how it should be and what actually the bug is. And finally, the evidence. Some video recording that is ultimate proof of the bug. Shows developer exactly what the glitch looks like. But the video only shows the symptom, show the cause you need locks, if possible, of course, not every bock require locks. Attaching this to your ticket is showing the exact line of code that failed. Mostly, it is used for crashes, freezes or major box because for example, for some art box, ding video and screenshot is pretty enough. As you can see the simplified how it could look like. But in Jira, you will have to degate the session section as attachments. You will attach your video in MP four or moth format and log file. Developers will open them and look what actually the buck is. Let's look at the incorrect buck report. The summary, the foxes follow and some description like I was playing the level, and then I jumped on moving thing and press something and then I do it. Why this is bad? I think you understand why? Because it has very good summary. It doesn't explain why or when. Some kind of emotion language annoying, please fix, fix up. You cannot say fix as soon as possible because your manager sets the priority on the things and asks developer to fix or not a app. Also, there are no steps, so developer has to guess what is moving thing and how to trigger actually this bull. This buck is missing. Environment, which built version, the bag cure, which device, it was produced. Also, there are no attachments at all, and of course, there are no expected results. So probably we even don't have this link in our design document. So developer could say, it's not a bug, it's feature. To conclude this lesson, I want to say that project to project, the bug reports depends the changes. Because some of companies use, for example, these fields, some use another, some of them, for example, have also some description field in which you can say more details. Some of them use I don't know, different things. But the core fields that you should have and keep them field are as you talk. The precise summary you make by formula, right, set severity and priority. Actually, the priority is set by your manager, not by you. The only exception would be if you're senior or lead QA or you don't have a manager, but still, you're going to lead. We set the priority, you can set only the severity in most of the cases. Then environment in which BC happen at step two reproduces the most crucial thing, actual expected results and your attachment. After that, your Bug report will look perfectly. Developers will say, thank you. 45. Example of good Test Case: Come to the lesson too. We know how to report. But how do we know what to test in the first place? You cannot rely on your memory. If you try to just remember to test the sound volume, you will forget it on Friday afternoon. We need documentation. And in this lesson, we will explore the difference between the test case and the Fast checklist and when to use each. Do you use which format? The test case is for regression testing. This happens when the game is feature complete. A test case has specific steps and unexpected result, which we might take from our game design document which is say finished. For example, expected result, Fox jumps approximate 2 meters and pretend you have new camera which tests it and Fox only jumps 1.5 meters. Fail this test case, but checklist, if you have checklist, you will have probably something like jumping works and it will pass. So it concludes that the checklist is mostly for smoke testing. This is for you when you get a new build, you don't have time to read 500 lines of text. You just scan the list like shop, check jump, safe, et cetera. It assumes you already know the game and you do basic tests. Let's look at some examples of correct incorrect test case. The incorrects case, you might see on the picture here, we have some IDs, some title, preconditions, no preconditions, actually, some three steps and expect result. Why this is bad? Because you don't have ID pattern. One is too simple. If your game is not like we are testing during this course, which has only a few inputs, one sound, and few assets, you should use here something like let's call on a bit like test case, Fox game Mv 01. Could be I don't know, some ID, say, it doesn't matter. It could be actually this case, fox, maybe functionality like physics physics. So B H zero, one, and you might have here 100 cases. You will know actually where from which game and which functionality, this case is, then you can link them into let's say, your bug reports or other kind of documentation look at another thing, it is missing preconditions. If the fox in the air in the menu, the test might fail, but we don't know why. This is actually a good thing to know that precondition for this case is like, you should load something. You should be in some state and don't pause your game. And after that, this case might pass. If you don't do that, you will not be sure about it. The next thing is some vague steps like open the game, press space, see if the fog jumps. It looks like some checklist, some checklist. For the smoke. Like you open the game, you market is done, press space to jump. Okay, the fox jumps. That's all. You should write here. The exact and accurate steps like let's look here. Press the jump, input key, and note which input key we have right now set by our designer. Then let's observe the Fox vertical position in some exact view and observe the components. Agree that this looks better than this and looks more like test case, more solid. And the last thing is subjective result. Here you can see that the tester wrote like Fox jumps. Okay, and it looks good. It looks good. It's not an engineering requirement. Because one person's good is another person's buggy. You should learned it because something good for you, let's say in level design might be some bug or misunderstanding or even usability bug because try a lot of design issues. So you must verify everything accordingly to the design document, to the design, vision, and accurate test case. Let's look what we have here in the correct test case. As we saw ID, I think you agree it's better than just one. What is one. This gives us precision. Test case, game functionality, and the number of test case in this let's say folder. Title, like verify, single jump heat and animation state while grounded. So we know what we're doing. We are fine, single jump head. So it is accordingly to our document. It's 1 meter. Okay? We have some preconditions. We should pad level one. We should have the grounded state as it is here. Game dot post. We have some steps here, how to create this test case. And of course, we have expected result. It is possibly taken from game design document like the Fox, some value, for example, decreased by 2.5 units or as I said by 1 meter. We jump, we will find it. I jumped by 1 meter. Speaking about the checklist, it might look actually like simple Excel or document and written like let's say I don't know, ground is present. We have written the checklist. You know, it's the simple thing, as I told you is for smoke testing, like the bill launches plus while we launch the game, while we launch the level, is the ground present here, plus when we jump, plus actually fox jump, as it moves to the heat. Plus, that's pretty simple thing that can cover basic things you know that are working in a simple way. You know that Fox jump, you should press Space Bar and it actually should jump. It should move on some heat. The build launch you run your X file and the but actually open again, open main menu, shows you some title screen, launch level one, et cetera. So you keep it simple. You just write it before your smoke testing of the build. That's pretty it from this lesson. And with the next one, we will talk about the test plan. So see if 46. Test Plan: Welcome to the lesson tree. Let's talk about test plan. In the previous lessons we learned how to report single back and how to write single test case. But now the clock is ticking. The developer just gave you a build at 4:00 P.M. On Friday and you can test everything. This is where the test plan becomes your best friend. The test plan is not just a list of tests. It's strategy. It defines the scope, what we are touching, and more importantly, what we are not touching. The developer only changed the eyes, physics, a junior tester might waste 3 hours checking the main menu settings, but professional key focuses where the code actually changed. Let's take a look at very brief, simple example of this plan. You can look for them in the Internet. There are a lot of examples, a lot of different makeups of it. It could be as written one and in the picture one in Canva, in Mirror, in Vima lot of places. You can use it as you would like, but let's look at let's say the most important things for now. We have test plan our project name, and let's say Winter release. Version code, our goal, we should verify that new ice level, we release our ice level features and ensure that jump and safe systems haven't broken. We're doing regression. Our scope for this is in scope, some new physics, new MAA, and safe float functionality. What we have out of scope is multiplayer and mac and in explode testing on Windows only. We have test levels. We are doing during this winter release. The smoke test, which is 15 minutes we're launching the game, we look if Fox game can launch. If we can enter Level one, the game, find that MI is here actually, and do we have safe load functionality. Then for example, sngy test for 1 hour. Does this new physics actually make the Fox light. And during this release, we're doing regression. We're taking, for example, full day the fox still jump correctly in the old forest level. So we change it, here the physics, and at that new level, of course, we should check our previous levels colliding with the physics if they are not broken. And let's say we have entry and exit criteria, like the pass, let's say, the pass level. For entry, we have built number is available in build pipeline, and all in progress tickets are moved to test or in fun and exit criteria might be like 100% of sof stopper box and critical box are fixed and verified during this release. In other words, let's entry criteria is you check list before testing. Is the build ready on the pipeline? Did developers finish their good review? Because if you start testing too early, you're testing let's say broken build. It is not ready yet. Criteria if you're definitional done. In gamef you will almost never have zero box. There is always some tiny texture glitch or small TIPA. So your criteria might say we can ship as long as there are zero ostopersen critical box. And this is where you as a QA help producer decide if the game is good enough the players. Also this plan might have one more category, which is named risk assessment. It is not actually required from Junior Qs, but I will let you know that it exists. Let's say what happens if the safe system, which we added here, it fails during testing. We need some plan B because we plan our release and you should act in real environment will be testing on different branches. Test the new feature on one branch while the main game is being prepared for release on another. Understanding this map transforms you from person who winds back into release engineer who ensures the game actually makes it to the store. So you should have, let's say, risk assessment plan, you type here. For example, plan A, we have zero. Let's say showstoppers. Zero major issues. We covered all game with regression and everything is good. But what if, as I said, the safe system fails? You should release the system. We promised our players or investors. You should have plan B in which we fails, we have failed core system test. So we are doing, for example, another branch, reverting. So we revert something from our reserve branch in which the system was working or the system don't exist at all, and we are letting or players or investors or any kind of human ways for this release that this thing is actually broken, we're aware of it, so we're giving you plan B. That's actually pretty simple this plan, but as for now, this is enough for you. You can go through the web and search for some examples, but most of the the plans you may find there are more for software price. Y a lot of strict things, and they should be pretty accurate. So try a lot of risks, a lot of criteria, a lot of test definitions, big scope, and other things. Also, we forgot to mention deadlines, but I think that in the company in which you will pass your interview, they will already have some template for so you will just adapt to it, knowing that we have scope, we have basically test levels, something to test. We have some criteria to pass this plan. We have risks, we have deadlines, for example, and it's not actually for you, but for your probability manager, we may have resources, three depths, one QA, and you can calculate some human errors, but it's not in it. As for now, probably we'll talk about this in another course, more senor one. For now, let's move to the next lesson. 47. CICD Basics: Welcome to Lesson four. In a professional studio, developers don't just email you the game file. They use a pipeline or CICD. The pipeline is a robot like Jenkins or HTHub actions that takes the code, compiles it, and spits out a build for you to test. But here is the cage all builds are equal. A build from a feature branch is very different from a build from the main branch. In this lesson, we will learn the GitFlow strategy and how to map your testing plan to the specific branch you are testing. Imagine the code is a tree. We have feature branches. They have names like feature, some double jump. This is a single developer working on a single task. It is highly unstable and your job is to do destructive testing. Try to break that specific feature and ignore the rest of the game. We have developed branch where all things merge together. It should be stable, but often it breaks when two features conflict, and your job is to do integration testing, like did the jump functionality merge correctly with the shop, for example, or skin animation or anything. The last thing is main branch or release. The code goes to the public here. It should be frozen and solid without any changes and well tested. You do here full regression, and on main branch, usually we at only critical buck fixes. In the project we have to deep platform Unity, there was only one branch main because the game is actually small and the man who did it decided not to break into the feature or develop branches. So he just used to push the code into one branch, and that's all. But in reality in big production projects, there will be a lot of branches. Develop feature main under developer might be another branches, similar to it under feature 100 other branches, but the main or release will be one. As I said, it is your release branch from where the players receive the game and which will be built using the pipeline, CD pipeline. As this project doesn't go with some pipeline, I will just briefly show you the solutions that might exist. But please take note that the project to project on some project, guys use Tim City on some projects, they use Jenkins, some project uses GitHub actions. You can briefly understand what they are doing just to know the difference between them. In general, for example, Timsty which I use on daily basis, that's simple thing. There is the have to mention of build process. You can see here, we have some build pipeline from some branch. It is called master. It might be released, it might be actually developed. It might be any branch you would like to build. But let's say we're doing automation of our core branch to deliver it by night to the players with some update. So we managed our automation. Developers run the script. They wrote the script, they run the script, uploaded it here, and you or your lead starts the run, and TeamCity starts to build actually your code, your range, and after all of these nodes, it simply downloads built to your designated pass. It may be some Google folder or program folder or any other kind of storage you would like. And then you simply push your Z file to steam, APIC or any other solution, and players receive it as of date. As you can see here, there are a few actually differences between Jenkins and TeamCity. The main difference is that Jenkins requires manual setup. It is local based, but the Team City is cloud based and provides some kind of integrations, some plugins, some fest setups and other things. But of course, if you talk about Jenkins, it is open source, so it is free to use. But the Tim City is BaiyT so to some of the things, SSD plan is automatic flow that guides your game from developers computer through the stages of building destin and releasing. Typically the draw four major phases is ors. So pipeline triggers whenever code is pushed to repository master, for example. Then the robot on server side transforms all the code that was pushed to random product like for PC or APK for Android. Then if the pipeline has some auto tests, unit tests or integration tests, some security scans, does it to ensure that changes haven't broken and missing and the last thing is deploy. So the final build is automatically delivered to some repository, some folder or whenever you would like, and then you push the game to steam Epic, Google Play market, app store or any solution. So as a QA from all of this lesson, you should learn that on feature branches, you trying to do some kind of destructive testing, negative testing, positive testing, you trying to break specific feature that is provided by developer in this particular branch. You're ignoring the rest of the game. For example, let's pretend that on the feature branch, we had improved UI. So here was the updated scene, you're switching to this branch, pulling the code, getting to Unity to this file and verifying that everything is working correctly in this particular case. Then if we move to develop branch, let's say that this feature got merger to develop you're switching to develop and find that there are no conflicts. You verify that this improved UI works with old UI or any other features that may contradict. And after that, if everything okay, these updates are going to main, and here you're doing full regression of new updated UI, old UI, and any other systems that your game has. After that, it goes to pilin, doing the build, and releasing to the players. 48. Bug Triage: Welcome to Lesson five. You have worked hard, but you have field 100 bucks, and the release is scheduled for tomorrow afternoon. But here's the coded hadality of game development. The developers only have time to fix ten of those bags. Who decides which bugs leave and which bugs they're cutting? This happens in a meeting called Bug Triage. It is a high stakes negotiation where the goal is not to fix every bug but to decide which bugs are acceptable, which not to ship to the players. In this lesson, we're going to look at the roles involved, the trig categories and the ultimate goal balancing game quality against the reality of deadline. Of all, let's decide who does what? Rage meeting is not just for QA. It's a trivversation between different departments, each with their own goal. Let's say you're AQA, lead or the person involved. You're the voice of the user. Your goal is to fight with the best possible experience to fix as much box as possible and the most major ones. You provide the evidence, the bog reports, which includes locks, rapper steps, and the impact the user might observe. Then here comes the lead developer. Their goal is to explain the risk of fix. They might say, I can fit the picture bleach, but it requires changing the entire rendering engine 24 hours before lunch. It's actually too dangerous. And here comes the producer. Their goal is to hit the release date without shifting it. Look at the budget, the marketing, schedule, deadline, and make the final yes or a no decision on whether a box stays open, or it is reschedule it to another print or we just close it as would not fix. The main goal of this meeting is alignment. We want to ensure that if a buck is shipped to 1 million players, everyone in the room has agreed the risk is worth the reward. Let's look at some simple agenda template. What we have here, Title I is Barge agenda. We have a meeting frequency like we're doing it daily or we're doing it weekly or on request. Its duration is required ATMDs a developer, project manager or producer the numbers. We should include here total open box, how many we have in our Block. Flow, are we finding box faster than we're fixing them? Because if yes, you might need to delay the release, have a lot of them unfixed. And the blockers we have simple list of B zero or P one bugs that are currently stopping the QATeam from finishing test plan. Remember, in test plan, we have entry and exit criteria and the absence of B zero box might be shortstop for us to complete this plan for the spring. Then we have the new arrivals, for every new bug found, the must decide, we should confirm its priority severity, does everyone in the room agree on how broken this is the risk of fix, like developers, they do estimate if fixing this bug endeavor di should be fixed right now before the release fix later or ship as known bug or won't fix at all. Al address zombies, reopen a box. Box we had previously, but they still occur or occur this new instance with different steps, let's say, and the last one is the exit review. Like, do we still have throw stoppers or critical box, and is the current stable enough to move from better to release candidate and actually ship we send deadline to the players? QA, you must learn to negotiate. If a producer wants to mark a crash as known B, you need to pull up your data and say, this crash happens to 10% of users. That is 1,000 hundred people who can play, for example, and using these numbers, you might win the argument and push all the forces to fix that crash as soon as possible. Let's try a real world example. Imagine you have three bucks left and only 1 hour of death time. It's Friday afternoon and everyone is going to home. What we have, we have Bk A. It is high severity, but low priority. If players stand still for 2 hours in the forest, the game crashes. Have Bk B with low severity but high priority. The snowman enemy level two has no sound effects. B C with medium severity, but critical priority. The gold continue is cut off on some phone screens. What is the correct rash decision? Junior might be B A because crashes are scary, but Senior K knows that almost no one stands still for 2 hours in the forest in one location to trigger a crash. B is actually annoying that Snowman has no sound effects, but it's just audio. It's just one effect on level two. And there choice is B C because it affects the players understanding of their progress. If they can't see how much gold they have, they can't engage with the shop. It is a business priority that protects the game's economy. In TriH, we SQA always protect the core loop first. Have you ever seen this bug from Assassins Great Unity? Actually, this bug was likely found in Trig. The team marked it as low reproducibility and decided to ship anyway to hit the Christmas deadline. This one became a global meme and permanently damaged the brand's reputation. So Trig is where the science of QA meets the art of game design. It's where you prove that you're just a tester, but stakeholder in the game success. That actually the end of Section nine. So let's move to the practice. We will test our focus game to find some box, to lock them. I will show it like live demonstration. And before this, I will break it a bit because currently the game looks pretty stable and no metro box exists. So I will do some things in the code to break it and showcase you how the QA in Unity works on daily basis to find the bags, to reproduce them, and to lock them. So see you in the next section. 49. Black Box testing practice: Hello, and welcome to the Section ten. This is the last section of that Unity QA course. And in this section, we will have three lessons, which will be like practice. At first lesson, we will play the gray box tested open source game, which is made by Unity and is created to understand which box we may occur in standalone builds. Then in lesson two, we will return to our Fox game, and it will be broken intentionally by me to showcase some bugs that may occur in such games like platformers with slight amount A and some physics and mechanics. So we will look at them, log them, find them. And in the last sort lesson of the section, we will look at another project, some more complex three D shooter game, which is built on Unity assets and can be downloaded by everyone. Without any issues, it also will be a bit maintained by me to showcase the possible box you may occur during your job. So stay tuned and let's move on. In this lesson, let's focus on the standalone built of game that I will share with you. So you also can upload it, play it, find the same box to feel how it is. It is named gray box. Testing link on it will be shared with you, and let's start. Here is the first buck. The player can move through the wall. This wall contains no collider, so user can simply walk through it. Let's test other walls. Another at looks great. So yeah, here is the first buck in this room. The wall which doesn't contain any collider and player can step through it. Let's lock it in our bug list. So the third thing is, let's do like gira. It is physics component, and description would be like player can clip through the solid walls using camera rotation. Is severity will be major. As it actually breaks the level design boundaries. Players should don't observe such things this game has the second level after you break the lb, but some games might just fol you to the void because it might be some boundary. Let's move on. And for splets post the game. Oh from what I can see, player can move. So we pose the game, and there are some glitches on the screen. I think it is supposed to be here by design, but still we see some glitches, and we see that moving mouse and using WASD and keyboard, Ms player move. That's another bug. That's no moving during pause. Let's also lock it. So what we care? Here here, UI player inputs, I'll say remains active while pos menu is open. Its ty will be high because as I said, player could accidentally walk off a cliff while changing some settings or doing some maintenance here or even let's say it is multiplayer game with 64 players, and some player wants bathroom quick or anything, some phone ran he used pause and game actually is not pause. That's especially in the single player games. Let's say some multiplayer games may work like that, but still, if we click pause, the mouse should not be rotatable and the player should not walk using the keyboard. Both should be static. Mouse should be for selecting resume, restart at menu or another buttons. Let's move on. So as we saw, we might check colliders walls. Yeah, here is also LLD bag level art design, which means that the C lines are not aligned with each other, so this texture might be actually as you see, they are different, and I assume this game uses this as map design. But in real world games, such things might be treated as back as slows and back. Like lens are not aligned with each other, but let's assume this game is designed in that way because this is here squares and here rectangles. Here's the aer Bug. If we are interacting with object with the cube and press pause, the object is like unlinked from us. It launches away. If we unpause, it sticks to us again. It is another kind of bug. Let's strike it as some probably physics. Let's say interacting with objects during pause causes extreme velocity. Severity for this, I would say high because it breaks the physics engine. It might not harm, actually the game experiences after we unpos our object returns in our hands. So it should not be some critical or another kind of, but still it is high because let me show you something if in this particular game stand on this tile which opens the door and we push the cube. It may disappear out of the door and player will be soft locked here because cup is not respondable. Let's try one more case. What if we have the cube and try to move through the door? Yeah. As I said, the cube just fallen through the door and we can't interact with anything. We can open the door, but we can't pick up anymore. The cube. Yes. So player is soft locked here. How can we lock it? This is actually level design box design. Um let's call it puzzle box, and say that it can be force it door actually locked door. That's important. And the severity from this, we can put as critical because this is soft lock. Player, is forced to restart the level or cute at all, the game, which means that if the soft lock occur at the end of some very, very hard level and no restart from checkpoint, which was, let's say, here. It means that the player should complete this hard heart level again, which lead to bad reviews of the game. So it is important to check also some negative cases like that. Be aware. But we can restart and do positive test, move to another room. What we have here, I think colliders will be okay here. But let's do at least situative testing. Yeah, collaters are fine. What we have a cube, and we should be at the top. What do you think? How can we reach the top with the cube? Just jump on it. It doesn't multiply or jump heat. So probably we can take it. Yeah, it glitches and it gives you some velocity to the top, and you can move yourself to the top. That's also actually a box. I know that in this game it is kind of design solution, but this game is built to showcase a box which may occur during your job. So what we can write here? Let's say it is also physics. Actually the same third. Yeah, it is actually probably the same. The third part without pause. So interacting with we can say cube. We know that it is cube or puzzle box, standing on it and taking it cause player to move to top. We can say that. Severity for this will be actually medium. Why medium, not high because this buck is not something actually critical, something harmful for player. Player may live with that. Yeah, he may observe some new heights, reach some destinations, but actually, if it doesn't fail some quest, why not? It's bucket should be fixed, of course, before a lease pod. It's not such high as it may be. Let's move forward. I know whether we should keep this que pod. Yeah, we should keep it. And from what I see, we should transfer this coup here. How can we do it using this back with door. No, here it doesn't reproduce. Here, the door has probably some collider, which doesn't give a chance to do that. And still we need to have the door open it. So et's try to find something. But what if we for our game and move through the door? Yes, we can do it. That's also a buck because the player is not post, but everything in the game doors, buttons is post. That's actually the same back as we already looked with the system which is related to the post. And which doesn't stop player from moving. So when this, this second bug will be fixed. This also might be fixed along with it. Then another bug might be the objects may push you out of bounds. Let's try this. As we see, we have this collider here. But what if another object pushes our player through this wall? It is actually successful, and never minds that this wall has collider, actually. Your player might be thrown away, might be pushed out of box, anything may happen. So this is also a great test case. Let's try to see what we have here. As we can see this object tries us to push us through the wall but here it is unsuccessful. I cannot jump there, but I should be able to jump on this style, then on this style. Then on this and then on this, yes. I'm not sure which box should be in this room, actually. Probably also push out of walls, probably something here in the center. But we haven't absorbed any except this try to push out of bounds, but it is unsuccessful unless unlike the previous one, the walls are with gliders, everything is okay. That's great with move. What we have here, yeah, I think we should take this. We can use a glitch, I think to speed up a bitter process. We need three boxes. We have one. Actually, the second one. I think we can use the pause here and try to through this cube through the door and move. So we used to kind of exploit. And here also the leaves exploit. We will stand on this, pause our game and most of the This is actually the end of this Black Box testing game. We found five pretty You know, we SQA see them quite often in BA projects, especially in games with Open World, with a lot of some boundaries, and, you know, the pause bug happens quite often. So keep in mind this kind of bugs. We will try all of them, some related to physics, some related to UI design in the next lessons in the Fox game, in the three D shooter game. There also might be some walls. And yeah, we will try all of them, probably some may ocurre. So see you in the next lesson. 50. Practical testing in Unity (2D game): Hello, and welcome to the practice lesson. Today, we're going to test the fox game and issues first, like everything we'll find. Then we will inspect each pack to understand the root cause of it. We have a new build to the focus game. Let's first launch the game and see what is wrong with it. I will play and commentate and you can take notes. Let's launch the game. Alright, the game is live. Let's observe. Immediately, look at the score UI. I haven't moved. I haven't touched anything, but numbers are racing. We already have 16, 17, and it is raising. But we know that a score should be an integer, like one, two, three, five, ten, but this is a float Stimal. Actually, it looks like timer. It's already 30 seconds since you started actually. This one is a critical UI buck. You can log it as buck number one. UI score displays time instead of points. Son number two is when I move, I press right or left. Actually take character moves. But as we can see, as we can see sprite, it is frozen in idle pose. Like this animation is called idle and we do nothing. And when I move, the animation so change to move moving something like that. And when I move, it doesn't change. The physics works, but the visuals are frozen. It's definitely an animation bug you can lock it as B number two. Run animation fails to trigger less one. Observation number three, the coins, I can't check them. I can't pick them up. They are acting like some unbeatable rock instead of objects that they can pick up and which will add some score to me. Actually this is pretty simple back. You can log it as back number four. That coin is solid obstacle that cannot be collected. One more observation. Observation number four is when you press space par and then press it again, like our fox jumps again and again and again and moving out of the screen. If we spend space bar, this is actually the thing called infinite jump exploit. So we can lock this as bag player can jump in mid air, which means that player can spend the spacebar and do jump action many times without any delays or if it is if it should be by design that we press space bar and the character jumps only once, then yeah, it is a bug. Let's finish this level. Since we can't one more critical bug. We're trying to move into wind zone, actually level zone, some door. Let's pretend it is door and we can't complete the love. I'm standing right in the center of the door and nothing happens. Trying from top from another site, I can't finish the level. It refuses to finish. This is actually high priority buck, it's critical player can't finish the level. Log it as let's say win zone or level zone fails to trigger. Now we have our list. Now let's dig into the architecture and find the root cause for each one. Let's solve the UI mystery first. Why is showing a timer. In unity, this is a data binding error. The UI text component is a dump. It just displays what it is told. If it shows time, someone is pegging at time, what we can do. Let's open the manager script manager script. Here it is C manuscript. And we can look at Update. Oop. Update. See here it is marked as bug. Not to forget about it. Actually, this runs every single frame, and you can see here the string that tells us that it is time, it is not text, it is not score, it is not nothing that we need. It is time. And this is actually a classic Tibucqe that developer left us in production. We'll likely put this to here to test the pond probably for some boundaries and forgot to delete it. And actually, the root cause is that we have time function that we call in update each second, like 60, actually 60 times per second. And this loop overwrites our score data. So if you will notice something like this, when you start the level, and you see running some timer instead of the instead of some score, instead of some progress bar, you should open at the game manager script and look into update function and look actually something which tells you time instead of score. Or text or whenever your game should have in this field. Next, let's find out why didn't we win. This is actually a critical thing. This is like exit. It's like imagine like BP club. It checks the IT or simply tag of everyone who enters. To verify this, you can open your player and look at tag here. Top. Your tag right now is untagged, and to make it working, it should contain player because player is trying to enter the door. Also, how can we else verify that? We can find for something called exit trigger or exit or finish level script. Let's open it. Let's maximize and check that I close. Our door is waiting for tech equals player. Then we start our level exit. Let's verify it like that. We change it or tech to player, and move into door and the game finishes. Actually, if you have some game with exit condition or finish condition and your character when you move into this stor or finish line or any other finished condition and it doesn't actually finish, it ignores you completely. You should verify tag on player object on your character, it is actually player. Next, let's find out why our fox is sliding. Let's get back to our game. Actually, animation is driving by a state machine. To switch from idle to run, the code sends a specific signal parameter, and if the signal name has some tipo, the connection fails. Let's open the animation window. We need animator, so when we get window Animation animator. Here receded list is empty, but that is fine because in this architecture, in this game, specifically, the logic is on the parent, but the visuals are on the child object. To open correctly, you need to expand the player object here and to select SR. Now we see the live data, how it is going right now in the game. We haven't post it, so you can see that some progress bar is moving, animations are moving and actually look at the perimeters list. It is waiting for some bullion, which is called run, but a lower keys. Let's refine in Player controller script. Actually, which command should be? We should find something related to run. Yeah, here we have set animations function, and player anime is taught to start running animation in case we have running grand word from the capital, not from lowercase. But here it is named as lowercase. That's why it is not changing its state to run. But it changes to jump, for example. As you can see, it changes. But when moving, it doesn't change. The script simply cannot recognize the run state and changed animation run. This is a string literal mismatch. Actually, we can verify this back even without looking at the code. If you open animator and you look you have your game running. You look here and you see that the state simply don't change to another. You can capture this as video and share to developer the exact location that animation run doesn't go, and he can instigate that in the code base. And now let's find out why we are actually flying. Why can we Bam our spacebar and too many jumps. The jump logic asks a simple question. Is the ground sensor touching the ground layer? In this same view, turn on your gizmusT button, and look at this red circle. That is actually a sensor. Now let's look at player controller script. We controller script. Let's now get to ground layer and see that it is set to default. And let's check the player itself a bit above. The layer is also default, so the sensor is hitting the player's own feet and reporting ground detected. The player is effectively standing on their own shoes. So if we change here to, for example, ground something different, it yes. You cannot jump many times right now. I'm hitting the space bar as much as I can. Now it works only when the character hits the ground. Even sensor hits some grounds then it can actually jump. So the root cause here is layer mask self detection. So when you will observe such kind of bug, first of all, verify the match of layers because ground check, it includes the players on level here in this example. They should be different. So you can bug that the developer that the layers are identical, and character simply jumps from his own bits. And the last one that we have noticed, why did we bounce off the coin? Why can't we simply pick up it or interact somehow? Unit physics, every object is a solid all by default. To make it a pickup, you must turn it into a ghost by marking it as trigger. Let's find the coin. Prefab. We need to find it is named in this project as Toler, but it is coin. It is prefab. And let's look at box glider to D component here. Box glider to D, and here we're interested in is trigger trick box. It is unchecked. And because it is unchecked, the physics engine threads it as physical wall. Like we have something in code, some trigger, which never runs because as I said, the physics engine rejects the player before the script can fire if we will mark it. A trigger and, of course, launch the game. Stigger safe, launch the game. Yes, we can move through them right now. So the root cause of this specific buck was physics configuration error. Is trigger was disabled. You may ask if we checked the trigger, why we still can't pick up the object itself? We can move through it, okay, but there still cannot be picked up. The issue is the same as the tor exit issue. The different texts. As you can see, the prefab a tag coin on default layer. And if you will look at script, it will say that to pick up the coin, layer text should be. But if you open the player object right now the tech is untagged. You switch to player one, we will be able to proceed with collecting the coins. So that's actually common issue in such games like this platformer. When you cannot pick up something, interact with something, finish the game or trigger some condition, which you actually should always verify the text. Tech actually should be the object you're colliding as parent, let's say, if you're playing with character with a car with any kind of let's say object and you move close to coin to finish line, some door, any kind of trigger, you should verify the text is player. And there is the full audit. We found data binding issue, string literals, layer masks, physics, pick and text. This is kind of gray box testing method that separates professionals from ammeters. Now you can as practice, try to lock this box on your side for some kind of bug report, adding some screenshots, videos, or any announcer as you would like. And, of course, I suggest you to run the game and to try notice all of these issues and to find solutions to them. Actually, the good practice will be not to load exactly that game. I will provide it, of course, but to find another broken game from open source and try to deal with. Or to find some unity projects that are, for example, in Unity Hub, test projects, they are reconfigured. They have some assets, and you can simply ask, for example, the AI to break the game, making some box without letting you know which box it did. So you will simply replace scripts, and when you will run the game, you will not know which box it contains and you will play the game as we did during our practice session. We launched the game, we did some regression test, some smoke test. Then find out five issues, then we proceeded to investigation on them. So I highly recommend you to do the practice on your own, finding the evidence, the root cause of Ichi Buck, and understanding them. In the next lesson, we will work with another project with first person shooter, and in the same way, we will find five bucks and understand the root cause of them. See you there. 51. Practical tutorial 2: All right. Welcome back to the lab. We have just received the release candidate for the first person shooter Maker game. So development team has signed off on this claiming it's feature complete and bug free. But if we don't trust, we verify. I'm going to run a quick smoke test just play through the core mechanics, as we did in the Fox game to see how they feel before we look at the code. Let's start. Let's run the game. And third things first, let's check the damage feedback. I'm going to walk up to the enemy and take a few shots at me. I'm taking hits. Okay. But have you noticed that because p is inverse. I'm taking hits and like HP is increasing each hit and it does to me. It's acting like damaged meter, accumulating red as it get hurt rather than fell parts that trains. That's definitely a logic inversion. Let's note this bug. Now I think that I need to defend myself. I saw here a shotgun pickup. Usually, these are triggers, consumables. You walk through them, you get the gun. Let's grab it. Well, I'm just bouncing off. It's solid rock object. I'm physically colliding with it like a greater all, and the issue here is, as we saw in the Fox game, it doesn't marked as trigger, so I can pick it up, definitely. We will investigate this after our smoke session. Let's get back to the AI. I have design doc right here. Let's pretend they state that this security robot has a 20 meter detection range, so it should detect me while I'm standing here from this place. But it's not triggering to us. Let's get closer, more and more Yes, it is triggering to us, but not from 20 meters as design document states. It's triggering on us, like from 2 meters probably, like when we touch the face of each other. So he's definitely blind until point plant crane. That is way off from the 20 meters spec, we'll find out that. Okay, let's test a reversal. If I grab this chit pack, you see that chitbacs unlocked we see new L bar on our bottom left hot, and I'm going to hold space and St as I can see, there is C way fix. I can use it. But the fuel don't drain. The fuel bar is not moving at all. I'm using p over and over and nothing. So we definitely have infinite view here. That is another kind of ba. And one more check movement felix. Walking feels normal. Even if I press shift, I can move a bit faster like run. That's totally fine, but let's also check the crouch. I press CK, which stands for crouch and trying to move, and I just lounge it forward like a rocket. Crouching is supposed to slow you down for precision, but it's actually making it faster. A way more faster. So the math here is definitely broken. The logic, like the crouch, logic is opposite. Instead of slowing down, we are increasing our speed. Okay, we have found five solid. Some of them even critical box. And now most people just write a ticket and stop here. But we're going to find the root cause as we did in the fox game. Let's keep the game running, but let's pause it, not to fail anything. And let's look at the inspector to see why this is happening. Let's look at the house bar again. Go to the Canvas in their arch and let's find the fill image house. It would be under the hood. Actually, actually, we can use a search to find field image health. Usually in the most projects on the most projects, the bar, the MO bar, tag bar, any kind of bar, which has some field progress. It is named like field image, field image and the name of the system. Now we're looking at field image health in the inspector, which tells us that field amount of that progress bar is 0.6. That's true. It matches the screen. So it tells us that UI component itself is fine. The problem is the script within it. Developer likely flipped the formula calculating one minus health instead of just current health. Basically, if you open this object and you see the amount is correct, it matches what you see on the screen. You can state that the logic is wrong. Next, that shotgun that we couldn't pick up. So let pick up shotgun in the R arch and take a look at the box collider. His trigger property is unchecked. Without the check box, the physics agent threads this solid hole. It never fires the trigger event because it's physical collision bounds. If you check it, we will be able to pick up. Basically, each time you can pick up some consumable, some coin or other things that you should be able to pick up, find it on the scene. Take its name to Ear arching, find it, then check box collider. Is trigger should be checked. Now for the blind robot, we should select the enemy hoverbot in this case, and find its detection module script. It says, the detection range is 20, like design document says to us. So the data is correct. But we saw in the game that he didn't shoot until close range. When the data says one thing, like 20, and the game does another, it's almost always means that there is a line of code, some hard coded value, which is overriding this setting everything frame. To verify this, you actually can bind for detection module. Open it and look for the property which is set for our range. As we can see, detection range, property is set to 0.5, which means that it is hard coded. It doesn't use the value which comes from design document. Let's check the jet tech Select that's collapses. Let's select a player. Let's find JTBAC script, attach it to it. And, of course, let's switch to DBC mode to show more ables. We need to find current field ratio. Current field ratio. Here it is, and it is locked at one. The game knows that I'm flying, but the logic that substracts you is missing. It is an infinite loop of f engine. Basically, it means that it is also kind of hard coded in the code. So you can screenshot this value. You can do a video that your fuel never ends and report this to your developer. And also, let's check our super speed crouch. To do this, we should find player arter controller. And find the setting Mac speed crouched ratio. Mac speed crouched ratio is 0.5. It means 50% of speed, but why did we go first? The code is likely plan this wrong, maybe dividing by 0.5, which doubles the speed. The issue is in mass in logic in the script. In QA, you always compare the actual result. What happens in the game against the expected result. And this kind of variable or any another variable, let's say about this one, it represents the percentage of movement, speed, the player should keep while crouching, the value usually set to half of one, 0.5, which means 50% of speed. And the logic is, if your running speed is 10 meters/second, the code should calculate ten multiplied 0.5, which equals 5 meter/second. When the buck happens moving too fast, there are only two possibilities the data error or logic error. The data error is simple. Designer accidentally typed five instead of 0.5 in the inspector. In this case, the code is fine, but the input data is wrong, and you will notice it simply from looking at it. You will see here five and understand that Mexpet is just a tipo. But if it is a legi error, the data is correct, we see that like current, 0.5, but the programmer used the wrong formula for mass, like dividing instead of multiplying or adding speed in array. So by looking this variable first, you prove that the settings are correct. Therefore, the fact that the character is moving faster means that script logic is ignoring or minus in this number. And you may ask, how can I understand which able I should look for? In unit development, ables are almost always named using keywords that describe what they do. There is three step process you can learn. It is like what where method and which step one is, who is acting weird, like the game object. If the player is moving too fast, we should select the player if enemy is blind. We select the enemy. If the gun is not working, we're selecting the gun, et cetera. At step two, we're looking what mechanics working. The component. We're looking at the list of components, scripts on that object. If we have buck like I'm moving fast, we're looking for a script, player character controller or movement. If you have buck the enemy can see me. We're looking for script related to enemy, something like enemy controller or detection module. If you have I behavior. If you have some infinite line, we are looking for the script which is related to fl. Especially in this game, it's only one jet pack. And the third step is where is the setting, the variable itself. Now we're looking inside that script for key words related to the bo. In our case, crouching is fast. We're scanning all of these variables for words, crouch speed ratio modifier and when we inspect, we simply see that we have here speed crouched variable which corresponds to our issue because for example, in error doesn't apply to us, sprint speed modifier doesn't apply to us, Qate Put step as fix that's not we're looking for. We're looking for Crouch. Crouch there is only one variable, which is our correct thing. So how you can actually think. The problem is speed when I crouch. I need to find the script that controls player movement. You're selecting player because issue in player is related to player. And you get to player character controller. This script controls actually player character. Everything is what is related to our character. Then you scan or crouch, you're finding this exact readable and find it settings are correct, but the code is wrong. For example, forget backpack. Your thought process should be like I have infinite fuel, I need to find the jet pack settings. You're selecting player, you're finding the JetPack touch script, and you're scanning for fuel, duration or fill. You can find here the consumed duration, or if you're in the back mode, you will see current field ratio which is locked.