Transcription
Hello everyone, this is Vera. In the last video, we discussed the requirements for games and the various documents in game development. Now, I suggest we learn how to test these requirements, what they should be like, and what engineers should pay attention to during the testing process.
So, a brief introduction: why is it important to test requirements? Looking at the diagram, I agree that the statistics aren't great, but still, most errors stem from our requirements. Therefore, we need to address this issue to avoid future problems, such as unclear requirements, frequent changes, last-minute modifications, and misinterpretations of those requirements. All of this can lead to project delays, incorrect implementations, uncontrolled changes, and a team that doesn't understand what to do.
To prevent all of this, we need to ensure that the requirements are complete. Requirements should contain all the necessary information for all team members. They must be clear, understandable, and non-contradictory. There shouldn't be a situation where something is described one way at the beginning, then differently in the middle, and finally something entirely different at the end.
Requirements must be precise, clearly indicating what needs to be done in our game. They should be modifiable without affecting other requirements. They must be feasible, balancing value with required resources. We should be able to trace the connection between requirements and other project artifacts. Each requirement should have a unique identifier for easy tracking.
Additionally, requirements must be unambiguous. We shouldn't have phrases like "it should work correctly." "Correctly" is subjective. There should be a clear way to verify whether the requirement has been met. Requirements should also be prioritized based on stability and urgency.
For example, we have a requirement for interaction with an item or character. This is vague. A better version would be: "The player hovers the cursor over the object and presses the 'E' key." The type of interaction depends on the object type. For instance, a character might have a dialogue, and we reference the dialogue requirement. A merchant might open a trade window, and we reference the trading feature, and so on.
So, how does testing requirements begin? First, we test for clarity and precision. Testing requirements can start with a surface review of the document. While this isn't exactly testing, you can often identify issues at this stage.
Let's start with a simple scenario: you begin reading the requirements, and right from the first lines, you have numerous questions. The game designer might say, "Read the entire document first." But if you still have questions after reading it, ask them. Ensure that these corrections are made so that other team members don't have the same questions after reading the documentation.
There should be no questions left after reading the document. Requirements are like a code of laws for the product, and laws should not allow ambiguity or inaccuracies. The documentation must provide clear information on how each feature and the entire product should work. Unfortunately, after reading most documents, a number of questions remain, but this is solvable.
Next, we test the requirements for logic. The system's operation must be logical. A user shouldn't be able to access the alpha version without completing a tutorial or at least a small cutscene. This sounds elementary, but it happens.
Draw a rough flowchart of the system's operation according to the requirements and ensure there are no logical gaps. Make sure the main functionality is described in the requirements. Ensure that the interactions between system modules are correctly described. Also, don't forget to decompose the requirements; this will help you write quality test cases.
Next, we look at possible scenarios. The documentation should detail both obvious and non-obvious use cases for our system. Obvious positive scenarios include correctly entering a username and password. A non-obvious negative scenario might be entering incorrect login credentials or not providing any data at all.
These are simple examples. Often, issues like error messages and system behavior during connection loss are overlooked. For instance, if there's a loss of internet connection, our game should behave correctly, without errors or freezes.
In the worst case, there could be reputational and financial losses. We understand that if the internet connection is lost, the game should display a message indicating the loss of connection so the player knows what happened.
How do we test this? Draw a flowchart for a specific module of the system, outlining all possible conditions and user actions. Ensure that the requirements describe each possible scenario. If they don't, clarify the expected system behavior for those scenarios and ensure the game designer adds this to the design documents.
It's also important to highlight integration with third-party services, as this requires going beyond just checking the documentation. Before starting development, the statistics collection process usually involves studying how these strict systems work and then describing how this system interacts with our product.
In this case, the likelihood of errors is high, especially if the developers or other team members haven't used the third-party service before. Mistakes can happen on both sides: the developers and the staff of the third-party service who provided consultation and wrote the documentation.
The main principles of testing all requirements involve conducting tests before development starts. You need to estimate the time required for testing the requirements and ideally freeze the requirements until testing is complete. This isn't always possible, as requirements can change during development. Those who wrote the requirements and the developers might overlook certain aspects, leading to slight changes.
It's best to conduct requirement testing with multiple cases simultaneously. This reduces the risk of human oversight and helps refine the document. Logging defects based on documentation is no different from logging defects based on the product. Bugs should be entered into the bug tracking system as usual, especially when requirement checks are happening alongside development. Notify the development team of any defects found in the requirements so they can correct them in time.
The level of detail in the requirements greatly depends on the project's scale, as does the depth of testing. There's no point in checking the response time of a button in a project that has just launched unless it's related to key functionality.
That's the theory behind testing requirements. In theory, it may sound complicated and unclear, but with practice and experience, it becomes easier. If you want to practice and learn how to test requirements effectively, I invite you to a workshop where we will test real requirements for a real product written by actual game designers. I'll leave the link in the description below this video.
Thank you very much for watching! If you found this interesting and useful, please like and subscribe. Don't forget to hit the bell icon so you don't miss the next video. Our next video will be about test documentation, bug reports, and we will also cover checklists, test cases, and test plans. See you soon!