It's a Bug, No It's Not.
Zeshan Ahmad
ERP QA & Test Management Leader | Empowering Businesses with Reliable, Scalable IT Solutions | Digital Marketing & Business Transformation Expert | Focusing on Sustainable Business Models
I can't remember how many times I have had this conversation in my career as a software tester and quality assurance analyst. This may be one of the reasons that sparks conflicts among testers and developers.
Testing is a different mindset, to elaborate this let me give you an example, if the requirement was to build a five by ten wall, a developer would go ahead and build a five by ten wall but a test analyst would try to understand why this wall is being built and what is the benefit of it. Is it too tall, too thin, too narrow, does the color of the wall resonate with the surroundings, what will happen if I push it, what will happen if hundred people lean on it. Will it bare the storm, can I build another wall on top of it, what about the possibility of creating a window in the wall in a near future and many other thoughts would come that will transpire into test scenarios and test cases. And when any one of the test scenario fail, initial thought of the tester is that this is a bug, but when you report that bug to the developer, he would disagree and show you there is no requirement for hundred people to lean on the wall.
However to the tester's defense, there is also no such requirement for hundred people not to lean against the wall but as a solution provider we are responsible to provide the best solution.
I am not saying that developers don’t think about the purpose and the benefit of the solution they are providing, but I have seen many times, they will give you minimal viable solution according to what business wants and most o f the time we find our self in this bug not bug dilemma due to lack of complete requirements. The irony of agile world is that there are no well defined requirements. While creating a solution the development team will discover issues that may even baffle the business itself.
So how do we solve this problem. I think in such circumstances, first thing is to log it, report it so you can track it. Then choose the proper category weather it is a defect or an enhancement or an improvement to the feature. Regardless of the fight weather it is a bug or not, we should take the best optimal approach to create the code around it if necessary and test is for sure to track such issue.
Let me know what your thoughts are.
LION??, Daddy, Coach, Mentor, Entrepreneur, Martial Arts Fan & Practitioner??, Monty Python Fan, Star Wars Fan?????, Lord of the Rings Fan????♂?, Technocrat, Foodie, Finder of Lost People, Creator of Happy Families
3 年Zeshan, thanks for sharing!
Technical Communication Expert, Documentation Mentor, Usability Advocate
8 年Golden words: "The irony of agile world is that there are no well defined requirements. While creating a solution the development team will discover issues that may even baffle the business itself."
Agile Project / Product Management ~ Product Owner ~ CSM ~ CSPO
8 年And also one thing most important avoid to these conflicts is positive attitude.
Country Director
8 年There are multiple ways to reduce these conflicts: ? Active participation of QM team or their representative in pre-development discussions on project idea, or desired changes, or updations. They need to validate the desired project, change to additions. ? Active Participation of the QM team or their representative in the process of requirement gathering and elicitation. ? Testing and evaluation of the final version of the Requirements. ? Testing and evaluation of the final version of the Design. ? Defining non- functional requirements by using pre-built templates. ? A strong prioritized evaluation/test cycles. ? Categorization and Prioritization of identified issues.