Risk Based Testing in Gamedev: Does it happen otherwise?

What the talk is about

Oleksandr Donchuk argues that game QA should use risk-based testing as a supporting model alongside classic test cases. Near release the game keeps changing, there are too many scenarios, time is short, and quality expectations stay the same, so full coverage is impossible. He recommends building a risk list in advance through a team brainstorm with developers, then prioritizing it. A simple model multiplies three factors: defect severity, difficulty of fixing, and likelihood of occurring; likelihood defaults to one. Checks are run from the highest priority down. In the Q&A he clarifies that defect cost means damage to the product, not the cost of fixing it. Useful for QA engineers and leads.