Testing Lessons From Civil Engineering

Below is the paper I submitted as a prologue to an experience report, discussion, and (hopefully) additional research that I'm presenting for the first time during CAST08:

Engineers don’t look at the world the same way that testers do.  Engineers look at the world with an eye to solving problems.  Testers look at the world with an eye toward finding problems to solve.  This seems logical.  What is less logical is the fact that engineers, and I’m talking about the kind of engineers that deal with physical objects, seem to be much more sophisticated in their testing than testers.  In fact, most of what I know about testing, I learned as a civil engineering student.  We didn’t call most of it testing.  We didn’t even identify it as anything other than “You really want to get this right.” Maybe Civil Engineers test better than software testers because of the motivations to “get it right”.  Consider what happens when a piece of Civil Engineering, like a bridge fails:

• Huge amounts of money is lost.
• Engineers lose their jobs and their licenses to practice.
• Lots of TV news coverage.
• Innocent, unsuspecting people die.

Consider what happens when a piece of software, like a program to assist with submitting personal taxes, fails:

• Some executives probably don’t get bonuses.
• Some smart people put in some overtime.
• The Government extends the tax deadline.
• Even more people use the software the next year, figuring the problem has been resolved.

I guess it’s no wonder Civil Engineers go the extra mile to “get it right”.  Maybe it’s not even appropriate (let alone cost effective) for software teams to test with the same kind of rigor as Civil Engineers.  But wouldn’t it at least make sense for us to take a look at how they approach this testing?  Might there not be lessons there that we can apply without breaking the budget or extending the project duration?  I believe so. Some of the principles and techniques, as I recall them from engineering school, that I’ve applied or adapted to software testing, which I believe have had a positive impact on my testing include:

• Prototyping
• Safety Factors
• Failure Modes
• Risk Assessment
• Independent and Collective Testing of Materials and Designs
• Experimental Design and Execution
• Thought Experiments
• Realism in Environmental and Usage Modeling
• Validation of Models
• Sub-section Isolation

I make no claim to being an expert in any of these areas as they relate to Civil Engineering.  I’m 15 years removed from these topics in that context.  In fact, the titles I’ve given these ideas predominantly come from my head.  I’m certain that, from a Civil Engineering perspective, what I recall about these items is at best incomplete, and possibly, just plain wrong.  Be that as it may, the influence that these items have had on my development and success as a tester are profound.  I believe that makes this concept worth exploring.
 
--
Scott Barber
Chief Technologist, PerfTestPlus, Inc.
About.me

Co-Author, Performance Testing Guidance for Web Applications
Author, Web Load Testing for Dummies
Contributing Author, Beautiful Testing, and How To Reduce the Cost of Testing

"If you can see it in your mind...
     you will find it in your life."