updated: Regression Tests as a normal part of day to day exploration / Regression Testing

 

Even before i heard of CICD, i had already coined the term 'continuous regression' in our office. For me it means 'testing for regressions' are not a specific activity, but incorporated into the testing/exploring process itself. 

In the Hypothesis of Test Phase Space, every dot in that space represents a state of the Test (one dot an input, the other dot an output). And every line connecting those two dots is a Test Path. Each line comprises of multiple other dots between the two end-dots: these are potential branch points to other dots (linking to misbehaviour-outputs, or linking to other test paths) such that while exploring current code changes/fixes it is inevitable that some of these code changes may/might be linked to other parts of the product. It is in such context that i couch continuous regression testing. 

Continuous modular regression testing should be part of normal exploratory testing. How fast and how thorough should these tests be? As speedy as the degree of acceptability will allow. No less. When should these regression tests be done? Preferably at any stage (especially any stage where system-testing is doneprior to publishing the software

('Regression': any pre-existing behaviour[working in a previous build] that (a.) no longer works, or (b.) no longer fits, in the current build.

('Regression Testing': Re-evaluating pre-existing features on a latest build or latest user scenario/s)


('Regression': any unwanted regressive impact of current code on pre-existing behaviour.)


link


Comments

Popular posts from this blog

The Quality Advocate (Test supervisor / manager / lead)

Test Report1