Testers vs Coders
Till date I haven’t worked on a single project in which testers and programmers haven’t disagreed regularly.
Let’s have a look at some reasons behind these situations of conflict:
Poor analysis and lack of feasibility study: Project is accepted without adequate consideration of its scope and domain. Senior management just bags the project and analysts start working on it. This often results into many questions remaining unanswered and documents prepared not covering the entire scope of the system.
Lack of domain knowledge: Programmers start constructing the code and testers start writing the test cases without proper domain knowledge. Insufficient knowledge leads to varying and incorrect interpretations that prove very expensive later on.
Poor estimation and management: Schedules are tight. Development teams work day-night to meet the deadlines. Code is built and handed over to the testing team without proper developer level unit testing. The testers then flood the defect tracking tool with 100s of defects and the project goes out of control and into fire-fighting mode.
At times even testers understand that the test cases they are executing are not covering 100% but just 80% of functionality. However even if the tester understands, he often has no option but to log the defects based on the test cases available.
Development team starts working on the defects. Programmers find many defects are not actually defects but are misunderstandings of the business. Programmer rejects the defect and the tester vs coder battle starts. The tester claims that as per the test cases available it’s a defect and the programmer says it is not based on their new understanding of the business.
There is no point in blaming any programmer or tester because they are just doing their work on the basis of data provided to them and the expertise they have. Here adequate trainings of business domains and system, good estimation come into picture.
But these conflicts and delays in deliveries can be avoided if both testing and development teams are managed in an efficient way.
I think if one follows some basic rules then these situations of conflicts can be avoided.
- Thorough review of the specification documents prepared. â
- New open source software stack for enterprise web applications
- Will AJAX bring up a different kind of software developer?
