IQAA: Regression Testing

Dr. Hanna's Practice #8: Perform regression testing that is based on impact analysis. The first practice in the list that you can't just nod your head at, since you have to have a good idea of what regression testing is (I do) and what impact analysis is (I didn't.) But I did like Practice #7: Testers should attend design and code reviews. It's not something I had heard before, but it's obviously a good idea if you are interested in faciliating communication within your company.

So what should a tester do at a code review? Primarily they will want to come up with test ideas; examine the code paths; ask how each one can be exercised. But also they can ask a very fundamental question: What other parts of the code is this project going to affect? This is an impact analysis. If I remember correctly, it was recommended that this analysis be done formally, as in developers have to write up a statement or report analyzing what other parts of the product will be affected. Not a bad idea, but probably not for smaller companies like Prosolv.

So based on the Impact Analysis, testers should be able to come up with a set of requirements that need to be retested, and there's your regression suite. Of course, every build that goes to testing should be tested on the critical path (or as I prefer, the "Happy Path"). Dr. Hanna suggested a 90% pass goal, but I'm not sure why that should be. Some tests will be showstoppers, others will be...well, whatever. I suppose if you have more than 10% "whatevers" failing, you've got an issue, though.

Just a couple of other notes:

- Regression testing doesn't do any good if you do it at the beginning of a project - it is certainly to be hoped that there will be few failures then!

- Impact analysis is also necessary when a requirement is changed. Go to a developer if necessary!

- Which led to the question, what if the developer doesn't know? Dr. Hanna's response: Find new developers ;)