BUGTRACKING

Faqs Bug Tracking

1). what is the difference between Usecase, Test Case, and Test Plan?

Use case: Use case is prepared by BA in the Functional Requirement Specification (FRS), which are nothing, but a step, which are given by the customer.

Test Case: It is prepared by the Test Engineer based on the use cases from FRS to check the functionality of an application thoroughly.

Test Plan: Team Lead prepares Test plan, in it he represents the Scope of the test, what to test and what not to test, Scheduling, What to test using automation etc.

2). How can we design test cases from Requirements?
Do the Requirements represent exact Functionality of AUT?

Yes, Requirements should represent exact functionality of AUT.

First of all you have to analyse the requirement very thoroughly in terms of functionality. Then you have to think about suitable test case design techniques (Black Box design techniques like Equivalence Class Partitioning, Boundary Value Analysis, Error Guessing and Cause Effect Graphing) for writing the test case.

By these concepts you should design a test case, which should have the capability of finding the absence of defects.

3) How to launch the test cases in Test director and where it is saved?

You create the Test Cases in the Test plan Tab and link them to the requirements in the requirements Tab. Once the Test Cases are Ready we change the status to ready and go to the "Test Lab" Tab and create a Test Set and add the test cases to the test set and you can run from there.

For Automation...In Test Plan ...create a new automated test and launch the tool and create the script and save it and you can run from the Test lab the same way as you did for the Manual test cases.    

To answer your question...the test cases are stored in Test Plan Tab.Or more precisely in the Test Director, Lets say Quality Center 's database TD is now referred to as Quality Center.

 

4). What is the difference between a Bug and a Defect?

When tester verifies the test cases, all failed test cases are recorded as bugs directed for necessary action and recorded in defects reports. As a testing point of view all fail test cases are defects as well as found bugs. While development point of view if product doesn't meet the software requirement specification or any other feature that is to be required, it is defect in that system. Who found this feature is not meeting his or her requirement, he or she call it is bug in that product.     

5) How we can explain a bug, which may arrive at the time of testing. Explain that bugs in details

First check the status of the bug, then check the whether the bug is valid or not. Then forward the same bug to the Team Leader and then after confirmation forward it to the concern developer.

6) What do u means by "Reproducing a bug"? If the bug was not reproducible, what is the next step?

Reproducing a bug is as simple as reproducing a bug. If you find a defect...for example I click the button and the corresponding action did not happen.... I will call it a bug...If the developer is unable to see this behavior...he will ask us to reproduce the bug...

Another scenario.... If the client complains a defect in the production...we will have to reproduce it in TEST environment.

7) How can we know bug is reproducible or not?

A bug is reproducible if we can reproduce it. If we cannot reproduce it...it is not reproducible in which case...we will do some further testing around it and If cannot see it...we will close it...and just hope it would never come back ever again....

8) On what basis we give priority and severity for a bug and give one example for high priority and low severity and high severity and low priority?

Always the Priority is given by our T.L Tester will never give the priority ...Some example for

High Severity: H/W Bugs Application crash.

Low Severity: User Interface Bugs.

High Priority: Error message is not coming on time, calculation Bugs etc..

Low Priority: Wrong Alignment, Final Output Wrong.

9). How is tracebility of bug follow?

The tractability of bug can we followed in so many ways.

• Mapping the Functional requirements scenarios (FS Doc) - test cases (ID) -- Failed test cases (Bugs)
• Mapping between requirements (RS Doc) - test case (ID) - Failed Test Case
• Mapping between Test plan (TP Doc)- test case (ID) - Failed Test case
• Mapping between business requirements (BR Doc) - test Case (ID) - Failed Test case
• Mapping between High Level Design (Design doc) - Test Case (ID) - Failed test case.

Usually the tracebility matrix is mapping between the requirements, client requirements, function specification, test plan and test cases.

10) What will be the role of tester if bug is reproduce?

Whenever the bug is reproduced, tester can send it back to the Developer and ask him to fix it again. If the developer cannot fix the bug once again and if the tester sends the bug back to developer, the third time, the tester can make the bug as Deferred i.e. he can reject the build (.exe)

11) Who will Change the status of the Bug...say: Deferred “?

As soon as Tester finds a bug he logs that bug as NEW status and assigns to Developer. Developer working on that bug changes the status as OPEN. When developer feels its not required fixing at that moment he changes the status as DEFFERED. If he completes working on that he changes the status as CLOSE and assigns the report to Tester. Tester retests the bug and confirms the status as CLOSE. We come across many more statuses such as DUPLICATE, NOT REPRODUCIBLE, TO BE FIX, CRITICAL, BLOCKED, NEED CLARIFICATION. We can use the status according to the bug.

 12). Is it possible to have a defect with high severity and low priority and vice-versa i.e. high priority and low severity?

              When the development team prepared the modules and they sent it for testing and after doing some part of testing then a bug raised in the first module its severity is minor and at the same time in second module a bug raised and its severity is major. We came to know the by the next day the client is coming for inspection and he wanted to get the first module prepared. So at this time less severity bug gets high priority and high severity bug gets less priority.

13). What is Defect Life Cycle in Manual Testing?

Defect Life Cycle:

Defect Detection

Reproduce the Defect

Assign the bug to the Developer

Bug Fixing

Bug Resolution

Regression (Bug Resolution Review)

14). What is the difference between Bug Resolution Meeting and Bug Review Committee? Who are the participants in Bug Resolution Meeting and Bug Review Committee?

Bug resolution meeting: It is conducted in presence of Test lead and Developers where developers gives his/her comment whether to correct the bug at this time or later and test leader accepts or rejects developers comments and even they decide what methods should be chosen to correct the error so that in regression test no bug should be reported and it should not effect other application.

Bug review committee: It is often conducted by test lead, project managers in the presence of client, where they decide as to what errors should be considered as bug and what severity level it should be treated as.

15). How to give BUG Title & BUG Description for ODD Division?

Assumption: ODD number division fails

Bug Tile: Odd number division fails

Bug Description:

1. Open calc window

2. Enter an odd number.

3. Click divide by (/) button.

4. Enter another odd number

5. Hit Enter or click "=" button in calc window

6. Observe the result

Expected Result:

Quotient displayed is correct

Actual Result:

Quotient displayed is incorrect.

16). What is build interval period?

In some companies builds are delivered from development team to the testing team to start the system testing. For example a new product XXX is being released to the testing team so the development team will deliver a build to the Testing team. Now testing team will do the testing and then will release the product to the client. Now there is a new version of the product coming up with the name XXX.1 and is being released to the testing team, so this will be the second build and the time between these 2 builds will be called as build interval. 

17). What is the Difference between End-to-End Testing & System Testing.

System Testing: This is the process of testing end-to-end business functionalities of the application (system) based on client business requirements.

End-to-End Testing: This is the macro end of the testing. This testing mimics the real life situations by interacting with the real time data, network and hardware etc.

        In the system testing we are taking sample test data only, where as in the end to end testing we are taking real time data (for a sample) and interacting with network and hardware

18). How would you say that a bug is 100 % fixed???

              In quality world you can't say Bug is 100 % fix or 50 % fix. If Bug is fixed than in new version we do regression testing to make sure that Bug fix doesn't have any impact on old functionality.

19). What is the difference between SQA Robot and Rational Robot or does both are same?

       SQA robot and Rational Robot are almost same. Only differences is the advanced version of SQA Robot is Rational Robot.

20). What is the difference between Rational clear quest and Test Director?

              Both are Test Management tools. Rational clear quest is from IBM. Test Director from Mercury. Most of the differences are unknown as features wise they have different features, as rarely any company will be using both tools. One difference is cost wise, two products from different company cannot have same cost.   

21). How to post a BUG.

          Bugs are posted with the tools now days, these tools are known as Bug Tracking Tools. Custom designed tools, built specific for company’s bug format, accepts the details of the issue from the testers as follows,

1.   Bug ID (Tool generates the ID)

2.   Bug Description

3.   Steps to reproduce the Bug

4.   Hardware & Software environment

5.   Status (NEW, RE-OPEN….)

6.   Version ID of the Build

7.   Assigned to

8.   Severity

9.   Priority

10.       Tester Name & Date of execution

Test Engineers fill the above fields in the tool and the tool acts as a central repository and tracks the entire bug life cycle.

22). What are the different types of Bugs we normally see in any of the Project? Include the severity as well.

Sl No.	Type of Defects	Severity
1	User Interface Defects	Low
2	Boundary Related Defects	Medium
3	Error Handling Defects	Medium
4	Calculation Defects	High
5	Improper Service Levels (Control flow defects)	High
6	Interpreting Data Defects	High
7	Race Conditions (Compatibility and Intersystem defects)	High
8	Load Conditions (Memory Leakages under load)	High
9	Hardware Failures	High
10	Source bugs (Help Documents)	Low

23) Some Tips for Bug Tracking

1.   A good tester will always try to reduce the steps to the minimal to reproduce the bug; this is extremely helpful for the programmer who has to find the bug

2.   Remember that the only person who can close a bug is the person who opened it in the first place. Anyone can resolve it, but only the person who saw the bug can really be sure that what he or she saw is fixed.

3.   There are many ways to resolve a bug. Fobbing allows you to resolve a bug as fixed, won't fix, postponed, not reproducible, duplicate, or by design.

4.   Not Repro means that nobody could ever reproduce the bug. Programmers often use this when the bug report is missing the repro steps.

5.   You'll want to keep careful track of versions. Every build of the software that you give to testers should have a build ID number so that the poor tester doesn't have to retest the bug on a version of the software where it wasn't even supposed to be fixed.

6.   If you're a programmer, and you're having trouble getting testers to use the bug database, just don't accept bug reports by any other method. If your testers are used to sending you email with bug reports, just bounce the emails back to them with a brief message: "please put this in the bug database. I can't keep track of emails."

7.   If you're a tester, and you're having trouble getting programmers to use the bug database, just don't tell them about bugs - put them in the database and let the database email them.

8.   If you're a programmer, and only some of your colleagues use the bug database, just start assigning them bugs in the database. Eventually they'll get the hint.

9.   If you're a manager, and nobody seems to be using the bug database that you installed at great expense, start assigning new features to people using bugs. A bug database is also a great "unimplemented feature" database, too.

10.               Avoid the temptation to add new fields to the bug database. Every month or so, somebody will come up with a great idea for a new field to put in the database. You get all kinds of clever ideas, for example, keeping track of the file where the bug was found; keeping track of what % of the time the bug is reproducible; keeping track of how many times the bug occurred; keeping track of which exact versions of which DLLs were installed on the machine where the bug happened. It's very important not to give in to these ideas. If you do, your new bug entry screen will end up with a thousand fields that you need to supply, and nobody will want to input bug reports any more. For the bug database to work, everybody needs to use it, and if entering bugs "formally" is too much work, people will go around the bug database.