We've all been there - it's Friday night, 11PM and the system you just deployed doesn't work. There's a bug. Your manager just hung up. You phone your friends to tell them that you're not going out tonight. You start thinking: Why didn't QA catch that. Now management is going to add more QA staff, give them more budget, and there's going to be a zero bug tolerance policy once again.

There is a way out of this problem. Could it actually be unit testing? I had the good fortune to visit two development teams in the same company and compare firsthand the experience of teams that might prove this assumption.

Two years ago, the teams diverged on different paths.

"Unit testing?" said the first team leader. "We know it is going to be hard. But we heard that it's likely to provide lots of benefits: cleaner code, fewer bugs, quicker development cycle... and our whole development team has been begging for this. QA also spends significantly less time finding bugs. Manual testing may have taken too long but that's gone the way of the dodo. We're going to have to get management on board. "

"We've heard that unit testing is a good practice but we are under a lot of pressure. I'm sure that it will postpone our release date," said the second team leader. "Let's do it after the release. "

The first team convinced the management to give 20% of its time to unit testing and continued to learn, improve, and were persistent in writing unit tests.

The second team kept on postponing unit testing ‘til after the "next release."

I went back to visit the teams recently, to see how they are getting along. It was eye-opening.

I had a great discussion with both teams.

The team that learned about unit testing and started testing (using Typemock Isolator) kept on speaking highly of their results and gave the unit testing love as they were overwhelmed with joy over their processes and tools.

Why?

Their software release cycle (developers and QA) is much shorter (25%-33%) than the other team. Software is released quicker. The team has stayed relatively intact as engineers prefer to work in environments with automated unit testing.

QA is relatively happy. Compared to the other team, they focus on real usage issues rather than simply getting the application to work. They find less critical bugs and the bugs they find are significantly less severe than the other team. The developers are more confident in their code, allowing them to make changes quickly, without introducing bugs.

The developers are consistently adding functionality. Of course bugs still creep in even with unit testing. However, the few bugs found by QA aren't anything to be ashamed of - both sides are happier and trust among the teams has increased. Management is also happier with the quality of the software - after all, fewer customer complaints means reaching the business goals.

What about the second team that didn't unit test?

The team that didn't start unit testing kept talking about how they would like to do unit tests and the developers are ashamed that they never started.

The team members were having problems. Pressure, delayed releases, and management were on the team's back because of too many bugs. That is why the management decided on a zero bug tolerance policy again. This meant that the team had to build a QA-style environment and had to test the system manually before sending the application to the QA team. Practically, they were doing QA's job in order to lower the bugs sent to the QA.

The developers are not happy. Their focus turned from adding more features to get the bugs to QA down. They do this by manual ‘QA style' testing, constantly running the debugger, engaging in time-consuming deployment and manual testing for every small feature instead of developer-style unit testing ... and they know it. This makes the development cycle longer and no one is happy as they are all overworked. Caffeine and foosball doesn't compensate for sleepless nights and endless debugging.

QA is saddled with bugs and is working overtime to bring them down and is requesting more and more money in their budget to get the bugs ironed out....tired of fighting with the developers and management about the number of bugs and consistently delayed release due to the incessant back and forth between the two teams.

By not unit testing, the team is doing their work plus QA's work: they are developing their software, plus testing their code

It is obvious that the team that was persistent with unit testing, and went through the ropes and hardship of learning how to do it correctly, had the upper hand. They improved their coding skills, were energized by their coverage and had a better time-to-market. The other team, well they starting to do the QA's job too.

Eli Lopian is the CEO of Typemock, the Unit Testing Company (http://www.typemock.com).