1. On which 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 team leader or Business Analyst. Severity is given by the reporter of bug. For example, High severity: hardware bugs application crash. Low severity: User interface bugs. High priority: Error message is not coming on time, calculation bugs etc. Low priority: Wrong alignment, etc
2. What do you mean by reproducing the bug? If the bug was not reproducible, what is the next step?
If you find a defect, for example click the button and the corresponding action didn’t happen, it is a bug. If the developer is unable to find this behaviour he will ask us to reproduce the bug. In another scenario, if the client complaints a defect in the production we will have to reproduce it in test environment.
If the bug was not reproducible by developer, then bug is assigned back to reporter or goto meeting or informal meeting (like walkthrough) is arranged in order to reproduce the bug. Sometimes the bugs are inconsistent, so that that case we can mark the bugs as inconsistent and temporarily close the bug with status working fine now.
3. What is the responsibility of a tester when a bug which may arrive at the time of testing. Explain?
First check the status of the bug, then check 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.
If we cannot reproduce it, it is not reproducible in which case we will do further testing around it and if we cannot see it we will close it, and just hope it would never come back ever again.
4. How can we design the test cases from requirements? Do the requirements, represent exact functionality of AUT?
Ofcourse, requirements should represents exact functionality of AUT.
First of all you have to analyze the requirements very thoroughly in terms of functionality. Then we have to think about suitable test case design technique [Black Box design techniques like Specification based test cases, functional test cases, Equivalence Class Partitioning (ECP), Boundary Valve Analysis (BVA), Error guessing and Cause Effect Graphing] for writing the test cases.
By these concepts you should design a test case, which should have the capability of finding the absence of defects.
Read: Art of Test case writing
5. How to launch the test cases in Quality Centre (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 requirement 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.
The test cases are sorted in test plan tab or more precisely in the test director, lets say quality centers database. test director is now referred to as quality center.
6. How is traceability of bug follow?
The traceability of bug can be followed in so many ways.
1. Mapping the functional requirement scenarios(FS Doc) – test cases (ID) – Failed test cases(Bugs)
2. Mapping between requirements(RS Doc) – Test case (ID) – Failed test cases.
3. mapping between test plan (TP Doc) – test case (ID) – failed test cases.
4. Mapping between business requirements (BR Doc) – test cases (ID) – Failed test cases.
5. Mapping between high level design(Design Doc) – test cases (ID) – Failed test cases.
Usually the traceability matrix is mapping between the requirements, client requirements, function specification, test plan and test cases.
7. What is the difference between use case, test case, test plan?
Use Case: It is prepared by Business analyst in the Functional Requirement Specification(FRS), which are nothing but a steps which are given by the customer.
Test cases: It is prepared by 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.
Related Topics:
Mercury Quality Center Interview Questions

Descriptive Programming:

When we start recoding on any application with QTP, QTP learns the object by adding some of its properties in Object Repository. QTP uses default Object Identification properties: mandatory and assistive to learn objects. For more information on how QTP learn objects, read this article. and QTP Object Identification tutorial.
Whenever QTP records any action on any object of an application, it adds some description on how to recognize that object to a repository of objects called object repository. QTP cannot take action on an object until unless its object description is in the Object Repository.

But descriptive programming provides a way to perform action on objects which are not in Object repository.

Download the Descriptive Programming Tutorials for QTP.
Document 1: Download – Basics of Descriptive Programming in QTP. [Note – This is writtern by Tarun Lalwani using QTP 8.2. It is atill applicable to all QTP versions.. A must read]

Document 2: Converting OR (Object Repository) Based scripts to Descriptive Programming
Document 3: Descriptive Programming Dummy Properties
Document 4: General issues people face while using Descriptive Programming (DP) in QTP.

Author – Tarun Lalwani (knowledgeinbox.com)

Related posts – Book Review QuickTest Professional Unplugged.

This excellent and self explained presentation is prepared by Prepared by: Igor Gershovich.

• This presentation explains the following:
• Object Repository vs. Descriptive Programming –what to use?
• OR Pros and Cons
• DP Pros and Cons
• QTP Scripting Using Object Repository
• QTP Scripting Using Descriptive Programming
• Descriptive programming – when and why?
• Different ways to work with objects
• ChildObjects method – using Collection Object
• Regular Expressions in Object Repository
• TO, RO and .Object methods in QTP
• Run-Time “Native” Object Properties/Methods  from AUT
• Object Smart Identification

Download this document – QTP: Object Repository, Descriptive Programming and Beyond

WHAT IS EQUIVALENCE PARTITIONING?
Concepts:   Equivalence partitioning is a method for deriving test cases.  In this method, classes of input conditions called equivalence classes are identified such that each member of the class causes the same kind of processing and output to occur.
In this method, the tester identifies various equivalence classes for partitioning.  A class is a set of input conditions that are is likely to be handled the same way by the system.  If the system were to handle one case in the class erroneously, it would handle all cases erroneously.
WHY LEARN EQUIVALENCE PARTITIONING?
Equivalence partitioning significantly reduces the number of test cases required to test a system reasonably.  It is an attempt to get a good ‘hit rate’, to find the most errors with the smallest number of test cases.
DESIGNING TEST CASES USING EQUIVALENCE PARTITIONING
To use equivalence partitioning, you will need to perform two steps
1. Identify the equivalence classes
2. Design test cases
STEP 1: IDENTIFY EQUIVALENCE CLASSES
Take each input condition described in the specification and derive at least two equivalence classes for it.  One class represents the set of cases which satisfy the condition (the valid class) and one represents cases which do not (the invalid class).
Following are some general guidelines for identifying equivalence classes:
a) If the requirements state that a numeric value is input to the system and must be within a range of values, identify one valid class inputs which are within the valid range and two invalid equivalence classes inputs which are too low and inputs which are too high. 
For example, if an item in inventory (numeric field) can have a quantity of +1 to +999, identify the following classes:  
1. One valid class:   (QTY is greater than or equal to +1 and is less than or equal to +999).   This is written as (+1 < = QTY < = 999)
2. The invalid class (QTY is less than 1), also written as (QTY < 1) i.e. 0, -1, 2, … so on
3. The invalid class (QTY is greater than 999), also written as (QTY >999) i.e. 1000, 1001, 1002, 1003… so on.

Invalid class	Valid Class	Invalid class
0	1	1000
-1	2	1001
-2	3	1002
-3	4	1003
-4… So on	5… up to 999	1004.. So on

b) If the requirements state that the number of items input by the system at some point must lie within a certain range, specify one valid class where the number of inputs is within the valid range, one invalid class where there are too few inputs and one invalid class where there are too many inputs.
For example, specifications state that a maximum of 4 purchase orders can be registered against anyone product.  The equivalence classes are: the valid equivalence class: (number of purchase an order is greater than or equal to 1 and less than or equal to 4, also written as (1   < = no. of purchase orders < =   4) the invalid class  (no.  of purchase orders> 4) the invalid class  (no.  of purchase orders <  1)
c) If the requirements state that a particular input item match one of a set of values and each case will be dealt with the same way, identify a valid class for values in the set and one invalid class representing values outside of the set. 
Says that the code accepts between 4 and 24 inputs; each is a 3-digit integer:
– One partition: number of inputs
– Classes “x<4”, “4<=x<=24”, “24<x”
– Chosen values: 3,4,5,14,23,24,25
Go back to Test Design Techniques
Related Posts: Methods of Black Box Testing

Gray Box Testing –

• It is just a combination of both Black box & white box testing.
• It is platform independent and language independent.
• Used to test embedded systems.
• Functionality and behavioral parts are tested.
• Tester should have the knowledge of both the internals and externals of the function
• If you know something about how the product works on the inside, you can test it better from the outside.

Gray box testing is especially important with Web and Internet applications, because the Internet is built around loosely integrated components that connect via relatively well-defined interfaces. Unless you understand the architecture of the Net, your testing will be skin deep.
Go back to Test Design Techniques

White Box Testing

• Testing the Internal program logic
• White box testing is also called as Structural testing.
• User does require the knowledge of software code.

Purpose

• Testing all loops
• Testing Basis paths
• Testing conditional statements
• Testing data structures
• Testing Logic Errors
• Testing Incorrect assumptions

Structure = 1 Entry + 1 Exit with certain Constraints, Conditions and Loops.
Logic Errors and incorrect assumptions most are likely to be made while coding for “special cases”. Need to ensure these execution paths are tested.
Approaches / Methods / Techniques for White Box Testing
Basic Path Testing (Cyclomatic Complexity(Mc Cabe Method)

• Measures the logical complexity of a procedural design.
• Provides flow-graph notation to identify independent paths of processing
• Once paths are identified – tests can be developed for – loops, conditions
• Process guarantees that every statement will get executed at least once.

Structure Testing:

• Condition Testing – All logical conditions contained in the program module should be tested.
• Data Flow Testing- Selects test paths according to the location of definitions and use of variables.
• Loop Testing:
  • Simple Loops
  • Nested Loops
  • Concatenated Loops
  • Unstructured Loops

Go back to Test Design Techniques