I Do Not See “I don’t see”

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”.

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.

Technical, how technical ?

"How technical I have to be here to test and understand what information is expected?" This question changes it's form based on Test Coverage expected for context of testing.

When I ask "what does technical mean here?", I help myself to learn what it is for the context of testing. Like the programmer learning technology to write the code for product, the manager identifying and practicing the new managerial skills required for managing the project, I see what has to be practiced technically for what I'm testing.

The 'Test Coverage' hints me what I have to approach and to what extent I have to navigate in the modeled map of system for testing it. Knowing this, it helps me to learn how skilled I should transform into so I can work along with the technology.

For example, if I had to test the Database System which is non relational, then how should I approach it? Apart data reflecting on commit what else do exist?  Say, the product I'm testing is on non relational database. How will I approach it now to test other than the data reflecting coverage? How technical I have to here now to test? What can I automate here and how? What is the area which requires focus of me than mere checks of automation coverage?

For a programmer, the programming skill is one which she or he practices each time. Apart from practicing programming, the programmer also practices coding for a technology by learning the specifics related to it. While doing this, the challenges come up in writing solution and fixing the problems observed. Likewise, to me for a tester, the testing skill is one aspect which has to be practiced everyday. Besides, I along with technology is also essential by practicing the technical perspectives required which supports and strengthen the testing.

Getting technical is not necessarily programming alone. The orientation of being technical has it's scope for testing. Each element of subject has its technicality.

In changing trend of the industry today, one being technical is becoming necessary as a day move to tomorrow. By reaching in time to market on solving the very appropriate problem of the people, it needs the blend of technical skills along with testing skills.