I’m going to start a semi-regular feature in this blog, talking about testing best practices.  If you know me and my consulting company, RBCS, you know that we spend time with clients around the world, in every possible industry, helping people improve their testing with training or consulting services, or doing testing for them with our outsourcing services.  Our work gives me insights into what goes on, the actual day-to-day practice of software testing.

Now, not all of what goes on is good.  There are bad practices, and we help clients fix those.  But you don’t need me to write about what not to do.  Aren’t there enough scolding bloviators in our business?  With a click of your mouse, you can read these people’s disdainful rants about testers they think are stupid, testers they think are in the wrong “school of testing,” testers they love to hate.  Lecture, scold, rant, bloviate.  How tedious!

So, being a contrarian, I will do the opposite:  With the exception of the paragraph above—where I poured well-earned scorn on people who write bad things about other testers—let’s focus on good news.  A blog entry on best practices should discuss testing best practices that my associates and I have observed other smart people doing. 

I want to start with Agile testing when it works.  No, I’m not recanting.  Yes, I’ve written about the testing challenges of Agile, and I stand by what I wrote.  Yes, I can talk about testing worst practices in some Agile teams, and I might in some future post—but not here.  Here, I focus on what’s right about Agile.  Here are five testing best practices we’ve found in Agile done right:

Unit testing. Okay, it’s true that most programmers, even Agile programmers, still have a lot to learn about proper test design.  But if you’re a professional tester like me, you have love hearing programmers talk about the importance of unit testing.  We all know that unit tested software is easier to system test.

Static analysis. Not only do smart Agile programmers like unit testing, they like static analysis, too. Coding standards are hip again.  Cyclomatic complexity is back.  Writing more testable, more maintainable code: that’ll make testers’ lives easier in the long run.

Component integration testing. This under-appreciated test level exists—on properly run Agile projects.  You can go years on sequential-model projects without seeing component integration testing.  However, on a good Agile teams, people look for integration failures, and, because of continuous integration, the underlying integration bugs aren’t hard to find.

Tools, tools, tools—and many free.  All of this talk about unit testing, static analysis, and component integration testing would be just that—talk—without tool support.  Fortunately, the Agile—err, what should we call it?—movement, revolution, fad, concept, pick your term, has brought with it a lot of tools to support these best practices, along with other best practices.  For those of us without unlimited budgets—and isn’t that all of us?—a lot of the best tools are free, too. 

Tester and developer teamwork. At the beginning of our latest assessment, I had a great conversation with a test manager who works on Agile projects. Among areas of agreement: our shared joy at the death of a bad idea. The bad idea in question was this: the idea that the role of the test team is the quality cop, the enforcer, the Dirty Harry to the punks of the software team.  “Seeing as I can refuse to approve the release, you gotta ask yourself one question: Do you feel lucky, programmer?”  Instead, we see more people working together, collaborating for quality, and that’s especially true on good Agile teams.

One recent morning, I spent three hours talking to two programmers—real seasoned professionals with years in the field—talking to them about testing.  The testing that they did.  In fact, it wasn’t so much about testing, but testing as an essential tactical element in a larger strategy for higher quality code.  They really knew testing, and they knew how the Agile approach and tools were helping them to achieve better testing and thus better code.  At the end of our talk, I mentioned how much I enjoyed talking to programmers about good testing and good code.

He replied, “Yeah, we spend a lot of time around here talking to each other about that.  How to be better craftsmen.  How to test better.  How to build better code.”

Wow.  If the entire methodology, the lifecycle, the tools, and every other aspect of Agile fades away, leaving behind only the habits of programmers serious about code quality, and testers working cooperatively with them to achieve it, that will be a signal achievement in the software engineering profession.  Best practices, indeed.