Tag Info

New answers tagged

0

One thing I've learnt over the years is that people generally have a vastly different assessment of risk. I worry a lot about high probability / low impact risk whereas my partner worries about low probability / high impact. That assessment is inevitably coloured by the environment in which people work, and whether the organisation states it has (and ...


1

It does seem to me that the deployment cadence is almost always of a lower frequency than the delivery (by devs) cadence. Also, that you don't get value to the customer until you pass a critical mass of components. Also, there is often a piece of legacy software that is resistant to automated testing. Also, (but not finally), stuff comes out of the woodwork ...


-1

Please see the below comments it will useful to know difference between regression and retest


0

Retesting: we execute the one test case on bug fix to make sure that bug is resolved regression testing: we re execute all or group of test cases on the application after many bug fixes src: http://www.time2ask.com/606/what_is_the_differences_between_retesting_and_regression_testing_.htm


0

You are not completely right actually. Test engineer just need to verify bugfix after state of issue changed to resolved, just be sure that expected and actual result are same. Test engineer does not need to execute regression testing after each bugfix. Regression means retesting the unchanged parts of the application. Test cases are re-executed in order ...


1

It is not true that any testing after bug-fixing is supposed to be called regression testing Testing whether a bug-fix was successful: You run one or more tests which failed. You analyse this failure and could identify a bug/defect. You correct this bug/defect You run the test or tests from step 1 again to test whether your corrections fixed ...



Top 50 recent answers are included