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.
So true. As long as programmers are rewarded only for producing code, and meeting unrealistic deadlines, they’re not going to be able to do anything about quality. It is so great to hear another success story like your team’s! Thanks for sharing it.
I thought this blog entry was just going to be a link to Skyrim.
I think another stumbling block with devs is looking only at the T in TDD and seeing “testing.” TDD is a design practice, not a testing practice, but buy having that T in there it freaks out all kinds of developers, and the walls go up.
I’ve been on teams where the first swipe at a feature was done using TDD with a QA person sitting right there. It’s amazing the edge cases a QA person can suggest while watching a developer go through the TDD process. Quality is on the whole team, and that was a great way to get it built in early in the process.
I agree that it is a cascading process but changing that process is going to be an uphill battle. I would argue (at least with what you have described of your current team setup) that they have not yet reached the point at which some of them can see the benefits of the efforts you are all putting forth. Until a team reaches this tipping point there is always the danger of regression. But once a team sees the benefit of good design, good test coverage and good feature collection (and experiences how this makes the process faster) they start to become true believers. The longer they have a chance to work with the application once it reaches this point the stronger the motivation becomes to implement these practices on future projects. …or that has been my experience so far. How to convince a waterfall team that all this effort is worth it in the long run (before the first test is written) is still something of an enigma.
Philip,
You’re right, it’s going to be hard to convince waterfall people that this way is the best way. They may not have the skill set that would enable it to work. But that doesn’t mean that it’s not a better way.
At some point, teams just have to do what they think is right and not make excuses about why they can’t do it. It may be painful and slow at first, but if we thought something was worth it enough to try it, we shouldn’t give up on it just because it gets hard. It may require changing teams around, taking time for learning, and bringing in some new people. Every team has an excuse at some point. The good ones will push through it.