Monday, July 4, 2016

That's the common thing to happen! What is next?


The words "hang' and "crash" looks so attention grabbing!  I see these words grabs attention today as well but it does not retain the attention for longer time unless the someone is behind the programmer and tester for it seriously.

Gradually, I'm learning, the crash and hang are something very usual in software applications or hardware products.  Crash and hang are not cruel but it is an indicator of what is being missed to see. Like fever in human body is not a threat; but, it is an outcome of something that is not good in body and an indication.

I have to admit this honestly. I was so thrilled some years back when I happen to see the hang and crash. I use to say it hanged and people use to run for lab.  Unfortunately I was not in a state of mind to tell "that is okay, but what we have to looks is what made it hang or crash".   The hang or crash behavior is an outcome of an actual problem which was never learned by me, then. 

While I happened to practice the test investigation, I learn, hang is a symptom. I fetching as much as information from symptom to unlock the problem node, is the essential part of what I'm practicing now.

Today when fellow practicing testers come saying, "it got crashed", "it is hanged and unable to proceed" and as this, I say "It is a common thing to happen in software products.  Than writing this as a bug, go figure out what is making the product to fall into this state.  If you are not aware to learn that from test investigation, let us pair up and learn it."

Most times or all most every time, the symptom is reported as bug while the problem source is unattended by the engineering teams. Fixing symptom is easier so that symptom is not visible again. But the problem resides and it shows up something else as symptom and one more bug if identified this symptom.

Symptoms are trace backs to the problem source. Not stopping here is a good little small step for being better in test investigation skills.



Monday, June 13, 2016

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.