I stopped writing the thoughts which I’m penning now, on
listening to fellow testers at desk. Listening to them, I’m making note of the
words which they are using in their discussion.
Altogether, I’m out from the thoughts of what I was writing and I’m into
the thoughts of what the fellow testers are discussing. I was writing an incident of code review by a
tester (by illustrating it with the snippet of the code) and how the tester figured
out the case which automation would have asserted as no problem while it is a
problem.
Okay, now I hear the tester saying “not a problem while it is a problem i.e. a bug”. Hearing this, I say myself, “yes could be the bug in the written
automation code”. But for the
testers, who happened to agree mutually later in discussion between each
others, they came to consent - it is a
bug in the product as well. While
this is happening, I see a tester walking in to the bay and joined discussion
by saying, “I read, not everything is a
bug what I think as a bug.” Well, now I’m out of my thoughts completely into
which I was and I growing more curious to listen the fellow testers discussion.
I asked the fellow testers, "What is a bug then? How you infer about it?" I hear them saying, "A bug is a characteristic which annoys the user" and "A bug is a characteristic or happening which threatens the value of product and product business". The other tester iterated, "not everything is a bug while I think it is a bug."
Now I have changed my writing thoughts from the automation case study topic to this topic and I started to make note of the words as we discussed. In discussion, I see a thick line of contradiction implicitly in these two lines – “a bug is a characteristic which annoys the user” and “not everything is a bug while think it is a bug”.
I asked the fellow testers, "What is a bug then? How you infer about it?" I hear them saying, "A bug is a characteristic which annoys the user" and "A bug is a characteristic or happening which threatens the value of product and product business". The other tester iterated, "not everything is a bug while I think it is a bug."
Now I have changed my writing thoughts from the automation case study topic to this topic and I started to make note of the words as we discussed. In discussion, I see a thick line of contradiction implicitly in these two lines – “a bug is a characteristic which annoys the user” and “not everything is a bug while think it is a bug”.
A user perceives the experience is annoying to her or him and
take it as a bug while using the product. But the product not taking it as a
bug, because, it does not see a threat to the value offered from it. Then what
is the bug here? Should I stand with a
user perception of experience or the product’s philosophy saying no threat to
value offered by me?
Alongside the thick of contradiction here, this is a thin
line of thought differentiating between the two statements – a user experiencing annoyance and a product’s value what it intends to give.
In other perception, it is, “whose words matter to label it as a bug and having
it in the fix list?”
If I use a product and I’m annoyed about a particular thing,
is it a bug? Does the product think, my annoyance is threatening the value it
is offering to user or me? In business, it is purely a strategic call for
having the change in the product or to continue with the same. Still, how do
three testers can voice about their experience of saying it is a bug and not
so, in reporting it?
The other round of analogy for this – if product is
functional then it is usable; but If the usability is bad, does the product is
still functional; or, the functionality is also bad in terms of experiencing
it? It is a relationship i.e. functionality and usability. So the bug and the
experience of the user, is also a relationship. With this, the value offered by
the product is also a relationship between the product and a user.
If product’s business does not think it is a bug and also not
as an enhancement suggestion to product’s wish list, the annoyance will
continue to who is experiencing it. The product believes the value is being
delivered with no threat!?
With this, the definition of ‘what is bug’ is highly
contextual to what the product’s business say. Knowing this, it helps me while not
ignoring a user feeling the annoyance for a reason in using the product.
Hearing to testers now, I brought the fourth thread into the
discussion, “everything that I say it is
not a bug, not necessarily, it is not a bug”. At the end, it is product’s business decision
after my advocacy on that characteristic behavior. As I won’t be able to find all the bugs;
likewise, I will not be able to understand and identify the bug while it is in
front of me and the product’s business. Still the products get shipped and the
discussion around “what is a bug?” continues.