Pliers, a Blowtorch & Mr Wolf: Integration Testing Lessons from Pulp Fiction

So, at the most recent local tester meeting, a suggestion was made that the next meeting should consist of folks giving lightning talks based on pop culture references and how they relate to testing.  COOL! 

One of my colleagues suggested a "Pulp Fiction" idea - not that he wanted to give one, but he thought it would be "cool."  So, sitting and having a coffee the next morning, I got to thinking about it.  What in the remarkably violent film, featuring various actors in interesting, if not compromising, storylines, could possibly relate to testing.  About half-way through the cup of coffee it hit me. 

Now, James Bach, and others, when hearing someone explain a heuristic or oracle or rule or concept, will ask "What do you call that?"  You see, there is something about identifying something - naming it - that makes it easier to refer to, gives you a point of reference, and other good things.

So, in sitting there drinking coffee, thinking about "Pulp Fiction" - it became remarkably clear.  How does this possibly relate to testing? How does this relate to integration testing?  Everything fell into place.

I give you, the "Pulp Fiction School of Integration Testing." 

Consider that the vignettes in Pulp Fiction are related to eachother.  They simply are not told in a linear manner.  They are closer to the way life happens - lots of intertwined stories all happening at the same time. 

Now, consider the way some folks do integration testing.  Maybe "some" folks is not really accurate.  Maybe "many" folks would be a better description.  But they get some idea that the idea of "integration testing" consists of "end to end" scenarios.  The thing is, most "real" people using "real" software in the "real" world don't always use software in a linear fashion. 

So why do so many people test their software that way? 

I don't know either.

When I think about some of the systems I have worked on, it simply does not make sense to rely on "end-to-end" testing.  Really.  Its kind of silly.  Here's what I mean.

A system rarely does one thing at a time.  People in one office or area will do one thing - a lot of times.  Say, item maintenance in a warehousing system.  Looking up information and checking descriptions and UPC codes and unit of measures and - lots of stuff.  Folks in another office may be checking inventory on the same items the other folks are entering or checking or, whatever.  Then, in yet another office, folks are handling orders customers are placing for the same items that the other folks were... you get the idea.

So why do so many folks test one thing, then the next then the next then... yeah, you get the idea to that, too.

Why don't we try and do integration testing closer to the way the "integrated" system actually gets used?

Ya know, kinda sloppy like life really is - or maybe like Pulp Fiction?