Saturday, July 23, 2016

Do I want "the bug" or "the testing" ?

When a fellow tester or colleague or stakeholder ask, "Let us find the bugs by testing" and "Let us learn the problems and risks by testing", I think the below.

Why testing is often seen or taken granted just to see the bugs out there or the risks residing within, if at all? Do programming is to introduce the bugs and fix them, all in all?  Then why testing and testers are seen as behind the bug always or put around the bugs?

I see this attitude (mindset) and expression of looking and practicing the Software Testing, yielding to experience just the one small part of a petal of the craft. While there are other petals and benefits of the craft, it goes unused and unexplored.  Unlocking from this expression and attitude becomes so complicated, it looks inseparable from the above said thought. The reality is, it is distinct and separate; but, taken as one.

While programming is to solve the problem, isn't the testing is to learn the problem if any in hand. Before this, I ask myself, why there should be a problem always to solve? I see this notion i.e. seeing a problem in first hand, makes the mindset just to focus on the problems rather than placing the problem as one part of the study. That means, problems get associated with everything, then! Why so? We look for it placing the importance for it? Does that importance is studied well to make it important to emerge as a whole than being a part?

To recollect the definition what I remember from Dr. Cem Kaner is, Software Testing is an empirical technical investigation activity conducted to provide (learn) quality related information of product to the stakeholder so that they make informed decision.

Here he does not say about the 'bug' or 'problem' or 'risk' or 'defect'. I see this is so close to daily work I do in my practice.  After this I get the question for myself, "He says, 'information' about quality criteria. Is there anything that is 'not a quality criteria' and still the tester provide the information from her or his testing about that too?"

Leading from here, my thought spans to a branch. This branch gives the thought of the word 'value'. In programming, declaring a variable and assigning it a value is simple? And this assignment takes it's types and namespace in the defined environment.  If this is simple to declare and assign a value, why this value of a product tend to become so complicated when it is tried to in terms of a software product to use?

Now should I learn the value of each and every aspect that is getting collected, then written as part programming and coming out as a usable commodity and the outcome of using it?  Is that value here is -- a bug or problem or risk, I learn from my testing?

Later this points me to line -- "A bug is that which threatens the value of a product". If this is so evident, then, why I hear or asked to look for bugs alone around the product? And, not to learn the value and what is that trying to diminish it in the context?

This further makes me to ask myself, fundamentally, are there anything else in the existence, which is non-bug that can threaten the value of a product and annoy the user? Something as this, programming is just to write buggy code? If so, testing is to look and anticipate just the bugs?

Unfortunately this has crawled so deep in the industry, we want bugs but not the testing. We ask the bugs and not the testing. The impact of this is recursive and passes on to the generation of testers as it is come to my time as well. It makes me to look for bugs (information) i.e. one of the outcome from testing while ignoring and tending to being away from the testing. 

I'm not saying to unroot this or to do anything that helps. But, is it possible to give a thought from the practicing tester before asking anyone to give the thought about this. I want to give my thought about this each time I test to learn what I'm doing and practicing.

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.