A question that pops up now and then is “What is the ROI of testing?” A Korean research paper from December 2011 tries to answer the question.
Here is an interesting post on how to make reverse use of GIT bisect to find fix-introducing commits instead of fault-introducing commits. (The link is broken, but the original post can be found at archive.org.) What it boils down to is this:
Since git bisect was designed to find regressions, we need to flip the meanings of “bad” and “good” in order to use it to find a fix.
It seems to me that using this would be helpful for anyone wanting to use the regression test selection (RTS) method we introduced a few years back.
Check my publications page for more details.
Update 2014-01-01: this reverse use of GIT bisect has recently been covered on stackoverflow.
There are many kinds of testing. Detailled scripted manual test cases are quite popular but an article at testzonen.se might be an eye-opener if that is your favourite kind of test case. According to the article, these test cases are a waste of time and effort and demeaning to the testers. Instead they advocate a form of test cases which they call “one liners”.
This is quite contrary to the trend towards automated testing which I have written about so often before… Or is it? I guess the main lessons to be learned here are:
- There are a lot of different test tools, methods, practices, conventions etc
- Each of them has different advantages and disadvantages, risks and rewards
- It is important to choose the right one for the right situation
- Which requires expertise
- But in the end, any testing is probably better than no testing
I find this rather exciting, generating / optimizing your whole test suite automatically.