How to Report/Log a bug?

It’s a good practice to take screen shots of execution of every step during software testing. If any test case fails during execution, it needs to be failed in the bug-reporting tool and a bug has to be reported/logged for the same. The tester can choose to first report a bug and then fail the test case in the bug-reporting tool or fail a test case and report a bug. In any case, the Bug ID that is generated for the reported bug should be attached to the test case that is failed.

At the time of reporting a bug, all the mandatory fields from the contents of bug (such as Project, Summary, Description, Status, Detected By, Assigned To, Date Detected, Test Lead, Detected in Version, Closed in Version, Expected Date of Closure, Actual Date of Closure, Severity, Priority and Bug ID etc.) are filled and detailed description of the bug is given along with the expected and actual results. The screen-shots taken at the time of execution of test case are attached to the bug for reference by the developer.

After reporting a bug, a unique Bug ID is generated by the bug-reporting tool, which is then associated with the failed test case. This Bug ID helps in associating the bug with the failed test case.

After the bug is reported, it is assigned a status of ‘New’, which goes on changing as the bug fixing process progresses.

If more than one tester are testing the software application, it becomes a possibility that some other tester might already have reported a bug for the same defect found in the application. In such situation, it becomes very important for the tester to find out if any bug has been reported for similar type of defect. If yes, then the test case has to be blocked with the previously raised bug (in this case, the test case has to be executed once the bug is fixed). And if there is no such bug reported previously, the tester can report a new bug and fail the test case for the newly raised bug.

If no bug-reporting tool is used, then in that case, the test case is written in a tabular manner in a file with four columns containing Test Step No, Test Step Description, Expected Result and Actual Result. The expected and actual results are written for each step and the test case is failed for the step at which the test case fails.

This file containing test case and the screen shots taken are sent to the developers for reference. As the tracking process is not automated, it becomes important keep updated information of the bug that was raised till the time it is closed.

(Please Note: The above given procedure of reporting a bug is general and not based on any particular project. Most of the times, the bug reporting procedures, values used for the various fields used at the time of reporting a bug and bug tracking system etc. may change as par the software testing project and company requirements.)

Bug Status Explained

Statuses associated with a bug:

New:

When a bug is found/revealed for the first time, the software tester communicates it to his/her team leader (Test Leader) in order to confirm if that is a valid bug. After getting confirmation from the Test Lead, the software tester logs the bug and the status of ‘New’ is assigned to the bug.

Assigned:

After the bug is reported as ‘New’, it comes to the Development Team. The development team verifies if the bug is valid. If the bug is valid, development leader assigns it to a developer to fix it and a status of ‘Assigned’ is assigned to it.

Open:

Once the developer starts working on the bug, he/she changes the status of the bug to ‘Open’ to indicate that he/she is working on it to find a solution.

Fixed:

Once the developer makes necessary changes in the code and verifies the code, he/she marks the bug as ‘Fixed’ and passes it over to the Development Lead in order to pass it to the Testing team.

Pending Retest:

After the bug is fixed, it is passed back to the testing team to get retested and the status of ‘Pending Retest’ is assigned to it.

Retest:

The testing team leader changes the status of the bug, which is previously marked with ‘Pending Retest’ to ‘Retest’ and assigns it to a tester for retesting.

Closed:

After the bug is assigned a status of ‘Retest’, it is again tested. If the problem is solved, the tester closes it and marks it with ‘Closed’ status.

Reopen:

If after retesting the software for the bug opened, if the system behaves in the same way or same bug arises once again, then the tester reopens the bug and again sends it back to the developer marking its status as ‘Reopen’.

Pending Rejected:

If the developers think that a particular behavior of the system, which the tester reports as a bug has to be same and the bug is invalid, in that case, the bug is rejected and marked as ‘Pending Reject’.

Rejected:

If the Testing Leader finds that the system is working according to the specifications or the bug is invalid as per the explanation from the development, he/she rejects the bug and marks its status as ‘Rejected’.

Postponed:

Sometimes, testing of a particular bug has to be postponed for an indefinite period. This situation may occur because of many reasons, such as unavailability of Test data, unavailability of particular functionality etc. That time, the bug is marked with ‘Postponed’ status.

Deferred:

In some cases a particular bug stands no importance and is needed to be/can be avoided, that time it is marked with ‘Deferred’ status.

Interview Questions: Database Testing

Hello Friends, I'm posting some most frequently asked Interview Questions on Database Testing. Now a days its been very common in most of interviews asking on Database concepts. I hope this helps someone looking out for. All the best for your interview. Thanks for reading.

http://www.scribd.com/doc/7151722/Database-Testing-Interview-Questions

ISTQB Foundation Level Certification Syllabus

Hello Friends, here comes spotlight on certification . One of the preferred certification by employers is ISTQB Foundation Level. Below is the syllabus for the same. Very soon I'm posting some ISTQB Exam Dumps along with some reference material. And also will post some more information about ISTQB Advanced Level Certification.

Istqb Foundation Level Syllabus 2007

QTP Topics to Practise

Hello Friends, I come up with something related to Automation. I know every know quite excited these days in learning QTP Automation Tool which is primarily used for Regression Testing and some use for Functional Testing too. Check out the document below which shows you the steps to follow in order to get your hands on QTP Training . I also included link to HP Mercury QTP Software and also gave links to some tutorials which are provided along with QTP Software. Most of the times these are not noticed much by everyone but they really gives you edge on QTP tool. Once you are comfortable using tool you can easily survive with industry requirements on Automation Testing.

Check the Document Below

QTP Topics to Practise

How to Prepare for Software Testing Interview

Hello Friends, Welcome to the most awaiting part in how to face a Software Testing Interview. I got some useful tips which i came across Internet. This is not my own creation, so all credit goes to the original content creator. Please drop in your suggestions and comments in what you need , so will try to get the stuff posted in here. Thanks for visiting my blog and please bookmark for updates using "Subscribe to Posts" from Home Page.

Please come back again to check here for more updates. This is just the beginning of our journey. More to come.... 

Download Interview Tips: Here 

Effective GUI Testing Automation: Developing an Automated GUI Testing Tool

Description:

Have you tried using an "Automated" GUI Testing Tool, only to find that you spent most of your time configuring, adjusting, and directing it ? This book presents a sensible and highly effective alternative: it teaches you to build and use your own truly automated tool. The procedure you'll learn is suitable for virtually and development environment, and the tool allows you to store your test data and verification standard separately, so you can build it once and use it for other GUI's. Most, if not all, of your work can be done without test scripts, collect test data, and generate test cases. You'll spend virtually none of your time playing with the tool or application under test.

Code-intensive examples support all of the book's instruction, which includes these key topics:

* Building a C# API text viewer
* Building a test monkey
* Developing an XML viewer using xPath and other XML-related classes
* Building complex, serializable classes for GUI test verification
* Automatically testing executable GUI applications and user-defined GUI controls
* Testing managed (.NET) and unmanaged GUI applications
* Automatically testing different GUI controls, including Label, TextBox, Button, CheckBox, RadioButton, Menu
* Verifying test results

Effective GUI Test Automation is the perfect complement to Li and Wu's previous book, Effective Software Test Automation: Developing an Automated Software Testing Tool. Together, they provide programmers, testers, designers, and managers with a complete and cohesive way to create a smoother, swifter development process—and, as a result, software that is as bug-free as possible.

Download: Click Here

Best Reference Book On Software Testing

Software Testing And Continuous Quality Improvement, Second Edition
Description:

Software Testing and Continuous Quality Improvement, Second Edition, illustrates a quality framework for software testing in traditional structured and unstructured environments. It explains how a continuous quality improvement approach promotes effective testing, and it analyzes the various testing tools and techniques that you can choose. Section I explains the role of QA principles and best practices in software testing. It provides a detailed overview of basic software testing techniques and an introduction of Deming's concept of quality through a continuous improvement process. This section explores the Plan, Do, Check, Act (PDCA) process, which is applied to all aspects of software testing. Section II reviews the software development life cycle and describes how testing and continuous quality improvement are incorporated into each phase of development. Section III details continuous quality improvement as part of the testing process. It breaks down software testing into a series of tasks that apply Deming's PDCA cycle. Section IV discusses fundamental challenges of managing testing projects, whether they are on-site or offshore. You learn how to establish effective test estimations to ensure that testing projects are on track. It also covers strategies for monitoring and managing software defects. Section V contains a brief history of software testing, previews advanced futuristic testing tools, and provides guidance for choosing the proper tool for various environments. It provides examples of some of the most popular products and offers a detailed methodology for evaluating them.

Click here : Download

10 Rules for Quality Testing

10 Sutras to become a Good Teseter.
Remember these ten rules and I am sure you will definitely gain very good testing skill.
1. Test early and test often.
2. Integrate the application development and testing life cycles.Also know as V-Model. You’ll get better results and you won’t have to mediate between two armed camps in your IT shop.
3. Formalize a testing methodology; you’ll test everything the same way and you’ll get uniform results.
4. Develop a comprehensive test plan; it forms the basis for the testing methodology.(Sometimes it is prepared by Test leader, just follow it under his guidance).
5. Use both static and dynamic testing.
6. Define your expected results with possible sets of data.
7. Understand the business concept behind the application. You’ll write a better application and better testing scripts.Try to have discussion with clients and request them to explain you there business process.
8. Use multiple levels and types of testing (regression, systems, integration, stress and load).
9. Review and inspect the work on periodical basis, it will lower costs.
10. Don’t let your programmers check their own work; they’ll miss their own errors.