It feels like an eternal love story from the gospel of some lost writer. The relationship between a tester and the bugs they found while exploring applications, give you the same thrills and emotional intrigues, just like reading an ancient haunted tale of lost love.
Here is a rant about it, enjoy:
The Driving Force:
Each domain carries its importance. Each works independently with one and other, but also interact to deliver solutions and respond to customers whenever they are needed. But what keeps them together is not the positive energy, it is the opposite, and we call them Bugs.
Bugs are there since the dawn of the first line of code. They are with us since first ever human being put logic into the existence of the universe and got that wrong. It was called “mistake” back then. Now, modern thinkers have come up with several names and titles for it, such as; Error, anomaly, fault, defect, and issue. Within the context of name changes, these fellows have been defined in several ways. I think, the software people could not handle its existence very well, and they still try to understand what it is.
The Correct Definition Of Bugs:
Here are some of its definitions:
As per ISTQB: (http://istqbexamcertification.com/what-is-defect-or-bugs-or-faults-in-software-testing/)
- A defect is an error or a bug, in the application which is created. A programmer while designing and building the software can make mistakes or error. These mistakes or errors mean that there are flaws in the software. These are called defects.
- When actual result deviates from the expected result while testing a software application or product then it results into a defect. Hence, any deviation from the specification mentioned in the product functional specification document is a defect. In different organizations it’s called differently like bug, issue, incidents or problem.
- When the result of the software application or product does not meet with the end user expectations or the software requirements then it results into a Bug or Defect. These defects or bugs occur because of an error in logic or in coding which results into the failure or unpredicted or unanticipated results.
In the context of black box testing, Cem Kaner, has defined bugs as:
- Doesn’t match specifications or written requirements
- Doesn’t match documentation
- Generates incorrect results
- Generates confusing results
- Wastes the time of a user
- Coding error (doesn’t do what the programmer intended).
- Doesn’t meet design objectives
- Any failure (misbehavior)
- Underlying error that causes a failure
- Doesn’t meet company standards
- Doesn’t meet industry standards
- Anything that, if reported, would lead to a code change
- Anything that causes standards
- Would embarrass the company
- Makes the product less salable Interferes with development expectations of a user. (Myers)
- A bug is something that bugs somebody (Bach).
Admit this, you will not find this much of definitions for any other software related element in comparison to Bugs. There must be a reason to it, isn’t that? Well, to give you the reason let’s start with how this all is structured together.
The Value Analogy:
Software development is what? It is simply a process of interconnected functions, leading to a product or a solution to the customers at the end of the line. These functions are; Development, business analysis, designing, support, quality assurance, marketing, and administration.
What they deliver ranges from size, complexity, customers, and the problems they solve for the given set of customers. In other words it’s the value they provide to the customers. This value changes from context to context. For example, a car on the assembly line can only create value for the mechanics and engineers constructing it. It will have no meaning for the customer who wish to drive the car. This value is also called Quality.
Hence the definition:
“Quality is value to some person”
And then;
“Quality is value to some person, who matters”
And then we further elaborate it with time;
“Quality is value some person, who matters, at a time”
The whole process of software development and related services are encircles around this definition of Quality and the value it creates.
So where does the bug fit is?
According to Gerry Weinberg;
“A bug is something which threatens the value of the product”
Love The Bug:
From here the whole ball game changes to new rules. This one addition to quality and value equation actually changes the way we perceive and think about developing a software application.
A bug is not just some glitch in the line of code. It is a ripple that is creating dissatisfaction at the customer’s end. We must understand that software applications are not just line of codes now, they are beyond that, similarly testing is not just about finding bugs, it is more than that.
Software applications are creating impacts (seen on unseen) on users mind and bodies. They create psychological responses based on their own outputs and behaviors. You know that the ATM machine is not responding due to the error in the application or some networking issue beyond your understanding, but the value that ATM giving you functionally, is what created anger and happiness when it is not working and working respectively.
Can’t Live Without It!
Although posing a risk on the application and resulting in the customer dissatisfaction, software bugs are the ultimate reason for the perfect applications delivered to the client. With the discovery of important bugs at the right time and with right coverage, the testers are bound with an ultimate satisfaction.
The base driving force of this love story is nothing but something, which bugs somebody.
If you can understand this relationship, then you understand my business.
