Archive for July 2007

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…

Advertisements

Use Cyclomatic Complexity to determine the Risk and Test Scenarios

July 19, 2007

Cyclomatic Complexity (CC) is a software metric (mostly code based metric) used to the number of independent path executions in the application. Introduced by Thomas McCabe in 1976, it measures the number of linearly-independent paths through a program module.

It helps the developers to determine the independent path executions and base line unit tests that they need to validate. Using this, the developers can assure that all the paths have been tested atleast once. It’s a great comfort for the developer and their respective managers.

It’s better to write JUnit Tests for all these linearly-independent paths and integrate it with any code coverage tool. These reports help to focus more on the un covered paths and improve the code coverage.

It also helps to evaluate the risk associated with the application. The following are the results published by SEI and they are being followed widely to determine the health of the code base.

Cyclomatic Complexity      Risk Evaluation
1-10                                              A simple program, without much risk
11-20                                            More complex, moderate risk
21-50                                            Complex, high risk program
Greater than 50                          Un testable program (very high risk)

Explore more at Cyclomatic Complexity in Software Technology Roadmap from SEI.

Further Reading on the topic

Use metrics to evaluate the risk early in the cycle & improve your test coverage.

Happy Testting …

An insight into Bugs in the Software Applications

July 6, 2007

Abstract:

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.

Life Beyond Code

July 4, 2007

Rajesh Setty is well known his book Beyond Code and blog Life Beyond Code. Last week, I had the opportunity to attend  his Seminar on Life Beyond Code. The event was organized by HYSEA at Hyderabad.

During the seminar he focused on the following skills

  • Personal Branding
  • Building Long term Relationships

 His book targets the Technology Professionals find an insight into the book below

We need to do different things and distinguish ourselves to get superior results in our life. For this, we need tools that will help us distinguish ourselves and we also need the discipline to practice them daily. In this book, the author puts together a set of such insights and practices from his notes and cheat sheets collected over the last ten years. The purpose is to help you emerge from a life inside the cubicle, and take it beyond the code.

His work and thoughts in this direction are truly amazing. His books focuses on the nine skills required. The only way to capture  them is to learn and practice them daily.

Explore his blog for more details.


%d bloggers like this: