When doing QA testing, past resolved bugs are often retested to make sure that new fixes don't cause them to reoccur. As this would make the test list grow uncontrollably large quickly, how do you decide when to no longer retest an old bug? And thanks for all the good work.asked by Steve Hunter

Thanks Steve!

This is actually a really good question. So when it comes to that, usually we focus on areas that have been affected by recent code changes, like recently Mark McCall came to me said hey, we've done a bunch of changes to landing gear, so that immediately tasks us out to start focusing, checking all those old landing gear issues to make sure that those don't recur, because you know of the changes that he just implemented, to make sure that previous fixes didn't get stomped on by new changelists and so on. So i mean, that's pretty much, we try to stay focused on the things that're in motion and are still changing, and then if something hasn't changed build after build after build, we're not necessarily going to be looking at all those old issues again. If they do return we'll reopen them, but we don't necessarily focus on them.

Yeah and that's the thing, it's like I know, once the bugs have been through their paces, they've been resolved and fixed, once it hits a new area if we see it again we'll check the database and be like, okay, this is back, and in all honesty there've been some bugs, especially with landing gear in particular that the landing gear comes back so many timesVS: That's why I brought it up, cause poor Mark has been banging his head against the wall, I swear to god some of these bugs spend time in the Lazarus pit and rise up stronger than they were before, it's just unbelievable with some of them.

It is pretty crazy.