Change is challenging, be in life or in software ! And to the tester, it means regress. And regression tests not automated can suck up time, so how can I select those test cases that matter? Typically test experience and product knowledge are the means that a tester uses to choose. How can HyBIST help here?
The key notion here is “Fault propagation analysis“. When a change is done, analysis of ‘what faults(PDT) can be irritated’ and therefore propagate resulting in a potential failure can help. To ease this analysis, start from the Baseline(Remember what-to-test x test-for-what), identify what EUT(s) have been modified. Note that EUTs do not live in isolation, they are interdependent/linked. So identify an EUT that has been modified and using the interaction matrix, identify what other EUTs could be affected. So what we have at the end of this exercise is the list of EUTs (what-to-test part of Baseline) to be possibly regressed.
Now we have to figure out the ‘test-for-what’ part of baseline to identify what tests and then the test cases to choose for regression. Note that the tests are ordered in to Quality levels, so think in terms of levels. What ‘Quality levels’ of these EUTs may be disrupted due to the change to the entity? Applying this train of thought, we can figure as to what types of tests may have to be regressed and now we can dig deeper to choose those scenarios that possibly matter. And to do this, think in terms of PDT(s) that may be irritated and therefore choose those cases that relate to these PDTs for performing the regression.