But you sound more in the now about their internal processes, so you’re probably right and I misinterpreted what they meant by that quote.
The general summary of how “bugs” work in software development is simple at a high level.
Someone reports the bug (developer, qa, player, user, etc)
Someone prioritizes the bug
Lower priority issues are put on a backlog to potentially be worked on later
Higher priority issues get fixed (most of the time)
The product releases when an acceptable level of bugs from steps 3 and 4 are reached, and “acceptable” never means zero or even close to it.
So, the developers have a pretty good idea of how many bugs there are, in addition to the more general sentiment that the people testing have about the stability of the game.
The general summary of how “bugs” work in software development is simple at a high level.
The product releases when an acceptable level of bugs from steps 3 and 4 are reached, and “acceptable” never means zero or even close to it.
So, the developers have a pretty good idea of how many bugs there are, in addition to the more general sentiment that the people testing have about the stability of the game.