From Tester to QA Lead: Game Testing, Jira & QA Mastery

1. Introduction: He llo everyone, and welcome to the course becoming a Q Elite skills and strategies. This course is designed to help you to get a solid understanding of what it means to be a Q elite. I used all my previous experience to put other main points into this course. Let's do a quick runo through the main key takeaways for aspiring Q Elite. First of all, you need to develop technical skills to stay proficient in testing tools and methodologies to ensure quality. Then you enhance leadership abilities, cultivate soft skills to effectively manage and inspire teams. Then, of course, you need to foster collaboration, build strong relationships across departments for better outcomes. And, of course, you need to commit to continuous improvement, embracing a mindset of learning and adaptation for growth. In this course, we're going to cover career growth and development as a Q elite, where to start and what to do to get to this position. We cover such things as mentorship, networking, and continuous learning. Another important topic of the course is project preparation, which is very important for every Q Elite. We will start with understanding game requirements and specifications, creating VBS structure, estimation techniques will be covered, planning and timeline management, and also creating test plans and strategies. Then we'll move to documentation preparation. We need to have a full understanding of documentation needs on the project, creating test case templates, designing checklist, defining severity and priority, and also set some reporting standards. A big part of every QLs work is Jira and its setup. We'll work on bug report template, on the filters, and on the dashboards. These are the main elements of efficient management. And, of course, we will cover main test leads activities during testing process, such as passing milestones, testing environments, bacterias process, prioritization, and testing activities. And of course, we need to cover risk management. We need to learn how to identify project risks, analyze product risks, develop mitigation strategies, continuous risk monitoring, and stakeholder communication. And of course, in this course, we're addressing common obstacles faced by QALts in dynamic environments, such as resource constraints, changing requirements, and team dynamics. If everything that was said previously is not enough, here's additional list of things that we'll be looking at, such as overseeing quality assurance process, development test plans, coordinating with development team, and ensuring compliance with standards. Also, we will take a look at what is needed to become a key elite, such as strong analytical skills, excellent communication skills, leadership capabilities, and attention to details. And besides that, we'll be discussing gaining leadership experience, enhancing technical skills, understanding project management, and building team collaboration. This course is a mix of theory and practice. On my example, I will be showing how to take a project and organize all the processes as a QA lead. So if you're ready to elevate your career in QA, this course is for you. 2. QA Lead Responsibilities: Welcome to our first part of the course on becoming a Q Elite. In this chapter, we'll try to understand what it means to be a Q Elite in game development. This is just a brief overview. More details will be shared throughout the course. Our agenda is next responsibilities of a Q Elite, skills and qualities required and transitioning from a QA tester to a QED. There are five main pillars of responsibilities team management, test planning, quality assurance, communication, and issue tracking. As a QA lead, one of your primary responsibilities is team management. You will be leading and mentoring your QA team members, assigning tasks, setting goals, and providing feedback. Creating a cohesive and motivated team is essential for achieving our quality objectives. Let's move to test planning. It consists of three main parts, objectives, scope, and resources. For objectives, you need to understand what exactly is expected from you and your team and what exactly you'll be testing. To read this, you need to create test plans and strategies. In terms of scope as a key elite, you need to fully understand the content of the game or the project and all the aspect that needs to be tested. For this, you need to define testing objectives, scope, and priorities. The next one is resources. Based on how much of the testing should be done, based on complexity of the game, you need to find proper amount of resources and allocate them and schedule testing activities for them. Moving to the next one. Quality assurance process. In general, you need to ensure that all processes and deliverables met the defined quality standards and procedures. Then you need to do sorrow quality reviews and Audis to identify areas for enhancements and compliance. Once the reviews are done, you need to implement all the improvements and initiatives to elevate overall product quality. Let's move to the communication part. Communication is very crucial thing for a Q elite. In general, you need to make sure that all the stakeholders are aware of the state of the quality of the game. You need to be able to collaborate with QA team, with developers, and with all the people who are interested in the success of the project. And finally, let's talk about tissue tracking. In general, we can split it into a few parts. First one is bug tracking. This is a process of managing B tracking system and resolution process. The next one is bug prioritization. In general, you need to prioritize bugs and then assign it to property members, either developer, artist, or maybe other stakeholders. The last one is bug resolution. As a key elite, you need to ensure that development team are aware of the bug and fix them, and then KATeam manages to check it and to verify the fix. In general, Kit plays a crucial role in game development. From the beginning of the project, you're the one who is responsible to deliver the best quality product to the end users. That's why you need to be good in team management, test planning, quality assurance, communication, and issue tracking. 3. QA Lead Skills: On to our next chapter. We will explore the skills and qualities required to be an effective Kd. Let's delve into the essential attributes that contribute to success in this role. I have divided the core skills into five main categories, technical skills, leadership skills, communication skills, problem solving, and organizational skills. Let's check one by one. Technical skills are fundamental for a Q elite. They enable efficient and effective testing process. Let's dive a bit deeper. You need to be proficient in testing tools that your team will be using on daily basis. Also in methodologies that you need to use for testing and in technologies that will be used for your project. Then you need to have a good understanding of the software development life cycle and processes for comprehensive testing. You need to know the way how the game is created from the start to the bottom, from beginning to the end. For the programming languages, it is not something that is mandatory or must help. It is something that is good to know and to be able to use to create automated scripts or just to be able to do more deep debug. While being a good qui lead, you need to inspire, motivate, and guide your team members. Then you need to make sure that you have a good decision making, conflict resolution, thinking, and processing, and also, you need to be a visionary leader and you need to drive improvements in the team. We were talking already that communication is one of the responsibilities of a Q elite, but also we need to look at it as a skill that you need to improve because enhancing communication skills leads to improved project success and team cohesion. Clear and strong communication skills are essential for a Q elite to convey project goals, expectations, and feedback effectively, fostering a collaborative team environment. In real life, you always faced with some problems, and when you're a celt, you are responsible for the resolution of them. To be able to resolve different problems, you need to have an aptitude for identifying, analyzing, and resolving issues. Then you sometimes need to be creative in thinking about finding solution, and then you need to have an adaptivity and resilence in navigating challenges. Organizational skills are essential for a q elite. They help to ensure you efficient project management and delivery. Let's check more in detail. First of all, you need to have a capability to manage tasks, resources, and timelines. In simple words, you need to be able to keep track of tasks and assign them to different team members. You need to make sure that you have enough resources, and then you need to make sure that you're doing everything in time. Then you need to have a good prioritization of tasks to be able to cover important things first, and then you need to be able to delegate other responsibilities to different people because as a human being, sometimes you won't be able to cover everything by yourself. Then you need to have an attention to details and adherence to quality standards. This is a general list of skills and qualities required. Throughout the course, we'll go more deeply in each of them and we'll cover it with a practical exercises. 4. Transition to the role: Now, let's explore the journey of transitioning from a QA tester to a QA lite. This process involves advancing from a technical testing role to a leadership position. In this small chapter, we'll do a small overview of transitioning from a QA tester to a QA lead role, and also we'll discuss the career development aspects and advancing to a leadership position. There are a few things that can help you in transition skills development, mentorship and opportunities. First of all, you need to work hard on leadership, communication, and managerial skills to transition from a technical testing role to a leadership position. Also, it is nice to find a mentor, someone who already has a role, who can show you all the things and teach you all the stuff, as well as participating in the leadership development programs. I basically participate in one of them in my company that trained me to become a lead. Try to explore any new challenge and possible responsibilities in the QVL to advance your career. For example, if there's a task that you don't know how to do, try to volunteer and do it. If the company is looking for someone who can take ownership over a new task, maybe it's also your chance to prove yourself. There are three main skills that differ from any other technical skills that are crucial for Q lead position. First of all, it's a leadership and management, then it's project management and organizational skills development, and then it's a communication and interpersonal skills enhancement. While working as QA, you might get a lot of technical skills that you know how to do, how to split task, prioritization, and other things. But this is something that you need to work hard on your own to obtain a QED role. There is one of the ways how to develop all your needed skills is using a mentorship and coaching programs. The mentor helps you at all stages from the preparation to transition during the transition process and then after. If you have a quid in your organization and you like him and like what he does, then try to ask him if he can mentor you and show you all that he knows. Usually, people like this if they are not too busy, they like to mentor other people and they like to share their knowledge with them. Also, I would like to add a few words about leadership development activities and programs. I highly recommend to participate if you have any available inside your company or outside. One day, one wise man told me that the best way to grow is to take on your responsibilities and be in charge of it. And it was one of the best advices I had in my life. So let's see what is here. Volunteering for roles. Is there any open position on the project? Always try to volunteer for it. If there is a task assigned to the group of people, always try to be active and display some different ways to solve it and approach it. Even if you're not sure that your initiative is correct and you're proposing the right way, having more initiatives is better than having none. Don't be scared to take ownership of any tasks or initiative. This is one of the best ways to demonstrate your leadership abilities and also to grow. The next point is building a professional network. To be honest, I didn't pay much attention to this one throughout my entire career, but recently, I started finding it very helpful and useful. First of all, working with other people and other professional and peers can bring you a lot of new expertise and different points of view and solutions to your problems. Also, there's always a lot of different possibilities for you inside different professional organizations and communities, as well as attending conferences, workshops and seminars bring you a lot of new experience and expertise. Either you are a listener or a person who brings some speech because one of the biggest stress for the person is to perform in front of a big audience. Qualit is a person that has a strong communication skills, interpersonal skills, is able to take on responsibilities and is not afraid to make some initiatives. And basically, there is nothing that is not possible to earn. And moving further, I will try to give you as many details on all of these as possible. 5. Project preparation. Requirements: Move to our next chapter, which is called project preparation. We are going to start with understanding requirements and specifications. What are game requirements and basically the requirements in general? There are a specific features, functionalities, and characteristics that the game must have to meet the expectations of the player and stakeholders. Here are a few examples just to better understanding what can be a requirement? It's a list of gameplay mechanics, graphics, audio, multiplayer functionality, and platform compatibility. If you already work a SQ, you're probably already familiar with requirements and what they are needed for. But let's take a look on the big picture. Why do we need the requirements? First of all, to ensure alignment with prior expectations. Requirements guide development process and decisions. And also, having query and listed requirements provides scope grip and project delays. Scope crip is a phenomenon when there are too many uncontrolled changes are done to the project, and it doesn't look what it's supposed to be. There are three main components of game specifications, technical specifications, they define expected platforms, hardware requirements. Then functional specifications is about the functioning of the game, gameplay mechanic features and design specifications. They define the art style, level design, and other. Why it is so important to have a good understanding of requirements. First of all, it ensures project cuarty and direction. As a QA lead, from the start of the project, you have a good vision and understanding what the project should be. Then requirements help to facilitate effective communication among team members. It often happens that developer and QA have different opinion on how the feature should work and having queer and written requirement can help them to solve this mystery. And the last one is that requirements help to identify potential challenges and risks early. For example, you have a multiplayer game and you expect to have 60 concurrent players. You need to plan testing activities in the way at one moment, you need to cover this play session. Usually, all the requirements are shared with the QA team in advance. But from project to project, from company to company, sometimes the requirements are created during the discussions with different eam members with stakeholders or based on some documentation or MVP product. I'm planning to create requirements for a Piu Park. I've chosen Pio park because basically this game covers all needed requirements that we can use throughout the course, but you can choose any other project or game you like and make the practical tasks in parallel. 6. Project preparation. Requirements listing: Take a quick look on the game and see what main mechanics it has. We have local play mode, online play mode, options, exit game, we have in options. Okay, that's some standard options, Pat Config. Okay? Local player mode, we have two, three, four, five, six, seven, eight players for online play mode, we have public. It's to join the public game, is to join friend game, hosts to start your own game, option is to set some settings. Okay, we can set some options here, choose color, choose Max players. Let's see co player, two players. Okay, player one, player two, and we have options world battle, endless. That's I believe some modes. In every world, we have different levels. And each has four sub levels. And basically, we have some puzzles that we need to solve. Okay, we have dos wives and we need to find solutions how to pass it. Okay. It's pretty clear for the start. So let's create some requirements for this game. As I said before, usually the requirements are shared with the QATm by the production, but sometimes you have to create the requirements by your own. Let's create some simple requirements for a Pico park, for example. This is just a Gus document and let's start. Let's create three sections. First one is technical specifications, then functional. Specifications, and the last one is design specifications. Let's start filling one by one for technical specifications. Okay, let's make it. We have, first of all, supported platforms. For platforms, we have Nintendo PC and mobile. Hardware. Requirements. For hardware requirements, let's go with four gigabyte RAM 100 megabyte, free space. Let's market, then moving next. Let's use some platform compatibility for Nintendo, it should be compatible with switch models. For mobile. Let's say IOS, compatible with IS 11 or water and Android 5.0 or Water. PC Windows ten and 11 Makes. Then the next part is input devices. Controllers, keyboard and mouse and for mobile, touch screen. So that's basic technical specifications that we would like to have for our game. Let's mark it all in different colors to have a better visibility. For functional specifications, let's start with gameplay mechanics. For gameplay mechanics, as we've seen in the game, we have puzzle. In gameplay, then put former elements, then increasing difficulty and then team based cooperation. We have also multiplayer functionality. For multiplayer functionality, we have local multiplayer that supports eight players and we have online multiplayer, total also supports eight players. Then features. We're not going to list here all the features. We'll be doing it more in detail in the next chapter about work breakdown structure. Here we'll be just listing some general features about the game. Something like dynamic. Well, design with interactive elements, then puzzles requiring team work to solve the challenging obstacles and hazards and also game modes. For game modes, we have world, but and thus Okay, marking features, then for better visibility. And now let's move to some design specifications. Art style. Let's make it a bit more beautiful. Art style. Pixel, art, gray. Fix, then bright bright and colorful visual aesthetics we design Here we have diverse level layouts. Then we also expect the game to have variety teams and environments, and also we expect it to be intuitive. Then also for design, we need sound design. For this, we need clear audio cues for all elements. But ground music. And also we need some sound for prior actions. Directive sound effects for gameplay elements. Changing some colors. Here are some basic specifications. Usually they are provided by production team. Sometimes they're missing, so you have to create it on your own, and this is a requirement that your game should meet in the end. They seem to be pretty awake at the start, but then we'll be moving to next chapter, work breakdown structure, and we'll be creating some more detailed elements out of this to make sure that we are able to test them. 7. Project preparation. WBS overview: Let's move to the next part and talk about estimation process and techniques in game testing. And we'll start with VBS. In general, VBS is a hierarchical composition of the project scope into smaller, more manageable components, called work packages. In our case, this is the scope of the game that we need to test. VBS organizes and defines the total scope of the project, breaking it down into smaller, more manageable pieces that can be easily understood and assigned to specific teams or individuals for execution. Let's take a look on the sum components of VBS. First of all, it's hierarchy. A VBS is structured hierarchically to break down the project scope into detailed components. Then deliverables. Each level of the VBS represents tangible outcomes that contribute to project completion. Control accounts, higher level elements in the VBS that serve as management control points. Then we're moving to work packages. This is the smallest units of work in the VBS assigned to the team members with defined duration and resssness. We will be looking at this more in detail in the practical part. Another element of VBS is the composition. The composition is the process of breaking down the project scope into smaller, more manageable components. And now let's create VBS for Pia park. Let's dive deeper into the content of the game. So what do we have here? For world mode, we have one, two, three, four, six, 12 different levels. Each of them has four sub levels. Okay, for battle mode. What do we have? We have four different modes. Yes, finish and for endless, we have also four different modes. 8. Project preparation. WBS Creation: Okay, let's start creating our VBS structure. Let's create a new page. We're going to call it VBS. Now let's start. We have Pica Park game. Then we're going to have some different categories. This will be our category. For functionality testing, we are going to have another split. F f for multiplayer testing. Testing and game modes. Let's start with multiplayer testing. What do we have here? We have vocal multiplayer, and we have online. Multi player. For loco multiplayer, we have 28 players, and due to the fact that it's local machine and you're playing from one PC, you don't need to have any type of connection. But for one multiplayer, we do need to mention it that we also have to test ability to play with two to eight players. Then we need to test connection. Gods do it it for now. For connection, we need to make sure we can host game. We can join game, and we can join Friends Game. Then interaction. We need to make sure that in multiplayer game, we are able to interact with other people and there is no wax and no starters and other problems. Okay. Moving to next package. Let's let's go with general mechanics. In this case, we have movement, testing, then interactions with objects. So let's list some main of them, key, then boxes, and jumpers and other. And now, let's move to modes. Frist mode, we have world. It consists of 12 levels. Each of them consists of four sublevels. Then we have and that has more four levels. And then we have battle that also has battle that also has four levels. Okay, let's move further next will be UI. For UI, we have main menu, and also we have in game UI testing. And also, we have settings and options that we need to test. Then we have audio. For audio, we have music and we have various sound effects. We also call this affix. Then the next one is visual. For visual, we usually use visual effects by affix and graphics. Then we have performance. For performance, we can have FPS, testing frames per second, then what? Testing memory usage, as well as network. Wait and see. Then the big part is compatibility. We need to make sure that we can play from different platforms together on game from different devices, analysis should be tested. First of all, it's platform. Then it's device, then it's operating systems. The next one is vocalization. For vocalization, we need language, support, then vocalization. UI testing to make sure that after translation or text fit to the expected size. And then cultural sensitivity. And then in the end, I will add some different testing activities that should be done, but usually they are not a part of the scope. Such as regression testing, integration, testing as well as compatibility, regression testing. First control count is functionality testing, then we have UI Then we have audio visuals, performance, compatibility, vocalization, and activities. Let's make all of them look the same. Now, let's make it a bit prettier and make sure that everyone corresponds to one package. So this is all the connection. I'm going to merge it, put connection here, so I don't need this one no more. Then it all belongs to connection. All of this belongs to multiplayer online multiplayer. I'm going to put it here. So I don't need this line no more. This one belongs to local multiplayer. I can just move it here, do it this line, wrong button. And all this belongs to multiplayer testing. So I don't need this line. I need to merge it and rename it. Let's do a small alignment. Now multiplayer testing that consists of local multiplayer that has one item and one multiplayer that has three items, and this one has three items. Now let's look a bit better to me. Now let's do the same with the rest. We have it here. This is general mechanics. H. Okay. Good. Then Buto has four levels. And this has four levels. I don't need these two. The litro. Now all this belongs to world group. And now that's all our ay modes. No. So we did this mode decomposition of main features of the game. This is what I usually do before starting any of the project to understand what features and things I would need to test in the future. 9. Project preparation. Estimation techniques: So we have finished with VBS, and now let's proceed to the estimation process. In general, estimation is a process of predicting or forecasting the amount of effort, time, and resources required to complete a testing project. Accurate estimation is the key to project planning and resource allocation and game testing. It ensures that project will be tested and delivered on time, as well as helps us to build a schedule and timeline. There are a few factors that affect estimation. First of all, is complexity of the game and its features. Then the size of the game. That's pretty self explanatory. The bigger the game, more time you need to test it. For example, time needed to test Tetris game and assassin scritGame is pretty different. Then another important factor is available resources and expertise inside the team. When there are no senior people in your team, the testing time will be higher. If there is a strict deadline to deliver your project, there is a chance that you need to allocate more people, more resources, and some of them will be new and you need to include the time that needed for them to accommodate in the estimate. There are existing a few techniques for effective estimation. Expert judgment when experienced tester provide input based on their knowledge and experience, analogous estimation, comparing the current project with a similar past project, parametric modeling, using mathematical models to calculate estimates based on specific parameters and free point estimation when you're using optimistic, pessimistic and most likely scenarios to more accurate estimates. Let's check one by one. Expert judgment technique. This technique highly relies on experienced testers. The estimation is mostly based on the previous experience that they might use on previous projects or when they try to do similar tasks. The next technique is analogous estimation. So in general, we're just comparing projects that you need to estimate to any similar project from the past. Sometimes you compare entire project, sometimes you just take some features from it and see how much it took on the previous project to finish the testing. Moving on, parametric modeling. This estimation techniques involves using mathematical models to calculate estimates based on specific parameters. So basically, you have a list of features and you take an average number of time needed to cover one feature and then just multiply it. And the last one is three point estimation technique. This technique involves going through every feature and providing best case scenario, worst case scenario, and most likely case scenario. And then the formula provides you the final estimate. Let's create an estimate for a Pico park based on VBS that we created earlier. 10. Project preparation. Estimate creation: Use the same document and just modify it a bit. Let's add additional line. We will be using three points estimate technique. So for this, we need mean time hours. Max, time hours. Most likely, hours. And then final. For final, we will be using formula. And now the estimate begins. Okay, for local multiplayer, we have two to eight players. So in general, what we need to check is the ability to join the game with different amount of people and that we are able to go past all levels. Passing all levels will be mostly covered by game modes testing. So for local multiplayer, we only need to make sure that we can start the game with different amount of players on the same PC. So for minimal, I would go with 4 hours for maximum, I will go with 12 hours and most likely it will be 8 hours. Then online multiplayer. Connecting in online multiplayer might take a bit more time because we need to make sure that we connect it from different devices, from different accounts. For this one, I will go with eight, 16 and most likely 12 hours. Then connection. To host the game, I need one person to create the game and other people to try to join. This is pretty simple task 1 hour, 2 hours, most likely 2 hours. Oh, joint game. I have a mistake here. Let's make it a bit bigger. Maybe it's better for visibility. Joint game, if I want to test different joints from different type of join, so I would go with the same one, two, two. And friend game is pretty the same. Most of the level interactions, again, will be covered in game modes, but we still need to test some interactions like collisions between different players. Also, there is a text messages that you can send, so I would go with 2 hours, 4 hours, and most likely it will be 4 hours. Okay, now we have numbers. Let's get some total number for these areas. So simple formula. And spread it across. For final number, based on the three point estimation, there is a special formula, which is best case plus four multiplied by worst case, plus most likely and all of these divided by six. We are applying it to everything. Let's formatted the data. Number we don't need. We need only one number for now. Okay, let's cover for the functional testing, so it will be 17. And let's spread it here and also here. Okay, proceeding with next movement testing. This is pretty simple task. Let's go with one, two, two interaction with object, a key. Also, simple task 111, boxes 111, jumpers 111, and other the same. Now we're coming to game modes. This is the most complex part of functionality testing. Because first of all, we need to go through all the levels. We need to check all the interactable objects there. We need to make sure that we can finish the level, fail the level, and also puzzles look good, level art level design looks good. We actually could even make it more detailed in our VBS and probably let's do it. This is normal practice when you think you finished one task and then you have other ideas that can help you estimate the project, so you can fix something later. Then for each of it, let's create some additional areas. So let's an additional row. Actually, we need a bit more rows. I reach sub level. We need to test pass fail. We need to test level. Let's call it level design. We need to test interactions, and we need to test puzzles because every level is unique and has some way to complete it. Now let's create the same for every level. Okay. Then coming back to estimation, due to the fact that we have 12 levels and four sub levels, anything that we need to do, we need to multiply by 12 and four. So basically, to check pass fail, we need around 10 minutes per level, then we need to use a formula here. We need to keep everything in the format of hours, but some of the things they take less than hour, so we need to translate it in the hours as well. So for example, pass fail, check, going to take us 10 minutes. So then the formula will be 1/6. We need to do this for four sublevels. We multiply it by four and for 12 levels. So in the end, we have 8 hours. Then let's just use the formula and worst case we need 20 minutes, and most likely it will be 15 minutes. For web design, it might take in best case scenario half an hour per, I worst case scenario 1 hour per level. Let's do the same. Let's just copy our formulas. And then just change the number. Half an hour is three by six and 1 hour is six by six. Best case I will go with 1 hour in best case also. I believe interactions will take the same amount of time as a AOD test and the same for puzzle logic. Sprung the formula. Okay, endless, we have four levels for endless mode, meaning that all the estimates should be multiplied by four. So for pass fail, I would go with 1 hour, then after multiplying four, eight, and best case, six, LAODO hour per level multiplied by four is four, eight, and I believe eight is more likely. Interactions, 2 hours per interaction, then eight or case 16, 12. Puzzle logic for endless mode is more simple. I'll go with two, four, four, and we're left with bottle and in my assumption, the estimate will be exactly the same as for endless mode. And now we have the final number for functionality testing. Then let's proceed for the next UI. Main menu UI, 2 hours of testing, best case, for worst case. Okay, let's go with eight because maybe there's more than six in game UI testing, two, six, Four, setting is option and options is a pretty big task. You need to check every setting, every option and see how it affects the game. I'll go with 24 48 and best case probably 32. Let's get the formula prolonged. Moving on. Music, there's not much of a music. So I'd go with four, eight, six, and aufix there is even less. There is a affix for some basic things, and most of them will be covered during testing of game modes. So we just need to make sure that there are unique suffix per unique actions. Two, four, four visual effects. Same as a suffix, two, four, four. And graphic testing, this is pretty big one because we have ability to play the game on PC on different resolutions on mobile. So graphic is something that would require at least two days of testing. So it's 16, 24, and best case is 20. FPS testing. This will be happening naturally. You need to do some special performance testing sometimes and plan these activities, so I would go with 16, 24, 20 testing should happen a few times, so it's 244. Usage is the same. And network Qutenc happens also naturally while testing other stuff, but sometimes you need to set some activities and use some tools to check it. So I would go with some big number because this is also multiplayer game, and network quotenc is important stuff. So I would go with 12, 24, and maybe 16 here. Compatibility testing. We have a lot of different platforms. It will be 16, 24, 20, we have a lot of devices. 24, maybe 48 in operating systems, we don't have that many, so it's 412, eight. The forma doesn't work. Okay. Now looks better. Language support for 86. Vocalization UI requires a lot of testing on different devices. It will be happening naturally also by testing other modes, but still you need to pay a lot of attention to this. So let's go with 24 hours 48, and the best case will be 32. Cultural sensitivity is not a big task. And we're left with activities. Activities are usually happening from time to time. For example, regression testing, you need to do it after some changes to the system, integration testing after some new features were done and compatibility regression testing as well, you need to do it after some bugs were fixed. So we will plan just a big amount of time there, and then we will spread them equally between the different milestones. So for example, regression testing is 48 hours up to 60. So let's say 56 integration testing, 24, 40 36 and compatibility, 24, 40 36. Okay. Now, let's add some formulas here. I'll probably skip it, so it looks faster for you not to wait. So we have all the numbers. Now, let's get our total final number. We need to get it from the column. We need all this number and we need to divide it by two because we wrote it two times. And here's our estimate for the project. In hours. If we want to split it into days, then we need to take it and divide by 8 hours a day. And for weeks, we need to take this number and divide to 40 hours because it's usually 40 hours a week working time. Form number So this is our final numbers. To fully cover the entire project, pick a park, we need 80 working days or 16 weeks. Just want to mention that this is pretty fast estimate. If you're a Q elite, you usually need to be more precise and go deeper into requirements and into the game and content and expectations into the design to provide more accurate numbers. These numbers are based on just a quick look, so they might be not that accurate, but I'm trying just to provide you a small overview of the process in general. 11. Project preparation. Planning: After we created the estimate, let's talk about planning a bit. Planning is a crucial aspect of game testing, and it helps teams to organize their efforts, allocate resources effectively, and manage risks. Effective planning ensures that testing activities are well coordinated, deadlines are met, and stakeholders are informed of project progress. By investing time in planning, teams can minimize uncertainties and maximize the chances of project success. In this chapter, let's check the benefits of the efficient planning. There are several key steps that are present in planning. First of all, you define the testing objectives and scope. We did it by creating requirements and creating VBS structure. The next step is identifying resources and constraints, then creating detailed schedules and timelines. Step four is establishing communication channels, and step five is defining growth and responsibilities. Creating a testing schedule involves translating the estimated testing effort into detailed timeline that outlines when each testing activity will be performed. While creating a timeline, you need to take into consideration a few factors. First of all, is resource availability. Depending from company to company, from project to project, there are always different composition of the team. The team, we mean how many junior testers you have, middle, senior testers. Is there one person available or more? Is it the company that gives you an amount of resources or it's up to you to find the resources? So this is something that you need to take into consideration while creating a timeline. Second one is estimation that refers to amount of time you need to test the game to its completion, then dependencies between tasks. This is something obvious, but sometimes you need to understand that some tasks cannot be done unless another task is completed and vice versa. The last one is project constraints. For example, if it is a multiplayer project, it is not possible for one person to cover it. Let's move to a creation of testing schedule and timeline for Pico Park project. 12. Project preparation. Resource allocation: Start creating a resource planner, we need to have an information from the development team about project constraints. For example, deadlines and dates of main deliveries. Usually, it is shared with the QA team in advance for them to be able to create proper planning. Let's imagine that this is a plan shared with us by the development team for Pico Park. What do we have here? We have April, May, June, three months of development. And the main dates are pre Alpha, April 19, Alpha, May 10, Beta, June 14, and Goden June 28. So we'll be working around these dates. First, let's create a resource planner. Let's create additional comb to the left. We will be using this comb for different namings. Okay. Resource one, resource two. Let's move it a bit, so it looks better. To create resource allocation, we need to take a look at our expected amount of hours. We have 640. So let's put it somewhere Okay. Now, let's create some allocation. And create some counters for our convenience. We'll be using formula. The formula will be here we place one person, then it adds 8 hours because this is usual amount of hours spent per one day per one person. If none, then zero. Okay. Let's do it for entire duration. And also at total sum. Usual forma. Let's check if it works. One here, one here, one here. Yeah, it seems to be working. Let's assign resources to different timelines. For pre Alpha, I would like to have probably one tester at the end just to make sure that the project meets the expected criteria for pre Alpha. Then starting from Alpha, I would like to have one resource available all the time. Basically, I would like to prolong one resource to the duration of the project and then see how much room we have for second resource and if there is a need for even more resources. So in total, we have 440 hours. So we have additional $200 for second resource allocation. I would like to start from the end because it is good to have more people near the release of the project. So I will go here This gives me 512 and then more towards Beta. Okay, 40 hours, so I have one more week. In this case, we have 640. And with this resource planner, we will be able to allocate additional resource three weeks before beta delivery. 13. Project preparation. Timeline creation: Went ahead and copied our estimate into the timeline sheet, so it is easier for us to create a planning. Just wanted to mention that usually you create it when you have a sync with production, and they share their production timeline with you. So you know when feature is ready to be tested and how to plan your activities better. This time, we don't have production team, so I will be just trying to use best practices in timeline creation. There is no need to create very detailed planning. Usually, not all things go as planned, and you adapt in the process. But creating timeline at the start just gives you at least an idea how you plan to execute the project. And then you just do minor adjustment in the process. So let's start. We are going to start in pre Alpha one week. Apple will be testing something that should be present, basic interactions and movement. 2 hours and 4 hours it's 6 hours, so it should take at least one day. Plus we give 2 hours to set up everything for the tester. In this case, we have general mechanic full covered and some basic stuff that should be also present in the menu. We don't expect any audio in the pre Alpha, any visuals, performance, compatibility, vocalization. So in general, we'll be doing some integration testing just to see how different system interact with other systems. Then we slowly move into Alpha. The Alpha is a time when prototypes of features starting to appear. So I would like to spend some time testing world, maybe three days one day of ends one day of battle. There might appear some first options. So let's spend some time here. We don't expect any visual performance and audio in Alpha at all, but we do expect to have at least some working platforms and some devices. And we're starting the final week of Alpha. In the final week, there might be already some multiplayer testing expected. So I would go with one day of local multiplayer day off and one multiplayer and one day off every mode. Of course, you can test three modes every day. We're just trying to drawize the main plan for us in general. After Alpha is over, I would like to do some regression testing just to cover the build. So I would go with three days of regression and a bit of compatibility regression. Let's set a small formula for easier calculation. So for this one, we need this number minus sum of Centio Good. Then we don't need general numbers here, and we need to make sure that it has numbers. This is just one day of work, so it's just one number here. And here we need just a sum of everything. And if it's near zero, then we did a good job. Okay, mooing back, second week of Beta. Let's test a bit of a content here, here. Okay. Okay. Okay. Then now we have two people available. Let's have some multiplayer testing here. Still, we do test content. Then second day, it would be nice to test some settings and options. And some graphics testing. Maybe even two days and also we would do some performance testing. But we also can start compatibility tests. These are three of them. We have one here and two here. We are two weeks till Beta is done. Let's do a bit of vocalization testing. And some compatibility to it. We need to check music and also visual effects. We can leave as affix and fix to golden stage, t's mark it not to forget. When are we hitting gold here? So it will be just let's put four and four. And we need to test music during Beta, so it's going to happen earlier. Then we need to test memory usage network latency during Beta. It will be like this to here and for and four here. Good. And the last week of beta, we need to test a lot of content. We need to do a regression first to make sure that a lot of changes had no effect. Let's put some regression testing first. Then then we have content testing. Let's not forget about multiplayer. So let's spend some time here. Then just finish everything. It here. Then let's do some settings, testing. We still have some time left from compatibility testing. And vocalization, of course. Is it 80 hours? Yes. The last week, we still have a lot of regression testing, which is good. We'll do it last days, so we need to finish with world and battle. We even can spend one more day testing and the rest is regression. How many more days I have? One more day. I would go with Let's check if nothing is missed. We have 40 hours here, 40 here, 40 here. Good. Good. So there is one more day that we can add, and we have compatibility regression testing, not fully used, vocalization and some other small things. I would rather spend more time doing compatibility regression testing just to make sure that all platforms for good. So during this week, we can find a way where there's only one person used and add another. Okay, 80 and 80. Now we're left with 12 hours, which is totally fine. It will be still used during the testing period, and now we have a general timeline. It will be changed a lot during the execution of the process, and that's pretty natural. That's normal thing. We just need to make sure that we have at least a plan for ourselves and the ability to cover all main things that we need and to place them during the most relevant time. So now we have our timeline, and let's move to the next topic. 14. Project preparation. Test Plan: Now let's take a look at another very important element, test plan. A test plan is a document that outlines the approach, scope, resources, and schedule for testing a game. It serves as a roadmap for testing effort, providing guidance to the testing team on how testing will be conducted, what will be tested, and when testing activities will take place. Let's take a closer look at the elements. First, it's approach that describes the method and techniques for testing the game. Then scope that defines what will be covered in the testing process. Then resources that covers all the tools, equipment and personnel needed for testing and schedule that outlines the timeline for testing activities and milestones. Let's take a look at all of the components of the test plan. We're each serving a specific purpose in guiding the testing effort. The components are test pan introduction, objectives, scope, approach, resources, schedule, risk and mitigation strategies, assumptions, and dependencies, test deliverables, and exit criteria. Let's take a closer look at each of them. Testpan introduction gives us a brief overview of the game being texted, purpose, and scope of the test plan, and it also provides an identification of stakeholders and contacts. Then we have clear and measurable testing objectives and alignment with the project goals and requirements. Then we have scope, and it defines what will be tested and what will not be tested as a part of testing effort. We have three main points. It's inclusion and exclusion of testing, features, functionalities and platforms to be tested, and boundary conditions and limitations. Then we have approach that consists of testing methodologies and techniques to be used, test levels, and test types. Then we have testing team composition and rows, tools and technologies required for testing and testing environment setup and configuration. Then we have a schedule that consists of timeline for testing activities, milestones and deliverables and dependencies and critical paths. Also, we include risks and mitigation strategies that consist of identification of potential risks and challenges, mitigation strategies to address risks and contingency plans for handling unforeseen events. Then we also have to include assumptions and dependencies that consist of internal dependencies, external factors and dependencies, and communication plan for managing dependencies. Also, we have to outline test deliverables. It is a list of test deliverables, test cases, the scripts, test reports, format, and structure of test deliverables, and distribution and review process for test deliverables. And then we have exit criteria. That's conditions that must be met to conclude testing and sign off process for concluding testing. And now let's move to the creation of Test pan for our game. 15. Project preparation. Test Plan creation: Already created a small template and placed here main elements. So let's start popuating it with a content. And we're starting with the test plan introduction, and here we have game overview. Let's put here an aio of our game that we will be testing. Something like Pio park is a cooperative multiplayer puzzle game where player must work together to overcome various challenges and reach the goal. Now, let's put here the purpose and the scope of testing. We're just pacing here that the main purpose of this test plan is to ensure that Pico park meets quality standards, functionality requirements, and user expectations at the release stage. And for the scope of the testing, we named that we need to cover everything that we placed in the VBS structure. So let's simplify it a bit and just say that the scope covers all work pages listed in the VBS for all platforms listed in requirements. Seems like it's got bigger. The last one is identification of stakeholders. The main stakeholders of the project are the people that are interested in its success. For us, it might be the producer of the project. Headquarters development lead to communicate with him about the issues and the problems and release management. Usually the mesa coders are the people that you work with, and they are mostly interested in the result of your work. You might also be able to provide here more detailed information like names, positions, and ways to contact them. Moving on to objectives and let's place here main objectives of the testing. First of all, we need to validate gameplay mechanics. An important thing is multiplayer. So we need to verify multiplayer functionality for both vocal and online modes. Then we're coming to compatibility. So we need to ensure compatibility across different platforms. And one of our objective is to complete all prepared test cases. And also, we need to make sure that all project requirements are met. Okay. Moving to scope. Basically, we defined all the scope that we are planning to test in our WBS structure. So let's just list everything here. Okay. Moving on. Approach. For methods, we'll be using black book. And also, we can try to use gray box and have an ability to test something in the engine. Then for testing levels. We are going to start with integration, then system and also acceptance. For test types, we'll be using functional non functional testing as well as more detail will be using compatibility, testing, performance, testing, usability, and also exploratory testing. Then for sources. Team. On the peak, we'll be having two testers, and team composition is another topic that we will be discussing. But in general, they can be middle and junior level for tools. Let's make it more beautiful. FTs, we'll be using Jira for testing. Test rail, for example, and maybe one of the engines. For example, it's Unity. Oh, I forgot to mention regression testing. For environment, we need PC consoles and mobile devices, Nintendo, which will be included in consoles. For operating systems, we'll be using Windows IOS and Android for browsers, Chrome, Firefox, and Safari and for network 11 and mobile network. Okay. Moving on. For schedule, we already created a timeline for schedule, according to the timeline that we created already. We're gonna get Alpha Alpha, Beta, and release. For Pre Alpha, it's April 19 Alpha is May 10. Data is June 14, and release is June 24. For risk, let's name something that comes to our mind. I expect some issues to happen with compatibility testing because it's a big technical lift. So I would go with technical issues might appear during compatibility testing. For a mitigation, first thing that comes to my mind is to define if it's project related issue or platform related issue, and if we need support from regional company. Issues are platform or project specific. In this case, developers will have more information and ability to fix the issue. Okay, let's have some assumptions and dependencies. So usually we assume that developers complete all the planar features and functionalities according to the requirements and design. And then we also assume that the environment is properly configured and has all necessary hardware software and network configurations. And let's have some dependencies as well. The one of the biggest dependencies is resolution of the defects because having bugs not being fixed or blocking issues present in the build might affect testing and planning. Going to the test deliverables. The main our deliverables are test plan, the outline of testing approach strategies and methodologies. Then we have test cases. Detail test cases that are covering all the scenarios. Then we have defect reports. We will be documenting all identified defects. Test summary report. This is a summary report that outlines the overall test results. And probably and that's all for now. And the last one is exit criteria. What do we expect from our testing? First of all, we expect 100 of test cases covered. Then we expect the successful completion of substance criteria for each milestone. And the worst one is that Final product has no major issues. And defect resolution rate is around 95%. So this is basic creation of test plan for a game. It is important to do it to have full visibility and overall picture of the project execution. Some companies make it more detailed. Some companies don't use it at all, but it is good to know some basic stuff and the ways how to create it. So let's move on. 16. Documentation. Reports: We are moving to our next chapter that is called documentation preparation. It is a part of KL's role to prepare a template and to organize a proper documentation flow on the project. In the first part, we're going to talk about K reports and templates. We will explore the importance of K reports in the development life cycle, different types of KA reports, and templates that are commonly used for documenting QA activities. QR reports play a crucial role in the software development life cycle by providing valuable insights into the quality of the product. These reports serve as a means of communication between the QA team development team and stakeholders, helping to identify issues, track progress, and make informed decisions throughout the development process. K reports play a crucial role in providing valuable insights into software quality and guiding decision making process. Thise reports serve as compasses to steer the course of the project development, ensuring that quality standards are met and maintained throughout the software life cycle. There are several types of QA reports commonly used in software development projects. This includes test summary reports that provide a concise overview of test results. Then defect reports that are used for identification and tracking of software issues and status reports that provide visibility on current project progress and performance. Let's take a more detailed look into each of them. Test summary reports provide an overview of testing activities conducted during a specific phase or cycle of the project. There are main elements such as test objectives, test coverage, test results, and recommendations. Then we have defect reports. By leveraging defect reports, teams can seamlessly track and address defects, enhancing collaboration, and ensuring efficient defect resolution process. Defect reports provide a comprehensive overview of each defect, including its unique identifier description, severity, priority, and current status. This is basically the main report of every QA tester. Moving to status report, they provide updates on the progress of the project, including milestones achieved, challenges encountered and action item spending. Status reports fosters transparency, communication, and alignment across teams for timely project delivery. Status reports serve as a means to keep stakeholders and decision makers updated on the project current status and any potential issues affecting its progress. Why it is important to have the same standards across all reports in the same team. Basically, by embracing standardized templates, teams can align their reporting standards, enhancing collaboration and ensuring a seamless flow of information within projects. In simple words, every time you receive a report, you already know how to use it and where to find the information that you currently need. Let's create Test summary report template for Pico Park. 17. Documentation. Report Template: Easiest way to create a template is to use Google Docs. Let's just create a new tab. Let's call it a test summary report and start creating a template. Let's make all borders white, to be able to draw new borders. Let's just create the outer border, something like this for the start and everything will be created inside. We just do we create a place for a name. This is our test, summary report. We center it now below, we want to have a date, start date, and end date. Something like this. On the other side, some additional important information like executor and build number. Now, let's move to sections. Our first section is summary. Center it and we just leave some space for it. We merge it horizontally to be able to put some main points. Then we are adding next section. The next section is testing scope, also centering it and leaving a place for main points. Done. Then moving on to our next section, which is testing results. Okay. Since we need more space, we can deal with water. For testing results, we are going to have two main sections, test cases and bugs. In this section, we just want to add some visual representation of our test results. For test cases, we want to understand how many of the test cases were passed then failed that are still to do because maybe we didn't manage to finish. How many are still in progress. And how many of them we could not test. We put it as CNT. We couldn't test them due to different reasons. The easiest example is that maybe we had to test eight people multiplayer, but we didn't manage to find eight people this time, and we only had seven people. So in general, we tested 1-7, but not eight. Then we have some numbers here let's put something, for example, for now, just to see if our formulas will be working correctly. 024. Now let's add some space here. Now, let's at a diagram here. We choose this. Let's start with this and then we go to search chart. I personally like Don Style more. Now we have this add label label. Here is our label. Okay. And let's play with customization. We have background color. We have border color. I prefer not to have it. Then everything here looks okay. Pass. Let's change some coloring because usually pass is more green, filed is more red. To do is gray. In progress is orange and could not test, let it be purple. Let's change style of legend a bit, let it be on the left, and let's add some value on it. I lab value. Looking good. Moving it here, arranging a Good. Now let's do the same four bucks. Let's just copy paste it here and change it based by severity. Critical. High. Pre medium W west. It can be changed depending on the project and setup. Critical ten, hyprio 20, medium, five, the lowest. This is just for an example. Then we can just copy paste and change the settings. We have that arrange this is our new range, then we add a label to it and value is here. Now let's play with colors a bit. Critical is definitely red, hybriOange medium medium is white, yellow, is green, and the lowest is blue. Then let's move to the next part, which is Sure. Summary of defects. We create space for it. But let's have some additional elements here like ID, then summary severity and that line it a bit. Good. This is a basic structure of our report, add some formatting to it. Min areas. Let's make them dark gray. The name of a report can be darker gray both. Making both. Then we have smaller areas. Let's make it white gray. Add some border here. Then we want to merge it horizontally and add some borders inside on them be whiter. It's too white, let's make it darker a bit. Same here. Good. This is a template that we can save, share with the team, and then use for any test pass we are planning to have. Now, let's use an example and fill it in. 18. Documentation. Report Creation: Have a test summary report template, let's try to simulate its creation. For example, we had a multiplayer pass, now we want to provide the report. So what we do, we just duplicate it, and let's call it TCR, multiplayer. This one will be our template template, and it will be our original template for all future passes. Let's imagine that we had a multiplayer test pass that lasted two days. So it started on 18th of October and ended on 20th of October. Man executor. This one, and build number change 25 data, 45, and sound 56. The way how build Number works is usually defined by the project. We skip summary for now, summary is something that we want to provide in the end when we have all data available. What is our testing scope? The easiest way to see our testing scope is to go to VBS and see what is included in multiplayer testing pass. So first of all, we'll be testing multiplayer connection like host game, join game, and friend game, then dating of PA. Functionality for two to eight players. Then we are planning to check all the interactions in multiplayer. There also can be some specific tests that you are planning to do. For example, we want to see how disconnect is working. Okay, then we just do it something that we don't need. Then we are moving to our test cases. For example, we have 40 test case passed 15 test case failed, zero to do, zero in progress because we finished a pass and for example, five, we couldn't test. Now I can see that there is one missing element that can be very beneficial. Let's dt here, and we need to change formatting a bit. So we need to change all borders and bring border back and the samson is total. Let's do the same here. I will update this later for the template. Let's have a sum here and exclude it from the chart. Let's have the same here. And also exclude it from the chart. Let's change color a bit to differentiate it. And we can also add another element. We can add a percentage for each category. So then it is this number divided by total. Okay. Let's do same here. Let's change formatting to a percentage. And we don't need that many numbers out there Dot. And again, we need to fix the formatting. Good. Now we have some visual representation for percentages for different categories. Let's imagine that we had a critical bug during our testing that when you have more than four players in squad, the multiplayer doesn't work. This is a critical issue for us. Then we also had few more high prio bugs, some medium bugs, and few issues. In the end, we have 21 issues. Now we're moving to the next section and this section is usually created with the help of Jira. We didn't talk yet about Jira. I will put some placeholder box here for now. From project to project, it is different of how many bugs you want to highlight in the summary report. Usually, it is critical, high prio and medium box. Let's imagine that on our project, we put only critical and high prio issues. In general, it will be looking like this. ID 01, ID 02, and ID 04. Usually, we put here a link to the Jira ticket. And then it will be looking like this. Then here we have summary four box. We can put it here. It doesn't work when the party has more than four players sever it is critical and the status usually represents if at the moment of the creation of the report any work on the issue started or not. In our case, it's most likely the work is already in progress. We do some formatting here. Critical. Let's change it to red. And status and progress usually is how I to yo. Then we have a few more high PEO box. I don't want to take time now and to come up with a summary, so it's summary one Summary two and summary three high prio do and prio is orange. Then this is extra for us. Let's just delete it. Fix formatting again. The summary section is the first thing the coviders will be looking at. So we want to put here the most important things and findings. For us, the most important thing is that multiplayer feature is not functional when there are more than four players. So we just can start with it. And we also can add a link to the jury ticket so everyone can track the progress. Let's imagine it is a link. Then the next important information is that there are three more high priority issues. So let's just put some short information about it. And we also add links. Then let's add some general information about the feature itself. In general, multiplayer feature is functional, so we can elaborate more. Pass rate is 67%. And also some information about quality. There are 21 box reported. As this is a simulated pass and we don't have more detailed information for now, I think we're okay with this current state of the report. So we're doing this rows. We can do some formatting making bold, and green. This green is to white, dark green. And after everything is completed, we either just copy paste everything and put it in the email or save it as Perdev and send it to all the stakeholders through communication channel that was established previously. There also might be different sections, different parts, and different ways of putting all the information together. I just showed you the simplest way to make sure to provide the valuable information to the stakeholders, provide some insights and general state of the feature that was tested. Making sure all the team members are using the same template makes communication more efficient because if you receive the same type of the report, you know where the information that you are looking for is located on it. Now, after everything is done, let's move 19. Documentation. Severity and priority: As a team, we are closer and closer to report our box. But before proceeding to this, we need to define some important things like priority and severity for reported box. In general, it is defined by the theory of testing, but let's have some unique guidelines for our project, the team should follow. For this, let's create additional tab in our document and call it severity and priority guidelines. Now let's do some simple formatting pretty quick. We do all Borders white. Then we want to have severity section. And priority section. Let's start with severity. First of all, we're expecting high severity, then we expect medium, severity. We expect low severity and lowest. Okay, let's start with high severity. What do we define as high severity? First of all, it should be feature that doesn't work. This is pretty clear. Then we want to add some real project timings. For example, we have feature that partially works, but we have a release soon and we need to test it. So we put here bugs that prevent QT from testing. Then we want to add some different elements. Example, major sound issue, and major controls issue. And of course, any crash or freeze. Good. Then moving to the medium severity. It's do formatting pretty quick. Okay. For medium severity, we need to start with something that we see some major graphical glitches. Then we have features that partially don't work. And something that helps to define the medium severity. This is a bug that affects user experience but doesn't prevent the gameplay. Good. We delete something that we don't need, and we're moving to low severity. Low severity usually define the bugs that have a minimal impact on the gameplay or user experience. Usually, these bugs do not require immediate action. The most common ones are text errors, then some minor I issues, minor. Graphical glitches and some minor performance issues. And we're moving to the lowest severity. Lowest severity issues are something that nice to fix, but they do not affect any of gameplay or user experience. Cosmetics very minor UI issue. The most common is suggestion. Suggestion is a very interesting type of bug. Q usually provide some suggestions, how they think they can improve the gameplay and use their experience. And from time to time, depending on the deadlines and how busy the developers are, all the stakeholders can sit together, go through all the suggestions, and fix or implement some of them. But they go to the lowest severity just because the game still works as originally designed, and this is just a way to improve it. Okay, let's just copy our formatting, do it all the text, and what do we have here? Let's call this one severity. This one. And usually there are three major priorities. First one is high, then we have medium, and then we have low. And for high severity and in the high severity sections, we have bugs that need to be addressed immediately to their critical impact on the game functionality or user experience. Here are some examples. First of all, game crashes. They always are high priority. Then we have bugs that are preventing the game from lounge. Then we have the bugs that are preventing QT from testing. Then we have current sprint issues. Why current sprint issues have high priority? Because it was our plan to implement these features, this sprint, and we're planning to show the result to stakeholders, and we want them to see that the functionality is working and they are happy and everyone is happy. Medium and low priority in general, mimics the severity sections, so we don't need to spend much time defining it. We just copy paste the same here. So we just copy it here. Let's add some color coding. And let's now talk about something that is a all of this, which is critical issues. Let's add it on the top of everything. This one is big and red. Which is put here a guideline for all critical issues that are not affected by any severity or priority. They are the most important bugs that should be treated as soon as possible. First of all, we come back to game crashes that happen immediately after boot are placed on the golden paths and prevent us from completing the game. They are also known as walk through bokers and any crashes that are present in the game before the lease. The next section is for data loss or corruption, including Save files, player progression being lost, and in game items or currency disappearing from player inventories. Then we have multiplayer issues where multiplayer doesn't work. For our game, it is very crucial and important because it's one of selling points and base mechanics. Then we have severe performance issues. Also, we include any security vulnerabilities. And the last one is important for business when any of the selling features are not working. Because in this case, we have a risk that company won't be able to sell the game, receive negative reviews, and the game won't be profitable. Q should be cautious about these features and make sure that production knows about any of the bugs that happened to it. These are pretty basic guidelines, but it is important that every team member knows about it and they are guided by it when reporting issues. Now let's move on to Jira. 20. Jira. Bug template: And we are moving to Jira part. Usually, when you arrive to the project, the Jira is already present and they just create an account for you. But let's imagine that on our project, we have to set up everything for ourself. So we just go to the usual Jira site and press get it free. We put our email and press sign up. It takes some time for Jira to set up everything. We're choosing the most popular template and Prest. It asks us to give a project name. Let's call it Pico Park test. And let's choose that I'm a little familiar with Jira. And at the current state, we have a full clear Jira, and we can start set up in it. First of all, let's create a bug template. For this, we need to go to project settings, then choose issue type, and we need to add issue type. This is a bug, and we press Add Jira automatically adds main fields like summary description, status, SME, label, parent and reporter. Reporter is present in height empty section, but we don't want it to be empty, so let's move it back to usual context fields. Let's move it closer to SNE for them to be near each other, and I don't think that we need parent so we just remove it. Now, we also want to add some context fields that going to help us in organizing the project. So first of all, I need to start with severity and priority. So I go to create Field section and choose dropdown. So I code severity and I have options critical high, medium, and lowest. I said medium as default. This is a required field, and we move it under reporter. We do the same for priority. The options are high, medium and low. Then we also need some important elements like steps to reproduce, so we choose text, and we call it steps to reproduce and make it also required. Also, the good thing is to have build number. We move it in the end as it is not so important. Also, for better tracking, let's add additional field code component. It is a drop down section and in options, we want to list all of the areas of our game, such as functionality, then UI sound performance visual compatibility and vocalization. We mode down a bit under the priority section. Now we save our changes. Now I see that actually steps to reproduce should be a paragraph type. So we remove it and add again. Now, it's done. Let's go back to project and try to create our first bug. We press Create button. We have this window appeared, and we start with Sam. Party consists of eight players. We go to step to reproduce, first step is to put the title on Build go to multiplayer host game, wait for seven players to join press start. Okay. I description, we give some additional information multi player. I doesn't work when there are eight people in the party, it works for one to seven players. In SINE, we put either our manager or responsible developer. I'm the reporter and our severity is critical because we have release in one week, and we put it as high priority per component which is functionality, label field. For now, we don't need it. Build number, for example, change x, then data, then sound. So this is our build number. We put any attachments that we have, like videos or screenshots, maybe ox. If there is a task to create multiplayer, then we might link it, but in our case, we don't link it. And we have this ability to *** it to make sure that everyone understands that this is important bug and we press Create. And we see that our first bug appeared on our board. 21. Jira. Status and Filters: Try to change the configuration of our board a bit. For this, I've added some placeholder bugs, so it's visually easier for us. What we need to do first, we go back to settings, issue types, bug, and we edit a workflow. I think at this stage of the career, everyone is pretty aware of the life cycle looks like. So we just need to add the statuses to Jira. So we need new in progress status, we're going to call it que review. And we need the status for all the box that were fixed and needs QA test. After the test, we might reject the fix, so the developer needs to do it again. So we add QA rejected status. And also, sometimes either developer or QA needs more info. So we add additional status that is called need more info. Then we press update the workflow. And now we have the updated columns. Let's close move back to project, let's see how it works. Okay, we need to rearrange it a bit. We press configure board. We move done in the very end in more info here. So we have to do in progress in more info, Q rejected, K review, and done. Let's save our changes and take a look how it works. Let's check if it also works properly. Let's put some box in different sections. Click on it and see that need more info. Let's correct. This is K rejected, correct. And this is in review. Let's also check if done works good. Yep. So our board seems to be working. Now, let's create some basic filters and start building our dashboards. Simply, to create a filter, we need to press on the search. And put it to the list view. Do it this one, choose our project pickupark type, bug. And that's all this is our first filter that is called Pia park O Bx. If we want to use it for the dashboards and the team to set, we need to change it from private to group or organization and choose all users. Then, this is our first filter. Let's also create additional filter for all critical or flagged box. For this one, we simply add additional attribute, which is called flagged. Now we have four box that are flagged and we save as a copy for it to be a new one. We call all flagged box. Now, you can see that we have two filters that we can use to create our dartboard. In the process of creation of dartboard, we might need additional filters, so we will be creating them in the process. And now let's proceed to the first dartboard creation. 22. Jira. Dashboard creation: Now let's proceed to the first dashboard creation. We press on dashboards, and we press Create Dashboard. Pico, park Main dashboard and we'll do the same with the share. And it's done. This is our first dashboard, and we need to define what we want to see on it and why do we even need it. I usually build dashboards. In the way they help me to create reports. So I have all visual information that is already filtered for me. First of all, I want to see the visual list of all my books. So I just go with filter. Filter results. I choose all bugs, and I choose what I want to see. Issue type, bug, K, summary, priority, severity, and status. A to refresh, save. And I have my first widget. Let's call it Pico Park visual list and green cover. Let's move it to the right. Then I want to see the box split by different severities. I go to two dimensional filter. I add it here. I choose box for Y xs. I want severity for Xxs I want status. Let's have ten, save. And now we can see the future for all the statuses and all severities that we have. Let's rename it. Peco park box sorted by severity. And I choose some different color. Then I want to see all my flagged issues. So I choose different theater flagged issues. What I'm interested to see is their status. And the priority to fix. Let's have more, and let's see how it works. Let's tweak it a bit, change places. Total and X to choose priority and Y to choose status. Let's rename it of five box by statuses. And let's make it red. This is our top pio. Let's also create a filter for all unresolved box so we don't waste our time on something that is already in a done status. Let's go to Filters. We go to all box and just add and just choose resolution. And we choose all unresolved box. We save filter as a copy and we call all and we call it all unresolved box. We save it, and let's go back to our dashboard. Let's dt and also add this filter. Which is two dimensional or unresolved box. Let's choose component and our severity. And let's see what we have. Okay? Let's rename it. Oh, unresolved box. By component. Good. Oh, let's make yellow and move here. So let's take a quick look on the dashboard and see what we have. First of all, we see all fact bugs by their statuses. So we can see that some of them are in progress, some of them were rejected, and some of them are still to be done. Then we can see all bugs by severity. So if we need to create some filter, we can just press here and add some details. For example, we need all unresolved bugs. So we add resolution, we press unresolved, and also we want to have some time measure when it was created. So we go here, press create time. And we can choose some ranges and use it for reporting. Then we have just a list of bags, and we can also filter it, for example, by severity. And we have the list of all unresolved bogs based on their component. And we can see the most critical box are present for compatibility and functionality, and we can even click on it and see what it is. Now, let's also add some visual representation. So let's choose a pie chart and, for example, choose unresolved box and component. It gives us this beautiful filter to understand the split of box between different components. Let's name it. A unresolved box by component. Et's move to the bottom. And we can do the same for severity. A unresolved box and choose severity. We can see the 25% critical high low ost. And let's also move it to the bottom. Done? No, it's saved. So we have just main dashboard with all the main information, including some visual representation of our data. In general, dashboard is very helpful too. I usually create a lot of different dashboards for different passes, for different components, and use them to see the status and the health of the project. For example, when there is a better validation period, I also usually create my special dashboard dedicated to this process. We're not going to go into details for now, but I think you've got the main idea and the way how to create it. So with a bit of imagination and practice, I believe you will be able to create beautiful and useful dartboard. And let's move on. 23. Testing. Milestones: Let go to our next topic and talk about text execution processes. Let's talk about important things such as milestones and QL's role in its success. Milestone passes play a crucial role in the project life cycle, marking key stages of the progress and ensuring alignment with project goals. In general, there are two main things that are important for Q Elite. First one is checkpoint oversight that ensures that project criteria are met before advancement at Milestone gates. Then it's testing supervision. As a Q Elite, you need to oversee the testing activities to uphold quality standards at Milestone passes. The important thing about milestone is that after conducting testing and milestone validations, it's easier for us to evaluate project status and progression and make sure that everything is delivered in time and according to quality standards. Having a milestone gaze gives us an ability to have a structured approach for assessing project development, guiding decisions on the project direction, and next steps. In simple words, after receiving the results of milestone validation, the team can understand if they are moving in the right direction. Let's do a brief run through main milestones, and let's start with Alpha. The Alpha milestone marks a critical phase in the project, focusing on core feature validation and early testing. Qa plays a vital role during Alpha by ensuring initial functionality and identifying critical defects for resolution. What are the expectations from QA at Alpha stage? First of all, it's testing and validation of core features functionalities. Then identification and prioritization of critical defects for resolution, making sure that production knows about the most critical issues first. And also to start the first collaborations with development team, communicate with them and make sure they understand all the priorities set by QA. And let's talk about the responsibilities of QED during this milestone. First of all, it's test planning before the start of Alpha milestone, QLID make sure that he has an understanding of expected functionality and features and creates a validation plan. Another important thing is understanding of the coverage. QED makes sure that he has all the updates from development team about what features were planned and implemented for Alpha stage, what should be tested, and what should not. And then QED creates a list of features to cover and shares it with the team. And of course, another important responsibility is communication with stakeholders. It can be done through charts, calls or emails and reports because the main thing is to make sure that other stakeholders have the full transparency aligned on the goals and understand the current state. Now let's talk about Beta Milestone. In general, Beta Milestone should be content complete and feature complete, and the game should be near the final stage. What are the main expectations from QA? First of all, Team should plan the regular regression testing to ensure the stability of the build. Then Katam is making sure that all content and all features are completed and integrated. And also team performs monitoring of performance metrics and is trying to identify the areas for optimization because at Beta stage, performance is very important and the game should run without crashes, spikes or FPS drops. Let's see what are the expectation from KElite at Beta stage. First of all, it's a coordination of all the activities and resources because at this moment, the production might have closed beta, open beta, and they will be using different buds for all these activities, and it's up to QElite to split the resources in the most efficient way. Another important thing is prioritization. The game has a lot of content already, all the features integrated, there will be a lot of box, and it's up to Q Elite to prioritize them. Also, there might be feedback received from conducting other activities like open Beta and closed beta. So Q Elite needs to make sure that it aligns with project goals, filter it, and share it with stakeholders. And the very important part is reporting. We need to make sure that we prepare comprehensive test reports, project readiness assignments, and share it with all the stakeholders. And now we're at the master milestone that signifies the final stage before production release, where all critical features are verified, defects resolved, and production readiness validated. What do we expect from QA team at this milestone? Verification that all features and functionalities are meeting specifications and don't have any bugs that are preventing the game from the release. The team confirms that all the bugs that were reported previously are resolved and the product is polished. And then Team performs the final validation, going through all the content of the game to ensure that product is ready for the release. Now, back to responsibilities of QA. First of all, we manage the final testing activities, making sure that nothing was missed, the full game was tested, and everything was completed. It happens very often that at final stage, the game still has some unresolved issues, so Keld needs to collaborate with all the stakeholders to make sure they are aware of it, and there are decisions made either to postpone release and fix the issues or release it and fix it later. Also, this is the time to raise your concerns about the state of the quality to all the stakeholders. And also, we need to prepare final test reports and readiness assessment for the project conclusion. So as a conclusion, there are a few things that are very important at every stage. First of all, is understanding of the scope and preparation of the testing coverage, and then making sure that all the stakeholders are aware of the state of the quality, able to understand your reports, and are aware of any issues that are present. 24. Testing. Milestones: Create some basic milestone criterias for our game. For this, let's create a new tab, call it milestone criterias. And start populating it with the data. Let's start with Alpha milestone and start with basic criteria. The first one is pretty basic that our game doesn't crash or doesn't freeze. This is pretty basic. Then two about our gameplay main functionality and gameplay is present. But for Alpha, we don't expect all the features to be integrated and implemented. So we add a small node one per instance. What is the meaning of this? Let's go to our VBS structure and see that the main features for us are multiplayer, general mechanics and game modes. We don't need all of this to be working. We just need to make sure that one instance of each is working. We don't expect online multiplayer and welcome multiplayer to be fully functional with eight players. We just need to make sure that it is possible to play the game in multiplayer mode. So we go here, multiplayer functionality, local, then multiplayer functionality online. Then we expect movement to be working. Then one level per each mode. Then let's make sure that we have some interactable objects that are also implemented. And same one per instance. The main meaning of it is that we have key boxes and jumpers as main interactable objects, but we don't expect all of the keys on all the levels to be working. We just need to make sure that general functionality for one key is working. So we copy it here done. Then we simply go by other functionalities. UI is functional. We also don't expect the functionality. We just expect menus to be functional. Then sound manager is integrated. So at Alpha stage, we expect some sound to be present in the game. Then we don't expect any visual at Alpha stage, but we do expect some performance. So at Alpha stage, we are hovering our target FPS. We don't expect it to be smooth, so there are no FPS drops. We owe 20. So we set our target to 20 FPs. Then we don't expect any compatibility to be integrated or vocalization and activities is more for a Q. So this is our Alpha milestone criteria. Let's just format it a bit. And let's add some data validation there. So we answer the drop down and we have two options. One is pass, another is fail. And we do the same for sub criterias. We also can group it for better tracking and then group this criteria. 25. Testing. Adding Criteria: The next thing, what we need to do is to integrate our criteria into our Jira project. We simply go to our project. Then we go to project settings, we find issue type bug, and we need to add any field that is a drop down. Alpha criteria, validation, and we need to put here all our criterias. And then we save it. Now let's see how it works. So let's go to our board, try to create a new feature, and we have Alpha criteria validation. So it works. The next step is to add the widget to our dashboard, let's edit, which is two dimensional filter, which is all unresolved box because in general, everything that was fixed is not so interesting for us. So for X, let's choose status for X, and for Y, we choose Alpha criteria validation. It appeared here. Number of result ten, and we safe. For now, we can see that we don't have any because we don't have bogs that have this criteria. Let's rename it COVID of validation. The change cover and what we need to do for box to appear here, we need to update this field in the box. So let's go to our project. For example, we have UI window is empty. We come to APhA criteria and we put UI isn't functional. And for example, it's let's put this criteria here as well. Now let's check our dashboard. So now we can see that we have bugs that are failing cover criteria because the best case is when all of them are none. So let's imagine we finished our Alpha validation, and now our dashboard looks like this. So we still have two criteria that are failed. We go to our report, we see that UI is not functional, so we put fail here and there are drops, we put fail here and there are no other issues, meaning everything else is pass. So we just pass everything that's how our Alpha milestone results will be working. Based on this, we'll be preparing the report and sharing it with other stakeholders. Now, let's prepare some basic beta milestone criteria. 26. Testing. Beta and Golden Criteria: Much easier to prepare better milestone criteria when we have VBS structure because in general, we just need to test entire game. So let's do this quickly. We have better milestone. So first criteria is the same. Second criteria is the same, but it's no more one per instance. Then we expect Welcome multiplayer to be fully functional and wine multiplayer to be fully functional, then we expect movement then we expect world endless and battle all the levels. Then we have interactable objects are implemented. No more one per instance, then we have something that is pretty new is content complete, meaning that all assets are integrated. And no holders remaining. Then we have UIs functional and for UI, we need all of the things. The next one is sound manager. It's no more integrated. Sound is integrated and functional and we just copy everything. Then we have visuals. Are integrated and functional performance is stable. No FPS drops below 60. Then the next one is compatibility is integrated. We had criteria and the last one is about localization. Ization is integrated. Let's do some quick formatting here. That's our basic Beta criteria. After the testing, it will be looking something like this. This will be pass. If we have no crashes, this might be O pass and then pass. This should be also O pass. There's some mistake in the formatting. Okay. Content complete pass, UI is functional. Maybe we have some bug with UI, so it will pass pass, but fail if there is one fail, that the criteria is failed in general. Sound is integrated, visuals are integrated, graphic testing fail, performance pass, compatibility pass, and vocalization is pass. And after having better criteria, you need to do the same with Jira, go there, and at the new field, we won't be doing it right now because it's exactly the same as we did for Alpha. And for Golden Milestone, the criterias are pretty the same because we check the main functionality. What we can do is that we can actually copy paste everything called Golden and add one criteria which is called O M dishes are fixed. Basically, this one criteria will be something that differs the state of the game on Beta and on Golden. Just a few words about the criterias. If you are working in the big company, you probably already have the criterias defined for you. So you just need to follow them. And if you are working in a small company, so it's up to you to organize testing and milestone path process. What is important is to make sure that your team fully understands your expectation and has a full visibility on how you are planning to perform milestone validation. These are just some basic criteria that were working for me my entire career. If you just create them for yourself and follow them, the life will be just easier for you. So that's all. Let's move on. 27. Testing. Prioritization: Finished creating the criteria and the testing now is in progress, there are a few activities that QLT is usually doing. Let's take a look at some of them. And first one is prioritization. Prioritization is vital in testing to optimize efforts, allocate resources effectively, and mitigate risks impacting project timeline. The development of the game is not perfect, and sometimes we face situations where we don't have enough time or people, so we need to allocate them properly. So as a key elite, you take this responsibility on yourself and make decisions. Prioritization allows teams to focus on critical areas, enhancing testing efficiency, reducing project delays, and ensuring quality deliverables within set timelines. There are various techniques for prioritization testing tasks exist, which is distance approaches and criteria. Let's take a look at some of them. First one is risk based technique. The main idea is in identifying and addressing high risk areas first. The next technique is called impact based. The main idea is prioritizing tasks based on their impact on critical functionalities to improve outcomes. Another one is called time based, and it is mostly based on considering deadlines and delivery schedules when prioritizing testing tasks for efficiency. The main idea of this technique is in ability of the QA lead to identify the most risky areas and test them first. The identification can be done based on on experience from previous projects on the analysis of the current state of quality, meaning checking the area that has the most bugs reported or after talking with development team and asking them about how the development is going and what they see as the most difficult area to implement. The main idea of this technique is that the prioritization of risky areas and additional testing ensures that high risk areas are thoroughly tested to minimize potential failures, enhancing project success and quality assurance. Let's check some examples from Pico Park. And let's imagine that after discussion with developers and based on own experience, we identify two areas that are the most risky. First one is online multiplayer. Multiplayer in games is always a risky area because it requires having the server, stable connection, and other details. Another area is compatibility, meaning that different platforms require different settings, and we identify this area as risky and expect a lot of bugs to be there. So we need to test it more thoroughly. Moving to the next technique, Impact based prioritization technique mostly focuses on testing tasks based on their impact on critical functionalities or user scenarios. In simple words, we prioritize testing of the areas that might have the biggest impact on user experience and their expectations. And as a result, after making sure that we tested all these areas, we increase the possibility of the project success. Let's take a look at some examples. And for the Pico Park, we have next example. First one is testing system performance because crashes or pass drops might impact the user experience a lot. Then the next one is, of course, walk through evaluation. Walk through is the main thing, and if users have blockers in their pass, it's not going to be good for the project. And the last example is connectivity check, making sure that all the players can connect to the server and play together, making sure that people can play with their friends. Okay? Moving on. And the time based prioritization technique is mostly using time as a main base. In simple words, we are testing all the features based on our timeline and development schedule. As we have our criteria for different milestones and we have planned features to be developed in the timelines, we're mostly focused on testing particular features to make sure that the project is still on track and all features received enough testing time. The main examples from Pickle Park are milestone testing as we perform validation at the end of each milestone. The next one is sprint content testing, meaning that for each sprint, the development team has a plan of activity they plan to implement and integrate, and we as a QA team are making sure that everything goes according to the plan. The last one is the coder activity testing. Sometimes in the process of development, different people want to make sure that some things work or they want to have additional build to be shown somewhere on some promotion activity. They might ask elite to test some specific missions or areas of the game. This is just a rough overview of the prioritization and in real life, you will be facing a lot of scenarios where you need to make decisions, what to test, and what to skip. I hope this can help you in understanding where you should focus first. 28. Testing. Triage Meeting: Another important activity that is not always happening on the project is BC drag process and stakeholder meetings. What is bug triage in general? It is a crucial process in the development that helps to prioritize and manage bugs efficiently. By assigning the right priority to bugs, teams can ensure the timely delivery of high quality products to stakeholders. Let's see all the elements of the process. First of all, we need to test the game and identify all the bugs that we're interested in. Then the team sits together, go through each and every bug and set the severity and decide the impact of each bug to determine its priority. The team can use milestone criteria or any other type of criteria depending on the situation. And as a last step, all the trash bags are assigned to the property member or the team based on their severity and priority. BAC triarch significantly influences product quality, release timelines and stakeholder satisfaction. Prioritizing and managing bugs effectively through triage process contributes to a smoother development cycle and ensures the high quality products are delivered on time to Mr. Expectation. BG Trias is done through stakeholder meeting. It is a platform for decision making and alignment among project stakeholders. These meetings facilitate discussions on bug prioritization, resolution strategies, and overall project progress, ensuring that stakeholders are informed and involved in bug management. It is important to involve key project stakeholders such as project owners, development teams, and business representatives. By involving stakeholders in back drag discussion, team gain valuable insights, qualify requirements, and align on the priorities. Who should be present on these meetings? Usually it's product owners, project managers, developers, testers, and other relevant stakeholders. It is either QE lead or project manager is the main facilitator of these meetings. During these meetings, collaborative decision making process take place to prioritize bugs efficiently and allocate resources based on project needs. Stakeholders collaborate to identify critical issues, evaluate their impact on project goals, and collectively determine the best course of action for bug resolution. This collaborative approach ensures that bug drier decision aligns with project objectives and stakeholders expectations. Simple words, if you just sit together in the meeting, go through the list of the box. For example, we have ten bucks and define which ones are crucial to be fixed as soon as possible. As the outcome, you'll be having something like four bucks, high prio, three bucks, medium prio, three bucks, low prio. All of the main people understand what to treat first and what are the next steps. 29. Testing. Environments: Let's move a bit and talk about software environments. Probably you already know something about it or faced it already in your career, but let's talk about it more in detail. What are the environments? They are dedicated setups used for different stages of the development life cycle. These environments replicate the infrastructure and configurations required for testing, validation, and deployment of application. Let's go through some of the main environments that are present in game development. First one is development environment where coding and programming occur. Then we have testing environment for software and game testing and bug identification. Then we have staging environment for final validation before release. Also, we can have UAT environment where we place our product and give users access to check their experience. And of course, we have production or live environment where the final user can play the game. Let's check them more in detail. So what is the development environment? This environment is needed to write code. This is the main branch where developers create the game. Then different developers integrate their change to ensure compatibility and functionality. Also, we are able to test different components in this environment. From time to time, developers put their updates into the testing environment branch. This is usually up to Quill to decide how often the updates has to be done. I personally asked developers to update testing environment twice a week. What's the main purpose? First of all, we do functional testing in this environment. Also, we perform integration testing, and we are trying to test it like end users. After all the testing is done on the testing environment, we push the updates to stage environment. The staging environment is crucial for validating everything before deployment to the live environment. It mirrors production settings and alls stakeholder to review and approve updates before the release. Also some projects have user acceptance testing environment. This is a place where end user or client representatives validate the game against business requirements and usability criteria. UAT feedback helps ensure that the software aligns with the user expectations prior to development. And the last one is production environment. This is the final destination of our project. These environments do not appear from nowhere and are not standard across all projects. The development team, together with other stakeholders, need to set up and configurate them properly. It requires careful planning and consideration of project requirements. This involves provisioning hardware and software resources, configuring network settings, and deploying necessary tools and applications. Managing and maintaining software environments is an ongoing process that requires regular monitoring and maintenance. This includes ensuring stability and reliability, ensuring security of environments, tracking changes and updates through version control and configuration management, and fostering collaboration between development QA and operations team for effective environment management. Real life, the process is pretty simple. You have an environment where developers produce the game. As a Q elite, you come to them and ask them to push everything to testing environment. After that, you perform testing and main bug reporting. When everything is done and all bugs are fixed, the team pushes everything to stage environment that replicates production environment as much as possible. When the testing is finished there, you just say go and the game goes live. 30. Testing. General activities: Besides different rules and events, you as a Q elite, also have to plan different testing activities for your team. Testing activities encompass a range of processes performed to validate software functionality, access performance, and ensure quality throughout the development life cycle. Each testing activity serves a specific purpose in detecting defects, mitigating risks, and enhancing the overall user experience. Let's explore the K testing activities and their optimal timing in the development process. Functional testing goes beyond simply verifying software against specified requirements. It delves into ensuring that the core functionality aligns with user expectations, covering gameplay mechanics, interactions, and progression. It is conducted during development iterations and before major releases to ensure core functionality meets requirements. Functional testing in Pico Park involve intricate checks on gameplay mechanics, user interactions, and level progress. Beyond checking new change, regression testing safeguards existing functionalities from unintentional disruptions. By verifying previously fixed bugs and core gameplay features, alongside testing compatibility with various devices, this process maintains system integrity and enhance user experience reliability. It is conducted after code changes or updates, including bug fixes, feature enhancements, or system updates before major releases. In development cycle, regression testing not only ensures new changes do not impact existing functionalities adversely, but also validates the stability of core gameplay features and address compatibility with different devices. Performance testing evaluates the software's responsiveness, stability and scalability under diverse condition, showcasing its reliability under variant user watts. By simulating scenarios like server wat handling and multiplayer performance, this phase ensures the system's optimal functioning and scalability before release. Usually, it is conducted during the latter stages of development to evaluate system performance and scalability before release. Throughout performance testing, Pico Park undergoes rigorous evaluations on several at handling and multiplayer performance to assure optimal responsiveness, stability, and scalability across variant conditions. Usability testing focuses on evaluating the ease of use and overall user satisfaction. Through assessing aspects like QR design, control responsiveness and player feedback, this phase aim to optimize the software interface for an intuitive and satisfying user experience. It is conducted during the later stages of development. Visibility testing in Pico Park involves in depth evaluation of user interface design, control responsiveness and player feedback. Security testing aims to identify vulnerabilities, weaknesses, and potential security threats within the software to safeguard sensitive data and prevent unauthorized access. It is conducted throughout the development life cycle with a focus on early identification of vulnerabilities and continuous security assessments. Compatibility testing verifies that the software functions correctly across different devices, browsers, and platforms to deliver a consistent user experience. It is conducted during the latter stages of development. In Pico Park, compatibility testing involves testing on various operating system, devices, screen resolution, and network configurations. And then the exploratory testing. It involves ad hoc testing techniques to explore the software functionality, uncover defects, and access usability issues in real time. It is conducted throughout the development life cycle with a focus on earlier defect detection and continuous improvement. 31. Risk Management: Important area of responsibility for Kid is risk management. Let's dive deeper into this matter. First of all, we need to understand what is the risk. Risk is a potential event or circumstances that may impact project objectives. So what is risk management? First of all, we need to identify risks. It involves recognizing potential risks that could affect project goals. Then we need to assess the risk. It means that we need to evaluate the likehood and impact of identified risk through quality and quantitative analysis. The next step is risk mitigation. It means that we need to implement strategies to reduce the impact of the risks on the project outcomes to ensure success. And the last step is continuous monitoring. It is ongoing survival to track and manage risks effectively throughout the project life cycle. Effective risk management begins with sorrow risk identification. Techniques like brainstorming, reviews and data analysis help uncover potential risks. In projects, potential risks include resource constraints, affecting project timelines, scope change leading to requirements, ambiguities, and technology dependencies impacting project delivery. Recognizing these risks early enables effective risk management strategies. Then we move to risk assessment. Conducting risk assessment is crucial in understanding the potential impact of identified risk on project objectives. Methods like qualitative and quantitative analysis help evaluate risks based on their likehood and severity. Quality analysis assess the likehood and impact of the risk subjectively, while quantitative analysis provide a more data driven approach by estimating probabilities and severity levels. When we have all risks identified and assessed, now it's time to choose the strategy. Here are the main types of the strategy. First one is avoidance, meaning that we are trying to avoid the risk entirely, but not engaging in the activities that possess the risk. Main example here is that we might not want to add a new feature if we don't have enough time to test it, and it might contain box. So it's better not to add the feature, avoid the risk of having additional issues. Another one is reduction. It means implementing measures to decrease the likehood or impact of the risk. Next one is transfer, shifting the risk to another party, such as through insurance or outsourcing. Same example goes here. If we don't have enough time to test the feature, maybe we should hire additional team to perform testing. And the last one is acceptance, when we choose to accept the risk and its potential consequences without taking specific actions. In addition to risk management, we need to understand the difference between project risks and product risks because understanding the distinction between it is crucial for effective risk management. Project risks are factors that may impact the successful completion of a project while product risk are related to issues affecting the quality, functionality, or usability of the pino product. Let's take a deeper look at the project risks. First one is scheduled delays. It is a potential delays in the project timeline, impacting overall completion. Then budget overruns, meaning exceeding the allocated budget leading to financial strain. Then we have resource constraints when we have limited availability of personnel or material affecting project progress. Next one is scope risks when project requirements extend beyond the initial scope due to changing stakeholder expectations. And the last one is external factors that are influences from outside the project teams control impacting outcomes. Now, let's talk about product risks. The first one is functionality issues. They are the main concerns related to the product's core functions and features. Then is usability challenges that are difficulties in using the product effectively and intuitively. The next one is performance bottlenecks. There are other issues hindering the products bit and efficiency. And the last one is security vulnerabilities, threats to the product data protection and user privacy. Now let's implement small risk tracker for our project. 32. Risk Management. Risk Log.: Create risk log for our project. For this one, we are going back to our Excel and start with main fields. First one is risk ID because every risk needs to have its own unique identifier. Then we have risk summary or risk description. We want to know if it's a product risk or project risk. So we have risk category, then we want to have impact of the risk, like whoood and severity. After this, we need to choose the mitigation type and mitigation strategy. And main things that we also want to know is a contingency plan, owner, and status. These are our main categories that we would need to have for every disk. Let's imagine a few different risks that we based on our experience, foresee that might happen in our project. So risk 001, risk 002. The first one and something that happens almost all the time, that's a problem with multiplayer. Let's imagine that our multiplayer does not sing properly with all eight players in the session. Then another problematic area is compatibility. So let's imagine that our Game UI does not work properly on mobile devices. Let's add some performance risk. Then let's imagine that we might not have enough people in our company to test the game. And let's choose the worst one. And this is also something that usually happens. It's delays in implementing vocalization for different languages. This is just a basic list of things that come to my mind. Usually, when the project starts, you as a key Eelite sit down and think of all possible risks that might happen. Sometimes you do a branch term with the team, maybe with the stakeholders. It usually depends on the scale of the project. So let's fill the information for each risk. Risk category. If it's multiplayer functionality, this is product risk. Impact. Always. If it's something about gameplay and multiplayer, it's high impact. Whood of it to happen. It usually depends on the expertise of the team. Let's imagine that we have pretty good team. So this is medium likehood. Oh severity. Severity is critical. So mitigation type and mitigation strategy. We cannot avoid this risk because we need multiplayer functionality, and we cannot ignore it or transfer to someone else. All we can do is to reduce the probability or the impact. What can we do? We can conduct early multiplayer stress tests and also we can ensure server stability with mock players. If nothing works, all we can propose is to delay multiplayer launch if necessary, or limit session size temporarily. The owner will be QA Elite, as he will be the main person to know about this risk and to have all the data as soon as possible. Status, let's keep it open, and let's move to another risk. Game I scaling improperly on mobile version. This is also product risk. It has not that high impact, so let's go with medium. Like hood is pretty high based on my experience, and severity is also pretty high. For mitigation type, this is the same story. We go with reduction and think about mitigation strategy. The main thing here is to try to cover as many devices as possible on early stages. So what we need to do is to test it on different devices. Also, we can use simulators to simulate all possible combinations of phones. For contingency plan, this is pretty the same. We can delay mobile release. The owner is most likely UI let who needs to think about different ways to rescale the UI and the status open. Let's move to decent FPS drops. Also product risk impact is high because performance is always high. ICT is medium, and the severity is critical. Same mitigation type, and let's think about mitigation strategy. The best mitigation strategy is to optimize graphics and well design to make it less intense. Contingency plan is to reduce visual effects or textures for low and devices. The responsible person is either main developer or tech lead, and status is also open. Testing team is not able to meet testing deadlines. This is project risk. Impact is medium, HD is also medium, and severity is also medium. Reduction mitigation type won't help here, so we are going to use transfer. If we won't be able to meet the deadlines, we are going to ask for third party testing services. For contingency plan, we need to prioritize main activities for our team and give the rest to the outsource team. Even due to the fact that it all needs to be managed by Q Elite, in JIF, this is up to project manager to get this additional team and mitigate this risk. And it's motto our final risk, delays in implementing localization for different languages. This is also project risk impact is high, because some people might not be able to play the game without their preferred language. Why who you? Well? Because usually we outsource all the languages to same people and they prepare all the languages, but maybe something happened and they don't have the specific language and severe is medium. For mitigation type, we need to avoid this risk as soon as possible. For the strategy, we need to begin localization as early as possible or hire additional localization partners. For contingency plan, we might want the game in primary language first and adding other post release. And the owner of this risk is vocalization lead. For example, this one be in progress. So this is the main idea of our risk and risk mitigation strategies. Let's make it a bit more beautiful. Good. Now we have all the things highlighted in the red that are high, and this is our basic list of the project risks. Let's move? 33. QA Team. Communication: Moving to the communication part. Sometimes, I think that communication is something that you train throughout your entire life. But still, there are some techniques that you can use to improve collaboration inside your team. Effective communication within the QA team is fundamental to the success of QA processes, facilitating bug reporting, death planning, and node sharing among team members. By fostering clear communication channels and promoting collaboration, teams can ensure productivity, reduce misunderstandings, and achieve project goals. Effective communication leads to improved collaboration, reduce misunderstandings, and enhance productivity within the QA team, ultimately contributing to the success of quality assurance project. There are a few key moments in fostering clear communication, such as establishing regularity meetings, define communication channels, and transparent reporting practices. Here are a few examples of clear communication practices. First one is stand up. It is a short daily meeting to align on tasks and address issues. If you're in the office, you can gather the team around you, take a cup of coffee, and just discuss all the main things. It also can be done via online meetings. Another type of meeting is retrospectives. It is a regular review to reflect on progress and identify improvements. Also, you can conduct peer reviews. It is a feedback session to improve quality and collaboration. Collaboration and node sharing within the QATm are vital for maximizing efficiency and maintaining quality standards throughout the project life cycle. Let's take a look at some examples how to encourage the teamwork for quality deliverables. You can try to use pair testing. It is a collaborative testing method involving two and more testers working together to enhance testing efficiency and quality. Different people might have different opinions on the way how to test the same feature as well as working together with someone might bring more joy to their work. You can set up knowledge sharing sessions in your team. It is interactive sessions where team members share their experience, best practices, and insight to enhance team knowledge and skills. And also, don't forget about innovation by promoting creativity and novel ideas within the team to drive continuous improvement and unique solutions. Let's talk about another type of communication that does not include actual speaking. It's a transparency in bug reporting because transparent bug reporting is crucial within the QA team for effective issue tracking, prioritization of fixes, and maintaining visibility on project status. The main elements of transparent bug reporting are keywords, clear summary, detailed bug descriptions, clear step to reproduce, and timely updates on bug status. By following these practices, you can provide more collaboration inside the team and make sure everyone understands the current situation on the project. Also K lead is included in a lot of different other conversations. Let's take a look at some examples. You'll be talking to development team a lot. You need to maintain regular communication with the development team to understand the status of ongoing development, upcoming changes, and potential areas of risk. Klits collaborate closely with the developers to ensure the testing efforts align with development timelines and priorities. Then you'll be talking a lot to product management. You need to gain insights into project requirements, user stories, and feature priorities. Q Et participate in requirements gathering sessions, clarify ambiguities in requirements, and ensure that testing efforts adequately cover all aspects of the product. Then, of course, you'll be interacting with other QT members. You'll be providing guidance, support, and mentorship to other QAT members. You'll be coordinating testing activities, distribution of tasks, and review tpan and test cases. Then K Elites communicate with project stakeholders, including project managers, clients, and business analysts to provide updates on testing progress, report defects and issues, and address any concerns or questions related to quality assurance. And in case where external vendors or contractors are involved in testing activities, K Elite serves as a primary point of contact. They coordinate testing efforts, provide necessary documentation guidelines, and ensure that external teams adhere to project standards and requirements. Let's take a look at case strategies for improving communication within a project team. Make sure you schedule regular meetings with case stakeholders to discuss potential status, priorities and concerns. You can ask them how often they want to hear about these updates. Use clear and concise documentation to communicate testing plans, test case, defect reports, and other relevant information. This ensures that all stakeholders have access to essential information and can stay informed about the project progress. Actively listen to the concerns, feedback, and suggestion of team members and stakeholders. By listening attentively, K leads can better understand the needs and perspectives of others and address any issues or challenges effectively. Maintain transparency in reporting testing progress, defects, and quality metrics, provide regular updates and reports to stakeholders, highlighting achievements, challenges and areas for improvement. With devise collaborative tools and platforms such as project management software, issue tracking system, and communication channels to facilitate communication and collaboration among team members and stakeholders. And establish do mechanism to encourage open communication and continuous improvement. Encourage team members and stakeholders to provide feedback on processes, workflow, and communication practices, and take action to address any issues or suggestions raised. Of course, this is just a brief overview of main communication strategies. Just make sure you're friendly and polite in your communication style, and you will be able to solve any problems that arise. 34. QA Team. Composition: Next topic is effective atm composition and management. Let's check the details. Effective at composition is crucial for ensuring quality in game development. Key roles like QUALD testers and analysts, as well as essential skills in technical proficiency and domain knowledge play a vital role in the success of the project. Let's go through the key roles in QA team. The first one is QA lead. The main characteristics are strong leadership and communication skills, extensive expertise in QA methodologies and practices, and ability to prioritize tasks and manage resources effectively. Then we're moving to QA testers. Their main responsibilities are executing test cases and scenarios to identify and report defects, conducting regression testing and verifying bug fixes and providing feedback on the game features, usability and overall quality. Then we might have automation engineer. They are capable of developing and maintaining automated test scripts, integrating automated tests into the pipeline, and identifying opportunities to test automation to improve efficiency and test coverage. And the last but not least K Analyst, and he's in charge of analyzing game performance metrics and player feedback to identify areas of improvement, collaborating with developers and designers to address quality related issues and contributing to test planning strategy, and documentation. Clear position and responsibilities within the QA team are vital for accountability and efficiency. Each role contributes uniquely to test planning, execution, automation, and performance analysis, enhancing the overall quality assurance process. As a Q elite, you need to have a clear definition of the seniority in the team. Firstly, because you need to know whom to hire in your team, and then you need to have a clear development plan for your team. Let's see the main differences in the seniority. Senior KA testing. Main responsibilities are leading test efforts for specific features and components, mentoring junior testers and providing guidance, and assisting the QED in test planning and strategy development. What is the expectation? Several years of experience in QA testing roles, strong knowledge of testing methodologies and best practices, and proven abilities to testing efforts. Let's move to mid level QA tester. Main responsibilities are executing test cases and scenarios to identify defects, conducting regression testing and verifying bug fixes and providing feedback on game features, usability and overall quality. What do you expect from his seniority? 2-5 years of experience in QA testing roles, proficiency in testing methodologies and tools, and ability to work independently and collaboratively with a team environment. And Junior tester. Main responsibilities are assisting in text execution, bu verification, and documentation, then learning KA processes, methodologies and tools, and then providing support and contribution to overall testing efforts. We don't expect much from seniority because Junior K tester is an entry level position suitable for individuals with limited experience in K and testing growth. Basic understanding of software testing principles and eagerness to and grow in the field and strong attention to detail and willing glass tour. Let's have a quick look on automation engineer and his responsibilities. First of all, he is responsible for developing and maintaining automated test scripts to ensure efficient testing process. Then he is integrating automated tests into continuous integration, continuous development pipelines for seamless testing and also identifying and implementing opportunities for test automation to enhance testing efficiency and effectiveness. Now let's take a look at QA Analysts. This is pretty rare position, but still we need to have a knowledge about its basics. This position is responsible for analyzing performance metrics to identify areas for improvement and optimization. Then K Analysts collaborates effectively with other teams to ensure alignment on quality standards and testing strategies. He also contributes to test planning by developing test cases, scenarios, and strategies for comprehensive coverage. And then one of responsibilities is creating and maintaining detailed documentation for test cases, results, and processes for reference and audit processes. Besides mentioned positions, there are other specialized teams that might be used on the project. Let's take a brief overview of various testing roles within a QATeam. Security tester conducts security assessments and penetration testing, identifies vulbilities and collaborates with developers to enhance software security. Performance tester designs and executes performance tests to assess systems capability, identifies bottlenecks, and recommends optimization strategies. Localization tester validates translated content accuracy tests for language support issues and collaborates with vocalization team for linguistic resolutions. Accessibility tester ensures software accessibility compliance, conducts usability testing with assistive technologies and advocates for inclusive design practices. Usability tester conducts security studies, gathers useful feedback for improvements, and collaborates with design team for enhancing user experience. And compliance tester ensures software compliance with industry regulations and standards, documents compliant findings, and prepares regulation submissions, constantly collaborates with regulatory affairs and G teams to address compliance issues. Now, let's create a team composition for our project Pickup Park. 35. QA Team. Composition creation: General, the project is not that big, so we don't need many people to be present on the project. We can go back to Twine and see our basic resource planner. So we expected to have 600 hours and to have two resources. So we can start with this copy it, create some basic formatting. Resource one and resource two. We just need to define the seniority of these resources. There are two ways how we can create this team composition. So let's create variant one and variant two. In our first variant, we have QA lid who is not working full time on this project, but he just takes care of how everything goes. So we put here QA lead part time. In this case, resource one that starts first can be middle position. And resource to that starts later. He just joins helps with testing so we don't need another middle. We can help junior QA. Don't know much support. So this will be our main plan for this Then let's imagine that we don't have Q LED in the team. In this case, we can have Senior K who partially covers QLED responsibilities. And then we also just add another Junior QA. To support senior with everything. These are two variants that might work good. First variant, we have K led that performs supervision and middle K tester who performs most of the job with the support of the junior. In our second variant, we have Senior KA who covers a lot of organizational part from Kleid performs most of the testing and has Junior K as a support. Then we might have optional positions that will work for both, such as vocalization, testing, tester and performance tester. We can invite them to perform quick pass on the final stages of our project. As project takes just a few months, we don't need automation tester because creating automated tests might take a lot of time and we won't be beneficial from it, as well as we don't need QANOS as requirements are not that complicated. Let's do a quick formatting. This is pretty simple composition for pretty simple project. 36. QA Team. Engagement: Was always special to me as a elite to make sure that people in the team are not only doing expected job, but also have a feeling that their work is appreciated in the team and they are in the good environment and have good people around them that support them and help with everything. In quality assurance and every other team, effective people management is vital for ensuring high quality deliverables, maintaining team morale, and fostering a culture of continuous improvement. There are a lot of different theories of engagement, but I like to stick to this six pillars engagement model that helped me a lot in my career, empowerment, pay recognition, attention, challenge, development, and sharing the big picture. Let's take a look at each of them. Empowerment in people management involves providing autonomy, authority, and resources for employee to make decisions and take ownership of their work. Empowering team member leads to increased job satisfaction, higher motivation levels, and enhanced productivity as they feel valued, trusted, and capable of contributing effectively to the organization's success. Effective recognition is essential for employee satisfaction and motivation. Recognizing employees' contribution boost morale and encourages continued excellence. Fair and consistent recognition reinforces a positive work culture and enhance employee engagement. Meaningful recognition involves regular feedback, public acknowledgment, and tangible rewards. Implementing diverse recognition strategies create a culture of appreciation and boost team performance and loyalty. Attention is about actively listening to our team members, understanding their needs, and addressing their concerns. By showing genuine care and interest, we can build trust, strengthen relationships, and promote a supportive work environment. By actively listening, showing empathy, and maintaining regular communication, managers can demonstrate care and understanding for employees needs, concerns, and feedback. Active listening, empathy, and regular communications are key practices in building strong relationships and promoting employee engagement. Challenge is about providing our team members with opportunities to grow, learn, and excel. When employees are engaged in challenging work that align with their skills and interest, they are more likely to stay motivated, innovate, and committed to their roles. Changing and meaningful work assignments push employees to expand their skills and capabilities, fostering personal and professional growth. Providing challenging work assignments not only stimulates employees development but also helps in retaining top talent. Development is about investing in our team members long term success and career growth. By providing opportunities for learning, skill building, and advancement, we can enhance employee engagement, retention and satisfaction. Let's take a look at some of the ways of employees development. First of all, it's training, investing in employee training programs enhanced skills and knowledge. Providing mentorship, cultivates relationship and guides career progression. Creating opportunities for career advancement motivates employees to excel. Developing individual development plans tailors growth strategies to each employee. Sharing the big picture is about connecting our team members day to day work with the organization's broader mission and vision. When employees understand how their contribution impact the overall goals and objectives, they are more engaged, motivated, and aligned with the company direction. And remember, if your team is well engaged, every project will be successful. 37. The end: So we're finished everything that was planned. I want to say thank you for everyone who stayed here with me and to say that you can contact me everywhere you want, for example, in Linkin. If you have some other questions or clarifications or the feedback. I know that my voice is not the best one to do courses and I try to make it sound as queer as possible. So I want to say sorry if it was not queer enough for you. I tried to show you examples of all my knowledge that I used to gather in different companies from company to company. There are different needs and the ways how you do your job. So I try to bring all the best from all the places I've been through. What I wanted to say is that practice makes everything better. So do not hesitate to get any game and try to do the same. Create test plan, to create planning, WBS structure because no one is perfect from beginning, and you need to keep trying to get to the place where you want to. In general, Ted position is pretty interesting and inspiring. You're in charge of the quality of the game, and you are the person to make sure that the entire team has a full understanding and visibility where the game is. And, of course, don't forget to be an example for your team. You're their mentor, you're their manager, to make sure they feel comfortable, inspired and engaged. I wish you luck in all your journeys, and I hope you're going to achieve what you deserve. See you.