QA: Become a Game Tester 2026

1. Introduction: Hello. Welcome to the introduction of the course QA becoming a game tester. In this course, you will receive all needed information to start your ET career and to apply for the first job. We will have an overview of QA position, declare needed skills and knowledge for good game tester and understand. Who is a QA specialist in game development industry? Before we start, I'd like to give a small overview of the state of the gaming industry from a financial point. The market is growing. The gaming market size is expected to be valued at more than 250 billion in 2023, displaying a projected compound annual growth rate of 10.1% during 23 t 30 year. The main factor that impacts the growth are continuous technological advancements that make game better and more competitive, the rising Internet connectivity, increasing adoption of smartphones, and the advent of high band with network connectivity, which actually make gaming more easy to achieve with a high variety of options. More than one out of three people on this planet are currently playing games. What does this information gives us? Right, a growing market means more games to be created and more working places to be opened in this industry and being able to join the gaming world as created during its rising gives a lot of opportunities in future. That's why we want to give you all needed basic knowledge to be able to apply to the job positions and have knowledge of junior game tester. If you are very new to this type of job, let me give you a quick overview of the main responsibilities. There is a saying like game testers just play games and get money for this. But trust me, job is actually much more complex and interesting. The main responsibility is to catch box, but the slang name of some mistake in the game that becomes an official name of all issues on the product. Though the main job of a tester is to catch all box in the game and make sure that the end product works as expected on all levels, starting from installing the game, completing the mission, and finishing with any small detail of it. Then when the tester has found the bug, he provides the developer steps to reproduce it because some bugs can be obvious and some of them require additional investigation. The developer needs to be able to reproduce the bug on his site and fix it because you can't fix something that you cannot see. As games become bigger and more complex, good testing requires proper planning, preparation, and strategy. When the time is limited, you need to plan all your test in advance and make sure you cover all possible areas in the most efficient way. And the last is to provide a clear explanation to everyone about this pack. That's why QA is here. They are the people responsible for the quality of the game and the way the end users see the game. Now we come to the expected question, what's needed to get started in quality assurance? Well, the good news is that's one of the most accessible professions in the entire video game industry. Entry and junior level game testing jobs will often be open to people with no professional testing experience. Of course, it's a plus to have it, but it's definitely not something that it must have. But being passionate about games or just having the will to get a new profession is not enough. Still a lot of companies require knowledge about test case management, basic testing theory, and testing tools. That's why this course was made. Here, we are going to cover the main areas of the profession, such as testing theory, game development and testing generics, testing documentation, including checklist, test cases and bug reports, and also testing tools and bug tracking systems. Also we will have practical parts for the most important elements. It's the combination of theoretical knowledge and its usage and practice. Let's talk a bit about the game tester profession and main reasons why people want to get this role. Perhaps the biggest advantage of working as a game tester is that you can make something, living doing what you love, which is something that everyone can say about their choice of profession. Becoming a game tester is a really great opportunity to turn your hobby into a good income. As a tester of an unannounced or unreleased project, you will have the opportunity not only to be pioneer, but also receive both money and pleasure from your work. Game testing is ideal for those who have an analytical mindset and like to figure out problems and then find solutions. It's also a good fit if you have a lot of energy and need a constant challenge at work. You'll never get bored in this job as it keeps you interested with a huge number of challenges, a variety of projects, and a variety of approaches to solving problems. You can develop your career through several directions, each of which requires different level of testing ability. There are pre production, production and post production stages, and the skill requirements range from artist to engineer. Game testing is a great start for both for people who don't know yet exactly what they want to do in a sphere and for those who have already chosen their direction and follow it. And the knowledge of testing is really useful for most positions in game development as it can even help to predict possible bugs as a design stage or even at the product idea stage. The game testing is a really interesting profession with its own advantages, challenges, and it's also one of the easiest ways to enter the IT industry, namely team development. That's the end of our basic overview of this position. See you in the next part of this course. 2. Game testing. Milestones.: Hello, everyone. I am glad to welcome you to the next part of the course QA become a game tester. Today we will talk about game testing in general or game testing generic. We will learn the types of bags, the stages of project development, and we'll touch upon the topic of different game platforms. So let's get started. All the topics that we will discuss in this part of the course are really important for understanding the profession as a whole and for clear vision of product development. Today's plan will be as follows. We will talk about the main stages of project development in the video game industry. Look at different types of bugs that are inherent in almost any game during its development. Take a look at the main gaming platforms, analyze their specifics, and understand what compliance is and who first party members are. Let's first talk about what game development pipeline is. The game development pipeline or game development process is a sequential process that developers follow to create a video game from concept to release. And the milestone is an important point or event that's marked during an execution of a project or product development. In the context of video game development, milestones are used to define key points or achievements in the game creation process. They serve as visual points in the project timeline and allow you to define intermediate goals, monitor progress, and interact with stakeholders. Each milestone usually includes specific goals, tasks or deliverables that must be achieved by a certain deadline. They can include milestones such as completing a prototype, implementing core game mechanics, finishing levels or stages, testing, and other key events in the development process. Milestones help the development team track projects progress, evaluate performance, identify issues, and adapt to plans. They also help management, investors, and other stakeholders to visualize the project's progress and movement forward and to make decisions about additional funding, changes in timeline or resource assignments. According to project management, establishing milestones is an important practice for managing projects and ensuring that the project is successfully completed on time and according to plan. There are three main stages in the development process, pre production, production, and post production. Each of them has its own pecularities and follows each other. Pre production is a stage in the video game development process that precedes the main production phase. This stage is preparatory and includes planning, research, and preparation of everything necessary to start the actual development of the game. The pre production process allows the game development team to prepare the production phase and ensure a clear understanding of the game and its requirements for the successful completion of the project. It's also worth mentioning two main attributes of the pre production stage in more detail. The first of them is GDD or game design document. Game design document is a document that describes the concept, gameplay, and all important aspects of creating a video game. A GDD is an important tool in game development that's used to store and transfer information between members of the development team. The main purpose of GDD is to agree on the internal game development plan. To ensure that all team members and project customers have the same understanding of what the final product should look like. A typical GDD contains the following information. Game description, a brief overview of game including the general idea, genre of the game, the setting, story elements, et cetera. Target audience, identification of many audience that the game is aimed at, including age groups, interests, preferences, et cetera. Gameplay, a detailed description of the game's mechanics, rules, systems, levels, characters, interface, and even everything. Graphics and sound, description of the game's visual style, artistic concepts, animations, sound effects, music, et cetera. Game progress, a description of the game's progression, achievements, difficulty levels, safe systems, and other Multiplayer. If the game includes multiplayer, a description of network features game modes, even player connections. Work schedule, definition of development stages, tasks, and deadlines, distribution of tasks between team members and prioritization. The GDD is a main document used during game development to ensure Unity of vision and simplify communication between developers. It serves as a reference and basic for further stages of development, including prototyping, levels, graphics, and programming. The second attribute is prototyping. Prototyping in game development refers to the process of creating trial versions of a video game in order to test and validate the idea, gameplay, mechanics, and other aspects of the game before it's fully developed. Prototypes can be created at different stages of the game development and have different levels of detail. The main goals of prototyping in game developments are validation of the idea. A prototype help to check whether the game idea works in practice and allows you to identify the strengths and weaknesses of the concepts and to make adjustments to it. Gameplay testing. A prototype allows you to test different mechanics, game rules, and player interactions with the environment. This allows you to identify possible problems, make changes, and improve the gameplay. Attracting investors or publishers. A prototype can serve as a tool for presenting a game and attracting the attention of potential investors or publishers. It demonstrates the game's potential and its features. Team communication. The prototype help the development team to better understand and communicate with each other about the project. It creates the shared vision and is used to discuss and improve the game concept. Prototypes can be different levels of detail from simple samples of basic shapes and primitive mechanics to something more developed with balanced gameplay, visual and sound. It's important to focus on the key aspects of the game and test them before further development. Prototypes can be created using special prototyping tools, game development engines, or even by manually creating simple trial versions. Our next milestone is production. Production in game development is a stage of active game development when the team is engaged in the actual creation of content, programming, and integration of game elements into a single finished product. Production in game development requires the cooperation and coordination of all members of the development team to ensure the successful implementation of the game and ensure its timely delivery. Let's talk about the main stages of production. The first one is first playable. First playable prototype or FPP is an important stage in the game development. It's the first prototype of the game that has enough functionality to allow the player to interact with main elements of the game and get a general idea of gameplay and feelings that the game is trying to convey. In general, the FVP is an important step in game development, where the main goal is to test the concept, functionality, and feel of the game in really early stages, just to ensure the right direction for further development. Our second stage is vertical slides. Vertical slice is a concept used to create a complete game experience within a limited amount of time and resources. Vertical slice is a comprehensive game prototype that includes all the main aspects of gameplay, visuals and sound. Vertical slice helps the development team to set realistic expectations of the game. It helps to establish quality standards and test and show the potential value of the game before going into full production. Our next step is the pre Alpha. Pre Alpha is early stage of video game development when the game is still in extremely imperfect state and has limited functionality. Pre Alpha takes place after prototyping and before the Alpha version of the game. Is goal is to identify problems, refine and improve the game before moving on to the next stages of development such as Alpha or Beta testing. Alpha. Alpha is a stage of video game development when the basic functionality of the game is already present, and the game can be played in full mode. The Alpha version of the game is like the first version in which all key elements of the game are implemented and combined into the single system. Let's talk about its main features. The first one is completeness. The Alpha version has a full gameplay, including all the main features, levels, characters, mechanics, and even user interface. Players can explore the game world, interact with it, and experience the core mechanics. Second feature is the buggy. At the Alpha stage, developers are actively working on identifying and fixing bugs, shortcuts, any problems of the game. Testing the game involves both internal developers and external testers, which helps to identify and solve problems before the game is released in the next stage. Another feature is visual style. At Alpha stage, the game may have a basic visual style and aesthetic. Also certain elements of graphics, textures or models may be temporary or subject to further optimization. And the last feature is changes and additional content. During the Alpha stage, changes may be made to gameplay. New content elements can also be added just to expand the gameplay and threaten the game's message. The Alpha stage is an important step in game development as it allows you to collect feedback from players and solve key problems before moving to the next stage, beta testing. Beta is the stage of video game development when the game is almost complete and has a full range of content and functionality. The beta version of the game is released to a wide range of players and it's used for final testing for bug detection and of course, for feedback collection. The main features of Beta. The first feature is full content. The beta version of the game has the full amount of content, including all levels, all characters, finalized story, game mechanics, and other elements. Players can enjoy the full game experience. Second feature is testing. The beta phase is used to test the game extensively among a large audience of players. This helps to identify and fix box glitches and flows in the game before the final release. Optimization. During beta testing, developers work on optimizing the game and establishing performance on different systems and reduce resource usage. Feedback. Players participating in beta testing provide feedback to developers. This can include bug reports, suggestions for improvements, game play comments, and so on. The developers use this feedback to improve the game before it's released. The beta stage is the last stage of testing before the game is released. After identifying and solving the problems that arise during the beta testing, the game is ready for the final release, which can be the release or just the final version of the game. Beta testing can be either closed or open like open closed beta. Open Beta allows not only developers but external testers to see the game and get feedback from them, which can really help in solving a huge amount of problems during the production stage. The last hour stage that we are going to talk about is the gold master. Gold master in game Dev refers to the final version of the game. That is consider it ready for mass release and distribution. This means that the developers consider that the game is stable, complete, and ready to be produced on physical media or distributed electronically. Talk about main features of gold master. Completeness. The gold master is considered to be the final version of the game, which has functionality content and is ready to be played. All the elements like levels, characters, story, game mechanics, and other aspects have already been implemented and passed internal testing. Buck fixes. Before the game becomes gold master, the developers are actively working on fixing any bugs and issues that were found during the previous stages of development and testing. Stability. The gold master version must be stable, meaning that the game should run without critical errors, crashes, or unpredictable issues on the wide range of devices and platforms. Production and distribution. Once the game becomes gold master, it's ready for production on physical media, such as disks or for electronic distribution through digital platforms such as online game stores. Gold Master is an important step that indicates the completion of development and confirms that the game is ready to release and access to players. Once production is complete and the game has shipped, the game development process continues with some team members being relegated to maintenance, like fixing back, creating patches, creating bonus or downloadable content like DLC. Others may move into the SQL or the next project. Post production in game development refers to the stage of video game development that comes after the game is released and includes a number of actions and processes aimed at maintaining and improving the game after its release. Let's talk about the main aspects of post production in game development. And the first aspect is support. After a game is released, the development team is involved in maintaining the game, resolving issues that players may have while playing the game, and releasing patch or updates that fix some box problems and add new content or features. Second aspect is updates. Developers can release updates to a game, which may include new content story or gameplay expansions, graphic enhancements, optimization, and other improvements to provide players with new experience and keep them interested in the game. The last but not the least is the player feedback. Post production includes the collection and analysis of players feedback, which can come through forums, social media, or official communication channels. This feedback help developers to understand the problems of players, their wish, and suggestions which help to improve the game. To perform such works, there's also a separate department of testers, Live QA. This is a team of smaller number of testers that was created specifically to support the game in a live format. The team is usually formed from the most experienced testers who worked with project during its development. The live QA is a type of testing released game when team is looking for feedback from users and forums and try to reproduce the issue to give additional details to development team. 3. Game testing. Types of bugs: After a detailed review of milestones and game development by Plein itself, let's move on to our next topic namely game bugs. In this topic, we will talk about the types of bugs, analyze their examples, and see how they affect the project as a whole. Bugs are the lifeblood of any tester. During their long and hard work, they encounter a huge number and variety of bugs, which can range from the fact that the game doesn't start to the fact that at extreme point on the map behind certain trees in the left corner of the grass, the beetle texture doesn't load properly. What is important to understand bugs are present in any game at any stage of its development. But the criticality of bugs can vary depending on the stage when it happens. For example, the same placeholder, instead of a texture or animation, may not be so important in the early Alpha build, but it will become critical during better validation. Understanding the nature of a bug will make it much easier to reproduce it, describe it, and even prove to the developer that it's a bug and not the way the design was intended. There are many ways to categorize bugs. But in general, let's divide them into the following. Crash, so the game is crashing. Walk through bugs that are related to passing the game input, bugs that are related to input devices. Hot, bugs related to players interface, gameplay, bugs that are related to game process, AI, bugs that are related to artificial intelligence, graphics, LALD. It's the bugs that are related to location of objects on the level or even their physical properties. Loads, bugs that are related to display of objects at a distance. Audio box, compliance. We'll have to talk about it a little bit later. Localization bugs that are related to the translation or to voice acting in the game. Each of these types are present in any game at different stages of its development, and our task as a good specialist is to find and describe them as much as possible and as clearly as possible. Let's talk about each of them separately. Crash and freeze will be the first in line. Let's talk about crash. A crash occurs when the game suddenly closes or throws the player to the desktop without warning or an error message. This can happen due to a software error or malfunction that prevents the game from running correctly. Freeze is slightly different. The freeze occurs when the game stops on a specific screen or in a specific state and doesn't respond to fuzzer player commands. The game may become stack due to a large number of calculations or due to a program error. These problems can be caused by a variety of factors, such as incorrect code, unstable optimization, any bugs flows in system requirements conflicts with other problems or even hardware issues. These bugs are among the most critical and developers usually try to fix them as soon as possible. Therefore, our tasks as professional specialist is the same as of pokemon catchers, like catch them all. The next one will be bug related to the game's progression. The most important is WTB or walk through blocker. The walk through blocker is a type of bug where the player cannot reach the end of the game for any reason, such as the quest has not started, the boss is vulnerable or the road is blocked. The walk through blocker can be caused by various factors. For example, it could be bugs or errors. Some bugs in the game like leading to situations where the player cannot continue due to any flaws or correct game logic. Also the factor of Well through blocker can be unclear task or instruction. If the task or instruction in game is not clear enough, the player may get stuck and just don't know how to continue. And another our factor is level design. Poor level designs such as improper placement of objects, flows in level logic or insufficient information to get through can create obstacles for the player. Of course, the first point applies to us the most. A good tester will never allow WTBs in a project. All through blocker, it's a big critical issue because blockers can lead to player frustration and negative experience. It's important for developers and testers to identify and fix such blockers during testing, and after the game is released, just to ensure a smooth and satisfying gaming experience for players. Input box. Input box in game development refer to errors that are related to the processing of user input, like keyboard, mouse, or controller, and its connection into the game. This box can affect the player's interaction with game and lead to incorrect or uncontrollable behavior. Let's have an overview of some typical input box. Delayed input, a delay in processing input when the game doesn't respond instantly to player's action. For example, delay between pressing a button on the controller and the corresponding action in the game. Incorrect input recognition. For example, the game may mistakenly perceive pressing two keys at the same time as one input or misinterpret mouse or controller movement. Stack input. Problems with effect of stack input where the game continues to respond to players input, even after the user has released the corresponding button or performed an action. Input lag, the delay between user input and the game's response. This can occur due to game optimization issues or even hardware limitations. This input box can affect the gaming experience causing frustration and inconvenience for players. It's important to conduct through testing and identify such bugs during game development, and of course, to provide mechanism to correct and resolve input issues to ensure a smooth and decorative player experience. It's also important to remind you which controllers are officially supported by any game. These are Xbox, dual SOC, dual sens, controllers. So we're focusing on them in testing. Next type of issues are menus and hot. Menus and hats, box and game development refer to box related to the games interface, such as menus, inventory, control panels, and the display of information on the screen. Sometimes game menus are programmed incorrectly so that the button leads to a run menu or a menu becomes inaccessible, or the player gets stuck in a menu and they cannot exit. This is actually due to logic problems in the navigation programming, causing an unexpected action to be performed or to lock itself. Examples like missing menus, overlaps, sliders, changing values or not being saved. So basically, this describes all types of errors present in any menu in the game. In video games, hot or heads up display is the method by which information is visually communicated to the player as a part of the user's interface. The main problems here as follows, Hat is not adapted to the platform, icons that go beyond the borders, missing buttons, icons, hot elements, et cetera. Let's talk about some common menu and had related errors. Incorrect button mapping. Incorrect mapping or assignments of buttons is in menu or control panel, resulting in an inconvenient experience for a player. Overlapping or misaligned elements, overlapping or misaligned interface elements that can make it difficult to read, text, or interact with other elements. Inconsistent or missing hat information. Inconsistent or missing hot information on the hot that should be displayed such as health, resource level or task information. No responsive menu or hot elements. Manu are hot elements that do not respond to player input or not function correctly, preventing the user from interacting with them. Visual glitch. It's like visual errors such as artifacts, incorrect texture mapping or improper animation that can distort the appearance of the game's interface. This box can affect the player's correct interaction with the game interface, reduce usability and cause inconvenience during the gaming. To identify and fix such bugs, it's important to conduct through UI testing, as well as provide ongoing support and improvements to menus and hats through the game's development. Gameplay bugs. This type bug occurs when a particular feature or action doesn't function as intended in game. This prevents player from performing desired actions such as jumping, dodging or using weapons. This can put players at a disadvantage. Play box and game development refer to box related to game mechanics, balancing system, and general gameplay interaction. This can be box related to the players inability to perform certain actions like not being able to shoot and shooter. The system of shelters doesn't work. A quest that just doesn't work or doesn't start, broken cat seen and others, and really many other related to the mechanics and main features of the game. AA. AA box in game development refer to errors related to the implementation of artificial intelligence in a game. This box can lead to the incorrect behavior of intelligent entities such as enemies, allies, or NPCs and affect their decisions, movement, and interaction with environment and the player. But before we talk about bugs related to artificial intelligence, let's find out who NPCs are. NPC or non player character is a term used in game making to describe uncontrollable characters in video games. NPCs are characters that are not controlled by the player, but by the computer or the game. They can be used to fulfill various roles in the game, such as allies, enemies, merchants, town people, or even just background characters just to add life and realism to the game world. Let's talk about some typical AI bugs in game development. Path finding issues, problems with past placing when an intelligent entity cannot correctly calculate the optimal path to a destination, encounter o obstacles or get stuck in the wrong movements. Correct decision making. In correct AI decision making that leads to unrealistic or inefficient behavior. For example, the enemy may choose illogical targets or inadequate actions in response to events in the game. Ack of response or awareness. Insufficient response of AI to changes in the game or environment. For example, an enemy may not respond to player attacks, recognize other entities, or interact with objects, teammate or NPC issues. Errors in the behavior of allies or NPCs, such as inefficient movement, improper interaction with the player or uncoordinated actions in team situations. Exploitable AI patterns. That's the identification of game situations in which the AI can be easily bypassed or deceived by the player, leading to an incorrect balance of a gameplay. This AI box can affect immersion, cause player dissatisfaction and degrade the gaming experience. Conducting AI testing, detecting and fixing box is an important part of developing and testing a game with artificial intelligence. Bugs that are related to video or graphic settings. Video graphic bugs in game development refer to bugs that affect the visual of the game, such as graphics effects, aspect ratio, screen resolution, and shadow issues. These errors can affect the game's image, quality, smoothness, or overall visual experience. Let's talk about some common video graphic box, visual glitch. It's like visual artifacts such as texture distortion, flickering, jecked edges or objects that are not displaying properly. Frame rate drops. Drops in frame rates that result in choppy or jerky gameplay. Texture problems, errors with textures, such as incorrect or stretched textures, missing textures, or incorrect display of materials. Lighting or shadow glass. Problems with lighting or shadows, such as incorrect light distribution, incorrect shadow or light reflection anomalies. Hardware or software box, artifacts related to the display of any elements on the screen, the aspect ratio or the screen resolution. The video or graphic box can affect players immersion, disrupt the visual quality of the game, and reduce the overall aesthetic experience. Developers usually test graphics and video, identify and fix such big to achieve optimal visual quality of the game. Level art and level design. Level art and level design box in game development is a type of problems that affect the games levels, their appearance, structure, and functionality. This box can affect gameplay, immersion, and the overall experience of players while completing levels. Let's first understand the difference between level art and level design. Level art box are a type of problems related to object textures. The main problems are missing textures, overlapping textures, low resolution textures, stretching textures, and other. Level design box, it's the type of error occurs when developers or designers miss something when the lining dos or objects and can lead to disruption of the gameplay. When players are trapped in a zone or an object or an invisible barrier appears that prevents player to complete scenarios normally. In order to move to LA LD bugs, we need to define also the term collision. Collision in game development refers to the interaction of objects in the game, in particular to the detection and processing of collisions between them. Collision determines how objects interact with each other in virtual game space. Collision can have different aspects, such as physical collision or the collision of physical objects. Collision with triangles, it's the collision with level surface. Collision with special areas, for example, trigger zones or activity areas. Collisions are determined by geometric objects such as rectangles, spheres, balls, mess, and even polygons. When objects collide, the game system detects this and performs certain actions according to the game settings and logic. This can include stopping the movement of objects, interacting with colliding objects, triggering sound effects, or activating game events. To make it clearer, imagine yourself swimming in the sea. If you move your hands in the water in different directions, you feel water resistance. That's it. In addition of seeing the water, you can also feel its physical properties. Let's have a talk about some typical level art and level design box. Collision issues. And again, level design box is the issues with collision where the player can pass through some objects or have any other invisible obstacles. Missing or misplaced objects, missing or misplaced objects in a level that can lead to impossible actions or disrupt the game's logic. Another problem is inaccessible or incomplete areas. It's like areas in level that should not be accessible to the player or are not properly designed. Poorly balanced gameplay. Unfair balance in a level where some areas may be too difficult or too easy for the player. Visual inconsistencies. Visual inconsistencies such as changing art or design style in different parts of a level. Progression blockers. Progression blockers, it's like obstacles that impact the player's progression, such as unreachable key objects or stack tasks. Level art and level design box can affect the smoothness of gameplay, levels, logic, and overall player experience. QA and Devs usually perform level testing, identify and fix such box to ensure quality and satisfying gameplay in every level of the game. Lot, Load is the level of detail. Level of detail in game development refers to technique used to optimize the graphical display in games. This technique reduces the load on the graphic subsystem and improves the game performance by reducing the detail of objects when they are far away from the player and or not in the field of view. With lots, developers create different versions of object models with different level of detail. When an object is close to the player or in the field of view, a high detail mode is used. However, if the object is far away or not in the player's field of view, a model with less detail is used. This allows you to save computer system resources and maintain game performance. Lot can be applied to various graphic components, such as character models, environment objects, landscapes, et cetera. The lot technique can also be used to display textures, particle effects, and other graphical elements. Identifying and fixing load box is an important process of game testing. Developers and testers need to check whether the load system works correctly and whether there are any noticeable glitches or transitions between different level of details. It's also important to determine the optimal load values for different objects and scenes to ensure comfortable gameplay and graphical quality. Audio box. That's very easy. That's just the problems related to sound effects and music and can be very different. The sound is too high or too low, not the way it should be, or the sound effect or music comes on the run time or placed in a loop. Sometimes it's because the game is looking for a sound file, but it's not named correctly. For example, the player interacts with an element that is accompanied by a sound, but the sound continues to play in a circle after the content has passed disrupting the game experience. Compliance. Let's talk about this team in more detail. The video game submission process is the process that every game creator, developer, or publisher must go through in order to successfully release their game on their target hardware. In almost every case, submission means that the hardware manufacturer have to test your game against the requirements they set, and your games must meet all of these requirements to pass the test. Each of the major consoles has its own version of the criteria and processes that must be followed. Compliance in game development refers to the compliance of developed game with various standards, requirements and rules that must be set by different organizations or platforms. The standards and requirements may include security rules, content rules, technical requirements, ethical standards, and other restrictions that must be followed during the game development and release process. Example, platforms such as Playstation, Xbox, or Nintendo may have their own compliance requirements that developers must meet in order for a game to be released on those platforms. This may include some technical limitations, graphics or sound quality requirements, control requirements, networking requirements, and much more. There are also mandatory requirements and standards related to safety, children's rights, content, ethic, and other aspects of the game. Developers must comply with these requirements to ensure compliance and distribute the game in accordance with law and regulations, as well as to maintain their reputation in the face of potentially restrictive content. Compliance is an important aspect of game development, as failure to comply can lead to rejections of the game's release or negative consequences for the developer, including user complaints or loss in consumer confidence. Therefore, developers must carefully research and meet compliance requirements during the development and release of their game. Localization testing is an important part of the development life cycle of any program. It checks whether the software is adapted to the linguistic, cultural or other requirements of each individual region, as opposed to globalization, which aims to launch a program that can be used anywhere in the world. The types of problems include untranslated text, missing text, coded or insufficient space to translate elements on the user's interface. Localization box in game development referred to problems related to the transition to the translation and language localization of the game in different regions or language settings. Since many games have a global audience, proper and high quality localization is an important aspect to ensure maximum player understanding and enjoyment. Let's talk about some common localization box. And the first one is translation error. That includes incorrect or inappropriate translation of texts in the game. This can be caused by incorrect translations, lack of context, or omission of translation for certain elements of the game. The second one is text overflow. This occurs when the translated text doesn't fit in the area allotted to it, resulting in being cut off or overlapping. This is especially problematic when the presence of the large amount of text affects the readability and interaction with the game. The third problem is formatting issue. This refers to text formatting issues in localization, such as incorrect characters, improper markup or inappropriate formatting. Cultural adaptation. This includes problems with taking into account cultural pecularities and norms when localizing. For example, incorrect use of characters, images, or inappropriate content for certain cultures or regions. Audio and voice over issues. That's issues that refers to audio translation, improper voice synchronization with video, incorrect accents, or pronunciation in the respective languages. Testing and fixing localization box is important to ensure that the game is localized for different audiences in high quality and correct manner. This helps to ensure harmonious gameplay, story and text comprehension and player satisfaction around the world. 4. Game Testing. Severity: So we learned a lot about existing types of bugs. We have seen crash, friezes, learned what collisions are, what loads are and what the compliance and localization difference is. But how can we understand which bugs are important and critical and which are not? This is the propose of our next topic. Let's start learning about bug severity. Severity is one of the key elements in the bug and issue management system. It helps to determine the severity and impact of each bug or issue on the quality and functionality of the game. The severity classification help developers and testers to focus on the most important aspects and to determine the order in which to fix problems. Severity scores can vary from developer to developer and from studio to studio, but common severity levels include critical or height severity. This level refers to bugs or issues that have an extremely large impact on a gameplay or even cause the game to crash. Critical box or box with high severity can interfere with the main objectives of the game, break important features, or even cause players to lose their progress. Fixing such box is an urgent task as they have serious negative impact on the game's rewarding potential. The second type is medium severity. It means that they affect the gameplay. This level is responsible for bugs or issues that have a significant impact on gameplay or user experience. This may include issues with functionality, interface, game balance, or other important aspects. While these issues may not cause the game to crash, they do affect player satisfaction and require the attention of developers. The last but not the least is the polish issue or issues with low severity. This level refers to minor issues or bugs that don't have a major impact on the core gameplay or user experience. They may include minor graphical artifacts, small typos, audio issues, or other minor deviations that do not disrupt gameplay or in game content. This also includes minor issues that have a cosmetic effect on the game. This may include minor visual artifacts, minor graphical flaws, small animation errors or other minor external deviations that do not affect functionality or gameplay. The last but not least, this category includes your suggestions for improving the games gameplay, design, or even narrative. The severity score helps the development team and testing team prioritize bugs and issues that were discovered during the development and testing. This allows you to focus on solving the most critical issues and provide the high quality and satisfying game for the players. First, let's talk about critical box. Critical bugs are software errors or issues that have a serious impact on the functionality, stability, or security of a software product. They have a high priority and need to be fixed immediately as soon as they can be found. These types of issues can significantly affect the quality of the game experience and players satisfaction. Critical bugs can have different characteristics and affect different aspects of the game. Let's take a look at some examples and understand why they need to be fixed very, very quickly. At first, let's talk about crash. Imagine that you as a player cannot complete a level because your game crash consistently. With each such crash, you will get more and more angry and enjoy the game less and less. In addition, you'll have to restart the game every time with a great hope that everything will be fine, but it's not. Crash, crash, crash leads to delete, delete, and delete. Crash is the highest priority bag and should be reported and fixed as soon as possible. Freeze. Freeze is basically the same situation, but with minor changes. When passing a level in horror game, the player should be frightened by the sudden appearance of a monster. The music builds up, you approach the door behind which this monster is hiding. You start to open it and that's so. The game just freezes in place. The sound continues, but the picture does not. I think it's not even worth emphasizing that this will be very frustrating for the player and he will want to remove this game from his device. Well through blocker. The player has to defeat the boss after completing the level. Everything went to this point. A lone and difficult path to overcome evil on a global scale leads the character to an abandoned throroom a flame is lead, and the Almighty king of the immortal rises from his throne. After a beautiful stage cuts seen, you are given control of your character. You dodge a series of unexpected attacks and launch a counterstrike, but the in takes no damage. And no matter what you do, whether you throw bombs at him, hit him with a sword or cast spells, he doesn't get a scratch. So you cannot complete the game. Why would you like to play a game where you cannot defeat your last enemy, no matter how hard you should try. Major LD issue. You are playing a racing simulator. A quick start, you catch up with another driver on a turn and instead of overtaking, you drive through the curb texture. Then another one and another one, and you realize you can drive through textures. It doesn't look like a simulator anymore or even racing. It's hardly a game. You'd want to play. Severe FPS drop. In the battle scene with main bad guy, there comes a moment when your number of frames per second drops from 62. Instead of a good and enjoyable battle, you as a player see something similar to a PowerPoint presentation. This makes it impossible to react adequately to attacks to dodge at the last moment, or even to move your character at all. After seeing this, the player will delete this game and go download something else. Feature not functional. We are playing let it be first person shooter. Your game has great graphics and incredible atmosphere, well developed characters and a story. But there is one thing wrong with it. None of your weapons shoot. And the main goal of a shooter is to shoot an enemy's. Why play something that doesn't work? Severe sound issues. Let's have another example. When play a zombie survival game, your main goal is to survive and escape by helicopter. And now it's approaching you. You hear the sound of propeller, that is getting closer and louder and louder and louder and it doesn't stop. The constant increase in volume leads to the fact that the helicopter is already so loud that it's simply painful to sit with your headphones on. It's hard to call this a positive and enjoyable experience. Most likely, this game will be uninstalled and forgotten like a bit dream. Okay, the critical ones were sorted out and everything should became clear. We have to report it as soon as we see them and shout about this box to the developers to fix it as soon as possible. Let's move on. Medium severity box are problems in the games that are not immediate or critical, but require attention and correction. They can affect gameplay, quality, usability, or other aspects of the game. Let's take a quick overview of some typical medium severity box. Medium graphic bug. Usually, it's small or noticeable graphical issue, such as texture rendering errors or incorrect lighting or something else that is similar. For example, one of the torches glows green instead of yellow, or you have a low resolution texture of one of the walls. Hadi. It's issues related to the menu or character interface. Incorrect button name, incorrect display of the health bar, incorrect display of the pins on the minimap, and other similar things. Ugly, unpleasant, but still not critical. Medium sound issue. Everything should be simple. Just the sound of a horse clocking instead of car engine, a delay in sound playback, slightly offset lip sync in the character's voice acting or a poor audio effect. By the way, lip sync is the process of synchronizing the movements of characters lips on the screen with the audio being played. Animation issue. Mostly, it can be missing jump animation of your character, stretched animation, run jump animation or other animations, uncalibrated animation during the execution of parkour elements and other similar things. Feature almost functional. Well, almost work in functionality. You can pick up an apple to eat, but not a pineapple. Your car has three wheels, not four. You can steal money, but not from any NPC. You can shoot, but only with single bullets, not with a full burst. In other words, we can say that something works, but not fully. Placeholder. Placeholder is something that temporarily takes place of a missing element. For example, instead of benches in the park, you can see chairs. Instead of a large number of different characters, you can see the same character in the gaming world over and over again. Or for example, it could be the same reloading animation for all weapons in the game. In other words, some feature was made, but a stop was put in place because of an element was not drawn or created or just placed in the game. Medium priority box are problems in the game that are not immediate or critical, but they'll require some correction. They can affect anything in the game, and still they are visible for a regular user. This box can affect the quality and enjoyment of the game, but usually do not interfere with the full functioning of the game. Therefore, fixing them is important, just to improve the overall user experience and ensure a high quality game. The last but not the least are quality or polish box. Quality bags are issues in the game that have a low priority and not critical to the functionality or experience of the game. They are minor and sometimes even unnoticeable to most players, the priority of their fix is quite low. They're also not pleasant for a polished product, but they are solved less as there are really big and significant problems besides them, but they are the largest number in the project, and if there are so many of them, it can also negatively affect the player's experience of the game. Let's analyze them as well. Small graphic bog. Just a small graphic bug like a texture in extreme corner of the map that is not loaded, a texture of an object that is not very well rendered or a small shadow in poor resolution. It's not critical at all, but it still can ruin the game experience. Small control issue. Something similar to joystick that may not connect the first time, the inability to bind a button that's only on your mouse present or a broken macro that 90% of players will not use and even want to see in the project. Small haywi issue, issues such as text that has moved on a little bit, untranslated text or misspelled word and also not critical and over the 60, 80% of players will not even notice the problem. But that doesn't mean that the problem doesn't exist. Small FPS issue. I can say that it could be small frame drops in a scene. For example, 60-50 in a very dynamic moment. Suggestion. Suggestion. Um, suggestion is a kind of tricky theme. Your suggestions on how to improve this game or area um, also counted as quality polish issues. Not because no one cares about you, but because in order to improve something, you must first bring the something to at least a working state. That's only why your suggestions are present in really low severity. So this is a type of a bug that will be fixed last. They're also important. But in order to deal with them, you need to make a working, interesting, and visually appealing project without critical problems. 5. Game testing. Platforms.: Okay, we've looked at different types of bugs and sorted them by severity. Now we can talk about where these bugs occur. Specifically, we'll talk about gaming platforms, their differences, and pecularities. We will look at several of them and see their difference. Gaming platforms are various environments where games are launched. Each platform has its own features, characteristics and target audience. Let's take a look at the popular platforms at first. Playstation from Sony, Xbox, from Microsoft, PC, PC. Nintendo, I mean switch from Nintendo and mobile. Let's talk about everyone just a little. We'll have more detailed overview soon. PC or personal computer, they're one of the most versatile gaming platforms. They offer a wide variety of games and have the power and flexibility of customization that allows player to enjoy high quality graphical visuals and diverse contact. PC is also open for developers, allowing them to create games for white audience. If we are talking about consoles, such as Playstation, Xbox or Nintendo Switch, they are popular platforms for playing games at home. They offer exclusive games, specialized hardware, even unique gaming experience. Consoles typically have similar interface to each other, but it's simplified from the PC. Their games have less complexity of installation, makes them more accessible to wider audience. And mobile platforms. Smartphones and tablets have become popular gaming platforms due to their mobility and accessibility. Games for mobile platforms often have more simplified gameplay, short sessions, and optimized controls for touch screen. Game stores such as Appstore and Google Play provide easy access to a large number of games. I also have to mention two more things on this slide. The first one is virtual reality. Is the platforms such as OklasRift, HTCfe and Playstation VR. That allows player to immerse themselves into a game and interact with virtual environments using special hardware. This creates immersive gameplay and new opportunities for gaming experience. And also I have to mention web based gaming services like steam epic game store GG is just online platforms that prove the ability for players to purchase and download games directly to their computers. They also provide gaming communities, social features, and tools for developers. Each gaming platform has its own audience uh, technical limitations, specific controls, and game development features. Developers have to adapt their games to the requirements and capatbilities of each platforms, providing optimal gameplay and enjoyment for players. Although many companies competed for the top spot in the top best selling gaming platforms, PlayStation took this honorable place according to the Guinness Book of World Records. Testing games on the Playstation platform also has its own pecularities. Let's take a look at some main aspects that testers should consider when testing games on PlayStation. The first aspect is the playstation certification. As with other platforms, games on PlayStation have to go through a certification process from Sony before release. This includes verifying that the game meets the requirements set by Sony to ensure quality and compatibility with the platform. Our second aspect is special controllers. The playstation use the dual shock controller for PS four and dual sense controller for PS five, which have its own unique baton layout, touchpad, Goscope vibration, adaptive triggers, and so on. Tester should make sure that the game interacts properly with the controller, including all of its functions and features. Playstation network. Playstation has its own online platform, known as PSN or Playstation Network, which allows players to play multiplayer games, download additional content, and even communicate with other players. Testers must verify that games online functionality and interaction is working on PlayStation and correctly interacting with BSN. Technical requirements. Playstation has its own technical limitations that must be taken into account when developing and testing games. This includes file size, memory and CPU usage limits. Testers must verify that the game meets these requirements and runs properly on the playstation. User interface. PlayStation has its sound user interface, which includes the main menu, settings, playstation store, and online features. Testers must ensure that the game interacts with the UI properly, including navigation, text display, and sound effects. Testing games on playstation requires attention to the specific features of the platform. Testers should check the game's compatibility with Playstation, its functionality, and quality just to ensure a good gaming experience for players. Let's have a look at a couple interesting facts about playstation. The playstation is so popular because of countless technological innovations and of course, Sony's commitment to meeting the needs of gamers. The playstation has always been sleek with elegant look and feel and gives a pleasant sensation to the person holding it in their hand. With 800 video games in the Playstation library, is the best subscription based gaming service available. Our second platform for review is the PC. PCs are considered one of the strongest gaming platforms in the video game industry. PC developers have the opportunity to realize their creativity thanks to the wide range of games that can be created for this gaming platform. Testing games on PC also has its own pecularities and features, as the PC platforms allow for greater flexibility and variety of configurations. Let's take a look at some features that you should consider while testing games on PC. And the first feature is variety of hardware configurations. PCs can have different types of processors, graphic cards, memory capacities, and other hardware characteristics. Testers need to make sure that the game works on different configurations and has no compatibility or performance issues. The PC supports different operating systems such as Windows, MacOS or Linux. Testers should make sure that the game runs on different operating systems and has no conflict and compatibility problems. Different peripherals. The PC supports different types of peripherals such as keyboard, mouse, gimpod, helmet of virtual reality and other. Testers should verify that the game interacts correctly with different types of devices and has no problems controlling or interacting with them. Some games are developed for multiple platforms, including PC. Testers need to verify that the game runs on different platforms without any problems and has no difference in functionality or performance. Also, PC games often have a modern community. That creates modifications for the game. Testers should check how the game interacts with mods and whether they affect the game's functionality or stability. When testing PC games, it's important to have a wide coverage of configurations, check compatibility with different operating systems and peripherals, and make sure that the game works correctly and is convenient for players on this platform. PC games also include action shooters, multiplayer games, strategy games, and many other based on specific game genre. Gamers prefer computers because they're easy to upgrade, provide high image quality and have much more power to handle blockbuster games and streaming channels. Also, PC is a very variety platform because of its customizable controls, high range of graphic settings, the big amount of peripherals, and also is the perfect choice for eSports. The third platform is Xbox. Microsoft released the Xbox gaming platform in 2001 when it was in direct competition with the Playstation two and Nintendo Game Cube. Testing games on Xbox platform include some specific features that testers need to consider. Let's take a look at them. As a playstation, Xbox has its own certification. Before a game can be released on this platform, it must go through a certification process, which means that it meets the requirements standards and rules set by Microsoft. Testers must sure that the game meets the requirements and identify any issues that may prevent certification. As a playstation, Xbox has own controller with his own unique buttons, joysticks, features, layout, and other. That should check how game interacts with the controller and must be sure that it interaction works properly, including all buttons, gestures, vibration and other Xbox. As a playstation, Xbox has its own online service called Xbox Live. Xbox has Xbox Live, which allows players to play multiplayer games, chat with other players, and receive updates and additional content. Testers should test the game's online functionality and ensure that it works properly with Xbox Live. Also, Xbox has its own limitations, technical limitations, I mean, such as maximum file size, CPU and memory resource restrictions. Testers should make sure that the game meets these requirements and works properly on Xbox platforms. User interface. Xbox has its sound unique user interface. That includes the main menu, settings, store and other features. Testers must verify that the game interactions with UI are interacting properly, including navigation, text display, and sound effects. Testing game on Xbox requires to test specifics of this platform. Testers must identify issues that may arise on Xbox to ensure the quality of the gaming experience for players on this platform. Let's have a look at a couple interesting facts about Xbox. Much of Xbox success is due to the Xbox Live online service, which offers players access to online games for an annual fee of $60 and includes the games with Gold's Reward program. Microsoft created a successful program that consisted of backward compatibility of games, making games from the Xbox 360 and even from the original Xbox compatible with the new Xbox. Many PC games were ported to Xbox after Microsoft bought Activision blizard or even was trying to bought. Nintenda has a rich history when it comes to games machines, but its most popular console is Nintenda switch. It has broken down the barriers between home console and portable gaming, giving players the ability to play video games everywhere. Testing games on Nintenda Switch has also its own pecularities and features. Let's take a look at some key aspects that testers should consider when testing games on Nintendo Switch. The Nintendo Switch has a unique characteristic of being able to switch between handheld and TV Doc mode. Testers should verify that the game switches between the modes correctly and work properly in each mode. The Nintenda switch uses wireless joy C controllers that can be used as one controller or separately by each hand. Testers should ensure that the game interacts properly with these controllers and supports all of their features such as motion sensors and vibrations. Intenda switch has its own technical limitations that must be taken into account when developing and testing games. This includes file size, memory, and CP usage limitations. Testers must verify that the game meets these requirements and runs properly on the console. The intenda switch allows you to play games with friends using two Jikun controllers from one console or additional controllers. Testers should check that the game multiplayer is functional and interaction is correct with other controllers. The Intenda switch has a touch screen that allows player to interact with game by touch. Testers need to make sure that the game makes proper use of the screen and responds to player touch. Testing games on Intenda switch requires attention to the features of the platform. Testers must check the game's compatibility with Intenda switch, its functionality, special features, and in general, the quality to ensure a good gaming experience for players. Mobile games are often called not real games, and the reason for this are not new to everyone. Bad graphics, bad story, terrible touch controls. However, despite all this hatred, many industry experts believe that mobile games will experience explosive growth in the coming years. Mobile game testing has its own pecularities and features according to the different unique characteristic of mobile platforms. Let's take a look of some man aspects of testing the mobile games. Mobile platforms such as AOS and Android supports a wide range of devices from different manufacturers, models, and configurations. Dancers need to be sure that the game works on different devices, different screen resolutions, expect ratios, and even operating system versions. Mobile platforms are updated frequently, and users may be using different versions of the operating system. Tessa should verify that the game works on current versions of operating system as has no conflicts with updates. Mobile devices have different hardware capacities, such as processors, memory, and graphic accelerators. Tessa should verify that the game runs efficiently on device and doesn't consume too many resources such as CPU or even battery level. Mobile games are usually distributed through app store, such as Appstore for AOS or Google Play for Android, and testers need to make sure that the game meets the store's requirements. It should pass the verification procedure and displays properly in the store. Mobile devices have also different features, such as touch screen, accelerometer, gear location, cameras, et cetera. Tester should check that the game use if it uses and interacts with these features correctly. Mobile game testing requires careful examination of games compatibility, functionality, performance, and usability across different devices and operating systems. It's also important to make sure that the game meets the requirements of app stores and works with specific features of the device. So we learned a lot about box and gaming platforms. Thank you for your attention. See you in the next part of this course. 6. Engines. Unity: Hello, everyone. I'm glad to welcome you to the next part of the course. QA become a game tester. Today, we're going to talk about testing tools. We'll look at what they are, what they're used for. Analyze the most basic ones in more detail and even do a little practice with Jira, which will be useful for both a basic understanding of the testing organization and your first job as a QA. So let's get started. Today, in our agenda, we'll have the three main topics that we will be talking about the game engines, back tracking tools, and version control tools. Let's talk also in general about the testing tools. Testing tools are essential in game development for testers, as they provide various benefits and facilitate the testing process. Let's talk about some reasons why testing tools are useful for game testers. Game testing often involves repetitive tasks, such as regression testing or testing specific gameplay scenarios. Testing tools provide features for test case management, also for test planning and test execution tracking. Testers can organize and manage their test cases, assign their test cases to specific team members, track the progress of testing activities, and generate reports, just to communicate testing status to other team members or even to stakeholders. Games often require testing for performance, including lot testing, stress testing, and measuring frame rates. Performance testing tools help testers to simulate real world scenarios. Analyze resource usage, identify performance bottlenecks, and ensure that the game performs optimally under a lot of different conditions. These tools provide insights into performance metrics, allowing testers to optimize their game performance and improve the overall player's experience. A gaming engine is a software development environment, also referred to as a game architecture or game framework with settings and configurations that optimize and simplify the development of video games across a variety of programming languages. A gaming engine may include a two D or three D graphics rendering engine. That's compatible with different input formats. Also with physic engine that simulates real world activities, artificial intelligence that automatically responds to players action a sound engine that control sound effects, an animation engine, and a host of other features. Game engines provide developers with ready made platform for creating games, allowing them just to focus on the game development process itself instead of writing all necessary systems from scratch. They include an integrated development environment or IDE, a set of editors, tools for Medellin, animation, scripting, sound, and much, much more. Let's talk about the main advantages of using game engines in game development. The first advantage is the speed. So the game engines provide a ready made infrastructure to allow developer just create a game content and not worry about creating the whole system from the very beginning. The second advantage is the visualization. Engines provide graphic engines that simplify the creation of realistic graphical effects, like lighting, shadows, particles, et cetera. The second advantage is physics and collision. Game engines usually have built in physics engines that allow you to model realistic physics of objects in the game and calculate collisions between them. Our next advantage is artificial intelligence. Engine provide tools for implementing artificial intelligence for characters and other objects in the game, allowing them to make their own intelligent decision and interact with the player. Many engines support game development for different platforms, such as PC, consoles, mobile devices, and even VR. This allows developers to quickly adapt their game to different platforms. Another advantage we can call a community of developers. Many game engines have a large developer community where you can get an advice, some support, training from other developers, and this allows you to solve problems and grow in game development more effectively. In general, game engines allow developers and testers to create games faster at low cost and with a higher level of functionality and quality. They are an important tool for successful game development in the modern game development Isdusttry. Some game engines are publicly available and are actively updated and supplemented by companies and their developers, while others are created by studios and only for internal use. Closed source engines include, for example, NVL from Ubisoft, Red Engine by CD Project ReD, frost Byte, by EA or Cry Engine from Cry tech. These engines are available only within the companies and under the strict or NDAs. But fortunately for us, there are two open source ones. Unity and Unreal Engine are one of the most popular game engines because of their openness and full of charge and because of a huge and constantly expanding community of developers who help each other with any issues related to these engines. We can also call some examples of games that were coded on Unity and Unreal. For example, the top games made it on Unreal Gears of War, Bioshock Infinite, Mortal Combat 11, and even such mastodons as Fortnight, Pop G and Rocket Leak. Let's have a closer look on the two open sourced engines. And the first one will be Unity. The Unity game engine in development since 2005 and has become the backbone of the Indie game industry. With constant updates and important new features like Unity reflect that are added every year, the support of engine is incredible. Not only is the engine well suited for two D and three D games of all types, but it's also a really popular choice for creating virtual reality or AR games thanks to the companies and developers who create user friendly decays for the engine. Unity is a popular game engine integrated development environment, game IDE. It's really widely used to create games, simulations, virtual reality, and even interactive applications. Let's talk about some key aspects of the Unity. Unity supports game development for a variety of platforms, including PC, consoles, mobile devices, web browsers, and even virtual reality. This allows developers to create games that can run on different devices without the need for significant changes. Unity has an intuitive visual interface and tools such as graphical behavior editor and graphical state editor. This allows developer to program the game without having to write a code, which simplifies the process of creating games for non programmers. Unity provides developers with access to a large number of extensions, resources and tools that can be used to improve the functionality and extend capabilities of the engine. Additionally, Unity supports third party programming languages such as C sharp or JavaScript, giving developers a choice in programming language. Unity provides powerful graphical compatibilities, including support for realistic rendering, lighting, shadow particles and water mapping. This allows you to create immersive visual effects and detailed game words. Unity has a large and active developer community. That provides support assistant, and knowledge sharing. In addition, Unity provides extensive documentation online tutorials, webinars, and other resources to help developers learn and improve their skills. And now let's talk about the strengths and weaknesses of the game engine. To DPs. One of the strongest point is that this engine is free for beginner developers. You can easily work with it until your income from the sale of your developments is equal to $100,000. This engine is really good choice for both two D and see D projects. It's really easy to learn and this easiness makes it really intuitive. Also, such big projects that everyone knows were made on Unity engine, such as i and the Wheel of the Wisp and the heart Stone. As you can see, it's not only easy to learn this game engine, but also you can create the really efficient, pretty and interesting games. This game engine is also great for IOS and Android development. It also has excellent support for mobile projects. Unity has an open SDK. It's the software development kit for AR and VR projects, which makes it a great choice when creating a project for virtual reality. Addition, Unity has an open access store with really huge amount of content. Individual features settings, assemblies, texture models. You can find anything. But there's also a fly in the ointment, namely the disadvantages of this engine. If the income exceeds the $100,000, the license will be quite expensive. Another disadvantage is that the more you use modern technologies in the development of your project, the more hardware capacity you will need to run it correctly without any errors. And the last disadvantage is that with each release of new version of Unity, many changes are added to the UI, which actually forces you to re learn some of its elements from scratch. 7. Engines. Unreal Engine: Unreal Engine is the popular game engine and development framework, known for its powerful graphic capabilities and versatility. Due to its robust graphical capatibilities with lighting, shaders, shadows, and more, Unreal Engine is the powerhouse behind many of most popular AA games that are out there today. Given its rampant use in this sector, the engine has been developed very specifically to handle a lot of complicated tasks more efficiently than other engines. Engine is also open source like the Unity. Meaning the community is constantly improving the engine as well. Let's take a look at some key aspects of Unreal Engine. This engine is known for its advanced real time rendering capabilities, allowing developers to create visually stunning and highly realistic graphics. It supports dynamic lighting, global illumination, particle effects, and other advanced rendering techniques. Real Engine provides also a visual scripting system that is called Blueprint, which allows developers to create gameplay, mechanics, logics and interaction with any object in the game without writing the code. This feature makes it accessible to create their own game for both programmers and non programmers. Unreal Engine supports multi platform development, enabling developers to create games for various platforms, including PC, consoles, mobile devices, and even virtual reality. It provides some building tools for deploying and optimizing games across different platforms. Additional key feature of Unreal Engine is its extensibility and customization. Unreal Engine offers the high degree of customization. Developer can create their own tools, extend the engine's functionality through some plugins or modify the engine source code to suit their specific needs. Unreal Engine includes a powerful physics simulation engine that enables realistic physics interaction in game. It supports rigid body dynamics, collision detection, complex physics simulations, allowing for realistic object behavior and environmental interactions. Unreal Engine also has the large and active community of developers who share knowledge, provide support, and contribute to the development of the engine. Additionally, the Unreal marketplace offer a wide range of assets, plug ins and ready to use content that developers can use in their projects. Unreal Engine is used in various industries beyond the game development, including architecture, film production, virtual reality experiences, and even simulations. It robust features, advanced graphic capabilities, and flexibility makes it a real popular choice among developers for creating high quality and visually impressive game and interactive experiences. Now let's move on to the strengths and weaknesses of Unreal Engine. So the strengths. Unreal Engine is great for projects that will have detailed and high tech graphics. Just because it allows us to use a lot of different technologies, especially modern technologies in newer versions of Unreal Engine like Unreal Engine five. It's more powerful and more optimized in terms of hardware resource allocation. That means that if you have the powerful PC, it will use the resources of your hardware more efficiently. Is the best option for highly detailed VR projects? Unreal has the building ability to write game logic in a visual format using blueprints, which makes it possible to do almost anything for people who are not familiar with programming languages. It Salsa has really huge marketplace with a huge amount of postpaid and free content. By the way, once a month, they made a giveaway or sale, how they call this? When they give us really useful and really high value content, once a month for free. But also in this engine, we can see some weaknesses. Unreal is still much more complex and comprehensive than Unity, which makes it harder to develop simple projects or single developer projects. By the way, because of its complex and its structure, it's kind of more harder to learn this engine and to get familiar with it. Projects that support high end graphics require much more powerful hardware. Because if you want to use modern technologies, please use modern hardware. This engine is more suitable for three D than two D projects. Okay, let's compare these two game engines. Both engines have their own advantages and disadvantages. So it depends on the requirements of the project to make the right choice. Both tools are capable of producting AA quality graphics and have excellent connections to most hardware standard software. This means that using either of them, you can create any project of really high quality. It all depends on your skills, abilities, and, of course, imagination. Both programs provide a wide range of tools, including terrain editor, animation, physical modeling, VR support, and more. That is neither of them has restrictions on the realization of the product you want to make or test. They're both excellent and suitable for the tasks. Both can be dealt with very easily and at least for basic orientation, but they contain significant differences. And the first difference is languages. The unreal use C plus plus language, while Unity uses C Sharp. C SHAP is considered more suitable for game development than C plus plus, so Unity is faster. Of course, this will not affect the quality of your project, but only the speed of computing. This is why Unity is more suitable for simple two D or three D projects. The goal of Unity is to target many platforms, including mobile. UnreL is usually used for PCs or consoles or Bs. Also, Bs can be used to create mobile projects and console projects or even projects for VR. UnreL includes blueprints. Well, Unity, you can get a component like the playmaker to do something without code. But still, you need to install the plugin and don't have it by default. 8. Bug Tracking: Our next topic is the bug tracking tools. The bug tracking software helps software teams find and resolve issues through the development process. These five applications offer a centralized location to record bugs, prioritize severity, and assign them to right team members. With a single view of all defects, QA team can track back trends and reference this information to improve the quality of the future products. Backtracking tools are an important part of software testing and development process. They allow a team to track, document, and resolve issues found in a software product. Let's take a look at just a couple back tracking tools. Jira, Jira is one of the most well known back tracking tools. It provides the ability to create, track, and assign tasks, including bugs in project management. Jira also has extensions for collaboration, reporting, and integration with other development tools. Bazilla. Bxilla is an open source tracking software that allows you to create, track, and manage bags and also issues during the development process. It provides features for assigning box, prioritizing, commenting, and even defining the changes. Trail, Traila is the project management tool that can be used for backtracking. It offer boards, lists and cards to organize and track tasks. TrallA also provides features of commenting, assigning responsibilities, and setting deadlines. GitHub issues. GitHub issues is B tracking tool that is integrated in the GitHub software development platform. It allows you to create and track bugs, as well as assign them to development team members. GitHub issues also provides reporting, tagging, and integration with version control systems. Mantis BT. Mantis BT is the open source bug tracking software that allows you to create, track, and manage bugs in a project. What are the main advantages of using a bug tracking system such as Jira O trello? Our first advantage is communication management. QA testers, developers and project managers needs a medium to communicate effectively. Having a central communication channel in your back tracking system provides opportunities for clarification through the QA process and speeds up software development projects. The second advantage is screen recording. Recreating bugs isn't always easy. Equipment developers with the screen capture or recording of defect gives them more time to focus on fixing the problem versus reproducing it. The third advantage is organization and filtering defect data. Managing defects, user feedback, and open tasks is a job within itself. You can manage your bug reporting tool better when you're able to organize and filter your QA projects. The last advantage is test reports and analytics. It's essential to track test trends and gather insights for the future QA projects. With test metrics, readily available in your backtracking tool, you can quickly transform and share the data with stakeholders. Using the fact tracking system or the back tracking system greatly simplifies both team organization and communication. It's a tool that allows you to effectively track any errors that have been introduced and fix them efficiently. Nowadays, it's impossible to at least imagine project development without even the most basic back tracking system. There are really a lot of advantages, so I don't see any reasons not to use it. 9. Versions Control: Our next topic is the version control system. The version control system or VCS, is an indispensable tool for managing files versions and change management in software development projects and other projects. It allows developers to collaborate effectively, track changes, restart previous versions of file, and merge changes from different developers. One of the main functions of the system is change tracking. Each change made to a file gets its own unique identifier called aversion. This allows you to track exactly when by whom and what changes were made exactly. Thanks to this, developers can easy view the history of changes, compare file versions, and restore previous project states. Another important feature is branch. Branch allows developers to create separate workflows where they can work on specific functionality or improvements without affecting the main project code. Each branch has its own version, allowing developers to safely experiment and develop new features. Once completed, a branch can be merged with the main branch by merging changes. The version control system also enable developer collaboration. Multiple developers can work on a project simultaneously, making changes in just separate branches. It also allows developers to interact, resolve conflicts, merge changes, and coordinate work on the project. The most popular version of control system includes next ones. Git subversion or CVN mercurial CVS and others. Each system has its own features and benefits. But the overall goal is just to provide developers with tools for effective change management and project collaboration. In general, a version control system allows user to keep track on the changes in software development projects and enable them to collaborate on those projects. Using it, the developers can work together on code and separate their tasks through branches. There can be several branches in the version control system according to the number of collaborators. The branches maintain individually as the code changes remain in a specific branch. Developers can combine the code changes when required. Furthermore, they can view the history of changes, go back to the previous version, and use or manage code in the desired fashion. The first advantage is a complete long term history of changes to each file. By long term history of changes, I mean every change made by many users over the years. Changes includes creating and deleting files as well as editing their contents. Our second advantage is branching and merchant. Parallel work by team members is understandable, but even people working independently can benefit from the ability to work on independent change streams. Version control systems, specifically branch, allow many developers to work effectively in parallel without interfering with each other's processes, and the ability to switch between them allows you to help any developer at any time without losing your own progress. And our last advantage is traceability. The ability to track every change made to the software and link it to project management and bug tracking software such as Jira, as well as the ability to annotate each change with the message described in the purpose and intent of the change can help not only with root cause analysis and other forensics, but also with simple change tracking and even bug prediction. One of the most popular representatives of version control systems is GIT. GIT is a distributed version control system that is widely used in software development. It provides storage, tracking, and management of changes to projects SCD. GIT has a large set of features that facilitate the collaboration of developers and ensure the security and stability of the project. One of the main advantages of Git is a version control system is its distributed nature. Each developer has a full copy of the repository, which allows them to work independently of the network connection. Each version of the project is stored as a complete snapshot of a state, which allows you to quickly switch between versions and restore the state of the project. It also provides powerful tools for branching and merging changes. Developers can create new branch to work on specific features or fixes directly from the main branch. Once the branch is complete, the changes can be merged into the main branch by the special command. If I'm not mistaken, it should be Git merge. This allows you to effectively manage the development of new features and ensure project stability. GIT also has a building change tracking system that allows developers to keep track of who makes what changes on the project. Each change has its own unique identifier, making it easier to track and analyze changes. Working with GID, developers use various commands and operations such as CamiTs branch, merge, tracking, recovery, and much many others. GIT also supports collaboration among developers, allowing them to share changes, review code, and resolve conflicts. And the last but not least, GIT is a powerful tool for managing code versions, collaborating with developers, and ensuring project stability and security. For now, it's a standard in the software development industry, and it is used by millions of developers all around the world. So we fully reviewed the basics of version control systems. Now let's move on to bug tracking systems. There are a lot of them, but one of the most popular is Jira. Jira is a popular project management and task tracking tool that is widely used in software development. Enables development teams to effectively organize their work, manage task, and change, set priorities, and track progress. Jira allows you to create projects in which you can create tasks, box, issues, and other types of work units. Each work item has its own attributes such as name, description, assigned person, responsible person, priority, severity, and other. Work units can be organized according to ERRchy which allows you to create a project structure and dependencies between tasks. One of the key features of Jira is the ability to monitor the status of the task. Each task has its own life cycle, which includes such stages as pending in progress, reviewing, done testing, and you can even modify them. Developers can change the status of the task, which indicates its current stage of execution. Jira also provides the ability to plan work and set deadlines. Each task can have its own deadline priority, estimated time, which allows you to manage project time and resources. It's also possible to set dependencies between tasks, which allows you to manage the sequence of execution. Jira has advanced reporting tools that allow you to analyze projects progress, track trends, and determine team's productivity. Reports can be generated based on a variety of criteria such as status, priority, tax distribution, et cetera. In addition, Jira is an extensible tool that supports integration with other development services and tools such as Git, Confluence, Bt Bucket, and many others. This allows teams to conveniently work with all the necessary tools in one system. All in all, Jira is a powerful tool for project management. Also for text tracking and team collaboration, it helps to ensure that the software development process is structured, efficient, and transparent. Thank you for your attention today. We will meet on the next part of this course, and our next part will be the Jira practice. 10. Jira Practice. Introduction: Hello, everyone. Welcome to our practical part of the Coors QA becoming game tester. If you are watching this video, it means that you successfully completed the theoretical part. And it means also that you now can have a lot of knowledge about new features, about the design techniques, about bug reporting, about what bug is, and so on and so on. A lot of information. And now you have somehow to organize this information. That's why we are here. We have to use it in practice. This part of practice will be about Jira, and we will learn how to use it, learn what we can do in it, and how to correctly, again, use it in your everyday work. Jira is the popular project and task management tool that's widely used in software development industry to organize any work, including testers, including testing. For testers, Jira can be a useful tool for managing test tasks and tracking their statuses, tracking box fixing progress, creating some dashboards for organizing work and so on and so on. Jira has a lot of main features for tester. It allows us to create and track tasks and box. So testers can create tags to specific feature or just a bug in a software product. Testers can set the status of these tasks like open in progress on hold, and so on. We will, of course, get to know it's a little bit closer but later. Box tracking is the most important for us as QA specialists, and Jira allows us to track our box to check the box in the project very efficiently. So we can report back writing Jira with very detailed information, with track resolution statuses, and even analyze how they can affect the development process. Jira also can be easily integrated with other version control systems, test automation, and other development tools. So in general, this instrument allows testers and develop and developers to effectively manage the test and development process. Jira is the main tool of your work. With help ads, you can report back, control issues, organize your work, and even the work of your team. And also, you can create some really necessary tools that will be used by the World Development Team. The first thing that you will see on the project, I believe. So if we are talking about Jira, you will see the Kanban board. Kanban board is the board that you should see now that is used for effective tracking of tasks, box, creating them, editing them, assigning them to any responsible person. So it's just for your tracking. As you can see, we can just take any task, move it to any different column, and according to the column, it is placed right now. This is the status of this task. So I can just take one task that I have, move it to in progress column. If I'm do some work related to this task on hold if something for example, doesn't allow me to work with this task or am I waiting for some answer from development team or from designer team, and so on. Ready for testing if some features or some new features are ready and fully able to be tested. QA, it's something like in progress, but this one is mostly for developers, and this one is more for us and done. Of course, you will see the big amount of columns, and in every company, they could be really different. Maybe somewhere you will not see the QA or ready for testing status, or maybe you will found the ready for build status and so on. So the statuses are just the visual explanation of what exactly is going on with this task. For good understanding, I created some tasks that we will take care of, and we will see how exactly we should work with this Caban board. And let's start with our first task. Okay, if you see it's my account, I can see definitely that these tasks are assigned to me, and I know if they are assigned to me, I must do something with them. So I have to start my work. It's like, let's mentioned that it's Monday, you already drink a coffee, and you see this amount of tasks that you have to take care of. Okay, I'm looking for the first task. I see the key of this task is just some identifier. That could help us to just identify the task, its number, the unique identifier. And I see, check any existing task. Okay. I want to take care of this, so I'm moving it to in progress, and I have to check any existing task. Let it be this task. Create a dashboard. I see the task that has summary created dashboards set of stud a SINE its main label test tasks, test print one, and reporter of this task. And of course, I see some kind of attached documents. Is just a placeholder. Sometimes you will see some useful links in this task like link to design document or maybe to Figma, or maybe even file or a screenshot or anything else that would help you to just complete this task. Okay, I checked this task. So for now, I can move this one, in our case, to done because I don't believe that we have to test if we were checking this task. 11. Jira Practice. Filters: Let's take care of another task. Like, create a new task. I already moved it to in progress. I now has in progress status. To create a new task, we have to tap the button create and of course, select the issue type. In our case, the issue type is what? Task. That means that we can write a summary, let it be use JQL 43 to create a filter. The JQL is the Jira query language. It's something similar to SQL but much, much easier. Usually, you use it for searching and organizing and combine it tasks into one filter. You will be able just up the link and see the box or tasks that you collect. A, we can assign this task, of course, to me, because why not? I'm doing all this stuff. It's like labeled like test task, like sprint. Our active sprint is a test print one. That's why I'm selecting this one. And I can write some description. Let it be something like use. To collect. All your box. Collect. And let's upgrade. So now we can check our task. So we see the description of it, we see the summary, we see label, we see sprint, we see reporter, and, of course, a SINE. And the most important, we can see our status. That means that we have to do something with this task. And of course we will do it, but a little bit later. Because it started, we need to at least use our search, create your first bug, and collect it by using JQL. For now, we can move this task into hold because we cannot take care of it by now. Let's select another task like assign any task. By the default, your task is unassigned. But you can assign it to any responsible person in this menu or while you are creating the task or big and assign it to the responsible person. For now, we can tap the assignee field, select. In this case, I will select myself and close it. I can definitely see that I'm the assignee of this task. I believe this one could be definitely moved to done. A also, create a new task. We can move to D as this one task because we already created it. Create your first bug or create your first filter. To create our first filter, we of course need to create our first bug. Let's move this task into in progress. Let's search for bug. We can definitely use any game and I will show you the next which bug we will use. And let's imagine that we work in Rockstar Games and we selected our game to find the bug in it is the GTA five. I don't have currently installed GTA five and it's hard to find bugs in it because in Rockstar testers are really good in polishing games. But we can have some kind of live hack and just open YouTube and find the back from GTA five. Let's watch it and understand what exactly is this bug about, and then we will report it. Well, I believe it's definitely easy to understand that we have the really interesting and funny bug here. The bag was exactly about the Travis. It's one of the main characters in the GTA five. Was driving the invisible helicopter. It means that we don't have the model of this helicopter. Travis definitely performs its animation of driving a helicopter, but without it. Funny, let's create the bug about it. To create a bug, we have to type the button, create, select the issue type bug and start with the summary. Summary, let it be something like the game, what when, where, and we will describe our summary in this case. Like the first is what? Copter model is missing. Another question that we have to answer is when in CAT scene, and of course, where after Latin a mission. In our video, we have seen that Travis during the CAT scene sits in invisible helicopter play so we can describe it in description. Helicopter model is not displaying in a cat scene. And let's name this cat scene also scene one. Sorry, but I don't know how exactly these cut scenes are called. I was not working in Rock star game, I was working Ubisoft. Then we have to add a catchphrase. In our case, our catchphrase is for additional information, please check the attachments. Another thing that we have to mention is steps to reproduce. Of course, we have to write the first step. Is the default step for any project, both the title on the build. It means, run the application. Build usually has some numbers. Let it be GTA five version 31, just like this is just a placeholder for visual understanding. Okay Um, of course, we have to know what mission was it? So Lounge. Mission. Let it be mission. Certi five. Mission, cert five. Um Complete mission. Certi five. Oh, my bed. Five. So for reproducing this issue, we have to start the game, launch mission, and complete it. So we will trigger the Gatsin. Let's also describe our expected result and actual result. Expected result helicopter model is visible per player and actual result. Helicopter. Model is missing. Model. And not helicopter. Helicopter. Let's also add a severity. As we know, the severity is how important and critical this problem is, and I believe it's definitely important. Let's set it as high technical produce CBT. Let's imagine that we launched the bill five times and we definitely see this issue. We have 100% that we can see it. Let it be five out of five. SINE. Of course, we can assign only to ourself in this case, but definitely in other projects or on your next position, you will be able to assign it right to the responsible person, even it's developer or designer or develops and so on. But right now we're assigning it to us labels. Let it be label that scene Sprint O test Sprint, of course, reporter. We have ourself as reporter and attachment. We also should add the attachment and let the screenshots. Maybe just one screenshot, I believe it would be enough. For now, let's create it, and I will add screenshot also. And to do it, I usually just select the perfect moment for it. Where I definitely can see that this helicopter is not visible. Make a screenshot of it, open paint, for example, as the photo editing tool, you can use, whatever you want, but paint is the most secure thing because it's not linked to the network, and all the copies would be saved just on your computer. Okay. Okay, I made a screenshot. It was not seen here, but just copy it into your paint, maybe somehow highlight the problem and add it here. We here. We can just tap the button and attach to add the attachment and add the attachment GT bug. Right here, I mark that we have no handicapre model. Looks like we created our first buck, so we can move this task into Dm. By the way, we can change statuses not only by dragon drop, but also by tapping on the task and just selecting it here. For example, file select ready for test. This one would move here. But I prefer just dragon drop. It's usually for me, much easier. Right now we can use the search to find a bug. Let's move this task into progress. And to use the search field, we have to move into where is it? Issues here. Let's change the view into list view. Okay, you will have the issues. It should be right here like issues is the tab, which you taps and it opens all issues that you have on this project, even it's box, tasks or something else, even epics, stories, and so on. And in this case, we can manipulate the search field here to search for some box combine into another filter and just sort them. Let's find our buck. Of course, we can see it right here, but let's find it by using the fields in this filter in this search. First thing, let's like the project. Our project is QA becoming game tester. We are selecting it here, and we should see a lot of tasks, like all tasks that are assigned to this project. We know that we have to find the bug. That means that we have to select the type of the task that we are searching for, and it should be bug. Search. Okay, now we have only four of them. Let's also try to add more filters and the created date. For example, it was created in last 30 minutes. And search. Here it is. We found our bug. Of course, right now, it looks like not necessarily sin, but if you have a lot of different issues, bags, task in your project, it's much easier to find them like this. But also, we could find this bug much much easier. We could just resettle our filters. The most important filters that I suggest is just a project because searching in another project is not good. And we can see the input field where we can input some keywords that should be present in the bug just to search for it. And we know that our book was related to helicopter, missing, model, model, and so on. So we have some key words like helicopter, missing, model. Let's search by them. Helicopter Missing model, and tap search. Here it is. It was really easy, right? We can tap it, open it in a full screen and see here, the model is really missing. Let's move back to our Kingdom word. You search to find a bug. I believe we definitely have done it. Now we created a bug. We also have some bugs in our issues. So we can create some filters and combine and collect them into just a single filter, for example. That means that we can remove our task, use JQL to create filter to in progress, and also our task, create a first filter into in progress. And let's take care of these two tasks. So let's move firstly to filters and view all issues. For now, we can see all our tasks and box, of course. Firstly, let's create the filter where we will see box only. Let's select the project and type of the task, it should be box. Here it is. Right now, we have not saved filter, so we just have the search result. To create it as the filter, we have to save it. So we're tapping the button save as filter name, let it be something like Project, box, and submit. Right now, we have created the filter. We can proceed to details of this filter, see the permissions. It's really important because sometimes you have to share your filter to some responsible person or the person that will take care of it, and don't forget to share it with this person or with the organization or even with the project. Et's move back to all our issues and find our filter. Our filter would be in the tabs filter and see project bugs. We're tapping it and we can see all bugs on this project. Now let's see the more advanced way to find bugs in your project. Let's imagine that we have a task that we have to create a filter with only two bugs like this one and this one. That's why we, of course, can use the basic filter, but let's switch to JQL into Advanced Search, and we have to share this filter, for example, with our project manager. How I usually do it, I create a key in Key in. Key in is something like the request to use Jira that should se request to Jira, and you will use your search only by keys of your box that are identifiers of your box. You're just asking, find me all issues with these identifiers. Key in. I know that key of these two box that I have to find is QA BDT 16, and also we have to use comma here because I need another one NUABGT 11. I'm tapping search, and here it is. We have the search result where we can see only two filters, only two box. We can save it also and name like JQL JQL filter, and submit, of course. Right now, in your filter step, you will see two of your filters. You can proceed to project box, like box of your project, and now to your custom filter. Of course, you are able to edit it somehow. For example, I want to delete this one. Search and I can save. Right now, if I will proceed this filter again, I will see only one here. Let's move back to our Cannon board. Use JQL to create a filter. I believe we have done it. Create the first filter, definitely done. Last task that we have is the dashboard creation. 12. Jira Practice. Dashboards: Let's start our last task. Is creating a dashboard. The dashboard is something that you will use on your daily basis for organization of your work, like for best mentioned. Of course, if you can definitely operate with chaos, it's very good, but still better to use them because if you need to find something very quickly or have a lot of different filters, it's better to use exactly dashboards. To create a first dashboard, you have to click the Dashboard tab and create a dashboard button. We can name this dashboard as personal dashboard. Add some description like Test dashboard for QA BGT. Viewers, you can manage whatever you want. But if it's your personal dashboard, better to leave it as private as viewers and editors. You will be able to edit the permissions later, of course, so you will be able to share it with your partners, colleagues, Raser testers, designers, just another part of your development team. We created the name, the description for it, and let's tap the button safe. What we see here is our main screen and the list of all gadgets that could be used to, um, create new dashboard. Of course, we can change the layout of it, and I prefer, for example, another one is the small one left side of this dashboard, and the big one on the right side. I prefer it like this because here I can put something that requires more place and just leave this part of our dashboard for something smaller. We change the layout and we can add some gadgets here. Let's add assigned to me and see how it works. After we add the gadget, we can freely move it from one part of your dashboard to another and right now you see this page with the settings of this dashboard. You can select any columns to display right here. And you are able to select it from this big list. We can add, for example, reporter and created. So we can see the date of creation. We can see who created this bug, the priority of it, summary, key, issue type, and let's also select status. Status, it is. We could also drag all these columns into different places in different order. For example, I want issue type first, key after it, summary, after the key priority, then status, and I want to, for example, swap reporter and create. And also, we can add after refresh. It means that if you put the check mark into this check box, your dashboard will update every 15 minutes. So after we said everything here, also, I forgot about number of results. Number of results means how much results would be visible in this gadget. For example, I want to select here only two. We have only four box here, so for example, I want to see only two assigntasks. It's not about box, it's about even tasks. So I can definitely select ten. I'm taping the save button and see what can I see here. Here, I can see all of tasks, box, epics, like everything that was assigned to me and not completed by me. If something is completed, it wouldn't be visible here. Now I want to add another gadgets. For example, let it be, let it be created versus resolved chart. Is the chart that will show you how a is how are your create tasks depends on result tasks, like how many tasks were resolved by the week of our work and how many were created. We will see it also. And for editing this chart, we have to select only two options right now. Of course, I can also add all these options, but I prefer just to add the filters that I need to use. In our case, it's project box. And the period. Period met, how many were tasked resolved and created in day or in week or in 1 hour and so on. I mostly prefer weekly. I selected the filter. I selected the period, and right now we have to see how many bugs were created and how many of them were fixed. Of course, we can also adhere outdoor afresh, which will allow our gadget to update every 15 minutes. And save it. So here you can see the number of created issues and number of resolved issues. You can also hover your mouse to some key points and see how and which day how many backs were created in which day and how many bucks were fixed. Let's also select another thing is the filter result. Filter result is really interesting thing because you can select any filter here, and you will see the result of this filter on your dashboard. I mostly use it to see, for example, last update issues or bugs that were assigned to me instead of this filter because I like this one much more because you can customize it more. But still, it's pretty similar to this one. Let's also add a filter here. It should be the project box and number of results, it should be ten, but we'll also see only I believe four of it. So maybe let's select two, and we will see the result of two last project box. Also, we can select any additional columns. As I've done it here, I can add status, create it and report it. Let it be status. Created and reporter. And don't forget to tap here to update your filter every 15 minutes, and save. Right now, I can see two last made bugs and tasks in my project. I can also swap pages, proceed to other pages. And see other bugs. Also, if I want to edit this filter, I can configure it. Maybe, for example, change the number of results to five and tap safe. Now I can see five results of it. Also, I can customize my gadgets a little bit. I can rename it. I can, of course, delete it, and I can change the highlight color. For example, the project box, I want to highlight in purple, just to make it visual more appealing for me. I can change the color, this one to red because it's important to me, and this one I will leave as green because it's statistics for me. Let's also add another last Gadget. And have a quick overview of it. Let it be by chart. Pie chart is used mostly as visual presentation of sorting your box by some options or categories. I can create a new filter for it for example. Let's also make it. View all issues. And I want just select my project and save this filter as bikes and tasks. Now I proceed to my dashboard. Edit it. And see the by chart. I want to select created filter and select the type of statistics. It means that we can sort or see some statistics about these tasks and box by some options. For example, I want to sort box by um Let it be priority. I believe we have the prior. Maybe better status. And update every 15 minutes, we have not to forget about this option and up safe. For now, I can see how much bugs and tasks in persons I have in this project. We can configure it as all previous gadgets. Maybe I want to change it to priority. Or maybe I want to change it to labels. I can see how much in percentage, I have tasks with different labels. After you completed the configuration of my dashboards, I can tap the and save it. Yeah, it looks right now a bit weird because we have to add maybe some more filters here and to make it look more visually appealing. We can minimize all these gadgets or expand, just some of them. We can also refresh them. Just not to refresh in every 15 minutes. If you just forget to put the checkbox in that option, you will manually refresh it by refresh button or by just refreshing the page. And also, we can maximize the view of it. So it will be like full screen. But I now use this option. It looks gross. Let's also expand all the sections, make it more visual appealing. And what can I say right now? If you watched the video till this end till this moment, I can see that it's the end of the first part of our practice, and I congratulate you because now you know more. See you in the next part of our course. 13. Test methods and test design: Hello, everyone. I'm glad to welcome you to another part of the course QA becoming game tester. Today we're going to talk about the theory of testing. We will try to cover some of the theoretical issues related to game dev, as well as some general provisions about testing. Knowledge of the theory often helps to structure your knowledge and find new ways of testing. Knowledge of testing theory will help to identify and eliminate errors, defects, and bugs that can reduce the quality of games. With an understanding of the basic principles and methods of testing, you will be able to develop effective test plans and strategies which will save time and effort, as well as reduce testing costs. You are part of a game development or a QA team, no one's theory of testing will help you to communicate and interact better with your colleagues, which will contribute to a more efficient and productive development process. As always, we have an agenda for today. We're going to talk about things like test methods and test design, test levels, and testing types. All this knowledge is really essential. And therefore, I advise you to listen very carefully, or better yet to write it down because there are the questions that are often asked at interviews as the most important, and you will be evaluated as a specialist based on them. So let's get started. So test methods and test design. We will first go through the test methods and then talk about test design and test design techniques. There are many of them, but first we need the general understanding and the ability to use them in practice. I will be able to help you with this by showing some examples with which we will analyze this knowledge, but you may be asked similar examples at your first or not even the first interview. Okay, let's talk about test methods. There are three main test methods black box, white box, and gray box. Let's talk about them a little more details. Black Box. The technique of testing without any knowledge of the internal mechanism of the application is called the black box testing. The tester has no idea about the system architecture or doesn't have access to the source code. Usually, during black box testing, the tester interacts with the user interface of the system, providing input data and analyzing the output results. Without knowing how and where these inputs are processed. Suitable data is inputted into the program and the results are outputted and the tester analyzes the behavior of the program without knowing how it works internally. This means that testing is performed at the level of the external system without considering its internal implementation. The purpose of black box testing is to check the correctness of input and output data, the ability of program to handle various scenarios and to detect errors and incorrect program responses. When performing this type of testing, the tester will try to experience the program from different user perspectives, ignoring the internal implementation details. Black box testing techniques include something like equivalent class partioning, boundary values analyzing, testing with structure specification and more and more. But we will talk about it a little bit later. Nes testing method on our overview is the white box. White box testing is testing with full understanding and full access to the project code. The tester has full access to the logic and structure of the code and can test which unit or part of the code doesn't work properly. In white box testing, the tester examines the internal mechanisms of the program, including the code structure, decision logic, or condition branches, just to create test scenarios that cover different ways the program can execute. A tester can use techniques such as unit testing, code analysis tools, debuggers, and other different tools to conduct tests. The main goal of white box testing is to check the correctness of the program implementation. Identify errors in the code and sufficiently cover condition branches, security vulnerabilities or program efficiency. This approach can help ensure high quality code and software, reducing the risk of errors and improve overall system reliability and performance. The advantages of white box testing include the ability to gain a deep understanding of the internal working mechanisms of the program, the ability to identify complex situations and flaws in the program logic, and the ability to create the scenarios aimed at specific code fragments or functions. And the last but not the least is the gray box testing. Grey box testing is the method that allows you to test an application with limited knowledge of its internal work. Having some access to the domain always gives the tester an advantage over a person with limited knowledge of this area. With this knowledge, the tester can prefer better test data and test scenarios when creating a test plan. Grey box testing is a combination of black box testing and white box testing. This testing method, the tester has limited access to the internal structure or code of the program, but still focuses on the external behavior and functionality of the program. In gray box testing, the tester may have access to some information about the internal implementation of the program, such as database structure or the logic of some functions. This allows you to perform testing more efficiently, focusing on important aspects of the program and possible places where errors can occur. Grey box testing methods can include analysing the program code, performing tests based on the data structure, using knowledge of algorithms or internal program logic to improve test efficiency. Now let's move on to the test design. Test design progress is a process of planning and creating test cases based on the requirements of a system or software product. It involves determining which specific scenarios, data and conditions should be tested to ensure proper coverage of functions and possible defects. The goal of test design is to create test cases that will maximize the detection of possible defects in the system and provide sufficient coverage of the product's functionality. When does the test design take place? Well, after the test conditions are defined, and there's enough information to create high level or low level test cases. Then you can create a test design for a certain level. Let's move on to test design techniques. Test design techniques are used to meet the goals of everyone involved in software development projects, including testers. Also, the main goal is to ensure that the product meets the expectations of customers and their businesses. These techniques allows testers to perform tests based on various risk factors without any questions. Let's take a look at list of standards that a smooth testing process should meet. Gather information to understand user's requirements, derive all important business scenarios, design test scenarios for every derived critical business scenarios, and assign all planned test scenarios to different test cases. Let's also have a quick overview of some steps that test design process may include. Requirement analysis is studying the requirements of the software to understand its functionality and expected behavior. Defining test scenarios, creating detailed test scenario descriptions that describe the sequence of actions to be performed to test a specific feature or module. Selecting test suits, is defining test suits that covers specific aspects of the software. Creating test cases, developing specific test cases with detailed steps to execute test scenarios. Defining test data is selecting the test data that is required to execute the test, executing tests, running test suits and collecting results, analyzing the results, evaluating the test results, identifying defects, and shortcomings, and reporting. I just the generating of a report on the test and results. It's like the main steps that every test design should follow. Now we can take a look at a few basic design techniques for a better understanding. Each technique can be used to find different kinds of defects. We will see five most familiar, most famous and most important test design techniques. The first one is boundary value analysis or BVA. Boundary value analysis is an important part of software testing including games, and this testing method is aimed at checking the behavior of a system or a program at the limits of its input data. Boundary values are the maximum or minimum allowable values that defines the limits of a range of data parameters or functions. In general, it's observed that many error occurs at the boundaries of the defined input values rather than in the center. Key recommendations. If the input condition is limited to the values X and Y, the test cases should be designed with the values X and Y, as well as values above and below X and Y. If the input condition has a large number of values, the test case should test the minimum and maximum numbers. This also check the values that are above and below the minimum and maximum values. It sounds a bit complicated for now, I understand. But let's look at an example and everything will become clear. Let's imagine that we have a game that can be played from age of 18 to 54. Don't ask why it's only up to 54, it's just the way we decided to do it. Your task is to test that this restriction works during registration. We have a valid registration 18-54-year-old. For a full test, we could create a user of each age in triplicate and try to register, but that would take a very long time. That's why we use boundary values analyzing technique. For us, 18 is X and 54 is Y. For the test, we take the values abo and below X and Y. And so instead of testing every user, we should test only six values, 17, which is below X 18, which is X 19, which is abo X, and the same for Y, 53, 54, and 55. If we are not registered for values 17 and 55, then the code works correctly. The next technique is equivalence class psioning. This technique is somewhat similar to the previous one, but slightly differs. This method of software testing breaks which test cases must be developed. The concept behind this method is that a test case for a representative value of each class is equivalent to a test case for any other value of the same class. This allows us to define both valid or invalid equivalence classes. In simple words, if we have three groups of warriors, ten people in each, then testing one warrior from each group will answer the question of whether the group is working correctly or not as a full structure. And again to the examples, just to make things clear. According to our task, we have a lot of characters with identifiers. All characters with an aside ID 1-10 and 20-30 should be red. All others are blue. To avoid checking every warrior and his or her ID, we divide it into classes. We get five classes from minus infinity to zero, 1-10, 11-19, 20-30, from 31 and beyond. And we take one warrior from each class expecting that his result will be the same as for the result of all members of his class. As a result, we have only five tests that we need to do. Of course, we always will have some exceptions, for example, we could have a class 1-10 where a warrior with ID five works correctly and the warrior with an ID six does not. But this test design technique is designed to find the common problem in the class settings as quickly as possible. The next technique is the decision table based testing, or we can call it a decision matrix. A decision matrix is an effective tool that is used in game development testing to evaluate and select the best solutions or functionalities to implement in a game project. When developing large game products, the development team is often faced with many alternatives and options, and a decision matrix is an excellent tool for organizing data and making informed decisions. Typically, the process of creating a decision table starts with identifying possible alternatives or functionalities that can be implemented in the game. Next, the criteria to be concerned when evaluating each alternative are identified. Criteria may include aspects such as gameplay, graphics, sound design, cost of implementation, and others depending on the specifics of the project. Once the criteria has been identified, each alternative is given a way to indicate the importance of the context of the project. These weights can be represented as percentages or numerical values. Next, the game development team scores each alternative against each criterion using numeric or text scales. The scores reflect how well each alternative satisfies the criteria. Scores are used to calculate a total score for each alternative, which reflects the degree of suitability of the alternative based on the weights of the criteria. The alternative with the highest total score is concerned the best option to implement in the project. The use of decision table is plate testing helps the developers team make an objective choice and focus on those aspects that best meet the specified criteria and project goal. This approach helps to reduce subjectivity and randomness in decision making and ensure more informed planning in development of the game dev project. Something similar is in game testing. We have to create the decision based on a table where we will have a lot of different options which are suitable for our case. Example, we could structure all possible options of what can user do while filling the registration form and cover all our test cases and test suits according to this decision table. We will have a quick overview of it a little bit later with an example. Also, we have some steps to create a decision table. The first one is list the inputs in the bra. Enter all the rules in the columns. Fill in the table with various combinations of the entered data. In the last row record the output for each input combination. I know it's quite hard. It's hard to understand, but we are having an example here. In this example, you can see the decision tree for a submit button, which should be available only when the user has entered all the data in the fields. T is true, which means that the field is filled. F falls, which means that the field is empty. The tester creates such a table in advance and then checks each case until the button actually becomes active. If the button becomes active in any of the cases 1-7, this is a clear buck. State transition technique or state transitions or just state transition. State transitions in testing refers to an approach to software testing that focuses on verifying transitions between different states of a system or program. This methodological approach focuses on testing functionality related to changes in system states and can be especially useful for applications where user interactions or events affect the behavior of the program. State transition testing is based on the concepts of system states, events, and transitions. A system state is a specific configuration or status of a system at a certain point of time. Event is an input of actions or just action or just event that caused a change in the system state. Transitions in turn represent transitions between states that occur when certain events occur. These transitions can be conditional and depend on certain conditions or variables. A state transition table is used to model and describe all possible states events and transitions between system states. This table helps to systematize all possible interactions and check the correctness of the program responds to various events. The use of state transitions in testing helps to make testing more structured and more systematic. It provides coverage of different system states and checks the correctness of transitions between them. This approach helps to identify defects associated with state changes and ensures higher software quality. In addition, state transition testing allows you to take into account various scenarios of system behavior, including negative and extreme situations, which makes it an important tool for ensuring the stability and reliability of a software product. This approach can be especially useful in demanding and complex systems, where it's important to thoughtfully test all possible states and transitions to prevent possible defects and undesirable situations. Okay, now an example of entering the password. Just make things clear. If the user enters a valid password within the first three attempts, the user will be able to log in successfully. If the user enters an invalid password on the first or second attempt, the user is asked to re enter the password. When the user enters the wrong password for the third time, action is taken and the account is locked. Error guessing. Error guessing is one of the software testing techniques based on intuitive guessing of possible errors and defects in the program. This method doesn't have strict rules or systematic approach, but is based on the tester's experience, intuition, and understanding of possible points of deficiency in the program. When applying the error guessing technique, the tester uses his knowledge and his experience to identify possible problems that may arise in the program. He analyzes the code, documentation, functional requirements, and other aspects of the software product, relying on his knowledge of typical errors and programs in programming. Example, the tester may assume that the program may not process large amounts of data correctly or there are problems when entering incorrect values. Error guessing allows you to identify problems that may go unnoticed during standard tests or automated test scripts. It can also be useful method when there is limited time or resources for a big test planning. However, it is worth nothing, then this approach may be limited and insufficient to guarantee the detection of all possible defects. Successfully use error guessing in testing, it's important to have a deep understanding of the software product and also the ability to analyze the code and recognizing some error patterns. In addition, it's important to document and record the error guess so that they can be further tested and verified. So we have to notice and document all the problems that we found during this error guessing. However, error guessing is not a substitute for other more formal testing methods, such as requirements based testing, model based testing, or even automated tests. It complements other approaches and helps to increase the effectiveness of testing by providing an additional layer of detection of potential problems in the program. Also, we have a guideline for error guessing. The test should use the previous experience of testing similar applications. Understanding of the system under test, knowledge of typical implementation errors. Remember previously troubled areas and evaluate historical data and test results. 14. Test Levels: Our next topic is testing levels or test levels. Test levels are a systematic approach of software testing and testing in game development that helps ensure that testing is complete and the defects are detected at different stages of development. These test levels are successive stages where a software product is tested from different perspectives, started from the early stages of the development and ending before its release. So we have four levels, four test levels of testing, unit testing, integration testing, system testing, and acceptance testing. Unit testing is just testing of each individual component of the program. Integration testing is testing groups consisting of several units and their interaction between each other. System testing is testing of the functionality after the integration of all groups of functionality was completed. Acceptance testing or also called user testing is already testing the entire system by end users or testers who simulate user behavior. Now let's move on to some details, and our first level for this overview is unit testing. Unit testing focuses on specific units or components of the software to determine if each of them works properly. The main goal of this work is to determine whether the program functions works as intended. The lowest level of testing at which individual program components are tested like functions, methods, classes, and so on, is unit testing. Also, this level of testing helps to detect defects in the code at really early stages and also helps to confirm the correct operations of each individual model. In this phase, the term unit can mean a function, a separate program, or a procedure, and the white box testing method is usually used to perform this work. One of the biggest advantages of the phase of testing is that it can be run every time a piece of code changes, allowing you to resolve issues as quickly as possible. It's quite a common practice among software developers to perform unit tests before handing over the program for formal testing to testers. This stage is usually performed by developers. The next level is integration testing. It's more complicated. After completing the unit testing phase, it's time to move on to integration testing. During integration testing, the tester checks how one or more modules interact with each other and generate output for different scenarios. Integration testing reveals defects that may occur when different parts of the system are merged and confirms that the components work correctly when they are combined into a single system. This type of testing reveals many defects related to functionality, requirements, and performance levels. Unity testing confirms that different modules can work separately from each other according to the requirements. But integration testing confirms whether these independent modules can work as expected when they are combined together. Mostly this level of testing performed by testers. There are several approaches for integration testing, such as big bang, top down and bottom up. Let's consider each of them. The big bang. This approach involves testing all system components simultaneously after they have been developed separately. Usually, after all the components have been developed, they are combined into a single system, and then integration testing is performed. This approach can be quite fast, but it can be challenging to identify and fix problems because so many components are tested at the same time. Top down is the second approach. In the top down approach, testing starts at the highest level of the system and functionality at higher levels of the system is tested. Gradually, the components at the lower level are replaced by dummy components or placeholders, and real components are added during this testing. In this way, the upper levels are integrated with the lower levels until all components are fully connected and tested. And the third approach is the bottom up. The bottom up approach starts at the lowest level of the system by testing individual components or modules. These components are then combined into larger groups and their interaction is tested. The integration process continues until the entire system is built and tested. So the top down and bottom up approach are opposite. When chosen an approach to integration testing, the development and test team must take into account the complexity of the system, available resources, and even amount of work. Each of these approaches has its own advantages and disadvantages, and it can be chosen depending on the project needs and testing requirements. System testing is the first level where the entire program or entire game is tested as full structure. The goal at this level is to evaluate whether the system meets all the defined requirements and to ensure that it actually meet quality standards. System testing helps to ensure that the program meets all the requirements and specifications. This testing is performed in an environment that is as close as possible to where users will run the product. System testing is very important because it confirms that the program or game meets the technical, functional or business requirements set by the customer. It's mainly performed by testers also. And our last level, but still important is acceptance testing. Acceptance testing is conducted to determine whether the system or game is ready for release. Acceptance testing helps to ensure that the software product is ready to go to market and will meet the needs of users. During the software development life cycle, Change in requirements can sometimes be misunderstood, which do not meet the intended needs of users. During this last phase, testing will take place as if the program or game were being used by the end user. After the testing is completed and the app or game is successfully passed, it will be released to the target audience. 15. Testing types: Testing types or types of testing are a pretty important part that helps us understand what kind of bugs we're looking for, whether it's a problem in the game or problem with text, sound, and so on and so on. Knowing all types allows us to ensure that the game or the application that we test is fully covered by all necessary tests so that nothing is missed. There are two main types functional and non functional testing. Functional testing is a key stage in software development process. That aims to verify the functions and functionality of the program in accordance with the established requirements and specifications. The main goal of functional testing is to make sure that the program works correctly and delivers the expected results for users. At the beginning of the functional testing process, testers analyze the requirements and specifications to understand what functions should be implemented in the program. What actions should the program perform and how it should behave in different situations. After analyzing the requirements, testers develop test cases or test scenarios, which include a sequence of actions to test individual functions of the software product. Each test case is aimed at testing a specific function or aspect of the program. When performing functional tests, testers run the program with different inputs and verify that the program behaves as expected and produces correct results. They observe the program, making sure it works properly and meets the specified requirements. During the tests, testers also record any problem, error, or defect they find and document the results and observations. After completing functional testing, testers prepare a report on the result. Report includes identified issues, test status, and any even recommendations for further development. Functional testing is critical to ensuring the high quality of a software product. It helps to identify problems and defects that may affect the correctness and reliability of the program before its release. Testers make sure that the program meets the requirements and expectations of users and also helps to improve the product and its readiness for the market. Functional testing checks whether each function, also called feature of software application works according to the requirements of the specifications. Functional testing shows what the system does. The purpose of this testing is just to verify that the system works functionally flawlessly. In simple words, to perform functional testing, you need to start the game and play. Higgs, let's take a look at example. We need to perform functional testing of a weapon in the game counterstrike. To accomplish this task, you need to launch the game, take any weapon, and perform certain actions like shoot, reload, check the ability to pick up and throw the weapon away. This will be the functional testing. There are five steps to considering functional testing. Preparation of test data based on the specifications of functions. Business requirements are the inputs of functional testing. Find out of outputs of the functions based on functional specifications, the execution of test cases, and observe the actual and expected outputs. Let's take a look at change related testing. Change related testing ensures that previously fixed bugs are actually fixed and detects bugs that may appear accidentally in the new versions after changes have been made. In other words, there are the types of testing that should be done after certain changes have been made to the game. Whether it's bug fixes, I mean fixed box or just additional functionality added, there is never a guarantee that something new will not break. First, you should conduct a re test or a confirmation test just to make sure that the bug was successfully fixed. To do this, the tester repeats the steps he or she took to reproduce the bug and checks whether it's really no longer present. Regression testing involves execution in previous tests to cover the basic functionality and scenarios of interaction with the system. Its main goal is to make sure that after changes are made to the program, it continues to work correctly and no new defects appear. Smoke testing usually involves running the main scripts or key functions of the program just to make sure they work correctly and don't cause critical problems. This may include checking that the application starts up, access basic functions, loads important data or connects to database. Sanity testing is a test of basic functions or changes in software product just to determine whether the system is ready for more detailed testing. It's usually carried out after receiving a new version of the program with minor changes in the code or functionality. The main difference between smoke testing and sanity testing lies in their goals and scope. Smoke testing checks the readiness of the system for further checking and sanity testing checks the correction of problems after changes and confidence in stability of the system. Non functional testing is an important part of software testing processes. The focus on verifying aspects of the programs that are not directly related to its functionality, but still are critical to its quality and reliability. This includes characteristics such as performance, security, stability, compatibility, accessibility, and so on and so on. The main goal of non functional testing is to ensure that the software product is of high quality and reliability and that it meets the requirements and expectations of users. This is important because not functional testers, mismatchment can lead to users dissatisfaction, deterioration of the product's reputation, and even financial losses. A variety of methods and techniques are used in the process of non functional testing. Tessers checks the performance of the program that is speed and efficiency in processing data and performing operations. They also evaluate the stability of the program by checking its behavior during prolonged use or under changing conditions. Tessers pay attention to the security of the software product looking for potential risks and vulnerabilities that could lead to unauthorized access or even attacks. They check how the program works on different platforms and environments to ensure its compatibility. They also test the accessibility of the program, as it is important that it's accessible and understandable to all users, including those with disabilities. Non functional testing helps to identify problems and defects that may go unnoticed during functional testing. This allows you to eliminate problems in time and improve the quality of the software product before it's released to the market. Non functional testing is an important part of software development process and helps ensure successful and satisfactory user experience. We conduct non functional testing to ensure that the end user needs are met. The product will not be successful will not be successful if you cannot meet the client's expectations. Let's look at its main types. UI or user interface testing in games includes the evaluation of the efficiency, usability, and quality of the game's graphical interface. This includes checking the correct placement of controls, the clarity of instructions and symbols, the relevance of the design to the games theme, and other aspects that are related to the user's interaction with the game through this graphical interface. UX or user experience testing in games focuses on accessing the overall user experience of the game. This includes evaluating the ease of use, smoothness of gameplay, meeting user expectations, sense of fun and other aspects that are related to user's interaction and emotions while playing this game. You is much more complex than the visual interface of the game. It also includes the experience that the user gets from interacting with the product or a game, the process a user has to go through just to open a game or service, the sequence of actions that the user performs when interacting with the interface and much, much more. Those types of testing play an important role in ensuring high quality gameplay and user satisfaction. Localization, globalization and internationalization testing. In games, they are different aspects of testing related to the adaptation of the game to different languages and cultural environments. Localization testing refers to the process of translating and adaptating a game for a specific language and cultural environment. This includes translation of texts, localization of graphical elements, adaptation of date, time, and other culturally dependent elements. Globalization testing checks the correct functionality of the game with any culture and language settings using various international inputs. This includes testing different formats of date, type of currency, time, symbols, and other global parameters. Internet analyzation testing is focused on checking the correct external expression of the game content in different languages and locations. This includes checking the external expression of text, graphics, audio and other elements in different localizations. So let's repeat. Localization testing is focused on a specific language and culture. Globalization testing checks how the game works with different cultural settings, and internationalization testing makes sure that the game content is expressed correctly in different languages and localizations. Security. Security testing in games is the process of checking and evaluating security measures used in a game system. It includes two important aspects penetration testing and vulnerability testing. Penetration testing is a process of actively identifying potential weaknesses in the system, including web applications, servers, and network components of the game. This type of testing consists of an attempt to penetrate the system using various techniques and methods to identify possible vulnerabilities that can be exploited by attackers or even hackers. The purpose of penetration testing is to identify and fix potential security risks and issues, ensuring the game reliability and game's security. Vulnerability testing is a process of identifying and evaluating vulnerabilities in a system, such as flows in a codes, insufficient security measures or incorrect configuration. This type of testing helps to identify potential vulnerabilities and flaws in the system so that they can be fixed before the game is released. It can include code analysis, check in configuration settings, check in network security and many other activities aimed at identifying vulnerabilities. Both types of testing are aimed at improving the security of the game and protecting it from potential threats and malicious influence. Compatibility. Compatibility testing in games is a verification process that aims to ensure that a game is compatible with different hardware and software configurations. Also operating systems, devices, and other components of the environment. There are two main kinds of compatibility backward compatibility and forward compatibility. Backward compatibility is a feature of a game that allows it to run on older versions of hardware or software. Backward compatibility testing includes checking whether a game retains its functionality and compatibility when using older components. Forward compatibility is just the opposite. It's the feature of a game that allows it to run on future versions of hardware or software. Forward compatibility testing includes checking whether a game retains its functionality and compatibility when using future components. An example would be games that worked on PS four and now also work on PS five and vice versa. Performance testing. Performance testing in games is the process of determining and verifying the performance of a game, including its speed, stability, and response to various lots. It's an important aspect of game testing because players expect a smooth and satisfying game with high response times. Stress testing. In this case, the game is subjected to an intense load that exceeds normal use to test its stability and responds to extreme conditions. Load testing. This is a test of the game's performance under excessive load when many players simultaneously use the game's resources. Stability testing. This is a type of testing that's aimed at checking the stability and reliability of the game during long term operation or under load. The main goal of stability testing is to identify possible problems related to crash, memory leaks, freezes or other errors, bugs or defects that may affect the performance and functionality of the game. Volume testing. Well, that's a type of testing that checks the performance of the game when working with a large amount of data or lot. This includes testing a game with a large number of objects, characters, levels, or other elements that may affect the performance and speed of the game. Concurrency testing. This testing is performed to verify the game's performance in a competitive environment where many players interact with the game at the same time or connect in an online environment. This includes checking the stability of servers, the processing of many requests, and the efficiency of network interaction. Scalability testing. The testing is performed to verify the ability of the game to scale and run efficiently when resources such as the number of players, the size of the game word or the amount of data is increased. This allows you to check how well the game can handle the growing load and continue to work without losing performance. And the last is endurance testing. Ndurance testing is just testing the duration of a game to see if it maintains stability and performance over a long period of time. That was all for this part of the course. Thank you for your attention. See you in the next part of the video. 16. Test case: Hello, and welcome to the next part of the course QA become a game tester. We already learned quite a lot, so it's time to move to the next section. And this section is called test documentation for QA in games. Simply but this is a set of documents that defines the test plan and strategy, as well as describe the tests, scripts, procedures, and instructions that are needed to perform game testing. Documentation is an important aspect of the software testing process because it helps to ensure the quality and reliability of the software product. Test documentation can be divided in two main levels high level documentation, which describes the testing process itself and low level documentation, which describes the testing processes at a more local level. The purpose of the test documentation is to organize and manage the testing process and also ensure the high quality of the game and identify potential problems and even defects. Test documentation provides answers to questions such as what to test, how to test, what resources are needed for testing, and of course, how to evaluate the tests. In this section, we will also have a plan, and it will be as follows. We'll go through the basic things that every tester should know, namely what is a test case, checklist, and bug reports are. After we get familiar with these concepts and their details, we will try to create these documents in our practical part. So let's move on. Let's start with the test case at the beginning. In simple terms, a test case is a game testing document that describes a specific test scenario or test case for testing a game. From a more specific point of view, a test case is a document or script that describes the sequence of steps to be taken to test a certain functionality feature or module of a software product. Test cases are developed to perform testing to verify that software product works in accordance with specified requirements and expectations. They are important tool for ensuring the quality of a software product before its release. The main purpose of test cases is to describe in detail the sequence of actions that a tester should perform to check a certain functionality of the game or identify defects. Test cases help to ensure uniform approach for testing. Allows you to repeat test scenarios and ensure that different aspects of the game are tested completely. There are several main types of test cases in game development. The first one is positive. Positive test cases use valid inputs to verify that the product does what is expected of it. The goal is to make sure that the system doesn't throw errors when it's not expected to. For example, if we press a spacebar, the character will jump. Or if we press the left mouse button, the character will start shooting. The second type of test case is negative. Negative test cases are they use invalid inputs and verify that the software doesn't do something it shouldn't negative testing aims to make sure that the system checks for invalid inputs by generating errors or by preventing the system from working in a certain way. For example, if a character can swim, you cannot jump into the water when you approached it, or a message is displayed that says you cannot jump into the water, or let's take a look at another example. We have to move the character to a certain point on the map, and if we choose a point that is outside the game zone or in general where he cannot be. We get an error on the screen that says invalid move point. The last type is the most interesting. It's a destructive test case. Destructive test cases are performed to determine the limits of the game before it crashed. For example, we will press space bar 100 times in a row to jump or try to kill a key character in the story and see how the game reacts. Let's take a look at the main elements or attributes of a test case. ID or sequence number. This is a unique number or identifier that is used to identify a specific test scenario. It can be a numeric code or text identifier. Summary. Summary is a short title or description that identifies the test case. It should be informative and accurately reflect the nature of the test. If we are talking in a more simple way is just a short description of what exactly gone wrong. Preconditions. Preconditions is an indication of the state or conditions that must be met for the test scenario to be executed successfully. For example, it may be necessary for the user to be logged into the system to recreate the problem. Steps or steps for reproduction. The steps that the tester must perform, including data entry and game interaction. This is a sequence of steps that the tester must perform to test a particular functionality or interaction with the system. The steps should be clear, detailed, and include the necessary actions such as entering data or pressing buttons, and so on. Test status. Test status is an indication of whether the test was successful or some defects were found or other results. This is an assessment of the test status. It can be labeled as pest or defects detected or failed or other labels that reflect the test result. Actual results. Well, it's just the actual results after the test is performed. This is the description of an actual result or state of the system after the test steps have been performed. The tester should objectively record the test results, including any notable anomalies or even inconsistencies with the expected result. And expected result. Usually, expected result is taken from the documentation. Long story short, it's a description of what should happen after the steps are completed. This is a description of the expected result or state of the system after the steps have been performed. It can be a specific output, message, screen display, or any other expected result. The last but not the least is the post conditions. But it is used not usually an optional. This is a list of things to do to return the system to its previous state after the test. It's usually used in cases where the team works with one server or a database and change during the executions of the test case can interfere with other people. Preconditions and post conditions are not mandatory attributes of the test case and are used more situationally. So in a nutshell, a test case is the unique description of a test where we write down in advance certain steps, then we plan to make sure that the game works as expected. If the expected results and the actual result are met, and everything is fine. If they're not met, we have a system error and of course, a bug that we should report as professional testers. Now let's see how to write test cases to make them feature oriented and effective. The test case should be clear and easy to understand so that every team member understands what it's about. An ideal test case is when even a person who is not involved in testing can pass it and understand whether the result obtained is as expected. The test cases are written based on the requirements for how the game should work. Therefore, a good test case should clearly show which requirements are being tested in this case, whether it's security, walk through or UI. In this case, it will be easier to understand what type of testing has not yet been performed. Good test cases should be able to be used several times on different projects or even similar functionalities, if it's possible, of course. This will greatly reduce the time it takes to write them. The test case should be accurate so that after the test case is completed, there are no questions about whether everything really works as it should or not. The test case should be constructed in such a way that after its execution, we get a clearly result. For example, in the CSO, the AK 47 rifle should do 110 damage if you make a headshot. And after the test, we clearly understand whether the actual result corresponds to the expected one. A test case should be written in such a way that it's possible to pass it with each iteration of testing. That it describes the expected result of the game because if you write unique test cases that check something that happens only one during the entire development, you will spend more time writing test cases then you will receive benefit from their execution. Little advice. Always make sure that your test cases are clear, accurate and complete when writing them. This will help you perform testing efficiently and improve the quality of your game and even help other testers get up to speed onto your project quickly. 17. Checklist: Let's move on to such an item as a checklist. A checklist in game testing is a structured list of items or criterias that should be checked during game testing. It contains key elements, functional aspects, scenarios, game modes and other things that need to be checked to ensure the quality of the game. Its main feature is that it looks like a list, and it takes little time to create. Checklists are often used to standardize the testing process, especially when performing repetitive tasks or testing certain features in different versions of a software product. They help testers not to forget important aspects to simplify the process of data collection and ensure consistency in testing. For example, a checklist for testing a new level in a computer game may contain the following items. Check the visual quality of the level like graphics, lighting, textures, Make sure that the player has access to all the needed and necessary weapons in inventory. Check if the game mechanics works correctly on this level, make sure that the player can interact with all objects on the level like doors, traps, switches, and so on. Check whether the artificial intelligence of enemies behaves correctly on the game level. Check for graphical or programmatic errors in the level, ensure that the level can be successfully completed and move on to the next one. Checklists help to increase the efficiency of testing, reduce the chance of missing important aspects and ensure the high quality of the software product. They can be used as hints for testers to help them focus on critical test points and ensure that the program quality assessment is complete. Let's take a look at the main pecularities of the check list. It's versatile or it's universal. Since it contains a common set of tests, it can be well suited for different projects. I mean, it's quite reusable. Easy to create and use during testing. You simply select the main things you need to test and write them down in a checklist. For example, start up, main menu, sound mission one, mission two, and so on. Analyzing results. With the help of a check list, you can easily analyze the process of the result of the testing. For example, we have a list of 20 missions in our checklist. At the moment, we have tested ten of them. So our progress is 50%. Out of these ten, one does not work. So it has box. For now, we have one out of 20 of the broken missions. Very flexible. The checklist is really flexible. Since this is a list, you can easily add or remove certain items. If I'm planning to check only UI today, I can create a copy for myself and delete all unnecessary parts for the checklist. In general, check lists are a useful tool for efficient and structured testing. They provide more confidence in the quality of the product and help reduce the risks or of releasing problematic or sufficiently tested features. Why do we need checklist? Well, there are two main reasons why we need a checklist in testing. The first reason for checking and assessing completion or non completion, just to monitor progress and understand what stage the testing is at. Also to understand when testing is completed or not completed. Our second reason is to make a note of tasks so that nothing is overlooked. Just to mark completed tests to understand that everything has been tested or to prevent testing the same feature from being tested twice in case of large and long tests, or if there are several testers working on the project. It's always a really useful tracking tool. 18. Bug Report: Now let's move on to the most well known element and the basis of tester's work, the bug report. In general, bug reports are the currency of quality control. They are the result of our work and confirmation of our role. Usually, there are the main channels of information between a tester and a developer. It's a document that contains a description and details of a bug that was found during the game testing. Basically, it works like this. You test the game, find a bug, and create a bug report. You fill in all the necessary fields and send it to the developer with requesting to fix this bug. This is a very rough description of the process because a lot of details can happen during it. The main purpose of a bug report is to inform developers or testers or even stakeholders about the problem and help them fix the defect. A bug report is an important element in software testing and development process, as it allows you to ensure quality and identify and fix problems before releasing a product to the market. Let's take a look at the main elements of a bug report. Summary, because the title or short description of the issue is a meaningful name that summarize the essence of the bug. Steps to reproduce a sequence of steps developer can take to reproduce the bug and verify that it's fixed. Severity and priority. Severity and priority are an assessment of how critical the bug is and how it affects user from game functionality. We will have a slightly deeper look at it just a little bit later. Description. It's a problem description, detailed description of the bug, including the steps that led to its occurrence, game behavior, expected or actual results. And of course, attachments. Attachments like screenshots or videos that clearly show the bug or how to reproduce it for better visual perception and understanding. Okay, we overviewed the main elements of bug report, but sometimes we have to add a little bit clarification. That's why we're using additional elements. Let's have a quick overview of them. The category or classification is the indication of the type of error. For example, graphics, functional or performance. Actual result. Is the result obtained or the error that we get after executing the specified steps and sequence. Expected result. The way the game should have worked after passing the specified steps. That's the behavior that should have happened if the game had no box. Affected version simply is just diversion of the build that was affected by this bug that includes this bug. So it's diversion where you can surely reproduce this issue. Reproducibility. It's a percentage that indicates how often an error will occur if you go through the specified steps. It can be 100% if the error occurs every time or 10% if it happens only once per ten place. And platform. Platform is the field, and it's usually used when testing one game on several platforms at once. In cases when we have a specific bug that occurs only on a certain platform, we can specify it in the report. A detailed and clear bug report helps developers to identify and fix defects faster, ensuring that the quality of the software product is improved before the release. Since a bug report is a basis with which a tester will work, let's go through each element in more detail. The first element on our overview is the summary or title. The summary is the first thing a developer sees, especially when looking at Bugs and Jira, where they are displayed in a list and only the title is displayed. Therefore, it's very important to have all the important information in the header that is structured and fully understandable. For this purpose, the PL system is usually used. It means the problem action location. Here is a small example of using the PL system. The first playing card doesn't appear. After pressing at card button, during tutorial. Okay, where is our problem? The R problem means that the first playing card does not appear. Action means that it doesn't appear after clicking the Adcard button and location means that it doesn't appear during the tutorial. We roughly speaking, you have to play the what where when game. Every time you write a good summary. Let's take a look at the next step that is equally important steps to reproduce. This is the element of the bugs report that shows the path that the developer should follow to reproduce the bug. In it, we describe step by step what actions were taken, what buttons were pressed, and in what order. The main requirements for steps to be clear and write and correctly are next. One action per one step. That's it. Launch the game. Click on main menu and click Start. A three separate different steps. The steps must be clear and understandable so that everyone, even some unfamiliar with your situation, can follow your steps and reproduce the error. After the last step, an error occurs. So there is no need to mention here is the error with one additional step. If you need to perform certain manipulations before you start the first step, you should write this in the prerequisites or preconditions. With detailed step by step instructions on how to reproduce the error, the developer who has to fix the error will spend a lot of time figuring out how to reproduce it. These steps should be as detailed as necessary, but at the same time, as simple as possible. Well, the ability to determine what is needed exactly is acquired with experience. Later, I will give some different examples of steps to reproduce. Now let's look at severity in the game testing bug report, which determines how serious or how big impact it makes on our game. It's a parameter that helps to assess the impact of a bug on the game's functionality, and on user's experience. Let's take a quick overview of the severity levels that are commonly used. Well, there are three main severity types. S one or high severity is critical issues. Means the bug or an issue that completely blocks or negatively impacts the game. The second one is S two or medium severity. It's the bug or an issues or a problem that has a moderate impact on the game or minor aspects of functionality, does not interfere with score gameplay, but may affect players comfort and enjoyment. And the last but not the least is low severity or a three is just kind of polish issues. A a bug or issue that has a minimal impact on the game's functioning or minor aspects that have little impact on gameplay or user's comfort. The severity determination helps developers and testers to prioritize the bugs and issues and plan fixes according to their impact on the game and users. And what I also have to mention that the severity is usually set by testers. The next element that goes hand in hand with severity is priority. In game testing bug reports, priority determines how important it is to resolve or fix a bug or an issue that has been identified. It's a parameter that helps to determine the time frame and priorities for fixing a problem during the game development process. Let's have also a quick overview of levels of bug priority. High or P one. An issue or the bug that needs to be resolved or fixed immediately because it has a significant impact on the game or could cause serious problems for users. The second one is P two or medium. It's an or a bug that needs attention and correction, but its impact on the game or users is not critical. They can be fixed after high priority issues and resolved in the next sprint, for example. And P three or low priority. It's an issue or a bug that is not urgent or critical and may be fixed in future releases. Usually, they have minimal impact on the game or user's experience. This field is usually filled not by testers, but by the project manager or producer. The next field that is also very important is description. Description is usually used when the bug is not something obvious and additional details are needed. The description field in a game testing bug report is a detailed description of the problem or bug that has been identified. This field in a bug report is intended to provide comprehensive information about the identified issues so that developers or other stakeholders can understand the nature of the problem and take appropriate action to fix it. The following elements may be included in the description. A specific description of the problem. Describe the main problem or bug as precisely as possible. Specify what exactly is not working or what the game's incorrection behavior is and so on. There may be many names of assets or objects, things that the player interacts with. There may be some specifical code names used by developers to name items or different objects on the map. You can also mention them here and additional details. I mean, that includes any additional information that must be helpful in understanding the problems such as coordinates on the game map, operating system, your hardware settings, and so on and so on and so on. A well written description helps you to understand the problem and focus on solving it. It's important to be clear, specific and detailed to ensure effective communication and collaboration between testers and developers. The next element can provide a lot of information that will help you visually understand everything described in the bug report, attachments. In game testing, they are attached files that are added to a bug report to provide additional information, evidence or details related to the identified problem or the bug. Attachments also may include screenshots, just photos of identified issue or abnormal behavior. Videos is the videos or the screen recording that demonstrates a sequence of steps to reproduce the problem or malfunction. Log files, it's the files that contains information about errors or testing or details about actions that were taken during testing. Configuration files is just the files that contain settings or parameters related to the issue. Or other documents or materials. I mean other links to documents. Maybe it could be some reports or materials that may be helpful in understanding and resolving the issue. Attachments help enrich a bug report with additional information and evidence that helps game developers understand and resolve the issue more effectively. They complement the text description and allow you to more accurately convey the identified problem or bug. We'll talk about the next element in more detail later, but it's also worth a quick review the category. Category field in a game testing bug report defines the type or category of a problem or bug you found while testing the game. For example, gameplay, UI, online, or even offline. This fields helps to organize and categorize issues for further processing and resolution. The next element for our overview, but it's better to say two elements is our actual and expected result. Actual and expected result are two different elements, but they usually stand side by side for better analysis. In a bug report, in game testing, there are two key aspects that describe the problem or bugs that has been found. The actual result is the actual result or the actual behavior of the game that was observed or detected during testing. It is what actually happened when certain action was performed or a certain situation was recreated. When describing an actionable result, it's important to be specific, accurate, and of course, detailed. An expected result is something slightly different. It's the result that was expected or should have happened according to the requirements, specifications, or even expectations. It describes the desired or expected outcome or behavior of the game in a particular context. Specifying the outcome expectations help developers and stakeholders to understand what might have gone wrong or not met expectations. By comparing the action and the results spectrum, it's possible to pinpoint the inconsistencies in problems that occur in the game. This helps developers to analyze and fix problems to improve the quality and functionality of the game. The following elements is very rarely used or is simply just a part of description or steps to reproduce, but still it's better to discuss it separately. Affected version. Affected version in a bug report, especially game testing indicates the version of the game or software in which the problem or bug was detected. These fields allow you to identify the specific version of the game in which the incorrect behavior or issue was present. Defining the version effect helps developers and other stakeholders to localize and focus on the specific versions of the game where the issue needs to be fixed. This field allows for better management and tracking of the progress of fixing an issue, especially if it's found in one version, but can be solved or has already been fixed in subsequent versions of the game. Next is reproducibility. In a game testing bug report, the, that element indicates the ability to reproduce or replicate a problem or bugs that was found during testing. This field indicates how easy or how difficult it might be for other testers or developers, or even stakeholders. To reproduce the issue in the game environment. Reproducibility plays an important role in the process of identifying and fixing issues. If a problem can be easily reproduced, it helps developers to better understand the cause of the problem and make appropriate fixes. In such case, reproduction of the issue can be performed several times to validate and test the fix. On the one hand, if the issue has low reproducibility, it can make it difficult for developers to fix it. Other testers or developers may find it difficult to reproduce the issue or buck, which can lead to additional effort to identify the case and fix the issue. Commonly used descriptions includes always intermittent or rarely or only once. Let's have a quick overview of them. Always, this level of reproducibility indicates that the problem or bug can be reproduced always or in every attempt. That means that there are clear steps or clear conditions that always lead to the problem. This level of reproducibility is the most favorable for identifying and fixing a problem because developers can easily replicate the problem for analysis and fixing. Sometimes or intermittens, is the level of reproducibility which indicates that a problem or a but can be reproduced from time to time but not always. This may be due to certain conditions or sequences of actions that sometimes lead to the problem, or maybe you have just not clear steps to reproduce. In this case, it's important to describe in details the conditions or ways in which the problem is reproduced so that developers can reproduce it, at least try to reproduce it for analysis and fixing. And the last one is rarely or only once. That's the level of reproducibility, which indicates that the issue or bug occurs very rarely or extremely rarely, or even just once. It may have some random or exceptional conditions that leads to the problem. In such case, it's important to indicate any possible conditions or factors that may be causing the issue to occur to give developers guidance for reproduction and fixing. Now let's talk about what platform. In a game testing bug report, the platform refers to the specific hardware or software platform on which the game was tested and the problem was found. The platform includes information about the operating system, device, console, browser or anything like any other platform on which the game is being tested. Provided the correct platform information in a bug report is important because it helps developers to understand which system or device is experiencing the issue and can help to identify and fix the issue more quickly and efficiently. Platform information can include details such as operating system name, for example, Windows, MacOS, IOS, Android, operating system version, device, or even console type like personal computer, Xbox or Playstation. And game or game engine versions. Specifying the platform in the bug report helps ensure the accuracy and specificity of the issue and promotes better understanding between testers and developers when resolving and testing the issue. After our overview of the all important elements of the bug reports, let's proceed to our practical part. So we will try to create all of these documents that we have just discussed. 19. Test case. Formatting: Hello, and welcome again. It's the second part, second practical part of the course QA becoming game tester. In this video, we're going to look at how to create documentation to optimize your work. If you're already a tester or just want to become one, you should realize that using these documents is an indispensable part of your daily duties. Today, we will learn how to create test cases, checklists, and even bug reports. We have already covered their theory, and now we're going to put it into some practice, and we'll start with test cases. As we already know, test cases are documented guidelines or instructions that defines the sequence of factions to be performed when testing software product or a game. Test cases help testers to product quality, ensure that the software product works properly and meets the requirements and the expectations. We will create several types of test cases like positive, negative, and even destructive test cases. At the same time, we will see their difference in real life. The positive test case involves verifying that a program or a product works as intended. So it does what it's supposed to do. And there are no errors or failures when we check the expected operation of the product or part of it. So let's start with firstly, positive test cases. The first thing that we have to do is just to create a separate document that we will called, I don't know, test cases. I call it like this. And we need to have a little formatting. The first thing that we will need is the ID field. It would be the idea of our test case. Usually, the idea of test case could be linked to your Jira, or maybe it should somehow identify the number of your test case or even just the key of test case. The second field that we will need is the summary. The summary is just the title of our test case, so we will take a deeper look at it a little bit later after we will fill in all the additional fields. Another thing is precondition. Preconditions is something that we need to do before we are moving to steps to reproduce and the steps. You can call it whatever you want. Mostly, like the steps, steps to reproduce or something similar. Also, we need to add the status, the actual result and the expected result. I don't know, maybe it looks a little bit small, can scale it a little. Okay. I believe now it looks better. And the last, not least, but still very optional field is post conditions. We could have it, but I don't think that we will fill in this field because it's optional, and sometimes it just use some information, how to return from the state where you're stucked in your bug, like how to restore the default program work. And now we have a little bit to format on the things. So let's start. I usually prefer this font just to make things a little bit prettier. We can, I believe, create a table, somehow make it separate. Also, I believe we can set the columns width. Where is it here or size. That would be 150. Even 200, why not? Of course, we can change the color of the background, just to look it a little bit prettier. And what I prefer to do is just to separate some lines, again, just to make it prettier. Then look how I do this because it's kind of silly, but still it works. Okay, now, we have our table. So we can proceed to writing our test cases. 20. Test case. Positive: Uh, we have to imagine what we're going to check. Let's say it's a simple login form that is consisting of two fields and the button, namely email, password, and I believe the login button. And if user enters the correct information, the fields will be highlighted in green color and the button will become active and can be clicked. Now let's write three positive test cases together. Again, the first thing that we will need is the ID. In our case, we can, I believe, just create a number of test case. Let's QA become a game tester. That's how it looks like. And that would be one. We can make these cells, have the content in the middle, just to look a little bit prettier, resize this row, not to make it so big and ugly and resize row of summary because we will definitely need more lays for our summary. Okay, so three. Firstly, positive test cases. The first our test case will be when entering a valid email, the email field has a green frame or green highlighting. So we can start creating it. And our summary will be some like the green uppercase. The green highlighting is present on boss input fields. Not like this is present or inputFild if it matches the requirements. So the idea of our test case is just to check whether the green highlighting is present when we have the correct and proper information in our input fields. It could be the password field or the nickname field or how I called it before the email field. So we are checking if user input corrected email or correct password. Just a little bit specify it, we can create two separate test cases, one for the nickname field or login field, and another one for password. So we can type login and make and same this case, but for password. A word tabs. And of course, we will need our ID. But we also want to make a little bit prettier. Okay. The first thing for our preconditions that we want to write down here, we need just to understand what exactly we need in our preconditions. To proceed to login screen, we have just started to build, which is just our first step to reproduce it. So I believe we will have the empty precondition here. And now let's move to our steps. Usually, we have the login screen that is present just on the very beginning of any mobile application or game lounger or website or anything else. So the first things that we need to do, let's imagine that we will have I don't know. Should let it be the mobile app. The first thing that we need to do is just to put the title on the build. So we just have to launch it. Another overstep. Let's imagine that we have the screen with, I don't know, two buttons like registration and login, and we have tap to tap the login button to proceed to login screen. Let it be tap the login button. That's how we should proceed to our login screen. The same steps I believe would be useful for our second test case. Another thing that we need in our test cases is the status. Status of test case is just his current status of what exactly is going on with it. Like, is it in progress? Is it already done or something else? Usually for such status, I don't just write the actual status in the cell. I create the drop down list with all possible variants just to simplify all the process. If I'm not mistaken. I can do it by the right click. Yeah, drop down. But and now we have to understand which values we need for our test cases. I believe we need to do because we didn't start our test case, in progress in progress. Because we started testing this test case, for example, we need We need fail. What exactly we can need. We need CNT. Let it be purple. We need not implement We need the words. And just to make the full list, we need Okay, bud. I didn't like these colors. I need the orange. Just a good orange color. Yeah, that's fine. And Okay. So now we created the sharp drop down with all of our possible statuses. The one we're sync, which I don't like is that we need to move a little of all our options. Okay. So we have to do if we didn't start our task, we have in progress, we have pass, we have fail, just the actual status of the test case if it's okay or not okay. Okay, but about the special status that we need to show that this test case is working as intended, but still have maybe some minor issues or some problems that are not related to this test case, but still it don't make it fully pass. CMT. CMT is the status that you use to show that you cannot test this test case, cannot test according to missing feature or missing design or blocker before or blocker in the app that will not allow you to test this test case or something like this. Not implemented. Not implemented is a status for, for example, the feature that was not added to your build, so you cannot test it, but you can test it you can test it not because something doesn't allow you to test it, but because it was not implemented in the build. So it was not added, not yet created and aborted. Aborted is the status usually for cutted features. So if the feature was cut, you can put here aborted status. And of course, the first status that we need is to do, and we need to make all of the statuses. Oh, sorry. All of the statuses to do. And I like to change some colors. I don't know. I just like to make things a little prettier. By the way, we can change type of our drop down like arrows or even plain text, which I don't like. Maybe let's leave arrow. It would be just more easy for visual understanding of everything. So now we can select any status that we want, and it will show us the current status of this test case. Actual result. Actual result is our next field, and we have to write down here the expected not expected, just the actual, actual status or what we see at the time, we repeat all the steps and just what we see. So our actual result here would be the green y Light highlighting is present. If we see this, of course. If we don't see, we can type that there is no green highlighting or green highlighting is not present. So we can add into one that actual result is okay and add into another one that the green highlighting is missing. Expected result. Expected result is similar to actual, but it's the result that we expect from the working of this feature that this was writen down in design or was told by our developers how it's supposed to work and so on and so on. Here we need to write that we expect that the green highlighting is present for the input field that match the requirements. Green highlighting is present. And I believe we can just copy it for our second test case. And the post conditions. Post conditions, I don't know if we need it right here, but let's imagine that we have the BG buttons or exit button, let it be exit button. That it's the exit buttons that would move us back from the build or just close the build or something like this. I don't know. So it should return us to the state of the first step. Let it be tap, quit. But I already see the mistake in our steps to reproduce. If we tap in the login button, we see empty fields, but we need to make them not empty, so we need to input or enter some information, and information must match the requirements. So we have to add the search step input info or even Email. To Email. Input field. And let's specify it a little like input, correct. Email into email input field. And the same, we should add the circ step to our second desase like inputs. An Sword matching the requirements into a word inputs. Inputs field. Our table is a little bit cut it, so we need to wrap the text, and we now can make all sections a little bit shorter. Again, just to make things prettier, nothing very special. Okay, I was our first test case. Let's start the second one and imagine what exactly we need to we need to create as a test case. Let it be that the user can enter starting 6-10 characters in the password field. So we need to check if our input fields can understand if the password matches the requirements. I worked in field. Not like this. User enters 6-10, even starting from or not like this. Password. Lens is equal Starting from six up to ten characters. Our preconditions. Again, I don't think that we need preconditions here so we can just skip this field. Let's center it again. I don't know why. Let's center it. And our steps. The first hour step is game boot, the title title on the build. It would be our first step almost everywhere. The second one is step login. Button we need this step just to proceed to our login screen and input. An Best word. Not like this. Input. Best word up to ten characters in it. That's just a good dicase. We also can check if we really understand the boundary values and the lysis. So we can try to check if we can enter five characters, six characters, seven characters again. Nine characters, ten characters, and 11 characters. Just to check if this feature works as intended. What do we expect from this feature? Password de ns is equal starting from six up to ten characters. Password requirements. We're checking the requirements, so we need to add the requirements here. Okay. If the password matches starting from six up to ten characters, the green highlighting should present and the login button should be active if, of course, our another field is also inputted in correct way. So we can just type here, the green highlighting is present, the same as in our first case. Because we see if we have the password, which length is six, seven, eight, nine and ten characters, the green highlighting is present. And another one, we expect that if our password would be 6-10 characters, the green highlighting would be present. Again, I prefer not to write best conditions, so let's skip it just this time and even next times. And again, what should we need? Our carts case should be something like the login button becomes active. I user entered information that meets the requirements of the form in boss fields. Again, we have the bus fields. If boss fields have the correct information that match the requirements, our login button should becomes active. It could be available to tap or to press on it and just to log into the application. Let's try to create datas case about it. Login button miss the B becomes active. I boss input. Fields are input match the requirements I input. If I boss input fields match the requirements. We're checking if the info match the requirements. Okay. Let's also wrap it. Preconditions. As I like to do this, no preconditions. Our steps But the title on the build. Tap Login button to proceed to login screen. Input. Correct. Email into email field. Input, correct. Password Password. Into password. Field. Let's also wrap it. Okay, what we expect right now? The login button becomes active. So in our expected result, we can write that login button becomes active. Let's imagine that we don't see this I post input fields have matching requirements in formation, and we don't see that login button becomes active. For now, we can write something like Login button is not active. And the gains keep the post conditions like them. It's also center. This column. And this column, where is it? This column is centered. Okay, looks fine. So now we finalized our writing of positive test cases. So we can proceed to writing the negative test cases. Similar to positive test cases, negative are also writing to check if something works, but mostly to check if the application works in proper way if user makes some surprising or unexpected actions. 21. Test case. Negative: Okay, now we understand how to write positive test cases. We will have the quick overview of statuses of the test cases that we already have written, but we need just to move on, and then we will set all the statuses and see how it works. So we've finalized the positive test cases, and let's proceed to negative test cases. Negative test cases are aimed at checking how the system reacts to incorrect data or some input errors. We will create I believe it's three of them. And let imagine that it would be incorrect email input at the incorrect email into email input field, incorrect password lens, like four characters, and what should it be the blank input fields and active login button just from the beginning. So let's start. Our first case is incorrect email. Let's imagine that in our incorrect mail, if we input it the incorrect mail, the login form should highlighted in red and display some errors like, sorry, your email is incorrect. With this information, we can write our test case. Email, email, email is it's in email field. Let's keep the word incorrect and change it to Email. That is inputted in email field doesn't match the requirements. Okay, so we're checking what would it be? How the application or the website or in our case, how our login form would work if user inputs incorrect email. Preconditions. Again, we can skip it. Our steps. Both the title on the build. Again, we imagine that we have the application, the mobile application with login form. So firstly, we need to again start this application. Tap login. Button input. Email that does not match the requirements into email input field field. And of course, we need to wrap the text just to make it visible. Our actual results. Let's imagine that we see that if we input the incorrect mail into our email field, it's still highlighted in green. So again, let it be the green highlighting is present. In our case, our expected result would be, for example, that green highlighting is not present. I should just not be visible. Or we can imagine that red highlighting should be present, but better just to assume that we will not have any high lighting because we don't expect this result. So now green highlighting is present. In our case, still no post conditions while we need it. We don't need it right now. Our second negative test case should be should be incorrect password. Okay. Input. Password doesn't match the requirements. No preconditions again. We don't need them. Our steps, again, starting with boot, the title on the build. What we expect? We expect from this that there is no green highlighting. In our case, let's imagine that we see that that we still have the green highlighting. Why not? Oh, I missed a couple steps. Sorry. Stop. Login button. Input password that does not match the requirements into pass word input field. Let's make it a little prettier. I believe we can do the same thing here. Email input field. Okay, now we have our nazetscase and of course, now post conditions. And our lasts case, it should be inactive button. If we have some blank or empty email fields. So we have to check if we have the inactive login button, if we have some blank or empty input fields. Log in. Button stays inactive if no information or even no email and I email and password fields are empty. We have to check if our login button stays inactive if the email and password fields are empty. Again, no preconditions, we don't need them here. Let's proceed to our steps. Start with d, the title on the field. Step login. Button. And again, I believe to check if we have the inactive login button on our login screen, we again have to repeat the same step, but for another screen, we just have to similar buttons. Maybe it's a little bit strange and not good from user experience, but for our case, it's still useful. Okay, what do we expect? We expect that we have the button. This stays inactive if no information was entered. Buttons specified Login button stays inactive. And let's imagine the result. I believe we should we can imagine that the result actual actually works. So let's imagine that it works correctly and reacts okay to the empty inputted fields empty information inputted fields. So actual result, login button stays inactive. And again, no post conditions. That's it? That's our negative test cases. As you see, our positive test cases check if the program works as intended, and negative test cases checks how the application or in our case, the login form reacts to empty or incorrect information that was inputted into our input fields and checks how this login form would behave. Let's move on, and let's proceed to destructive test cases. 22. Test case. Destructive: Okay. After positive test cases and negative test cases, we could switch to destructive test cases. Distractive test cases are aimed at checking boss, the system's resistance to various types of attacks and the use of very extensive or unexpected data. This is our main goal. To look at this scenario, that will be very unexpected for our login form. We can imagine a lot of different special situations that were not expected by the design of the application that were not programmed by developers, and we could see how the app reacts to such actions. Let's imagine that we will have three also destructive test cases for our login form. We have to check how would it work in these cases. The first one should be the massive data entry. We can imagine that in the same time, 1,000 users are pressing the login button. So or maybe even we can imagine that the login button was pressed 1,000 times in a row, like, very fast one by one. But still, I like the first variant or the first option more. So let's check it. So we have to test how the system behaves when mass data entry is performed on the login form. Mm 1,000 users Tap Tap login. Button at the same time. I believe it would be really unexpected for our application and even for our login form. Here, we need some preconditions. We are testers, so we cannot just call our friends because not every one can have 1,000 friends that would be available at the same time to tap the login button in the form. We can use some additional testing tools, for example, the J Mtter J Matter is a tool that would help you to simulate login of 1,000 users in our imaginable login form at the same time. So our preconditions should be install J matter and the second one should be set JMter Options to simulate 1,000 logins. Per second. We will have something that would definitely help us to simulate login into our login form 1,000 users in a second. That's our preconditions. Let's move to our steps. Of course, our first step would be put the title on the build Of course, not only said the matter, and also we have to connect Matter to login form. Because meter will not understand what exactly he should simulate and where. Okay, so let's continue with our steps. The first one is put the title on the build as usual, and let's imagine the second, we have to top top login. But um, So it's just to proceed to login screen and simulate taping login button. By thousand users via GMter Because why not? We can do this. We are testers, we are professionals. We also need to imagine which actual result and expected result we should have why we're imaging everything because we don't have the real login form. We just imagine some situations and try to somehow write them down and systematize them. Okay, our expected result, we expect from the system that even logging of 1,000 users at the same time will not break our login form or somehow crash our backhand or anything else. So we can type here that no issues are present because we don't expect any problems with logging of 1,000 users. But in our case, we can imagine that the site was not the site that our login form was frozen. As we can understand, it was frozen because our Ben has some problems. So we have a lot of different requests for our Bens. That's why it has some problems. So we can type here something like login. Form is freezed. Oh, very interesting login. If we have the frozen login form, we need to use the post conditions just to return system to work in state. So we can type here something like restart the build. Still, it's our application, so we have the build, and we can restart it. Suddenly, the login form is freezed. Let's imagine that the application is freeze. Why not? I Would be much easier. Application freeze. Or even let's make it more serious application crashed. Chesh. Still? A good word. Crashed. Okay, let's continue with another destructive test case. Let it be Let's be our second variant of this test cases just tapping on the login button 100 times. Just one by one by one user. He just sits and taps for, I don't know, 10 seconds, ten taps per second. So he taped the login button 100 times. So login button was tapped 100 times in a row for 10 seconds. So now we specify that our login button was tapped 10,000 times one by one, in a row for 10 seconds by one user. I don't think that we need some preconditions here because we don't need to install anything additional. We don't have to link anything additional and to connect. So we can just keep the preconditions for now. And let's proceed to our steps. The first step, of course, was the title on the build. We also can simulate tap in 100 times on login button, but still we can do it without anything additional like additional tools. So let's imagine that we just sit in 10 seconds press the login button. Just to make it a little bit easier. Tap, Login button. As we remember, we're taping this login button just to proceed to login screen and tap Login button 100 times in 10 seconds. Okay, what do we expect? We expect that application would work as expected. So, I mean, work as intended. Like, nothing will be changed, and still login button would be active, application will not crash, will not freeze, and so on. So I believe we can just copy this expected result into the cell. So we have no issues no issues are present. And let's imagine that for real, no issues were present. So our application was too good, and it's easily pass tapping the login button 100 times in a row for 10 seconds. Our post conditions, if everything is okay, I don't think we need some post conditions. Okay, let's start with the cert destructive test case. Let it be exceeding the amount of data entry. We have the password filled, and we can enter the special password that will be that should be somewhere around six to ten characters. We already checked that these characters can be that the password can be correct, that the password can be incorrect. What if we will check if the password has the length of 10,000 characters? So the first things that we need to do again is just type our summary. Pass word. Lens. Not like this. Input Inpoputi. Still funny. It's word. Lens equals 10,000 characters or more. We didn't need anything additional to ist. Still, we can just sit for just a couple of seconds, pressing the random numbers, maybe the second, maybe minutes, even just pressing the random characters or keys on your keyboard and just see what would it be? But still, it's also possible to simulate. Sometimes you can simulate it just by using Lauren Ipsum or by any other tools. But the easiest way just to press a lot of keys on your keyboard, and it will not take a long time. Let's proceed to our steps. And again, put the title on the build. 'Cause why not? Tap login button to proceed to login screen. And we have to input 10,000 characters into a word field. Let's also wrap. What do we expect? We expect that no green highlighting is present and login login button is not active. But still, login button should not be active. If we have both Not really. Still, we expect that there will be no green highlighting. Let's just copy that no green highlighting is present. Still, we can add that login button. Stays inactive because we still expect that we will have no green high lighting, we still expect that login button is inactive because we entered the wrong password. The actual result let it be only only 16 16 let's be 32 characters are available to enter in password field. So we try to input 10,000 characters into our input field, and we see that only 32 characters are available to enter in the password field. Still, no post conditions goes. Why do we need them here. Okay, now let's deal with status. We have the good number of test cases like the ten test cases, just to check some positive aspects of the login form negative and even some destructive test cases just to check something really unexpected. So we're checking that green highlighting is present for login input field if it's matches the requirements. So we're checking if the login It was not login. It was email. Sorry. It's my mistake. Um, so we have to check if the Android email is correct and the green highlighting is present, so we can change the status of our test case in pass because everything works fine. And we see that our expected result is equal to our actual result. Let's check another one. The green highlighting is present for password input field if it matches the requirements. Again, we see the actual result and expected result that still is equal. So we can put here pass two. Password requirements lens is equal starting from six up to ten characters. So we have the lens 6-10 characters. If the inputted password is starting 6-10 characters, then we have the green highlighting. We see our actual result and expected result and everything is okay. Okay, now we see that the login button becomes active, is inputted in for in both input fields, match the requirements. And we are checking that we can enter the proper email and proper password into our input fields, and it works as intended. But in our case, we see that actual result is not equal to expected result. That's why we can put here fail because we expect that the login button becomes active, but the login button doesn't become active. Email that's inputted in email field doesn't match the requirements. Okay. Still, we can compare our expected result and actual and see that it's not equal. So we can put here, fail. Inputted password doesn't match the requirements. So we're checking if this password is longer or shorter, does not match, does not match. So we are checking if our inputted password is longer or shorter than it is expected. So we still compare our expected result and actual result and see that green highlighting is present in option where it should not. So we can put heat here fail. Login button stays inactive if email and password fields are empty. Comparing and pass. And let's move to our destructive test cases. The most interesting part one slend user step login button at the same time. Application crashed, no issues at present. We see that we have the real big problem here. Login button was tapped 100 times in a row for 10 seconds. Comparing equal pass. Inputed password lens equals 10,000 characters or more. Still, we can modify, by the way, our actual results because I don't answer the question to just compare both results. If we have no green highlighting is present and login button stays inactive, we have the results that we have only 32 characters that are available and let it be Wait, now. Let's not modify and we will have the interesting status for it. Here, we can see, Okay, but why we're putting this status? Because we can check on the certitu characters that are available to enter into the password field. By the way, we can still see the result with the certitude characters, and if the result is the same as expected result, let's just copy it here. So that's why we will put here a pass. If we will have something that works and something that doesn't work, we still can put here a Kp. So that's how it works. That's our document of test case. 23. Checklist. Formatting: The checklist. We already know what the checklist is. Checklist can be a useful tool to ensure that all steps are taken to maintain and improve the quality of the product. It's big detailed list of items or elements, features, or even parts of the application or the game that we should test, and of course, we revise the work as intended and according to the general plan and the GDD. Checklist is something that you would use on your daily basis. Mostly, checklists are detailed, easy to repeat, and well structured to be both visually and meaningfully understandable. In this part, we will create a checklist for such game as CSG, counterstrike Global offensive. Of course, we're not able to check all the game. That's why we have to select only one feature and describe it as detailed as we can. The feature that we would test and describe would be only one weapon is the glock 18. Let's start our practice. Firstly, we need to make a copy or just create additional tab. Let's also select several cells. To create something similar to Heather. And let's name it. Good luck. A, Dan. Check list. Every check list have separate values. But let's use general options in ours. What should it be? It should be, of course, key. That should be summary. Status because we have to understand what exactly we are doing with our checklist item. Bound issues. And comments. Of course, you can add here some additional options like, I don't know, descriptions, or even you would like to make it as you've done before in test cases and add here steps to reproduce, preconditions, and so on. But mostly, you only need these options. And now let's play with it a little to create it more visually appealing. Center. This cell, of course, we can center all of these cells. Make it bolt. That's also. Let's make frame for all of them. Just to understand where is exactly our table is. Of course, we need to separate the name, and we can also late Yeah. Like this. And the bottom border. Well, it looks better right now. Of course, we can play with color formatting, like just to change the background color to green one. Maybe you want to make this blue or something different. Just play as you would like to do it. We have to rename our sheet into checklist. And the first thing that I usually do with a checklist, I usually create a drop down list of elements for statuses. First status that we need these to do fail pass you also could add something like in progress. But usually, I don't use the status because it's quite complicated. They're always selecting progress when you're working with separate element and you have to change your status multiple times. It's just much easier when you have only three or four statuses for example, okay, but when something is words but not as intended and never using progress because it's really complicated. Let's select the colors. And we have to select all of our cells and fix the formating. And again, for better visual understanding, I'd like to resize this rows, not into 21, but into 30 pixels. That's it. We created our check list. Now we have to fill it with a lot of different elements. The first one is key. Key is usually the unique identifier of the element that you would test. Mostly, you will have the key that will be related to your projects that you are working with. But in our case, we could just use numbers. We'll fix this later because we will need to modify it a lot of times. Let's center it. A make it not so white. Okay. Now, let's proceed to our game. 24. Checklist. Creation of basic checklist: In our case, it would be much better to split our checklist into separate sections with separate topics. For example, general shooting, interaction, animation, I don't know, fix, asfix or sound and music. UI HT. Of course, we should cover shop and magnetization. Uh, I know you can have the different attitude to monetization, but still the things that allows us to earn money, and we also have to check if monetization works as intended. Now, let's wait till the round will finish and we'll start our check counterterrorist win. The first thing that I would like to check is the general information about the weapon. We can see that the weapon is present. We can shoot, we can reload, we can switch into different modes. We can drop the weapon, we can pick it up. We see some changes in UI. Also, we can freely but if we don't have it. What's more, we can see the bullet counter. If we will shoot all the bullets, we will have the automatic reload. We can overview the weapon. We can switch the weapon to another one. Of course, we can deal some damage with weapon, but to check it, we need to spa on some bots. We see the texture. We see how it looks. We see some minor scratches. It's material and so on. Of course, we can see the wear fix. When you're shooting, you see the fire. We see how bullet flies away. Also, we can see the UI of it again. How it changed when we drop the weapon, and we pick it up when it's active or inactive. I believe now we can proceed to our checklist, split it in different parts, and of course, check it. Let's go and write down all the check list elements or check list items. Yeah. Now we are on our check list. First, what we need to do is to create a section. We can merge the cells and call this section somehow, just to make the better management and organization of the checklist. So in future, we will be able to use it and not be lost during our checks. Let's call this part general. It would be something like general information about the feature. Of course, we can paint it in some colors just to make it visibly more appealing. And let's start with something like Glock 18 is present and fully functional on the build. Why create such type of the checklist item? Because if something would not be covered with our unique checklist items, it for sure would be covered by this one because we would be able to put here some found issues that would be not related to other elements, but still would be related to the Glock 18. Yeah. Let's continue with the general information. Glock 18 is a secondary weapon. That means that we can carry it in secondary slot and we also could carry additional weapon while we have the Glock 18. Glock 18 is a default weapon. For terrorists. I mean not real life terrorists, but in game, just the team. So let's call it terrorist team. And make it like this to avoid some misunderstanding. Glock 18 is displayed in right or left hand. Was the character. Right left because according to different settings, it could be displayed in right or the left hand. Glock 18 is present and available to buy in the shop. Still some general info because usually at the beginning of the round, we need to buy some weapons or grenades, head armor or body armor. And according to this, I believe this would be a general information. And also, let's write down additional general checklist item. It should be something like, let's make it according to our base station because why not? We love 18 Price is 10,000 bucks in in game Shop. Because I didn't know the price in real life, and it's better not to right here the price in real life. Looks like we finished our general part of this check list. Let's create additional one. Again, merge. We can just make a copy of this cell, just not to format it too much time let's proceed to the main part of this feature is shooting. We would describe shooting chess in more detailed way because it's the main feature of the weapon. So let's proceed. Player is able to shoot with glock 18 by pressing LMB. I mean, left mouse button. Player is able to change shooting mode of the weapon by pressing RMB. Two shooting modes are available and functional for the lock 18. And let's also describe which modes single burst. According to the fact that it's the main feature of the game. Let's write more discases about it. And I believe it would be good to write some discases related to bullets in the clip and the bullets in the stock. Block 18 has 20 bullets in the clip. Not the eclipse. LsonGok 18 has 120. Bullets. In a stock. Sorry, I maybe don't know, like, the real names of some parts of the VPN. I just know bullets and clips. That's why I write these cases according to that information. Um, I believe we could move it a little bit and write some disk cases, some check list items related to shooting molds. Layer. Shoot with one bullet in a time by pressing LMB in single mode. Also, we could create the same test case but for burst mode. And it would be one bullet, not one bullet, but three bullets. Et's proceed also with the reload reload is also important part of the shooting. Mm player is able to reload weapon by pressing if I'm not mistaken, the R Um, let's add some additional details. Aable to reload weapon with not full clip. We are not able to reload when we have 20 bullets in the clip. We can reload the Vapon if we have 19 or less. Also, there is a feature like Auto reloading, which applies to the weapon after you shoot all the bullets from the clip. Auto. Reload is ali I player shoots all bullets from the clip. Also, we can describe which number of the bullets we have exactly and how do they change according to our reloading. Number of available bullets in Oh, Clock. Number of available bullets in a clip and stock is saved and updated. After Reload. I believe that's all. We could copy this cheap list item, copy it here, and also we could describe the behavior not during the reload, but also during the web and switch. After weapon switch. Have to resize it. I believe that's okay. Um, let's also proceed with the damage. Of course, we can see right now the damage in the build. But I believe we can assume which damage it should deal. For example, by shooting in body or shooting in hand, or shooting it in head or in leg. But let's just take two options like the head and the body. The lock, 18 deals. Let it be 21 25 damage. Per shot. While shooting in my body. Also, we can clips. We can copy. Same check list item, change it to heads, and assume which damage should it deal in a head. Let it be 70 75 damage per shot. Beer shot looks like beer. I believe that's all related to shooting. We can, of course, write a lot of additional things like how weapon behaves after all bullets are shoot from the stock and the clip, or how we are able to reach the weapon if we throw it on, like, the high place or anything else. Or maybe that weapon can do damage if you just throw it into the weapon. But I believe that's not present in the counter strike. So let's move on. 25. Checklist. Execution: I believe that's always the shooting system. Let's proceed to some additional things. For example, we can describe something like let it be interaction. For that, we should add row above, of course, merge all cells. We also are able to copy the cell into this one. Again, avoid formatting and type interaction. What could we do with our interaction? We could overview the glock 18. We also are able to switch the weapon, select it, drop the weapon and, for example, pick it up. So let's describe it here also. Layer is able to overview Glock 18 by pressing F. Layer. Layer is able to switch the vivan to primary by pressing one. Let's copy this one and create additional. By pressing three, we are able to switch the weapon not to primary, but milli. Also, we're able to switch the weapon by pressing Q to the previous weapon that we were using. So let's describe it also. Like player is able to switch. Oh, switch the weapon to previous by pressing Q. Also, after we switch the weapon, we are able to switch it again to our Glock 18. So let's describe it like layer is able to select 18 by pressing two. What exactly could we do with it? We could drop it and pick it up. Let's describe it also. Layer is able to drop the Vpon by pressing G. And of course, we're able to pick it up by pressing E or reaching the pon. But we will describe it in separate checklist items. Able to pick it up, pick the weapon up. By pressing E, or we are able to pick it up by reaching it, but not by default reaching it because if we have a secondary slot that is used for additional secondary pon, we will not be able to pick it up. That's why we need to empty our secondary slot and describe it here. By reaching it with empty secondary slot. Secondary pon slot. I believe it's always the main interaction with the Gloceighteen. Of course, in any section, you can describe a lot of different information that not the list of all available items. You could additionally write a lot of items by yourself, everything that comes to your mind. Let's merge and proceed to next section. Let it be animation. Animation is a really good thing to check because we need to test if it works as intended, if it's not stretched somewhere, if it's not flicker somewhere, if it's not jittering or anything else. That's why we should describe, most of the available animation. Better, of course, to describe all the available animation, but in our course, we would describe only main animations. And of course, that's the vibon that means that it should have the shooting animation. Glock 18 shooting animation is present. Is present and fully implemented. By this item, we just cover that it's not only present, but it also works as intended. And of course, we need to describe how we could activate this animation. Shoot Animation is played after user presses, if I'm not mistaken, LMB. We could copy both of these elements and modify them. Let it be not only shooting animation but reload reloading animation. Let's also EdsorRloding, animation is played after user presses R. Also, we have the overview animation. Over. We should press F to overview the VPN. That means that we need to modify this a little bit. O view. And what also we have is dropping the weapon and switching the weapon to Glock 18. So let it be weapon drop animation. Oh Drop animation is present and, of course, fully implemented. When it plays by pressing G. So we would copy this element into this cell, copy Vp and drop and change the overview into Vp and drop, and we have additional checklist item. Vp and drop animation is played after user presses F. Again, copying these two elements into new ones and modifying them. Not only dropping, but therebon pick up. Animation is present. But in our case, in this game, we don't have the pickup animation. It just disappears from the ground and appears in our hands. We have the animation when it appears in our hand, like we are taking it out from our belt or I don't know, somewhere in this area. So we still could call it pick it up. But I have just to describe that it's not actually the pickup animation. So the weapon pickup animation is present and fully implemented. Also, the weapon pickup animation is played After user presses, E, and also its plate after user reaches it with secondary Vponempty slot. When user reaches it with empty secondary Vp and slot. And let's also describe the switching. Switching between different animations. Still, is the same animation as we pick it up, but we have to describe that in this case, we also have the animation. So switching pan to Block 18 animation is present and fullly implemented. And we have to describe when we see this animation. So we are copying, pasting. Um I believe even better to copy this. So which pm animation is played up to user presses. Q. One or three. Of course, we could describe also some additional elements like switching weapon exactly to glocatin or throwing it into another character and how Reg Dal applies and so on. But I believe we could stop on this. Let's proceed to additional or another section, and we should merge this cell again, copying, pasting ando colo it somehow. Let it be a fix. Oh. Sorry. We are. Let's also understand what we affix do we have? We have the fire re affix when we are shooting in a single mode. We have the fire affix that is different when we are shooting with weapon in burst mode. We also have the animation another animation affix of bullet shell fly when we're shooting. Let's describe three these affixes. Fire affix. Is present for single mode shooting. And again, we could describe it also as we describe the animation that's present and fully implemented. It would be much better and writes something like that affix is present after user presses exact button. So we could copy this one here and of course, modify it because it's not di shooting animation is fire, afix You could just copy it and change single mode into the burst mode. And also, let's describe how we can see that after the single shot, we see how the bullets fly from this gun. Like it flies away. Bullet shall fly. We F X is present. Again this cups lock is present and fully implemented. That's it. And of course, we have to describe when exactly it happens. We will change fire into the bullet. Shall and of course, it's played after we press the left mouse button after the single shot. We could also describe much more additional wayfix like the bullet trace wafix or the smoke wafix that comes out from your gun if you shoot all the clip. But I believe we could stop on this just to understand the concept of it. Let's proceed to next section, and it would be a affix. As affix, or for better understanding, we could call it sound or sound in music. But mostly in your daily work, you would use Aafix. This is why we will leave it like this to the Aafix. Let's understand which affixes we have. We have shooting a affix, single mode shooting, burst mode shooting, mode change Sex, reloading Suffix overview while you're holding this weapon and turning it around, of course, it makes some sound. Drop a affix, and, for example, pick up a suffix. Let's describe all of them. Glock 18 single shut the cups lock. Glock 18 single. Shut fix is present and describe when it's present. Shut SFX is played after user press LMB. Also we have the burst mode. Let's describe it also because it's different as a fix. During the burst mode, you can hear like three bullets are shut in row. Glock 18 burst mode is suffix is present, and shot suffix is played after user presses LM B. Next thing is the shooting mode change. Glock 18, shooting mode, change a fix is present and fully implemented. We forgot to add this part of the phrase that is fully implemented because we want to avoid all problems that we have according to not being perfect of the sound. Let's copy text from this cell into this change L&B to RMB and burst shot into shooting mode change. Next would be reload. Block 18, relot as a fix is present and fully implemented. Let's copy not to waste time. Real SFX is played after user presses R. Also, let's describe the weapon overview. Glocating view SFX is present and fully implemented. Overview as a fix is played. After user press a switch button, F. And two things that we are leaving here is the drop and pickup. So let's describe them also. Glocatin drop. Suffix is present and fully implemented and pick up as affix. Up drop. Affix is plate after user press G and pick is plate after user precess E. Or reach it with empty secondary slot. Let's also make some changes here just to leave this visible. What's next? Next, our sections that we would describe. That would be Ui and hot. User interface or heads up display. What we know about the hot in the counterstrike, that's related to the swepon. We know that glocatin has the icon that is present somewhere in the bottom right corner of your monitor. We know that it's highlighted when player selects it as active weapon. We know that under this icon, we have the name of the weapon. We also know that if we drop this we upon icon and its name disappears. Also, we know when we are picking up this weapon, this icon is blinking. And also, what's the maybe main part of this part of it or hot is the bullet counter. We also have to describe behavior of it. So let's start. Glocatine is present. Glocatin icon is present in the butt right corner of users Hot Block 18 icon. Let's describe first the name. Weapon. Name, display. Displayed below the weapon icon. Also we know when we're selecting it, it's highlighted. Glock 18 is highlighted. If layer selects it as active weapon. If we drop it, the icon disappears. So the lock 18 icon is not displayed. After user drops this weapon. Also, we know that this icon appears if you pick it up, so Glock 18 icon appears in users. After user picks it up. Pick it up. Also, we know that it starts blinking if we are picking up the weapon. So we could just copy it and change what appears into blinks several times in user's hut after user picks it up. What we also need to describe is the bullet counter. Bullet counter is displayed in user's Hot bullet counter is reduced according to shut bullets. That would be reducing and also we would add additional word updating. It would be much better with slash. It looks visually understandable. Also, we know that bullet counter is displayed in red color if we have less than five bullets in a clip. Let's also write it. Bet counter is displayed in red color. I numbers No, number of available of present of present, bullets in a clip. Are less than five. Also, what we know about our bullet counter is that it displays 20 bullets in a clip after a load. So if we would reload the weapon with 19 bullets, it would be updated to 20. If we would reload it with one bullet, it would also display at 20 afterload. Bullet counter. Displace 20 bullets in a clip. After reload. After reloading No, after just reload, yeah. Again, you could just sit and just imagine what you would be able to adhere and practice on your own. Because being a good QA is always practicing your skills. We have two last sections is the shop in game shop when you are buying the weapons, heat, armor, helmets, or the body armor, some grenades, diffuse kids, and so on. We have to describe behavior of block 18 inside the shop and the monetization. Firstly, let's proceed to the shop. Start with the fact that user is able to buy glocatin in the shop. Glock 18 is present in in game Shop. Let's also check where is glocat displayed. Glock 18 is displayed in pistols. Section. And now we are proceeding to the availability of the Glock 18. So Glock 18 is available to buy in game shop. Maybe it's better to call not the in game shop, but in game by station. We are changing it here also. Et's proceed to the price. So the clock 18 price is $200 and in game by station. After that, we are able to purchase it we know the cost of it, and now after buying it, it should be displayed in our hands. So we are writing something like lock 18 appears in characters. Hence after successful purchase. We know that Glock 18 costs $200. That's why we need also to check if we are available if we are able to buy it when our money amount is less than $200. I Glock 18 is not available to purchase I character has less than $200 maybe it's better to call it I characters amount of money is less than $200. And of course, we need to add that it's available to purchase in game shop. O also, we need to check if the money that our character have I mean, has are reduced after buying glocatin which prices $200. So characters amount of money is reduced by $200 after successful Purchase. Of the lock 18. Well, that's the main part of the shop. Of course, again, you can add whatever you want here, I mean, related to the shop. You can add some UI stuff here or sound. For example, when you are buying it or anything else, you also get good at its here as in UI hot or in sound. It's all your work that you would be able to do after you start your way as a QA specialist in, like company or as a freelancer. So it's like your daily work when you're creating such checklists. And let's proceed to the last but not the least the monetization. We know that Conda strike two has system like skins and cases, and we need to check if we are able to buy, apply or win some kind of skins or textures or stickers for this weapon. That's why we're calling the last section monetization. And we will write down here couple examples of how exactly we will check the monetization. We don't know exact naming, which was used in development of the skins and textures. That's why we would create a placeholder for them like skin, one skin, two, and so on. So the skin one lock 18 is present and fully visible for user. This case is like general because if something is wrong with the skin one, we are able to link here some found issues. Right here, some comments that Hello, look, something is really wrong here. Now, skin one for Glock 18 is available to buy a marketplace. Because you are proceeding to marketplace in steam and you are trying to buy it and to apply it, of course, that's our next case that this skin is available to apply on the pan. Skin one is available to apply for the Glock 18. We're not only able to buy it. We're available to win it, and we're available to win it in case and in game. I don't think that we are able to check how often it would be possible to win this skin or locating in case or after the game, but we're able to check if the skin is present in exact case. So skin one is available to win in the case. Will it be also placeholder case one, I don't know exact names. If if I remember correctly, it was like bravo or like secretoperation. So something related to counter strike. But in our case, let's leave it as a placeholder. Skin one is available to win in the case one after opening it. The most interesting part that you would check a lot of skins. So you can just copy, paste as much time as you need them, and just change the name of the skin. Skin two, skin three, skin four, and so on and so on. We are also able to change the name of cases, but we're not testing cases right now. We're testing skins. Of course, you could be able to check if the price is correct. Is it able to apply for the weapon? Is it how often you would be able to win it through the case, or maybe how often you could win it after the game, or even if it's able to be gifted to someone else. Everything is just related to a your work and the part of this feature that you would take care of. I believe that's all related to check list. The checklist, as you see, is a really big document with a lot of different items that you usually write down by yourself and have to pass it or fail it. According to the situation in game, you have to compare it also to your GDD or to design or even to the words of your developers. Of course, don't forget to leave some comments if something wrong, for example, in our case, lock 18 is default weapon for terrorist team. We put it here, fail and comment like, it's default for both. Maybe it was the mistake in producing this feature. Don't forget also to put found issues. If you put a command here that is default for both, please report it as a bug, provide it here. Bag one. Of course, usually you would do it as a link. You will paste the link. And by pressing in the cell, developer will be able just to see what exactly is related to and what is the problem with this exact case. 26. Bug report. Creation: The next topic of our practice is the bug report. Bug report, we already know some information about it. It's just a short, not really short, but still it's quite complex summary with descriptions, with attachments of the issues that you have found during the game. To make our bug reports, usually all QA testers use Jira and we already know something about Jira. I already created the test board in Jira. We will have the quick overview of it, of course. But right now, we have the main goal is to create some bugs. As our default game that we will test, I selected the Marvels Adventures. Pretty interesting game specifics. Now, I just let it because it had a lot of problems. And one of the most easiest problems to reproduce is the problem with camera. If I'm using the Dual Sha controller, I'm able just to press touch pods. Do proceed to character menu. But if I will hold the touch spot, my camera will be slowly moving backward. And I'm not able to reset the camera to default. So sometimes when you will fight in this game or run or do anything else, you will see something similar to this. Like I'm playing diablo or something similar. We can report this at the bug. Okay. So the first that we should do is proceed to our Jira and, of course, tap the button create. We can go full screen just to make everything visible. The first thing that we need to do is select our issue type. We have several issues types like epic bug task or story for our task, we have a select bug because we are reporting some problems. Summary. Summary is one of the most important fields because by summary, you will usually search for all issues that you reported, search it in Jira search or just understand what is this issue about. And for better understanding, I usually prefer use text. Tech is just short, something like label, which will help you to understand what is this issue about. As we have seen before, we had the problem with camera, so I can use tech three C. T C, which means character, control, and camera. And it affects our gameplay, so definitely we can use gameplay. There are no specific texts. You can just select a bunch of them for your project. It just depends on the type of the project and common game areas that you usually test. So it's just for your better understanding and for developers better understanding. And we have to write our summary, something like pressing. Touch President Holding. Touch spot. Undual shock. Come troller. Moves camera backward. Which shouldn't be existed in this game. I hope so. I have no documentation, so I cannot compare it to the documentation. Usually, you have just to play the game, compare it to your documentation, and understand what exactly going wrong. Sorry, I don't have the documentation for Marvel Savengers because I'm not a part of Squanx. That's why I can just believe that it's a bug and not the feature. The next field that we have to fill in is the description. Description is quite similar to summary, but still needs more details. You have to explain, describe this problem just to allow the understand what is this problem exactly about and have some different additional details. The first thing that we should do is write something like a short text about what exactly is wrong with this problem. In this game. Let's write something like I user press and hold the touch pad on the shock controller, camera moves backward. Just oh, I have a typo which part. Just to avoid repetitive sentences, I can give some additional details why I think that this issue is really a problem. And usually I write something like lease note. User has no option. To set camera. Engle. Angel. Angle. And Mm just to set camera angle to default. I again explain that it's a problem because user cannot reset to default his camera view, it would confuse some not pleasant experience for the player. Usually after that, I write something like four additional information. Please check the attachments. Why this writing four again a typo. In four Mission. Why I'm writing this just because it is just something like in letters like dear Gregory or sincerely or faithfully and so on, it's just a sentence to move to other parts of your bug report. Our next part, we still write it in our description field is steps to reproduce. And the first steps that we should do boot the title on the build. Because the first things that we need to do is just lounge the game or we can just make something like lounge. The build let it have name, the build version 3.123, one, two, three, four, five, six, I don't know. Let it be like this. Because if you're working with some project, you will have some different build numbers and you have somehow specify which build exactly the developer needs to launch just to reproduce your issue. The second thing, start mission. I didn't know what was this mission exactly, so I can just name it like start Mission 01. Let it be the first mission that we observe when we launch the game. If I'm not mistaken, we are able to select the hero before starting any mission. So select any hero. For example, let it be Iron Man. Or just to make it similar to our video. Let it be winter Winter Soldier. Okay. The next hour step after we specified what we exactly need to do before we launch the mission. We have to connect or maybe not. Let it be tap and not even tap. Press and hold. Dual shock controllers. Touch pod. If we are mentioning the Dolsa controller Tapat, it means that we already connected the Dolsha controller or we are using PS four build. So that's why we need to do some preconditions. Have your dual your just dual shock. Controller connected. Again, we specified that we need connected controller just to reproduce this issue because if you're using mouse and keyboard, you won't be able to do this. Next, we have to feel our expected result. Of course, our actual result. Again, we have a part of imagination in our bug report because we don't have the design documents, so we cannot compare it somehow to the actual documentation. That's why we usually, can write something that it's not according to design that we have such option or just paste the link from the design document to allow developers compare it to the design. But for now, we don't have it, so we will just imagine that we have it and it contradicts our design document. So no camera movement is present, ter, tap, sorry pressing and holding dual shocks touchpad. Let it be according to the design Document. Usually, you can create a link you type the name of this link is design document and paste on the link just a specific sentence, specific section of your design documents, still to make it more visible for your developers. Just not to let them waste time for finding everything and spend more time for fixing this issue. Actual results. What usually I do is just copy our expected result and modify it a little bit. We don't need according to design document, and we can just delete no and start with the uppercase over sentence. So the camera movement, that will be there. Camera movement is present after president holding dual shock touchpot Dual shocka lot of typos The next thing that we should specify is the technical reproducibility. It means how often you can reproduce it, how easy it is to reproduce. Usually for technical reproducibility, you use something out of something like one out of ten, two out of ten, five out of five, and so on. What exactly it means? It means that out of five tries, you were able to reproduce this issue five times, for example. It's the five out of five reproducibility. If you were able to reproduce it only once for ten attempts, your reproducibility is one out of ten. Pretty similar. In our situation, our reproducibility is 100%, it means that we launches the build five times, launches mission 15 times and press and hold DL shock touch pad five times in a row and we have 100% reproducibility. Let's fill it in also. Technical rep usability. Five out of five. Also, usually you will have some custom fields like severity or something else. In our case, we don't have severity as additional field to fill it in. We will mention severity here. Severity. This issue does not crash our build or freeze it, so it's not the critical. It's not major because still all most common and important gameplay features are in working state. Still, it's not lowest because it's like you two candidates, so you will be able almost to play Diablo or I don't know, any other 2.5 games in Marvel's Adventures. I believe that this verity is Medium. Why medium because still it affects game play, not so much, but it caused some negative experience for our players. Then AIE field, ANE field is the field that you have to select to mention who will take care of this problem. Usually, I assign it to me at first. Why? Because I usually modify this issue after I created it because maybe I like better summary, maybe I have some more details in descriptions. Maybe I want to change some attachments and so on. We have to select label. Right now, we have no labels that would fit to our problem. So let's create several. Let it be bug. Because why not? We can create this label, again, to have some specifications that it's the bug, not the feature. Let it be three C. Again, as I mentioned before, it's something similar to our text in summary and let it be controls. Next thing we have to do is select our sprint. So the sprint is like the time usually starting from one to up to four weeks that you are working with your development team just to deliver something similar to working build to your stakeholder. Right now we have our active sprint is theta print one, we are selecting it reporter is always you because you reported this issue, attachments attachments we will have the video recording or some screenshots or pictures or even logs or something else that we will attach to our bug just a little bit lately because I have to crop the video and to add this problem. And linked issues. You have two fields here. Sometimes it shows how this issue relates to other tasks or bugs or problems or epics or so on. Usually, I select blocks if it blocks something or maybe relates to if this issue relates to another issue. But in our case, it's just blocks. That's optional field because we can somehow assign it to other open issues or link it to some related box that I explained before. The last thing that we have to do is top create. And right now we have our first created bug. We can press it, have a quick overview of it. And of course, I will upload some attachments into this bug. Okay, I made a print screen of our issue. I put it into paint, cropped it a little bit. Now I have to save it. Usually, you name the file like the name of your bug that you reported. You have just to save it. We of course, like the format Japeq PNG is quite more complicated and it has bigger size than Japeq. So right now, I can just add fresh created attachment into this bug. Be just a screenshot because you already have seen the video and exactly, I don't want to crop it right now because I still need to make some recordings. Here, we can definitely see that camera moves away too far. Of course, we can modify this attachment and somehow put here a red square or red frame to show where our character, and also we can write something on the screenshot, just to again, make it more visible for our developers to understand what exactly this issue about. In every field in every section, you need to help your developer understand what exactly the problem is. 27. Bug report. Second example: The next game in our practice is the cyberpunk 2077. We all know this game as a game that was released with a bunch of problems, with a bunch of issues, so it would be really easy to find something right here. Let's have a quick overview. It's the prologue of the street kids. So I believe we can find some box with lots yeah, here it is. So as you can see, if we are trying to zoom in, we see more details on this vehicle. If we're trying to zoom out, we see less details. Is the issue with lots. Let's also create the bug about it. And of course, don't forget to make a screen recording. Okay, let's create our bug report, the second one. And again, we have to tap the Create button. The first thing that we should do, again, is select the issue type. In our case, it's bug. No epic or task or story, it's just a bug. Second one, we have to select the status. Status is to do by the default and we still need it. So we're leaving it like it is. And let's proceed to summary. The first thing that we are doing is creating some texts. Let it be ST prologue. Why S T prologue, I just make it shorter. Is the prologue of sweet kit in the cyberpunk 2077. That's why I'm editing it. Specify what exactly is this issue about and it's about lots. We're just typing lot here. And let's create a summary. And our summary would be something like level of details. Transis No, C. Shan is visible for layer. And let's specify where exactly it was. For object. Let's name this object like car 01 in and of course, the mission, Rag. I'm typing here on the prologue because I exactly I earlier specified that it was a street kit prologue. Let's proceed to our description, what we're starting with is detailed information of this issue. Description. While playing the SD prologue while playing the street kit prologue, user observes level of details transition after Zoom in O because we were zooming in and out. Object car 01. Yeah, that's our detailed description. So we specified where exactly it was, what exactly the problem is with what object during what while doing what? And of course, our catch phrase is for additional information. Please check the attachments. I definitely sure that you'll be tired of this phrase, but still we need to add it because it's just a general transition between the description and other key points of bug report. Now let's proceed to steps. Excuse. Yeah, here it is. Let's start with our default first step to reproduce this issue, we have to launch the game. So put the title on the build. Of course, you will have something like a build number, and it should be like version 3,897.76 54f0. Let it be like this. It's just the random numbers, but your build number could definitely look like this with adding a lot of different symbols with the underscore and so on. In our case, we don't have the build number, so we are just typing the title on the build. Next step that we should specify is which mission should we launch. We exactly specified it in summary, in description, so we're just copying it and typing something like launch mission ST prologue. In our case, we have to reach the parking. So we're typing reach. The parking where Object, car zero, one is placed. Specified what the parking is. Reach. Now, reach my good. Reach. SurgerF try. What should we do next? We should specify that we have to reach this object. Reach Object car 01 on the parking. Another step. What should we do next? I believe the lots are dependent on distance. So we have in our case, just imagine what distance is. Let it be, I don't know, by the video is something around 10 meters. So we could describe it here. Have a distance between u character and object. Car zero, one, 10 meters. The last thing that we have to do is just to zoom in and zoom out. To zoom in and zoom out, we have to press right mouse button and release right mouse button. So we have to describe it here. Press release RMB, like right mouse button. To Zoom in Zoom out. And we have a mistake here. Because we skipped one really important step. If you will follow all the steps, you're launching the game, you're launching the mission, you're reaching the parking, you're reaching the car. You have the distance between a car and the character. But one option is still a problem. We didn't point our camera to this car. We also have specified here. Why we need it so detailed Because to deliver the perfect bug report to the developer, you should describe it and imagine like developer is the 5-years-old kid. No offensive to developers, is the practice. Because if you detail, if you are detailing your bug report in all necessary key points, and you have a lot of information here. It would be much easier to found your bag and don't waste time for reproducing it and they will just easily found where the problem is and we use this time for fixing. Let's specify here also. Pen camera to car 01. Okay. Next thing we have to mention is our expected result and actual result. Expected result. Our expected result is that lot transition is not visible for user. It should be never visible for user because it break in some immersive experience of the game. So we could write something like lot transition is not visible for user. To make it more clear, I usually add some links from GDD or your game design document or even some other references. It could be, I don't know, photoshop screen, Figma screen, any other documents, your acceptance, checklist, and so on. In our case, we don't have it, but we can make a placeholder for the link just to see how would it look like? Let it be the link to this board. We will not use it still so we can just add random link here, and we can also select how our link will be displayed. We are typing here like Cyberpunk 2077, GDD. So we have our reference, and of course, don't forget not only to add your link, but also to make it more clear for reading. Load transition is not visible for user cording to cyberpunk GDD. Let's proceed to our actual results. Our actual result is that it's still visible. So we're mentioned it in here. Lot transition is visible for user. We don't need to add the link here because we are writing what we see and not what should it look like. Let's also write down our severity because why not? We could think which severity should we select. I definitely not critical because it's not breaking our game and not major As still not medium because I don't believe that this issue would be noticed by a lot of users. We could just select minor. It's still visible, but not for a big amount of players. In different companies, you will see different types of severities. Someone is using critical major, medium, minor and so on. Someone could use five types of severities. Someone could use three types of severity. Someone could use, apart from critical medium, and so on. They just use severity one, severity two, severity three, and so on. So if you know the general severity, how it is written by default, you will easily recognize and understand how your severity will be written in the companies that you will work. The last thing we have to mention is our technical reproducibility. Technical reproducibility. It is here. Let's imagine we launched our build five times. We launched our mission five times. We have seen and observed this issue five times. So we definitely know that our technical reproducibility is 100%. So we can write down here like five out of five. Assignee, again, assign to us. Why to us because you could still add some details to your tasks and so on, and only when you will send this issue to your developer or game designer, you would change the assignee to the responsible person. I don't mean that you are not responsible person, but still to the person that would fix your problem. Labels. Let's create some labels like lot. And let it be ST Prologue. Still labels are quite similar to our tags. With our text, we could definitely see the labels that we are using right in summary and for me, it's much easier to orient my tags. But still, labels are usually pretty similar. Sprint, select our active sprint or maybe you will be told to select another sprint or even back log if this issue is not critical enough for this stage of development. Reporter, was you because you reported this problem and attachments. On the background, I just created the perfect attachment and we are just editing it here, and of course, I will show you. Let's create the problem. I mean, the bug report. Here's our attachment. I pointed where exactly the problems are so we could see the transition between details in these zones. 28. Bug Report. Crash report: Our last candidate for our bug reports is the Data Zoom. It's our cord game. I definitely know that if you're launching the game and you see the loading screen and you're trying to press your left mouse button a lot of times in a row, your game could crash. So let's observe it. We're launching the game Now, loading screen, tap in a lot of time. Crash. Let's create additional issue, our last one bug report. Again tap in the create bottom. And what should we do to select our issue type, our status, and proceed to summary. Summary. Let it be Lounge. Lounge Lounge. Build Gresh. Of tapping. And B for big amount. Not like this for many. Let's specify it also for 30 times during loading, screen, is displayed, I believe. Bold crash after tapping left Mouse button for 30 times during a lot screen display. I don't like this word. Let's change it to something different. During loading screen, displayed. Again, the same. Um, it'll be while loading. Screen is displayed. Okay, it looks better. Tapping 30, 50 times in a row. Um while loading. Screen is displayed typo. Display. It let's change it a little. Built is crashed after user taps 30 50 times in a row while loading screen is displayed. Again, type. Sorry, you keyboard, hard to type. Our case as for additional information, please check the attachments. Steps to reproduce. What should we do? But the title under Build, don't forget about your build version right here. You will definitely need to add it. In our case, we don't need it because we don't have the build version. Top LMB, like leftmost bottom, 30 times 30 or more times while latin screen is displayed. And that's all. Next thing we should have to specify is expected. Result I don't believe that we need something like link to our game design document because, well, every game shouldn't have any crash. This why we're typing here. Crash is present like this aftertten LNB While screen is displayed. Oh, it's expected. I'm sorry. Rash is not present. And actual result. Result. Let's just copy it. I just got from here, only one word. Crash is present. Let's specify our severity also. Severity. Critical. And also technical RduceB cups. Five out of five. What I forget to mention in our summary is crash. Still, signing it here, forgot to make the text bolt. Labels, crash. Sprint. Let's select active sprint and attachment. I will edit a little bit later. Create Okay, now I have only just to add my attachment. I'll do it right now. And it's almost all. Okay, behind the camera, I created the attachment, and we have to upload it here. Attach. Here it is. That's our attachment. The bill was crashed. And I believe that's all. We have reported three different types of bugs, learned how to do it. I believe it was the really important experience. The next thing that you should do, please try launch your favorite games, try to find some problems in it, and try to report it like we learned some time ago. 29. The end: Thank you for participating in this interesting, I believe, course. Good luck in receiving your first job and of course, becoming a great specialist in the game development industry. See you soon.