er.ighosh

 Profile Answers by er.ighosh 

• Aug 3rd, 2009

 

Case 1: The functionality tested is out of scope.
Solution: In the above case we can justify the issue as out of scope.

Case 2: The functionality tested is in scope and test case is not present for the same.
Solution: In the above case we can justify the issue in scope and update the testcases with timestamp and notify the manager for the same.

Case 3: The functionality tested is in scope and test case is present for the same.
Solution: In the above case we can justify the issue as a testing error(missed bug) and try to figure out what was the reason for the miss and keep track for the same so that there may not be any misses in the future**.

**Generally associates do not feel strong enough to bring up their mistakes in front of others. But if you are prompt towards your efforts in bringing up your mistakes with proper documentation(as historic data); that would certainly help in bringing up the productivity in future.

anuBM

 Profile Answers by anuBM 

• Aug 14th, 2009

 

If the mistake is from your end accept it.

Also tell what were the loophole which could be corrected in next release.

rahulskin

 Profile Answers by rahulskin 

• Aug 21st, 2009

 

The tester should ensure the following.
- The functionality is already tested before releasing.
- If defects raised on the same.  Regression tesing is done properly.
- Any issues with the functionality. (From Testing, Development side)
- The RS documents are clear for the same and is functioning as per the same.

kurtz182

 Profile Answers by kurtz182 Questions by kurtz182

• Nov 10th, 2009

 

The question is:  Suppose a bug has been produced in live for the piece of functionality you have carried out testing. How will you give explanation to PM/Manager?  

This issue can not be considered 'Out of Scope' and there must be a test case for it because it is 'a piece of functionality you have carried out testing'. 

In this scenario, the tester will need to research to determine whether the issue was caused by 1) a faulty test case, 2) a difference between Production and Test environments, or 3) by the tester's mistake or lack of follow-through.  Whatever the case may be, it is the tester's responsibility to isolate the problem and take steps to correct it.  Once this has been accomplished, then the particulars of the issue should be fully disclosed to the appropriate individuals (Project Manager, Test Manager, etc.).

1. Faulty Test Case: 
a) Does the test case accurately map to the proper business requirement?  If not, then perhaps the business requirement was missed and this becomes the source of the problem.
b) Is the business requirement incorrect?  If so, then the requirement needs to be rewritten and new test case(s) produced from this new requirement.
c) Was the test case authored improperly.  That is, did the tester misunderstand the business requirement and create an improper test case?  If so, then the test case(s) need to be reauthored based on this newly correct understanding.

2. Difference between Production and Test Environment:
Does the defect occur only in the Production environment but not in the Test environment?  If so, then this must be made perfectly clear to management.  The tester may need to work with other functional groups to figure out how to bring the Test environment in alignment with Production in order to prevent this issue from reoccuring.

3. Tester oversight or lack of follow through.  As humans, we sometimes make mistakes.  There are situations when the amount of time that a test team is allowed to test becomes constricted and testers feel they must hurry to finish their test runs.  In these situations, testers inadvertently miss test steps or even entire test cases.  And it is Murphy's Law that the overlooked test case will be the one that could have uncovered a significant defect!  If this happens, the tester must own up to the error and inform management.  I have made my share of mistakes--we all do.  It is best to admit the blunder and take personal measures to ensure it doesn't happen again.  The most important aspect of ANY relationship, work or otherwise, is trust.  And if you try to cover up your mistakes, you will quickly lose the trust of your managment and cohorts.  Honest is truly the best policy in any circumstance!

trramai

 Profile Answers by trramai 

• Jan 18th, 2010

 

We will check the compatibility and the environment which they are running the software. If there is the issue of compatibility then fault is not from Tester. We will go in Root Cause of the issue and if the issue is from our side we will accept it. And also we will make sure that this type of issue will not occur further.

Explanation: we will provide the screen shot to the client that we had taken at the time of testing this functionality.

Ramesh Gaikwad
PCS, Mumbai