Developers, You Do Not Have To Do QA Work
Bangalore: What happens when the software you just deployed has a bug? Why didn’t the QA team detect this one? Eli Lopian, CEO of Typemock shared an interesting case he had encountered with sys-con. He met two development teams in the same company and compared the firsthand experience of teams that resulted from their differing attitude towards unit testing.
The first team leader knew unit testing wouldn’t be easy but it could provide lots of benefits such as cleaner code, fewer bugs and a quicker development cycle. These are benefits every developer would consider a godsend. QA also would have to devote less time to finding defects. Since manual testing is slowly reaching extinction, the team leader considered using a tool and sought the approval of the management for supporting this.
Although the second team leader knew that testing was considered to be a safe practice, he did not want to postpone the release date and thought that unit testing would put them under too much pressure. So, he decided to do it after the release.
The first team was able to get management to devote 20% of its time to unit testing and it was able to learn, improve, and improved at writing unit tests. The second team did not prioritize unit testing and kept postponing it for the next releases.
The team that placed emphasis on testing (using tools like Typemock Isolator) was happy with the results and spoke highly of their processes and tools. Their software release cycle (both developers and QA) became much shorter (25%-33%) than the second team.
QA saw a lot of changes, now they had to focus on real usage issues rather than worrying about getting the software to work. The bugs they found were less severe. The developers were able to make changes quickly without introducing bugs as they had a lot more confidence in their code.
Bugs may still exist even after unit testing but the overall quality of the software had improved significantly and there were notably less customer complaints.
The team that didn't start unit testing had problems. They had to deal with delayed releases, and the management was pressurizing them because of too many bugs. Due to this, the management decided on a zero bug tolerance policy. This meant that the team had to test the system manually before sending the application to the QA team. In essence, they were doing QA’s job to cut down on the number of bugs sent to QA!
The developers’ focus modified from introducing additional functions to keeping the bugs at bay and obviously the QA was overworked as well.
The team that stuck to unit testing, and went through the initial difficulty of learning how to practice it properly, had the upper hand while the other team, was doing the QA's job as well.
Post your Comment
All form fields are required.