Since we have been looking at a lot of software testing techniques recently in class (Boundary-Value, Equivalence, Decision Table, and Path Testing), I thought it would be interesting to look into the test strategies that go into the larger part of testing. Of course techniques are important, and you want to get proper test coverage, but testing as a whole is a lot larger than the individual techniques that go into it. So I found a blog called Blethering About Testing by Dan Ashby, in which he discussed his test strategy model that was an update of the Heuristic Test Strategy Model designed by James Bach. I really like the way that Ashby outlined his model as a flow chart and how his blog post explained it all.
Both the HTSM (the original Heuristic Test Strategy Model) and Ashby’s updated version take in the context surrounding the testing, (such as the quality criteria, the tools being used, etc. ) and I think that this is a vital step in setting up testing. If you don’t know what the environment that you are testing in is, there is no way you can set up testing automation, or do any testing that will mean anything outside of your own system. So I agree with this being the top of the flow chart, as all of this “Context” is vital for any other step.
I also really like his “Exploratory Approach” section, where he discusses taking notes throughout testing sessions, and investigating into the project, in order to find more information on what needs to be tested. This leads into the “Information” part of the flow chart, and most importantly (to me at least) the “Continuous Testing” section in the blue bubble.
To me, this continuous testing section is the most interesting part of the whole flow chart. He explains each part of it in depth in his blog post, so I won’t repeat it here, but basically he splits up all of the testing into different sections. So you test the actual code, you test the software in different environments (and test all parts of the software, including back-end systems), but on top of that you test new ideas for features that come up, you try to continuously improve your software through testing.
What I really got out of this whole chart is that testing techniques are only the tip of the iceberg when it comes to actual testing methodology. There is so much more to testing than just writing JUnit test cases, you still need the techniques to carry out proper testing, but you also need the help of the environment, to be able to explore your own code, and to have some creativity in order to make the best code you can. It isn’t just about making sure the code doesn’t crash or there isn’t a bug, it’s a whole suite of examining code to make a vision come to life.