One comes to learn about the things that testers in various companies hear from their project managers. Enjoy.
1. You need two days to write test cases!? You already have the requirements specification. Just copy and paste from it.
2. You don't have the latest requirements!? I am positive that we communicated the latest changes to all developers.
3. Remember that we are using the Agile methodology. Time is critical. Do not waste it by creating any test cases or bug reports. Just test and discuss the bugs directly with the concerned developer.
4. Note that the build you are testing can change any time. Even if you notice that the build has changed, just continue your testing as if nothing has happened.
5. There is no need to test the xxxx module. I have already had a [senior] developer test it and he said it is working fine.
6. You are new to the project. We will have another [senior] tester repeat your tests and compare both your results.
7. I want to be aware of each bug as it is found. In addition to logging the bug report, call me/ mail me as soon as you find a bug.
8. You have found a bug? Are you sure that you have tested the latest build [implying a very recent untested build]?
9. What bug did you say you have found? Please confirm each bug with the developer before raising/ logging it.
10. Why doesn't your bug report have a test case ID? Note that no bug will be accepted without an existing test case ID.
11. Your bug is a duplicate of bug ID xxxx. Note that NO [implying not even the first] duplicate bugs will be entertained by the developers.
12. Finally, It is 8 p.m. The developers have worked very hard to create this release. Now, they have all gone home. You can do all your testing. Just remember that the release has to be delivered to the client first thing tomorrow morning.
Okay, I admit that these things are not at all funny for the recipient at the time they are said. But, they are hilarious once you think or talk about them later :)
There are 2 8's above. Iam refering to the second one.I have seen it happening in more than 1 occasion I have seen testers inability to understand the functionality and the pressure to file bugs resulting in filing incorrect bugs.I wouldnt rate that funny
ReplyDeleteSuprinder, indeed there are 2 #8 above. Thanks, it is corrected now. Now, the second #8 (# 9 now) may happen if the testers do not understand the functionality or are under pressure due to which they may mistakes. But is that how testing should be done? I mean, if the tester does not know the functionality, how he or she is supposed to test well? See the earlier post, Why your bugs are rejects (20+ reasons...)? @ http://inderpsingh.blogspot.com/2010/03/why-your-bugs-are-rejected-20-reasons.html for the various reasons due to which the tester's bugs may be rejected...leading to #9.
ReplyDeleteThe reason why I put #9 as funny is that even if there is no (serious) problem of rejected bugs, the project manager may still request/ mandate discussing each bug with the developer as a way of:
a. Slowing down the bug discovery rate (due to the additional time now taken by the testers to discuss each bug with the developers). This gives more time to the developers to test their code and fix their bugs before they are discovered by the test team.
b. Reducing the number of total bugs found by the test team against the build, especially if the developers debate each discovered bug.
c. Keeping the number of bugs reported in the defect management system quite less
All these lead to a false sense of confidence in the quality of the release (after all, only a small number of bug reports could be present in the defect management system if the testers follow the manager's request/ mandate to the letter).
This is a real possibility if the tester belongs to a different team (officially, only the developers report to the project manager).
The illustration of testers passively testing without the full understanding of functionality is a wrong practice but anyways it happens and hence I think the dev team being aware of it take measures.
ReplyDeleteNow if dev team has other motives as you mentioned then thats not only wrong practice but an ill environment where product is being developed and where product is bound to fail.
I mean in a healthy environment whether a product is good or not the credit will be given to
people behind it and that would be both the development team as well as test teams and others.
All the above is fine but point # 12 reveals true pain of software testers
ReplyDeleteit is 100% true.
Deleteya its usually happens at office hours
ReplyDelete