New
#21
Hi all
You can consider RTM as like a QC (Quality control) system before moving an application to a live / production system.
I'll slightly over simplify it here but essentially most IT projects follow the following line when developing a new application / fixing an old one.
You have 3 systems Development, Test (or QC) and Production / Live.
Development is done and finalized in DEV. The build is the migrated to TEST or QC where live / power users test it and try to break it. If it passes the build is then deployed into the live system.
You can consider the RTM as the QC version -- not quite retail as it's in final testing but if no significant problems are found this will essentially be the same version as will be released to RETAIL.
(In a real world environment the actual process is slightly more complex as you have to do "Regression Testing" - this is checking that a fix you apply doesn't break something that has been previously fixed which can happen if a second change is made to a module that's been previously changed by an earlier fix) but conceptually the 3 step process is correct.
Incidentally you often experience "regression" problems in complicated software builds like an OS -- you can even see cases of these on the forums. This happens when people say xxxxx was fixed in build yyyyyy but seems to be broken again in build zzzzz.
Hope this clears up some of the muddle.
Cheers
jimbo