We’ve all been there — it’s Friday night, 11:00 p.m., 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 then continued to learn, improve, and stay persistent in writing unit tests.
The second team kept on postponing unit testing ‘til after the “next release.”
When I recently went back to visit the teams, my findings were eye-opening.
I had a great discussion with both teams.
Team 1, 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.
Team 1's 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 Team 2, they focused on real usage issues rather than simply getting the application to work. They found less critical bugs that were significantly less severe than the other team. The developers therefore are now 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 the trust among the teams has increased. Management is also happier with the quality of the software — after all, fewer customer complaints means reaching business goals easier.
What about the second team that didn’t do unit testing?
Team 2 kept talking about how they would like to do unit tests and how the developers are ashamed that they never started.
The team members were having problems. Pressure, delayed releases, and management was 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. They were practically doing QA’s job in order to lower the bugs QA had to resolve.
These developers were not happy. Their focus turned from adding more features to lowering bug count for the QA department. They did 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 knew it. This made the development cycle longer and no one was since everyone was overworked-- Caffeine and foosball doesn’t compensate for sleepless nights and endless debugging.
Paradoxically, Team 2's QA got saddled with bugs and was working overtime to bring them down. They ended up requesting more and more money in their budget to get the bugs ironed out. They got tired of fighting with the developers and management about the number of bugs and delayed releases because of the incessant back-and-forth between departments.
By not unit testing, the Team 2 was doing their work plus QA’s work: they were developing their software, plus testing their code.
It is obvious that the team that was persistent with unit testing, that went through the ropes and hardships 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. Team 2, well, they were like a second, less-experienced QA.
This article is accredited to Eli Lopian, the CEO of Typemock, the Unit Testing Company (http://www.typemock.com). A well-known figure in the agile and test driven development arenas, Eli has over 17 years of R&D experience at large companies such as AMDOCS (NYSE:DOX) and Digital Equipment Corporation (DEC). In these roles, Eli was responsible for optimizing the development process and led the transformation of the development environment to support efficient processes and tools. (http://www.typemock.com).