May 20
Hemal Shrimanker in the article ‘Abide by software testing rules’ looks at some of the basics of testing software. Simple and easy to implement rules that are often ignored and lead to disastrous consequences.
May 08
Web Performance, Inc. (WPI) has released Web Performance Load Tester 3.6 which includes a number of new features that make it easier to use and more intuitive for its non-programmer user base.
Feb 20
We will first focus on what exactly cookies are and how they work. It would be easy for you to understand the test cases for testing cookies when you have clear understanding of how cookies work. How are cookies stored on hard drive? And how can we edit cookie settings?
Mar 27
Software testing essentially reveals the mistakes done by a human mind when building up a piece of code. However, in some cases software testing can become a never-ending story. Testing team completes first testing cycle, no. of defects are found, development team fixes the defects, again testing is carried out, some more defects crop up and so on.
Sep 07
 The title ‘Testers Vs Programmers’ says it all. I think no sport can match when it comes to the conflict between testers and programmers.
 Till date I haven’t worked on a single project in which testers and programmers have agreed on any single point.
Jul 11
The title ‘Testers Vs Programmers’ says it all. I think no sport can match when it comes to the conflict between testers and programmers.
Till date I haven’t worked on a single project in which testers and programmers have agreed on any single point.
Let’s have a look at some reasons behind these situations of conflict:
- Functionality is not clear. Tester thinks in different way and programmer thinks in other way.
- Lack of training of the product/project functionality to both development and testing teams.
- Last but not least poor estimation and poor management.
As I have mentioned above the 3rd reason is the root cause of everything. Everywhere we face the situation where managers are always in hurry to deliver the code. This results into working late to complete the unrealistic deadlines. Now in this case the training part is completely ignored. Testers prepare test cases as per their understanding, development team builds the code and at the time of final testing the battle for fixing issues and most importantly rejecting some of them starts. Again result is endless discussions on the defects logged and really they are the defects or not.
It is a like a rule that programmer has to argue with tester when any defect or issue is raised. At first instance no programmer accepts that the defect raised is valid. Then start the unavoidable discussions and arguments. Tester tries to explain what the problem is and programmer never agrees upon it.
Considering a typical situation of the release of the build/project. At this time one should watch carefully how the things work? Tester finds ‘n’ number of defects. On this programmer asks the analyst about the issue. He says specifications prepared were not clear. At last moment the changes are done. Again in tester finds some more defects and it goes on and on and on. The result is estimation fails and project is delivered with open issues list or something.
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 that can be avoided.
- Estimation should include ample time for training on functionality and the system to be developed.
- Thorough review of the specification documents prepared.
- 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 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 of that all these things are happening as expected. Just people management is not enough. But what these resources are doing is correct or not should be checked from time to time. If all the resources are clear with their roles and responsibilities or not? It should be verified that code reviews are done, unit testing by development team done is perfect. As well as 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. And this will definitely avoid the conflicts between testers and programmers.
Finally, I think all this is ok. But I doubt in how many companies all these things are followed and the estimation is done keeping in mind to all these aspects.
What has been your experience and what do you think is the way forward to ensure better understanding between testers and coders?
Editor: Harshad Oak