Archive for the ‘Technical Support’ category

Context driven information for Bug Reports

July 26, 2007

Context driven information is the need of the hour and there is a huge value associated with the same. It’s good to capture the context driven information in the bug reports. My initial experiences with bug reports way back in early 2000 have taught many lessons to improve upon.

Bug reports used to capture what is the problem with the system familiar to the user (tester) who reported the same. People spend very less time to capture all the details required and there are many reasons for the same. I hope some of the upcoming testers will also be in the similar situations.

Some of the Reasons people quote here

  • We need to test more and less time to capture & write more information in the Bug Reports
  • It’s tough to capture all the information required
  • System is complex & It’s tough for the novice users to understand the bug reports
  • You know capturing all the info is process driven & it may not be worth of efforts
  • It some times boring activity to collate the info & push it
  • I can reproduce it on my machine if developer needs it.

This list can go on…

I hope you have come across this situation at least once in your career.

This is my third post in the Bug Life Cycle Series and it’s good to know the different users of your Bugs and their context with them. The mission of your bug report is to provide details and context of the problem and convey the importance of it with a user driven stories.

Your bug report must be the voice of customer and it need play the role of an advocate against the problem. Bug Advocacy from Cem Kaner is an excellent source to begin with. If the bug report unable to specify the need of the context, then it’s better not to write any report

It’s good to explore & capture some of the following problems

  • Productivity
  • Performance
  • Usability
  • Migration
  • Stability etc

Try to link your issues with most suited functions listed above. It may not be obvious to other users in the system to explore & analyze the issues in that fashion.

There is another context associated with Bug Reports. That’s with the stake holders of the project. The Bug Tracking system must give the right trends and identify the hot spots. Testers must capture the right kind of data to derive better valuable metrics over the bug repository.

Care must be taken to capture

  • Capture all the Test Environment details
  • Detailed classification on the feature. Classify to the maximum possible sub feature/component of the system
  • Clarity on Severity & Priority
  • Versions and Build Numbers (Affected & Fixed)
  • Bug Classification (Requirements / Design / Implementation etc)
  • Bug Types (Functional, Performance, Usability, Security etc)
  • It can go on…

The above info helps a lot to identify the trends in bugs and focus on the unstable components / environments.

Final Thoughts
Push the entire context driven information to the bug repository at least for a release cycle and observe the results. Check back with your repository to identify the trends and risk associated with the release and I am sure that it will be in the similar lines of end user feedback.

Happy Testing…


An insight into Bugs in the Software Applications

July 6, 2007


Bugs are there every where in the software applications. Almost every one who uses software applications for their day to day activities; do come across different kind of problems while working with them.  Each of these problems has different meanings to different people on it. There are many instances where in which, we (as end users of the system) do feel that how come they missed this bug, it’s very important in this context (The context where in which the user operates).

Tester deals with Bugs every day and its good know about other people get affected with them. The list includes Customers, Stake Holders, Sales, Professional Services, Technical Support, Architecture & the Development team.


This is my second post in the Bug Life Cycle Series. Before going more into the Bugs and their life cycle, it’s good to know, what it means to different people across the software application. Based on the contexts, the same bug might mean different things to different people. Do go through Role of Software Testing to understand my mission about Software Testing.

Wikipedia defines Software Bug as the following

A software bug (or “bug”) is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect result). Most bugs arise from mistakes and errors made by people in either a program’s source code or its design, and a few are caused by compilers producing incorrect code. A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy. Reports detailing bugs in a program are commonly known as bug reports, fault reports, problem reports, trouble reports, change requests, and so forth.

Tester Perspective

Any deviation from the expected results of the test case will be treated as a bug in the software application.


Customer Perspective

Customer uses the software application to solve his business needs. Any problem while modeling a solution to the business need will be considered as a bug in the software applications. These problems can be classified into two. They are the list of problems that they can live with and the other is the list of problems that need to be addressed to solve the business need.

The second list of problems will be sent to the vendors of the application for the fix. Some times, customer sends only the show stopper problems for his business. It’s true in the fact that as an end user, I will contact the vendor only if the problem is critical for me.



Technical Support Perspective

The Support Team classifies (though it’s critical) the customer requests into New Features, Enhancement, Bug, How to & Enquiries etc with respective severity levels. The decision will be taken by validating the problem with the features in the product.


Developer Perspective

The feature is designed this way and all the cases have passed. The end user might be using some other scenario. Yes, Some times there are bugs in my code. But it functions well if we use the way the application has built.


Management Perspective

Any problem with the application will be treated as Bug if it has impact over the revenue and customer satisfaction.


Final Thoughts

It’s tough to have same perspective across all the people (might happen in an ideal world). The bug for some one may not be the bug for the other person. However there are some set of show stopper bugs for which, the perspective will be the same.

Hey Testers, Communicate the Value of Testing

June 15, 2007

It’s almost a month since my last post on this blog and busy with my upcoming release of QuickRules BRMS. I have been talking to the people around on the Software Testing and felt that it’s not communicated well. Though there is enough information on this subject, i would like to describe my own version of the same here.


Testing is about making things better by providing constructive criticism based on the context (we can also say qualitative information and not being nice) at the right time and in the right direction too.

I like the phrase, “Testers, you are the headlights of the project” from the book Lessons Learned in Software Testing.

I have been thinking about this concept helped for the individuals. This revealed lot of crucial information and i hope this helps my fellow testers to motivate them & their teams.

There are many real life testers (incase if we need to list all of them) who contributed & still contributing a lot for us in every phase of life to grow and improve upon (fix the imp bugs among ourselves).Let’s explore some of them below.

My Parents are the first testers in my life. They contributed invaluable information at each stage (Milestone release) of my life. Instead of saying “Sshhhhhh you can’t do that, they used to tell me further implications that might arise”. An insight into this tells us that it’s not an order, but there is context based information for informed decisions.This helped me to stop for a while, analyze the information and work on the required steps to improve upon the current state.

My teachers helped me a lot by providing the constant feedback (just not being nice) through assignments, tests and covey the areas which are good and bad for me in the respective subjects. They are the best testers because they are the ones who taught the concepts and observed my execution towards the same.

There is a tremendous scope for the improvement, incase if we have acted upon the feedback at the right times.

My Boss at work used to evaluate (Test the Tester) me & provide the feedback on the tasks performed by me. This information helps to analyze to identify the next set of steps to be taken for the improvement.

If we look back, there are many testers around us providing the qualitative information to make things better and improve upon.

The Value of this information is tremendous since it came from people who are more experienced and passed through the current stage where we stand. The value lies in the fact that most of the successful people around, learnt a lot from others (learn from others mistakes too rather than your own) and they have become experts in their own fields.

How does this helps Software Testing

Software testing too comes under the similar lines and its role is to provide context driven information for the stake holders to make informed decisions over the application under test (AUT).

So as being testers, we need to provide the constructive criticism at each stage of the Development. If we look back at the above scenarios, the value addition is more because the people involved there have better skills over the context.

That being said, the current industry lacks skilled testers. The true value addition in Software Testing will be more, if and only if the people involved there have better skills over the context they working with.

Do share your views here or send them to me at

Happy Testing…

Non Reproducible Bugs – How to deal with them ?

May 7, 2007

Last week, i had reviewed the bug reports submitted by my team & found that some of them are not reproducible. I am curious about where things went wrong & checked with the team.

Some of the Responses:

  • Look Venkat, this bug is not-producible always. So we have captured the log.

  • It does occur if we re-start the application

  • It takes good amount of time for the investigation

As a Tester, i have come across of situations where some bugs won’t reproducible again and i infer that many of the testers might have gone through the same episode atleast once.

But then, Non-Reproducible Bugs are errors of the testers even though we may not agree. More over this is true for Technical Support & Testing functions.

It’s tough for the Developers to work with such bugs and testers used to get lot of objections over such bugs. If the count is more, then it might spoil the relationships between testers and developers.

An Insight

I infer from my experiences that systems doesn’t have the powers of human brain. It’s tough to repeat the same mistake again from people since they are conscious. Systems doesn’t have that much capability interms of thinking and they do perform the sequence in which they have coded for. 

How do deal with Non Producible Issues

Testers need to improve their skills inorder to reproduce such issues. The following might be a help.

  • Try to capture the story around the issue and not just steps.

  • Capture the complete Test Enviroment

  • Capture all the available Test Execution Results. This includes your test data, screen shots, applications logs, system logs, server logs

  • Need more patience (they won’t occur easily)

  • Need more observation skills on the application behavior under test.

  • Narrate the story around the issue to the stake holders and to corner the issue.

  • Resources & Time Contraints might be an issue (More true for Tech Support). Bargain for the same


They are bound to take lot of time & resources in the process. It’s suggested to reproduce each & every issue. We must explore more for the critical issues & re-produce them asap. In the process, we learn more too.  

Happy Testing.

Lessons to be Learned from the Bugs

April 30, 2007

In this post, I will be looking at Bugs  with an insight that helps testers to learn some new lessons on why the same might have occured. It’s quite common that the testers are  blammed  for  all  the  missed out  bugs  in the system as if they are super natural powers to over see all the issues that are there in the system.

Bugs are there every where. Not just software applications, look at any system for that matter & there are issues wrt End User needs and the same might need to evovle over a period of time with the changing needs / requirements from time to time.

What is a Bug ?

It’s tough to arrive at a generic defintion for the bug & people might have heated discussions on what is a bug & what is not. Mostly it’s based on the context in which people are working. We do come across many bugs in our daily life while working with the tools that are needed for the day to day operations.

So in my context, Bug is something  that’s unable (doesn’t allow me) to satisfy my needs with the system.  What do to do ?

Capture the story around the Bug and not just steps to reproduce. Talk to the reporter and discuss on the scenarios used with the system that lead to the bug.Let’s explore the possible options even though Tester validated the system early

New Test Scenarios for the Testers

  •  We mayn’t even think of that scenario while validating the system. Add the similar test scenarios to the Test Suites

  • The scenario may not be logical (though it seemed to be for testers) for the user though functionally correct. Add to the similar scenarios to Test Suites

  • Might have been a compatability issue with a new environment that doesn’t exist in Test Labs  

Reduce mistakes and improve test teams capability

  •  Might have been missed by a Tester. Check with the tester who performed the Test earlier and find out on why issue missed and the same marked as a pass even though it fails. Might happen through overlook also. Do more analysis here and try to reduce the same.

  • Might be over looked through regression tests. Might have failed and passed in the internal builds and finally breaked in the production system. Analyse the reasons here and improve upon on regression testing.

  • Make it a point to log the bug as soon as they discover the same. People might loose the same from their memory as time goes

%d bloggers like this: