Software Testing

I “am” plugging this book, and for good reason …

Update (January 22, 2010) : The authors (Paul Ammann and Jeff Offutt) donate 100% of the book's royalties to the Software Engineering Scholarship Fund, a scholarship fund for software engineering students.
 

Admittedly, I am a bit biased, being both a student of the authors and a QA geek. To create even further bias, even though I bought a copy of the book for over a year ago, I never thoroughly read the preface until yesterday. I was both surprised and flattered to read my name in print, acknowledged as one of the students who contributed and helped with the book. I recall reading and commenting on the text before it was published and then being disappointed that I couldn’t attend the class before I graduated—it was a new course then and I had some graduation requirements to fulfill.

Coming from someone who contributes to the core MXUnit test framework, written a few blog posts, and spoken at conferences on testing and TDD, the book’s title may be construed as misleading. It can be used as an introductory text, but also presents practical, novel, and advanced concepts, such as coverage criteria (graph and logic coverage, input space partitioning, and syntax-based testing ). I suspect one of the main reason’s for the title is to make it accessible at many levels—and this is a big asset. Introduction to Software Testing can be used both as a text and as a test engineer or developer’s reference.

One of the goals of the book is to strike a balance between theory and practice. The book’s introduction establishes the context of testing in software engineering from a more formal process point of view. (It might be helpful or more accessible if the book were to also mention Agile methods, too, in which testing is an integral part of the process.) The book also identifies the fundamental weakness we all have to deal with in respect to testing—Testing can show the presence of failures, not their absence. This key point applies to both manual and automated testing and at all levels, unit through acceptance. In other words, based on your tests, you can’t prove that that your code does not have bugs. This is one of the main problems the book addresses through exploration of coverage criteria. Through coverage criteria, is it possible to describe and possibly measure the relative quality of your application? …

Now some 4+ years after receiving a masters, I’m going back to school and the first class I’m taking is SWE-637, Software Testing, the class I missed on the first go-around. I’m excited to dig deep, however, having a full-time job and being a parent drives me to try to work as smart as possible (that’s a constant learning process). Adding a graduate software engineering program to that, makes for very little time for anything other than that which absolutely necessary. With that, my goal for this semester is to focus on automated test design—how best to design automated tests in order to cover as many requirement criteria as possible in the least amount of space and time. I’d like to use functional testing as the primary medium and (as a bonus) develop a good grasp of the upcoming 2.0 version of Selenium (with Webdriver) as the test harness. But the focus will be on the principals of good test design rather than the tools.

Coverage criteria and test design is largely what the course and the book address. After focusing on TDD, unit testing, and building a testing tool, I still have the unanswered question of “what makes a test a good test?”. And how can I measure how much of a class, component, system, object, etc., is adequately covered by my tests? I know that when I write a lot of tests and take the time to reason about what I’m doing, I know the quality of my software is better. I know, too, coverage tools can let me know what parts of my code have not been exercised. Yet still, there’s that lingering question that tests can’t show the absence of defects …

Test and be Happy!

bill shelton