Posted by: Jaideep Khanduja
Bug, coder, coding, developer, Development, project management, software, Software Project, tester, testing
In most of the orthodox software project scenarios software testing is a late entry. Mostly testing starts when the coding is finished. The concept of complete code testing prevails where the testers are assumed to conduct testing on the product once it is declared as complete. A whole lot of time has already been consumed in development, and another timeslot is reserved for testing. In both slabs one team sits idle most of the time. When the development is getting completed, developers are busy in coding, and testers sit idle. When the testing is being done, testers are busy and developers sit idle and keep waiting for testing to get complete so that bugs report or test report is submitted to them by the testers.
The two teams – developers and testers – remain isolated most of the time and testers don’t get enough time to understand the product well.
The separating wall between the two teams is quite visible in this sort of scenario
. Fallbacks in this are felt on both the sides. On one hand where the testers do not get the full taste of the product as they are kept away while the product is in making, on the other hand the developers suffer the similar heat when the testers are testing, finding out the bugs and recording the bugs without actually involving developers with them so that the developers actually see how the bugs are getting simulated by the testers.
Though testers do take snapshots of the screens trying to decipher the occurrence of the bugs but usually that is not enough for the developers and another lap of time is spent by development team in understanding the bugs and trying simulating them to understand the real flaw in the code.
If everyone understands the loopholes in this system, why aren’t the efforts done to overcome it…