Testers often come across this frustration of bugs not getting accepted by the development team. It takes huge effort and rounds of negotiation before both of them come to a same page. What causes this debate? How can we minimize it? How can this overhead be avoided? Let us explore.
Developers would not accept a bug because of following reasons:
1. It is not a bug!
Here, either tester or the environment is at fault. Tester, because he might have missed certain gray areas of the requirement and analysed the functionality wrongly. Environment, because some configuration or plug-in required to run the application might be missing.
2. Ambiguous requirement!
Here, both tester and developer have their own understanding about the expected functional behaviour of the product. The requirement document is does not neatly outlines or able to explain the issue in contention.
3. Deadline is close!
When project deadline is close, everybody is in hurry to release the product. If developer has huge pile of issues to be fixed, they may reject less critical bugs and would address only the critical ones. Yet, it is management call as to what to be omitted and what not.
4. The product is ok with this bug!
Developers may come with a fancy argument that customers never complain about such issues and we should also not pay attention to such issues. For example, any cosmetic bug to improve the look and feel of the product.
5. Previous versions are running with the same issue!
This is ironical but unfortunately very prevalent argument we hear that customer has never complained about this issue and the product is already running fine.
6. Follow the process!
Developers are biased towards their modules. So they follow the right steps to reach to the result. However, testers try to crack the application with their negative testing as well. Developers, in this scenario, often complain that testers did not follow the process, which the customer is already trained on. So it is not developer's job to fix the bug if the desired steps are not followed.
So, after listening to one of these arguments what approach should a tester take. Should they rework on their own testing strategy, develop negotiation skills, get more idea about the product or talk to the management. Actually, a tester can do all of them or mix of multiple strategies. How? Here we go:
1. Testing strategy: If there is a bug which is not being accepted by developer, a tester should relook the environment, test documents, procedure and business requirements. There might be something lacking in one of these components. So, they better rework now rather than getting pointed out in future about own fault and experience embarrassment.
2. Negotiate: If there is issue with the slippage of deadline due to too many issues, testers may need to negotiate with leads and managers to defer the deadline in order to release quality software. Better late than never! A product with bugs will impact business more than delaying the release.
3. Analyse the requirement documents: If there are ambiguities with the requirement document, tester should point them out to the concerned stake holders and get them resolved.
4. Keep logging bugs: Many a times, testers get carried away after seeing a bug and tend to discuss with development team rather than logging the bug in the bug tracker tool. This is deviation from the process. If tester is convinced about the bug, she/ he should log it. In the worst case we have a flag called “Rejected” in the bug tracker tool, right?
5. Gain more knowledge about the product: As discussed above, there are occasions when testers have limited knowledge about the product. As a result they may not find the right bug or they may unnecessarily raise wrong bugs. To avoid this threat they should gain more knowledge about the product. I believe, testers should know about the functional aspect of product more than a developer of the product.
To sum up, testing is a collaborative approach and testers should take the charge to collaborate with all the stakeholders, including developers. However, every stakeholders need to remain cautious because bug leakage at the production costs really high. A stitch in time saves nine!
No comments:
Post a Comment