Prof. of Software Engineering at George Mason University, Offutt discusses how he originally was a math major but switched when he took his first programming class.
LogiGear: How did you get into software testing? What do you find interesting about it?
Professor Offutt: When I started college I didn’t know anything about computers. I was a math major and in my first semester, my adviser convinced me to take an introductory programming course that was being specialized for math majors. Programming was taught in the business department, so a math-focused class was quite different and the faculty wanted to make sure enough students took it.
I was immediately hooked. Programming was fun and it was easy! (Unlike calculus, which I didn’t like.) It took me a few semester to find out that the pre-engineering majors who thought calculus was easy and fun often found programming hard. I was shocked to find that companies actually paid good money to programmers!
But I was frustrated by how much effort it took to write really good software. Design was poorly done, languages and programming tools were terrible (I started with BASIC and COBOL on punched cards!), and debugging was horrible. So I wanted to do whatever I could to help build quality software. When I got to graduate school I met a professor who was working on testing and I quickly found I could apply my love for discrete math (not continuous math) to making better software. So I’ve worked on testing, and especially automated testing, ever since.
LogiGear: What kind of work are you doing? How did you pick those specific topics, anyway?
Professor Offutt: I’ve found the hardest problem in testing is the key issue of getting test values. Most other aspects are either easy, straightforward, mechanical, or automated. And I’ve had a passion for inventing criteria and algorithms that can automatically generate good tests since my PhD thesis work.
A few years ago I agreed to teach a class on designing and building Web applications. I immediately realized that deploying software on the Web affected every aspect of software engineering, including testing. So I developed a technique for modeling Web software component interactions that can be used for testing (and other activities). I also invented a black-box technique called bypass testing, and I am currently working on a mutation model to test the novel control and state interactions that Web applications use.
I pick problems based on what I have trouble with as a programmer or as a user. And it helps if the problems are interesting to students.