Mike Clark

I'm on a mission to help tear down the barriers we've so methodically built up between QA and developers over the years. Having a box labeled "QA" on an org chart is so 90s. More importantly, it's just not efficient, in my experience. Now, before your feathers start ruffling, rest assured that I'm not saying we don't need testing skills on a team. Rather, I believe folks with testing experience are so valuable to the team that I'm proposing they get more involved with developers from the beginning. Waiting until the end of a development cycle and then throwing code over the wall is a disservice to those skills.

I've been struggling a lot lately with the nomenclature we use on projects. I'm frequently guilty of calling some folks "developers" and others "testers" or "QA". And every time I utter one word or the other, it doesn't feel right. I don't like labeling people that way. Worse yet, my words are like one more layer of bricks on the barrier. Indeed, applying the developer or tester label further reinforces the divisive relationship we've been living with for far too long. Don't we all share the common goal of developing better software faster? So, starting right now I'm making a resolution to not use the label "QA" or "tester". I realize that not using those words won't solve the problem, but I believe it puts me in the mindset to help chip away at the barrier.

Another approach I've been using to maximize our collective skills from the beginning is to help the team use tools that everyone has a stake in using. In my experience, testing tools that use a proprietary language targeted specifically at testers do more harm than good because they polarize the team. There are those who know how to use the tool and those that don't. Those that do report to a QA manager and those that don't are considered developers. The software under test is the only common ground. If testing the software is difficult, it's the testers' problem because developers don't understand the testing tool. Add another layer (or ten) of bricks to the barrier.

We need more testing tools that everyone on the team understands and uses from day one. Does that mean if your software is written in Java, everyone on the team must know how to program in Java in order to test that the software works as expected? I think not. Open source tools like FIT offer a convenient middle ground. The test fixtures that poke and prod the software are written in Java, but the data and commands that drive those fixtures are expressed in an HTML table. And with FitNesse, anyone can run FIT tests directly through the browser. That's right, even customers can run the tests!

I'm not alone in this endeavor to employ better testing tools. At the end of my test-driven development talk, I've been mentioning some of the open source tools I've been using and teaching teams to use. I recently started polling the audience to see if they wanted to dive deeper into some of these tools and the response was nearly unanimous. So, by popular demand, I've expanded the talk to a 3-hour session at the upcoming Rocky Mountain Software Symposium. In the first half, I'll teach the mechanics of JUnit -- how to write and run programmer tests -- and the test-first design technique. Then in the second half we'll go beyond JUnit by taking an indepth look at other open source testing and continuous integration tools I've been using heavily as of late, including Ant, Anthill, HttpUnit / HtmlUnit, Cactus, Canoo WebTest, JUnitPerf, FIT, and FitNesse. I have live demos of each of these tools that build and test the example app we develop in the first half of the talk. The talk is actually the basis for a full day of training I tailor to specific project interests. I'm also giving a separate talk on continuous performance testing using JUnitPerf.

A revolution is taking place, methinks. I believe we're on the cusp of a fundamental (and healthy) change in our industry. Ironically, I think this economy is a catalyst for that change as we're challenged with doing more with less. No longer can we afford the feigned comfort of barriers.