Testing as an inter-disciplinary skill

I know it has been a while since I last wrote a blog entry.  Unfortunately lack of sleep and cramped schedules deprived me of much writing time of any kind the last few weeks.  Hopefully I can find a way to fix time for this purpose, or at least leverage some for a crowbar before my ideas go stale.  (Note to self, start carrying the notebook again.)

With the obligatory apology completed, now to some discussion.  This past weekend, I had some time to spend with my father.  He's a Chemical Engineering graduate from West Virginia University, and has worked in a number of different environments.  Without giving you an entire biographical sketch on my father, let me just say that he began working for FMC in South Charleston, WV shortly after graduation, and now, through an ironic quirk of fate now works at the same plant, that has since been spun off and changed owners a few times as a Chemical Operator.

My dad, often reflects on how things are at his plant, a place I even had the privilege and honor of interning at for a summer, and learned a great deal about just how complex an industrial plant can be.  This honor allows me to have a much better idea of the parts of the plant that he's referring to, even though it seems as though they've re-purposed some of the land for other things in his description I can usually get at least a basic understanding of what he is talking about.

I of course am not a Chemical Engineer, my last Chemistry class was Chem 16, and I was glad to be done with it, the likes of organic chemistry was not something I felt I needed to learn, although at one time I had considered that field.  So while I may not understand all the complexities of how a plant is laid out and run, I found some interesting parallels to experiences I have had in the Software field.

For example, take a particular process, any process you can think of, be it software or industrial.  Imagine this process produces a raw or virtual product.  The process has rules, and procedures that are to be followed by the floor workers, the programmers, the so called 'QA' group and so forth.  Maybe they have cross functional teams, or maybe they work in segmented distinct sections of the 'plant' to produce the product.  Whether they are stamping out bolts and panels for a car, or controlling the flow of material inputs, you can see how the manufacturing sector and the Software Sector may seem to have a lot in common, at least on the surface.

What does this have to do with testing?  Well, one area of interest to me has to do with how to improve the process in which software is developed on the teams I have worked in, and I have worked in several different situations.  The first, and perhaps most frustrating happened near the end of my College career.  I was taking an Operating System Class, and each class divided into smaller teams to build and code the projects.  Somehow I ended up with a trio of other students, a pair of them Grad Students.   Well, we began by planning, and figuring out how to divide up the work load.  Things initially seemed to be going well, and then the worst thing possible could happen.  The one other undergrad guy, dropped the course, which increased our individual work load, and then, soon to the Grad students disappeared from class.  I suddenly was in a situation where I never wanted to be, alone trying to solve a massive project. Fortunately I was able to transition to another team later in the semester, but there are so many things I could have learned better if I had just been with them at the start.  The team literally imploded under its own weight as people were pulled in different directions.

The same thing happens in software teams in industry.  How many people have I known who share multiple hats?  Lead architect, chief tester, database engineer, technical writer, system configuration admin, etc.  Those are just generic hats, when you add in possible technologies like AJAX, jQuery, Flash, and other libraries and techniques, the distribution of knowledge in a team can be spread out.  This may not necessarily be a bad thing, but it can hurt teams when people are retasked to other projects, or move on to other opportunities.

On one particular project, I was given the responsibility of picking up a section of the site, a search page to port it to the latest version of .Net.   I had seen the search in action before, and thought I had a pretty good idea of what was going on, well that was my first mistake.  Once I dug under the hood, I realized the intricate classes and data connections related to this page were very complex.   The change to the latest version of .Net meant the manner in which data was passed around had changed, and it was not just a simple matter of pointing to a different data source.  In short, maintaining that now 'legacy' piece of code became a headache, one that I prayed I'd never have to work through again.

Note it wasn't that this particular page was prone to error, it was literally a swiss army knife, with a multitude of possibilities, and that was before you started saving various searching configurations.   The draw back was that it was a difficult mechanism to extend, and that ultimately lead us to redevelop the module and to take advantage of another Reporting Service technology inherent within the version of SQL Server we were running at the time.

My father described what seemed to be a similar situation.  Changes in how they ran the plant, where or how certain inputs were calibrated, and how they ultimately had certain effects on the outcome.  Most teams in software will encounter bumps in the road that they have to learn to overcome, and it seemed that this was a similar process for my dad's company.  If you encounter a problem in the process, you examine it, and try to determine how to fix the problem, and hopefully develop a procedure to avoid repeating the mishap.

There's just one problem, that in my Dad's case gave me concern.  What if there was a situation where an error happened, but the process was not at fault?  In software we can tweak and tweak until the cows come home, but with each new procedure, each new piece of red tape, how much do we slow our ability to produce and test code as we go?

My father went on to describe some of the different teams that worked in the plant.  They have their managers, their QA people, their maintenance guys, their operators in various sections of the plant and so forth.  I found myself asking my father what he thought Quality was.   Truth be told, I blame Jerry Weinberg for the question as I recently borrowed an old copy of Quality Software Management: Systems Thinking from a friend at work thinking it was out of print.   (It turns out I was mistaken on this. Thanks to Jerry, for pointing out to me that it actually is still in print, just not in Amazon's roster.  It is still available with Dorset House Quality Software Management: Vol. 1: Systems Thinking by Gerald M. Weinberg. My apologies for listing it as out of print in error.)

I found myself wondering how my Dad, a chemical engineer doing operator work saw these things, and then I described how Jerry in QSM describes quality simply as value to some person.   Now I've seen a number of other tester bloggers wrestle with the ideas concerning quality.  Unfortunately none of those entries were fresh in my head on this particular day.  However, one point I did remember from the chapter I had just finished reading, was that because quality is subject to interpretation to some person, there are going to be different definitions, and expectations depending upon who the person may be.  Jerry does an excellent job of describing this phenomena in the first chapter of that book.

This then prompted another question, "Is the Quality Assurance Group" the only people who need to be concerned with quality in the plant?  I was trying to drive home that perhaps one of the issues in his plant was that people believed Quality is something that only that group in the labs is concerned with, everyone else is just a laborer doing what they are told.

I'll be honest I've never understood that mentality.  I have always pushed myself to do the best of my ability and in a team setting to do whatever I can to make that group successful.  The situation reminds me of one I've seen on paper in a few webinars.  A software group may have a group of Business Analysts that try to figure out the requirements.  They then pass those on to some architect, or developer group who tries to implement them in the chosen coding convention.  Then those same requirements are then passed on along with the builds for the project onto the testers who have to then parse those requirements and try to figure out how to determine whether a product 'passes' or 'fails'?

Sound familiar?   My dad basically described this situation, where the Analysts would get an idea at a high level of something they'd like to see happen, but often times they don't know the capabilities of a particular piece of equipment or hardware, whether it has constraints that may limit how it is used.  I'm reminded of the complaints about highway plans where I went to college.  So many described the roads as poor and unorganized, and often as if there had been no plan at all.  I often heard people say, that like the roads the best way to fail was to start by failing to plan.

Having lived through some similar situations I can attest that it can be very difficult.  My first role as a Software Developer, I never imagined that they'd require me to do quite so much testing.  Software Engineering Classes for BS Computer Engineers focused more on how testing was often a separate phase done by a somewhat independent group.   Yet here I was soon after starting my first professional job for pay, and I discovered myself having to test this module.  Sometimes, all I had was the name of the module, no requirements, or notion of how it should work.   Even worse, initially I was only given the code, and had to parse through them buy hand to figure out what was changed, plug it into a newer build, and then test it.

It didn't take me long to realize that this was an untenable situation.  How much time and effort was being wasted integrating someone's code into our project only to have to back it back out when we discovered it was not as mature a feature as we had thought.  I prefer not to think about that, but I began to push back and ask for at least some basic requirements or description of the features, and eventually we began requiring a demonstration build of the project as a proof in concept that I could put through its paces and explore to see if it lived up to what we were expecting.

Honestly, it was a very hard experience.  My dad says that Engineers go to College to learn how to think and how to teach yourself about the disciplines you encounter, but that you don't really have any clue how you will use what you've learned until you are out and working in industry.  In short, as a fresh out of college graduate, I didn't really know jack about how to do my job well.  There were so many things that I'd not encountered that I had to learn those first couple of years, and without any real guidance from the more senior developers in the team, I was left to figure things out on my own.  Fortunately I am a fast learner, but even then I know that I probably made more mistakes that first year than I ever imagined possible. 

This is not me being critical.  Just like I look back at stories penned before I finished High School, and today I can barely understand what I was writing or how I formed lines of thought to compose one line of text and weave it into another.  Truly they were embarrassing times, but they were learning times.  They drove me to work harder, to try to be better at each little thing I did, and I felt I was making progress up until I got retasked to working the Tech Room.  In truth, it was probably for the best, there were a number of glitches in our process for including and releasing new builds, and I was fortunate enough that my ability to work with people on the phone enabled me to switch hats, yet still learn a great deal about our product.  It was that connection to the customers that finally made things start to click.

In any event, just like things were in flux in that first assignment, I wonder how such changes affect my dad at his work.  How can they expect to keep their production levels high, when a key component goes down?  How would I expect a web site to operate if a key database or server went out?  This is what I was driving at with my dad.  That maybe, just maybe, the ideas of Systems Engineering for software, of testing, and development, do not just exist in their own bubble, but are perhaps shades of things that could help improve things at his plant.

I really enjoyed the chat with my father.  I wish I could have more such talks with him, to exchange ideas about how to think through problems as an engineer, or a tester.  One thing is for sure, the more I read about software development, the more I wonder why more work place components are not striving to improve their processes instead of staying at the ad-hoc level.

PS. Thanks to Gerald Weinberg for writing Quality Software Management: Systems Thinking, and thanks to my friend Craig for letting me borrow it from his book shelf as the book seems to be out of print due to its age.  I look forward to completing reading it, even though some of the ideas presented within may be a bit dated.  One of the joys, that being a full time tester has brought back to me, is the joy of digging for new ideas and knowledge through books, blogs, and the internet.  I'm not sure I would have had this wonderful conversation if not for having started that book, so Jerry, thanks a bunch.