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. – Here I will like to state one point that reviews are not just meant for records which are presented at the process audit. The reviews are more essential for the application development.
- Estimation should include ample time for training on functionality and the system to be developed.
- Meetings between testing and development teams should be started in project's initial stages. Which will lead to clear understanding of the system and clarification of the doubts at the very beginning?
Managers have to take care of it. Tester's role is that of breaking the system keeping in mind the functionality expected as well as trying any other difficult scenario. So if specifications are clear then it becomes easy for development and testing team to build a code and the test cases.
Managers, team leaders should take care that all these things are happening as expected. Just people management is not enough. Leads should ensure that code reviews and developer unit testing is not igniored. Also if the test cases prepared by the testing team have covered all the functionality or not? The best thing to ensure all this is that tester and programmer should discuss their respective module/functionality from time to time. Then they can understand the functionality and if anything they have missed out.
What has been your experience and what do you think is the way forward to ensure better understanding between testers and coders?
Home | 
X 
