I’m a huge fan of TDD, and one thing that is really frustrating is when I’m working with people who either don’t know how to write unit tests or don’t agree with the idea of writing unit tests. This is especially true in a static language because those people will design the code in a way that prevents me from writing tests.

Why is it that so many developers don’t care about testing? Most developers that I’ve worked with, whether I agree with their ideas or not, take pride in their work and generally care about their job.

I think that this goes back to the traditional divide between development teams and QA teams. On most teams, there is always pressure to get things done faster. In order to get things done faster, you have to either cut something out or get better at what you do. It’s much easier to cut something out, so inevitably the team will do what they can to cut development time. This means cutting out unit testing (or not taking the time to do it in the first place). Once you cut out unit testing, the next thing you throw out is good design principles and just get it done as fast as possible.

We all know that if you don’t write unit tests and you just throw in spaghetti code to get something done that you’re going to have a lot more bugs. It takes time for QA people to find bugs, reproduce bugs, write up bugs, and retest bugs. But why should the development team care? They were just told to go faster. Who cares how long it takes the QA team to test the application? Why does the development team care if it takes an inordinate amount of time to regression test the application?

The QA team knows what is going on, so they don’t trust the developers. They know that the developers are likely to write bugs, so they will need to be more thorough. The problem is that sometimes this means doing an inordinate amount of manual testing (which may or may not be possible).

This is what happens when development and QA are separate teams that don’t work closely together. Each one is only looking out for their own interests, not the interest of the project as a whole. In my opinion, it makes no sense to do it this way, but this how it’s done in many companies.

On my current project, we have broken down the walls. The QA team and the development team report to the same manager. The developers, BAs, and QAs sit together in the same area. Before we work on a feature, we all sit down together and decide what will be tested with unit tests, what will be tested with automated acceptance tests, and what will be manually tested. Because we’re all on the same team, I (as a developer) care about testing just as much as anyone else on the team. There’s no reason for me to not care about testing. Don’t I want the app to work too? If I write crappy code, it’s going to take longer for the team to get things done. If I don’t help automate regression testing, it’s going to take the team longer to manually test everything. I don’t want either of these, so I’m going to help out. The QA team is starting to realize that they can trust our automated tests (which they’re not used to), and we all agree that in the future they will do much less manual testing.

Because we’re on the same team, we’ve enabled developers to care about testing. If we want to get things done faster, I want to make sure that I automate as many tests as possible so that QA doesn’t have to manually test them. I might even pitch in to help with manual testing when that time comes. In the end, we end up with high quality software delivered in less time because we have very few bugs and we will test things in the most efficient way possible.

In most companies, there is a definite divide between the development team and the QA team. They don’t sit together in the same area, they don’t have the same boss, and they often aren’t even working on the same project at the same time. Sometimes the QA team doesn’t get involved until it’s time for the “testing phase.”

To me, this all makes no sense. I’ve been on teams like this, and the same thing usually happens — developers develop something, and when the QA team starts to look at it, they don’t know the first thing about the feature that was built. They try to come up with a test plan, but they don’t come up with all of the edge cases because they don’t know enough about the feature. Other times they come up with something that the developers hadn’t thought of, or they find bugs because the developers didn’t do anything to test their own code (even manually).

Before we go any farther we have to dispel two common misconceptions about the role of a QA team.

Some people think that your QA team is like a college professor giving you an exam. You learn about a feature from the BAs or the users, and then the QA team is there to verify that you understand everything after you’ve written the code. The QA team shouldn’t give you their test plans because then you might just write the code to make their test plans pass (heaven forbid!). That’s like your professor giving you the answers to the test, and that’s cheating. (I’m being sarcastic, of course.)

Other people think of the QA team like a group of external auditors. You don’t know when they’re testing or what they’re testing. They’re just here to catch you screwing up. They have to be extremely thorough and cover all the bases to make sure that nothing gets through, regardless of whether the development team has written any automated tests.

I would much rather work together with QA people. I would rather come up with the test plans together so that we can make sure that I automate most of their tests for them and build the right thing. I would rather have QA people involved up front so that they can help me think about how something should be tested. They also are very good are finding holes in requirements that no one else though of, which is very valuable to have up front before we right any code.

The hard part in all of this is getting people to work together who typically don’t work together. Usually developers and QA have different managers, and developers and QA people might not even be working on the same projects at the same time. You might need to get your management to work together to get people on the same teams working on the same projects at the same time.

We’ve been doing all of this on our current project and we’re really starting to see some exciting things. Much more on this to come!