What will you (tester) do if there is miscommunication in bugs, every cycle is ignored from developer side and re-opened from tester side?
If tester is asked to test a build within short period, after testing, how will you (tester) react if the developers says that you have missed the bugs?
Answered by: kurtz182
View all questions by kurtz182 View all answers by kurtz182
Member Since Nov-2009 | Answered On : Dec 17th, 2009
1) I would ask the developer to identify precisely what bugs I missed.
2) I would the review the list of bugs in the build notes and compare this with the suite of test cases that I had run during the test cycle.
3) If this is not the release build, then I would add test cases for the missed bugs in the suite of test cases for the next test iteration
4) If this is the release candidate, then I would immediately raise this issue with management and let them decide how to proceed based on the bugs' priority and severity levels.
1) I would ask the developer to identify precisely what bugs I missed.2) I would the review the list of bugs in the build notes and compare this with the suite of test cases that I had run&n...
Testers need to finalize and communicate the scope of testing as well as depth of testing clearly before testing the build under pressure. This should be communicated both to developers as well ...
Which of the following statements about regression statements are true?1. Regression testing must consist of a fixed set of tests to create a base line2. Regression tests should be used to detect defects in new feature3. Regression testing can be run on every build4. Regression testing should be targeted...
Answered by: kurtz182
View all questions by kurtz182 View all answers by kurtz182
Member Since Nov-2009 | Answered On : Dec 5th, 2009
I believe the following statements are true about regression testing.
3. Regression testing can be run on every build
4. Regression testing should be targeted areas of high risk and known code change
5. Regression testing when automated, is highly effective in preventing defects.
According to me, it should be:
3. Regression testing can be run on every build
5. Regression testing when automated, is highly effective in preventing defects.
4. Regression testing should be targeted areas of high risk and known code change
5. Regression testing when automated is highly effective in preventing defects.
Editorial / Best Answer
Answered by: kurtz182
View all questions by kurtz182 View all answers by kurtz182
Member Since Nov-2009 | Answered On : Dec 5th, 2009
In every test cycle, the defect is consistently 'Ignored' by the developer and 'Re-Opened' by the tester. This problem exists due to a miscommunication somewhere. What will you do as a tester to rectify this issue?
1) I would first make sure that I have entered accurate and thorough details in the defect report in order for the developer to reproduce the issue. I would include details about the test environment so the developer can duplicate it. I would also include screen shots to prove the defect does indeed exist.
If the developer 'Ignores' this, then s/he obviously believes there is no defect at all and that the application's functionality is working precisely as it is supposed to.
2) Next, I would cite the requirement in the defect report and describe my interpretation of it. Then I would describe how the existing functionality does not meet the intended requirement.
If the developer 'Ignores' this as well, then I begin to consider whether I have misinterpreted the requirement. It is possible that the developer is correct.
3) I would revisit and study the requirement to determine whether I misunderstood it when creating my test case(s). If necessary, I would meet with the Business Analyst to gain further understanding about the requirement. I would discuss my test case and the defect with the Business Analyst to determine whether my understanding and approach is correct.
If my research convinces me that I have fully understood the requirement and that my test case accurately and thoroughly tests it, then I would meet with the developer and discuss the results of my investigation with him/her. I would explain the requirement in the manner intended by the Business Analyst. I would reproduce
the issue in an attempt to prove how the defect fails to satisfy the requirement. Hopefully, the developer will be encouraged to fix the defect.
If the developer continues to 'Ignore' this issue, then I will get the Business Analyst involved.
4) I would set up a meeting with the developer, Business Analyst, and myself in attendance. I would encourage the Business Analyst to explain the requirement to the developer and explain how the test case and its results properly exercise the requirement and identify a failure.
If the developer still 'ignores' this issue, perhaps it is time to replace the developer!
To be very simple, tester should specify the functional document(FD) which tells the exact functionaly of the piece of code and explains how it deviate from the requirement which lead to a creation of...
If a developer is fixing bugs with their own ideas and schedule in mind that means he is not following the test cases, he changing the status to IGNORED, then it is an error on the part of the develop...