In my point of view, the time depends on the defect 
severity and complexity

Depending on the functionality of the code. if it is 
specific to some output then will go for automation of it 
my writing own script, eg., using rational robot for web-
based application. 

if code is to generate random values accepts only values 
from 1 to 100 and A to Z char does not accept any special 
characters or unicode charactes with respect to 
localization and globlization, then i check whether the 
code is hard coded or not. To check a single test case with 
1 to 2 minutes of time is enough. say enter 1 and you get 
xxxxyyyxxxyyxxxyyxxyy and when you enter the same number 1 
for the next time it "should not be" as 
xxxxyyyxxxyyxxxyyxxyy it should be some thing diffrent.

the time is depending on the new functionality is added and 
no . of fixed bugs

The re-execution of
selected test cases on modified build to ensure bug fix work
with out any side effects is called Regression Testing.
(Change Testing)

Level -2 (Regression Testing):
                                                     During
above level-1 comprehensive testing, testing people are
reporting mismatches between test cases expected and build
actual to development team as ?defect report?. After
reviewing and resolving the defect, development people are
releasing modified build to testing team. In this stage, a
development person is releasing ?release note? also. The
responsible test engineers are studying that release note
and try to understand  modifications in that modify build
and then test engineers are concentrating on regression
testing to ensure that modifications.


                            Level-0

                            
                             Level-1
			   


          Check in  Level-2  Check-out
                           (Regression)


	From the above diagram, test engineers are conducting
regression testing on modified build w.r.p.t modifications,
which are mentioned in ?release note?.



Study release note & consider severity of resolved bug






High                           Medium                        Low

all P0 (priority)           all P0                         
  some P0
all P1                          max P 1                    
    some P1
max P2 test cases       some P2 test cases         some P2
test cases

                             On modified build


Case1: If the development team resolved bug severity is high
then test engineers are re-executing all P0, all P1 and
carefully selected maximum P2 test cases on that modified
build w.r.p.t modifications mentioned in release note

Case2: If the development team resolved bug severity is
medium then test engineers are re-executing all P0 carefully
selected all P1 and some of P2 test cases.

Case3: If the development team resolved bug severity is low
then test engineers are re-executing carefully selected some
P0, P1, P2 test cases.

Case4: If testing team received modified build due to sudden
changes in customer requirements, then test engineers are
re-executing all P0, all P1, max P2 test cases. 
0

We cant say the time line for regression testing. It 
depends on project functionality and what we need to test 
in regression testing. All we need to consider