It’s a common practice to identify the priority and severity level of a bug.
I am asking for your opinion about the obviousness level of a bug and how to incorporate them into software development life cycle.
Looking forward to hearing more from you.
@Hiep,
Welcome to the site and thanks for your question.
That sounds like a good question…but I’m not sure I understand what you mean by “obviousness level of bug”. Could you help clarify a bit of that term.
Thanks
Yes, it could be confusing 🙂 Let me give you an example.
Given an “age” text box that only accept a number from, say, 1 – 150.
We find a bug that it allows to enter a text, number out of range etc…
Obviousness -> how obvious is the bug? Because there are bugs which are so obvious that we can not accept that the developer is so careless to create it.
Hey Hiep,
That’s clearer now with your example.
Your situation is not uncommon in the “world” of developers and this may boil down to definition of “bug” in this case.
From the developer’s point of view, it’s not a bug when:
*It’s not mentioned in requirement (E.g.: “Nobody told me to do that”)
*It’s a corner case (E.g.: “Who’s the hell on earth will do that?”)
In other words, the developer does not see the reason why he should fix it….and it makes sense.
Now it’s testers’ job to tell or persuade the developer why he should fix it.
As James Bach’s definition: “A bug is something that bugs somebody who matters.”
It means that whom this bug impacts and how much it impacts.
As your example above, if the textbox allows user to enter text, this may mess up the database or impact other fields (or whatever you can find out) and you prove that it’s not good at all.
Check out this link to find more reasons to persuade if a bug or not (http://www.developsense.com/blog/2012/07/few-hiccupps/)
And if you cannot find good reason to persuade developers to do that, I think developer has his point to not do this case.
Hope it answers your question.