How to report a BUG???

Firstly, how do we call it. Either BUG or DEFECT?
As far as my concern, both are practically same. Defect is when the tester raises a issue, where as we call it them as Bug  when the defect is accepted by the developer officially.

Its a professional war :) between a developer and a tester. However its a friendly battle :) Only one can have the upper hand, either a quality code or a strong tester.
When a bug or a defect identified, a tester should report it to the respective developer. But how? What are the steps need to follow while assigning a bug to the developer?

With the following template I guess the bug/defect can be reported accurately

1.Title: A short description about the bug in a single line
2.Identified by: Name of the tester
3.Date: Bug identified date
4.Assigned to: Name of the respective developer.
5.Environment: In which environment does the bug identified. Like windows or linux or solaris... 6.Build no: Build release number in which the bug is identified.
7.Bug Type: States the type of bug it is. Typically these are,

• Functional:  Bugs that are deviated from the expected flow.
• Usability: When an end to end scenario accomplished in different way instead of the actual way
• GUI: Bugs that affect the presentation, look or layout of pages, images and form elements.

8.Bug Severity: This renders the impact of the bug on the application. Defining the type of bug identified, whether its functional or usability or gui or security. Severity levels can be differ as per the process followed by the companies. My severity levels are likely critical, high, medium, low.

•  Critical: If a bug is mapped to this means, then the screen/application encounter with unexpected errors and can not be tested further and need to be resolved immediately. Ex: Can not log in to app
• High: If a bug is mapped to this means, then the functionality in the screen/app is deviating from the expected result. Ex: clicking on a link takes you to page X instead of the intended page Y
• Medium: When a record is saved into database but improperly shown in the user interface. Then the bug can be mapped with this.
• Low: Bugs that do not interfere with core functionality and are just annoyances that may or may not ever be fixed. Typically spell mistakes, color legends. Ex: Search results format display incorrectly in different browsers

9.Priority: How fast the bug has to be resolved. Decision take by the developer/manager
10.Test data: What kind of test data used while testing and through which data the bug is identified.
11.Module name: Name of the module bug identified in the application.
11.Screen name: Name of the screen under respective module, the bug identified.
13.Description: Detailed description of the identified bug with proper reproducible steps.
14.Root cause: Specify proper reason for the bug caused.
15.Attachment: Proper snapshot of the bug, if required.

"Although tester has classified the bug, lead or manager has right to re-classify the bug."

Happy Testing...

 A Journey towards Testing...:)

What should you test first when a new functionality change occurs

In my experience of testing an application when build released, as a team first we must read the release notes properly which was provided by the development team. Then prioritizing the our testing levels

1.Sanity Testing(Initial) : Go thru each and every links in the application and ensure that there will be no blockers and finally certify that build is ready for further testing

2.Adhoc Testing for a while: Testing the application with random scenarios for one or two hours

"After all we are most likely  to find bugs on new features which were released with the build, then why doing this Sanity and a sample adhoc?"

"Of-course I do accept that our first priority would be testing the new functionality. But before moving to that tester has to certify that build was properly deployed which is the initial phase before actual testing starts isn't it?  After successful completion of sanity we will proceed according to the release notes and all..."


3.Executing Test Scenarios(High Level) : After a while of adhoc testing, tester must execute all the high priority scenarios according to the release notes which i mean to say is positive way of testing. Surely tester can filter the high priority bugs in this stage itself

4.Executing Test Scenarios(Low Level) : Executing the application in depth including the medium and low priority scenarios also adding with negative scenarios.

5.Re-Testing : Retesting of the Fixed bugs and
After few iterations of the same process, in the final iteration, the big task ends with...


6.Regression Testing: Ensuring new changes would not effect to the existing functionality.

As recently started my journey in testing, I experienced these type process when build was released to testing team.

HAPPY TESTING!!!

A Journey towards testing...:)

Testing is nothing but Common Sense

Its 2nd Jan of 2012 and its been over 1year passed started my journey towards testing. In this one year span of time I have learned a lot during my training period and afterwards. I can see much difference in myself.

During my journey, I learnt Why to test?, What to test? and How to test?. I started my journey with the question "Why to Test?" followed by "What to Test?" and now researching myself every time  "How to Test?".

"Why to Test?"
I can say testing is essential before  any product or an application gets or getting released into the market. Even a match stick will be tested before released into the market then why don't we do testing for our application which is more valuable. An organization with good product earns good reputation in similar fashion A company with a good testing team will always deliver high quality product. But never forget "No product is 100%bug free". :)

"What to Test?"
I can say this as Testing beyond the scope is called 'What to Test?'. We the people testers has to think out of the box in a generic way as an end user perspective. Testing only the functional specifications written in the document is rewriting the textbook examples. A person can achieve more when he can solve the exercise problems.

"How to Test?"
A tester thinking with little common sense will help in good results and that's what I believe and experienced in achieving better results. A developer uses logical thinking to indulge his logic into the code but somehow he loses his common sense while deploying it (I don't blame for it, its just a human mistake). But a tester has to use his common sense first then a logical thing. In my experience I have seen in many areas people are emphasis about bugs than the quality and I believe that is due to lack of common sense. But ultimately we need our product must be released with less bugs. That can be achieved by adding COMMON SENSE to our testing can get it easily.

With the reference of a functional document any one can test the product but executing beyond the document is nothing but common sense and that's the difference between an end user, a developer and a tester. I am using my common sense while testing. So I'm proud to be a tester and by this I can strongly say to anyone that

 "TESTING IS NOTHING BUT COMMON SENSE"

TESTING WITH COMMON SENSE GIVES BETTER RESULTS. AGREE????

A Journey towards Testing...:)