Software development is a very detailed activity. It comprise of several key elements, roles and stages. One stage coming after another, the preceding one providing outputs to the following one and thence converting a viable idea into a viable product.

Forewords:

Everyone works till the end to achieve a common goal and this goal is in form of a product which is based on computer / mobile system and will be used by a customer who is most of the time human. If the user is not human, then this could be another system, a protocol, a device driver, memory manager, or internet service, which would be using this application.

In any case, no matter who is the user of the system, one thing is clear, the user must use the system without any hindrance, expects what is expected from the system, takes benefits from it, use its data and reports for decision making, feel satisfied, happy, excited, informed and energetic.

Line of codes when written are a bunch of syntaxes sewed in together and represents a component in the system. For a developer perspective these are pretty exciting and challenging, but for a user, it does not matter much, unless these line of codes does something other than expected from them. So what the “value” part depends on the formation of these lines of codes. For developer and user the value is different.

The Bugs:

“Many serious bugs go unfixed because the decision-makers don’t understand the bug report they are reading or the bug’s implications.” – BBST (Bug Advocacy)

These hidden mishaps, anomalies and errors either happening due to bad line of codes, application malfunction, Requirement compilation, lack of training, Lack of domain experience, lack of standardization, lack of user design, confusions, etc. etc. All come under the definition of “Bugs”.

To define it more clearly, Cem Kaner expressed this in his BBST course 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
Failure to meet reasonable expectations of a user (Myers)
Anything that causes an unnecessary or unreasonable reduction of the quality of a software product
Would embarrass the company
Makes the product less salable
Failure to meet reasonable expectations of a stakeholder
Interferes with development, testability or revision of the product
Interacts badly with other programs and computers

Well, these can cover up much of the questions and answers regarding bugs and what they are, but then we cannot complete this without the inclusion of James Bach’s, which is:

“A Bug is something that bugs somebody!” – James Bach

What is bug Advocacy?

“A bug report is justified if it exposes a problem that does in fact reduce value for a stakeholder with influence.” – BBST (Bug Advocacy)

For testers, it is very exciting to discover bugs, but then, any user of the application can discover the bugs. So what is the difference?

The difference lies in the depth and projection.

The depth is the approach a tester duels down into an application, using heuristics, applying oracles, research, investigation, and reporting. The projection is where the case is constructed, which aim is not to criticize or finger point anyone’s fault, but to let the management construct an informed decision regarding product quality and stability.

That is why the bug report matters – because that one conjecture is a stepping stone which will decide about your findings. A tester needs to convince a developer / project manager / client / and fellow testers that her findings are something, on which they can spend their time. She also needs to make sure that these findings are for the product improvement and not an act to blame someone.

There are several ways a tester makes their finding worthwhile and quality oriented, such as:

Using proper templates for bug reporting
Use good English – or whatever the language applies. They do not shortfall in the use of proper grammar, and syntaxes, as otherwise it shows immaturity and non-seriousness
One line description which attracts attention, and it is to the point, while also focusing on the problem
They summarize the report with detailed “contextual” description of the issues and not the step wise test case. That can be done by the developer as well.
They are not shallow, and go in deep to the problem, even identifying what might have gone wrong at the developer’s end. Remember, saving the time of the developer to reach solution is one of our goals.
They attach images and screenshots with focused details, labeling and proper naming conventions.
They use proper evidence in form of calculations, documents, reports and cases to strengthen their story
They create videos for longer version of the cases. So that it saves time from tedious documentation and pin points the error nicely.

Why Testers do it?

Simple, we need to be cost effective, quality oriented and detailed. We need to understand that the real cost of quality resides in re-works, rather than the time spent on development and testing in the first cycle.

If the bugs and their reports are not effective, we will lose our reputation as testers. We as testers are not the decision makers and finding bugs in the application does not make us the enemies of the development team. We need to understand that what we do actually helps management in making informed decisions and minimize the risks in application.

In the end we have a satisfied team mate and the client at the other end of the cycle.