Software Testing Ain’t Gonna Solve Your Problems

It’s always amazing to me that companies refuse to go to the Gemba* to understand why they are having problems.  Rather than going to the root of an issue, they will attack all kinds of symptoms. We’re coughing so we must need a cough suppressant.  Never mind the fact that our lungs are filled with yucky cold/flu bile that’s trying to come up.  The problem isn’t the cough.  The problem is the virus that’s destroying you.

In some companies, software testing is often used to combat bad practices.  Our code is crap and it’s breaking at every turn, maybe we need some people to test it so we can find the problems.  As awesome as testers are, we can’t save you from your bad decisions.  Do not be deceived!  You reap what you sow.

I believe in quality assurance (making sure the process is sound) more than quality control (making sure the product is sound).  If you’re doing things the right way, you have a great chance of success.  Part of the reason I believe in QA over QC is because of Sun Tzu.  In the Art of War, he  says, “Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win.”  If you have a good process in place, then you can develop software with confidence that it’s going to be of good quality.  If you have no process or a bad process in place, you’re fighting for quality but only after the bad quality software is complete.

So, what are some things that might make a good software development process:

Code Reviews: One of the biggest things I learned at Edfinancial was the magic of code reviews.  They work on so many levels.  They work:

1. As a device to Share Knowledge among your team.  Are you in a company that has legions of siloed developers working on their own thing?  Put a stop to it!  Implement code reviews.  It forces your team members to see what each other are doing.
2. As a Learning Opportunity.  You want to know how to mentor your young coders?  Have them do code reviews with more experienced coders.  They will learn so much about best practices.  (Personally, I learned a ton from my former colleague Ryan when he did my code reviews.)
3. To Spur Collaboration.  When you have code reviews, this is a great time for spirited debate on the implementation of something.  Also, it prevents someone from completely going off the reservation.  It’s the reality check.  It’s the “What were you smoking?” check.  Many times crazy bad code just gets committed without so much as a once over.  That’s tragic!  Unacceptable!  And easily avoided!
4. To Find Bugs. Besides testers, you know who’s good at finding bugs?  Other developers.  They are great at it!  They are almost always tough on other people’s code, and that’s great for quality.  They will catch the honest mistakes.  Developers often catch their own mistakes as they are showing the code to someone else.  THIS IS BIG!!

Configuration Management: Systems are very complex.  So is code.  So is coordinating several people working on the same code.  You need to make sure that someone is keeping it all straight and enforcing the rules with an iron fist.  You want a process that’s well defined and repeatable.

1. Source Control: You should have all your production code in source control.  If you’re deploying stuff that’s not in source control, SHAME ON YOU!  You source is the life blood of your team.  Without it; you’re dead!
2. Automated Build and Deployment: Nobody should be doing the build and deployment of complex systems completely by hand.  People are too prone to simple errors.  There are countless tools out there that simplify this process.  For shops that do this manually, it’s a gut wrenching experience, but it should actually be as easy as pressing a button.
3. Change Control, Configuration: When you deploy code, do you know exactly what’s going out?  Can you easily tell me what’s been deployed, built, and configured?  If not, then why not?  If you have source control and automated build and deployments, then the change control stuff should be easy.  There ought to be logs documenting that.
4. No Hot Fixes on Production: You should not be making hot fixes on production!  That’s a sign of bigger problems.  And if you do have to make a fix on production it needs to go through a review and approval process.  And it should be the exception, not the rule.  It should never be some lone coder firing new code into production without consulting anyone.  That’s just plain stupid.

Priorities: What the heck are we doing?

1. Requirements: Testers can’t effectively test when there’s no expectation of what the code is suppose to do.  How are we suppose to verify and validate requirements when there are no requirements to look to?  The better question might be how do developers code without requirements?  Companies need to take the time to gather enough requirements to move forward with development.  NO!  YOU’RE NOT BEING AGILE BY HAVING NO REQUIREMENTS OR DIRECTION!  THAT’S CALLED AD HOC CHAOS.
2. Vision: Okay, requirements are a day-to-day thing, but what is the big picture?  What are we trying to accomplish long term?  Note that the less defined the vision is, the less chance that you’ll accomplish something specific.  Oh, and share the vision with the team.  Don’t make it a mystery.
3. Focus: Once you as a company has decided what the development team will work on, don’t constantly change your mind.  A whimsical manager with a big stick can kill productivity more than anything.  One completed piece of software is greater than 10 incomplete pieces.  Keep your eyes on the vision.
4. Realistic Expectations: Some managers think that they can complete software by sheer will.  If I crack the whip hard enough, the developers and testers will work faster.  If the team says 100 hours of development and 100 hours of testing, you as a manager can’t say I need that next Friday.  Sure you delivered it by some arbitrary date, but you will be putting fixes out for the next 6 months.

My assertion is that companies often attack the cosmetic, top level problems instead of attacking the root cause problems.  Testing is often a band aid thrown on the gushing wound.  If they were interested in fixing things, they would attack the root.

I think the big problem is that I am naive.  I assume that companies are indeed interested in fixing those quality issues.  But in truth, they are probably not that interested.  As a top level person in management, it’s more important that I get the product out than it being good quality.  It’s better to sell vaporware than to have a good product and not be able to sell it.  Rather than fix problems, it’s easier to look like you’re fixing problems.  We have quality problems so I hired some testers.  See!  I did what I’m suppose to do.  I didn’t give them power to effect the process, but it’s a nice gesture to have a token tester or two so they can say things like, “That’s whack!”

As long as the money is coming in, does quality really matter anyway?

*Gemba: A Japanese term that’s used in Lean to describe the source of the problem.  Literally translated, it’s “the real place” or “the actual place”.  In the context of manufacturing, it’s the plant manager going down to the assembly line to look at the problems.  I used that particular buzz word because I knew that it would make Bill happy.  Inside joke between us.