Software Testing Concepts (Manual Testing)

Definitions
Project : It is something developed based on a particular customer requirement and used by that particular customer only.

Product: Product is some thing that is developed based on the company’s specifications and used by multiple customers.

Quality: Quality is defined as not only the justification of the requirement but also the present of value (user friendly).

Defect: Defect is defined as deviation from the requirements.

Testing:
Testing is a process in which the defects are identified, isolated (separated), subjected (sending) for
rectification and ensured that the product is defect free in order to produce a quality product in the end and
hence customer satisfaction.
(Or)
Testing is the process of executing a program with the intent of finding errors.
(Or)
Verifying and validating the application with respect to customer requirements.
(Or)
Finding the differences between customer expected and actual values.
(Or)
Testing should also ensure that a quality product is delivered to the customer.

Process of Developing Project in the Software Company.

BIDDING THE PROJECT : Bedding the project is defined as request for proposal, estimation and signoff.

KICK OF MEETING:
It is a initial meeting conducted in the software company soon after the project is signed off in order to
discus the over view of the project and to select a project manager for the project.

Usually High Level Manager, Project Manager, Technical Manager, Quality Managers, Test leads and
Project leads will be involved in this meeting.

PIN (Project Initiation Note)

PIN is a mail prepaid by the project manager and send to the CEO of the software company in order to get
the permission to start the project development.
SDLC (Software Development Life Cycle)
It contains 6 phases.

INITIAL PHASE / REQUIREMENT PHASE.

ANALYSIS PHASE.
DESIGN PHASE.
CODING PHASE.
TESTING PHASE.
DELIVERY AND MAINTENANCE PHASE.
Initial Phase
Task Interacting with the customer and gathering the requirements.
Roles BA (Business Annalist)
EM (Engagement Manager)
Process
First of all the business annalist will take an appointment from the customer, collects the templates from the
company meats the customer on the appointed date gathers the requirements with the support of the
 templates and comeback to the company with a requirements documents. Then the engagement manager
will check for the extra requirements if at all he fined any extra requirements he is responsible for the
excess cast of the project. The engagement manager is also responsible for prototype demonstration in case
of confused requirements.
Template
It is defined as a pre-defined format with pre-defined fields used for preparing a document perfectly.
Prototype
It is a rough and rapidly developed model used for demonstrating to the client in order to gather clear
requirements and to win the confidence of a customer.
Proof
The proof of this phase is requirements document which is also called with the following name
FRS - (Functional Requirement Specification)
BRS - (Business Requirement Specification)
CRS - (Client/Customer Requirement Specification)
URS - (User Requirement Specification)
BDD - (Business Design Document)
BD - (Business Document)
Note
Some company’s may the over all information in one document called as ‘BRS’ and the detailed
information in other document called ‘FRS’. But most of the company’s will maintain both of information
in a single document.
Analysis Phase
Task Feasibility study.
Tentative planning.
Technology selection.
Requirement A\analysis.

Roles System Annalist (SA)

Project Manager (PM)
Team Manager (TM)
Process
(I) Feasibility study It is detailed study of the requirements in order to check whether all the requirements are possible
are not.
(II) Tentative planning The resource planning and time planning is temporary done in this section.
(III) Technology selection The lists of all the technologies that are to be used to accomplish the project successfully
will be analyzed listed out hear in this section.
(IV) Requirement analysis
The list of all the requirements like human resources, hardware, software required to accomplish this
project successfully will be clearly analyzed and listed out hear in this section.

Proof The proof of this phase is SRC (Software Requirement Specification).

Design phase
Tasks HLD (High Level Designing) LLD (Low Level Designing)

Roles HLD is done by the CA (Chief Architect). LLD is done by the TL (Technical Lead).
Process
The chief architect will divided the whole project into modules by drawing some diagrams and technical
lead will divided each module into sub modules by drawing some diagrams using UML (Unified Modeling
Language).
The technical lead will also prepare the PSEUDO Code.

Proof The proof of this phase is technical design document (TDD).

Pseudo Code It is a set of English instructions used for guiding the developer to develop the actual code easily.
Module
Module is defined as a group of related functionalities to perform a major task.
Coding Phase
Task Programming / Coding.
Roles Developers / Programmers.
Process
Developers will develop the actual source code by using the PSUEDO Code and following the coding
standards like proper indentation, color-coding, proper commenting and etc…

Proof The proof of this phase is SCD (Source Code Document).

Testing Phase
Task Testing.
Roles Test Engineer.
Process

 First of all the Test Engineer will receive the requirement documents and review it for under studying the
requirements.

 If at all they get any doubts while understanding the requirements they will prepare the Review Report (RR)
with all the list of doubts.

 Once the clarifications are given and after understanding the requirements clearly they will take the test case
template and write the test cases.

 Once the build is released they will execute the test cases.

 After executions if at all find any defects then they will list out them in a defect profile document.

 Then they will send defect profile to the developers and wait for the next build.

 Once the next build is released they will once again execute the test cases

 If they find any defects they will follow the above procedure again and again till the product is defect free.

 Once they feel product is defect free they will stop the process.

Proof The proof of this phase is Quality Product.

Test case
Test case is an idea of a Test Engineer based on the requirement to test a particular feature.
Delivery and Maintenance phase
Delivery
Task Installing application in the client environment.
Roles Senior Test Engineers / Deployment Engineer.
Process
The senior test engineers are deployment engineer will go to the client place and install the application into
the client environment with the help of guidelines provided in the deployment document.
Maintenance
After the delivery if at all any problem occur then that will become a task based on the problem the
corresponding roll will be appointed. Based on the problem role will define the process and solve the
problem.
Where exactly testing comes in to picture?
Which many sort of testing are there?

There are two sorts of testing.

1. Un conventional testing
2. Conventional testing
Un conventional Testing
It is a sort of testing in which quality assurance people will check each and every out come document right from the
initial phase of the SDLC.
Conventional Testing
It is a sort of testing in which the test engineer will test the application in the testing phase of SDLC.

TESTING METHODOLOGY (OR) TESTING TECHNIQUES

There are 3 methods are there

 Black Box Testing.
 White Box Testing.
 Gray Box Testing
1 Black Box Testing
It is a method of testing in which one will perform testing only on the functional part of an application with out
having any structural knowledge. Usually test engineers perform it.

2 White box Testing (Or) Glass box Testing (Or) Clear box Testing
It is a method of testing in which one will perform testing on the structural part of an application. Usually
developers are white box testers perform it.

3 Gray box Testing

It is a method of testing in which one will perform testing on both the functional part as well as the structural part of
an application.
Note:
The Test engineer with structural Knowledge will perform gray box testing.

LEVELS OF TESTING
There are 5 levels of testing.

1) Unite level testing

2) Module level testing
3) Integration level testing
4) System level testing
5) User acceptance level testing
1) Unit level testing

If one performs testing on a unit then that level of testing is known as unit level testing. It is white box testing
usually developers perform it.
Unit: - It is defined as a smallest part of an application.

2) Module level testing

If one perform testing on a module that is known as module level testing. It is black box testing usually test
engineers perform it.
3) Integration level testing

Once the modules are developing the developers will develop some interfaces and integrate the module with the
help of those interfaces while integration they will check whether the interfaces are working fine or not. It is a white
box testing and usually developers or white box testers perform it.

The developers will be integrating the modules in any one of the following approaches.
i) Top Down Approach (TDA)
In this approach the parent modules are developed first and then integrated with child modules.
ii) Bottom Up Approach (BUA)
In this approach the child modules are developed first and the integrated that to the corresponding parent
modules.
iii) Hybrid Approach
This approach is a mixed approach of both Top down and Bottom up approaches.
iv) Big Bang Approach
Once all the modules are ready at a time integrating them finally is known as big bang approach.
STUB
While integrating the modules in top down approach if at all any mandatory module is missing then that
module is replace with a temporary program known as STUB.

DRIVER
While integrating the modules in bottom up approach if at all any mandatory module is missing then that
module is replace with a temporary program known as DRIVER.
4) System level testing

Once the application is deployed into the environment then if one performs testing on the system it is known as
system level testing it is a black box testing and usually done by the test engineers.

At this level of testing so many types of testing are done.

Some of those are

 System Integration Testing

 Load Testing
 Performance Testing
 Stress Testing etc….
5) User acceptance testing.

The same system testing done in the presents of the user is known as user acceptance testing. It s a black box testing
usually done by the Test engineers.

ENVIRONMENT
Environment is a combination of 3 layers.
Presentation Layer.
Business Layer.
Database Layer.

Types of Environment
There are 4 types of environments.
1. Stand alone Environment / One – tire Architecture.
2. Client – Server Environment / Two – tire Architecture.
3. Web Environment / Three – tire Architecture.
4. Distributed Environment / N – tire Architecture.
1) Stand alone environment (Or) One – Tire Architecture.
This environment contains all the three layers that is Presentation layer, Business layered and Database layer in a
Single tier.
2) Client – Server Environment (Or) Two – Tire Architecture
In this environment two tiers will be there one tier is for client and other tier is for Database server. Presentation
layer and Business layer will be present in each and every client and the database will be present in database server.
3) Web Environment
In this Environment three tiers will be there client resides in one tier, application server resides in middle tier and
database server resides in the last tier. Every client will have the presentation layer, application server will have the
business layer and database server will have the database layer.
4) Distributed Environment
It is same as the web Environment but the business logic is distributed among application server in order to
distribute the load.
Web Server: It is software that provides web services to the client.
Application Server: It is a server that holds the business logic.
Ex: Ton tact, Tomcat, Web logic, web Spear etc………

SOFTWARE DEVELOPMENT MODELS

There are 6 models.
 Water fall Model (or) Sequential Model
 Prototype Model
 Evolutionary Model
 Spiral Model
 Fish Model
 V - Model
1) Water fall Model (or) Sequential Model

INITIAL Req. Gathering BRS

ANALYSIS Sys. Design SRS

DESIGN S/W Design TDD, GUI

Unit Test UTR

CODING Implementation
Int. Test ITR

Mod. Test MTR

TESTING Black box Testing
Sys.Test STR

UAT UATR
Del & Maint Delivery to Client

Advantages:
It is a simple model and easy to maintain project implementation is very easy.
Drawbacks:
Can’t incorporate new changes in the middle of the project development.
2) Prototype Model
S R S Doc Client Environ
Base lined conformation
Unclear Req

H/W Prototype Demo to Client

Prototype
S/W Prototype Demo to Client

B R S Doc Req .are

Base lined Refined

Advantages:

When ever the customer with the requirements then this is the best model to gather the clear requirements.
e
Drawbacks:
It is not a complete model.
Time consuming model
Prototype has to be build company’s cost
The user may strict to the prototype and limit his requirements.

3) Evolutionary Model

Initial Req.

Development
Feed back
N with new Req

User
Application User Values
Acceptance

App is
Y
Base lined

Advantages

Whenever the customer is revolving the requirements this is the best suitable model.

Drawbacks

Dead lines are not clearly defined

Project monitoring and maintenance is difficult.
 4) Spiral Model

Defining the objects

Work around
Constraints

Refunding and
Risk root cause Analysis.
planning for
the next cycle. Estimation
Contingencies.

Implementation.
Advantages
This is the best-suited model for highly risk-based projects.
Drawbacks
Time consumed model, costly model and project monitoring and maintenance is difficult.

5) Fish Model
Verification:
Verification is a process of checking conducted on each and every role of an organization in order to check whether
he is doing his tasks in a right manner according to the guidelines or not. Right from the starting of the process tiles
the ending of the process. Usually the documents are verified in this process of checking.
Validation
Validation is a process of checking conducted on the developed product in order to check whether it is working
according to the requirements or not.
Delivery &
Analysis Design Coding Maintenance

Requiremen System
ts gathering Testing

HLD
SRS SCD
LLD
BRS
Black box
Review
Testing

SRS TDD White Box Test S/W

Review Review Testing Changes

Verification

Validation
Advantages
As the verification and validation are done the outcome of a Fish Model is a quality product.

Drawbacks: Time consuming and costly model.

6) V – Model

Verification Validation
Initial BRS Prepare Pro. Plan
& Prepare Test Plan
Analysis SRS Req. Phase Testing

Design TDD Design phase Testing

&
Coding SCD Program phase Testing
`1
System Testing
Testing S/W Test Management process
Build User Acceptance Testing

Delivery Port Testing

& S/W Efficiency
Maintenance Test S/W Changes

Advantages

As the verification and validation are done along with the Test Management. The out come of V-Model is a quality
product.

Drawback

Time consuming and costly model.

 TYPES OF TESTING

There are 18 types of testing.

1. Build Verification Testing.
2. Regression Testing.
3. Re – Testing.
4. α - Testing.
5. β - Testing.
6. Static Testing.
7. Dynamic Testing.
8. Installation Testing.
9. Compatibility Testing.
10. Monkey Testing
11. Exploratory Testing.
12. Usability Testing.
13. End – To – End Testing.
14. Port – Testing.
15. Reliability Testing
16. Mutation Testing.
17. Security Testing.
18. Adhoc Testing.
1) Sanitary Testing / Build Verification Testing / Build Accepting Testing.
It is a type of testing in which one will conduct overall testing on the released build in order to check weather it is
proper for further details testing or not.

Some companies even call it as Sanitary Testing and also Smoke Testing. But some company’s will say that just
before the release of the built the developer’s will conduct the overall testing in order to check weather the build is
proper for detailed testing or not that is known as Smoke Testing and once the build is released once again the
testers will conduct the over all testing in order to check weather the build is proper for further detailed testing or
not. That is known as Sanitary Testing.
2) Regression Testing
It is a type of testing in which one will perform testing on the already tested functionality again and again this is
usually done in scenarios (Situations).

Scenario 1:
When ever the defects are raised by the Test Engineer rectified by the developer and the next build is released to the
testing department then the Test Engineer will test the defect functionality and it’s related functionalities once
again.

Scenario 2:
When ever some new changes are requested by the customer, those new features are incorporated by the developers,
next built is released to the testing department then the test engineers will test the related functionalities of the new
features once again which are already tested. That is also known as regression testing.
Note:
 Testing the new features for the first time is new testing but not the regression testing.
3) Re – Testing:
It is a type of testing in which one will perform testing on the same function again and again with multiple sets of
data in order to come to a conclusion whether the functionality is working fine or not.

4) α - Testing:
It is a type of testing in which one (I.e., out Test Engineer) will perform user acceptance testing in our company in
the presents of the customer.
Advantages:
If at all any defects are found there is a chance of rectifying them immediately.

5) β - Testing:
It is a type of testing in which either third party testers or end users will perform user acceptance testing in the client
place before actual implementation.

6) Static Testing:
It is a type of testing in which one will perform testing on an application or it’s related factors with out performing
any actions.
Ex: GUI Testing, Document Testing, Code reviewing and etc…

7) Dynamic Testing:
It is a type of testing in which one will perform testing on the application by performing same action.
Ex: Functional Testing.

8) Installation Testing:
It is a type of testing in which one will install the application in to the environment by following the guidelines
given in the deployment document and if the installation is successful the one will come to a conclusion that the
guidelines are correct otherwise the guidelines are not correct.

9) Compatibility Testing:
It is a type of testing in which one may have to install the application into multiple number of environments
prepared with different combinations of environmental components in order to check whether the application is
suitable with these environments or not. This is use usually done to the products.

10) Monkey Testing:

It is a type of testing in which one will perform some abnormal actions intentionally (wanted) on the application in
order to check its stability.

11) Exploratory Testing:

It is a type of testing in which usually the domain expert will perform testing on the application parallel by
exploring the functionality with out having the knowledge of requirements.

12) Usability Testing:

It is a type of testing in which one will concentrate on the user friendliness of the application.

13) End – To – End Testing:

It is a type of testing in which one will perform testing on a complete transaction from one end to another end.

14) Port Testing:

It is a type of testing in which one will check weather the application is comfortable or not after deploying it into
the original clients environment.

15) Reliability Testing (or) Soak Testing:

It is a type of testing in which one will perform testing on the application continuously for long period of time in
order to check its stability.
16) Mutation Testing:
It is a type of testing in which one will perform testing by doing some changes

For example usually the developers will be doing any many changes to the program and check it’s performance it is
known as mutation testing.

17) Security Testing:

It is a type of testing in which one will usually concentrate on the following areas.
i) Authentication.
ii) Direct URL Testing.
iii) Firewall Leakage Testing.

i) Authentication Testing:
It is a type of testing in which a Test Engineer will enter different combinations of user names and
passwords in order to check whether only the authorized persons are accessing the application or not.

ii) Direct URL Testing:

It is a type of testing in which a test engineer will specified the direct URL’s of secured pages and check whether
they are been accessing or not.

iii) Firewall leakage Testing:

It is a type of testing in which one will enter as one level of user and try to access the other level unauthorized pages
in order to check whether the firewall is working properly or not.

18) Adhoc Testing:

It is a type of testing in which one will perform testing on the application in his own style after understanding the
requirements clearly.

SOFTWARE TESTING LIFE CYCLE

It contains 6 phases.

1. TEST PLANNING.
2. TEST DEVELOPMENT.
3. TEST EXECUTION.
4. RESULT ANALYSIS.
5. BUG TRACKING.
6. REPORTING.
1) TEST PLANNING
Plan:
Plan is a strategic document, which describes how to perform a task in an effective, efficient and optimized way.
Optimization:
Optimization is a process of reducing or utilizing the input resources to their maximum and getting the maximum
possible output.

Test Plan:
It is a strategic document, which describe how to perform testing on an application in an effective, efficient and
optimized way. The Test Lead prepares test plan.

CANTANTS OF THE TEST PLAN

1.0 INTERDUCTION.
1.1 Objective.
1.2 Reference Document.
2.0 COVERAGE OF TESTING.
2.1 Features to be Tested.
2.2 Features not to be Tested.
3.0 TEST STRATEGY.
3.1 Levels of Testing.
3.2 Types of Testing.
3.3 Test Design Technique.
3.4 Configuration Management.
3.5 Test Metrics.
3.6 Terminology.
3.7 Automation Plan.
3.8 List of Automated Tools.
4.0 BASE CRITERIA..
4.1 Acceptance Criteria.
4.2 Suspension Criteria.
5.0 TEST DELIVARABLES.
6.0 TEST ENVERONMENT.
7.0 RESOURCE PLANNING.
8.0 SHEDULING.
9.0 STAFFING AND TRAINING.
10.0 RISKS AND CONTINGENCES.
11.0 ASSUMPTIONS.
12.0 APPROVAL INFORMATION.
1.0 INTERDUCTION.
1.1 Objective.
The main purpose of the document is clearly described here in this section.

1.2 Reference Document.

The list of all the documents that are referred to prepare the test plan will be listed out here in this section.

2.0 COVERAGE OF TESTING.

2.1 Features To Be Tested
The list of all the features with in the scope are mentioned here in this section

2.2 Features Not To Be Tested

The lists of all the features that are not planed for testing based on the following criteria are mentioned here in this
section.
 Out of scope features
 Low risk areas
 Future functionalities.
 The features that are skipped based on the time constraints.

3.0 TEST STRATEGY

It is defined as an organization level term, which is used for testing all the projects in the organization.

TEST PLAN
It is defined as a project level term, which is describes how to test a particular project in an organization.
Note:
Test strategy is common for all the projects. But test plan various from project to project.

3.1 Levels of Testing

The list of all the levels of testing that are maintained in that company are listed out here in this section.

3.2 Types of Testing

The list of all the types of testing that are followed by that company are listed out here in this section.

3.3 Test Design Technique

The list of all the techniques that are followed by that company during the test case development are listed out here
in this section.
Ex: BVA (Boundary Value Analysis)
ECP (Equable Class Partition)

3.4 Configuration Management

3.5 Test Metrics

The lists of all the tasks that are measured and maintain in terms of metrics are clearly mentioned here in this
section.

3.6 Terminologies
The list of all the terms and the corresponding meanings are listed out here in this section

3.7 Automation plan

The list of all the areas that are planed for automation in that company are listed out her in this section.

3.8 List of Automated Tools

The list of all the automated tools that are used in that company are listed out here in this section.
4.0 BASE CRITERIA
4.1 Acceptance Criteria.
When to stop testing in a full pledged manner thinking then enough testing is done on the application is clearly
described here in this section.

4.2 Suspension Criteria.

When to stop testing suddenly and suspended the build will be clearly mentioned here in this section.

5.0 TEST DELIVERABLE.

The list of all the documents that are to be prepared and deliver in the testing phase are listed out here in this
section.

6.0 TEST ENVIRONMENT.

The customer specified environment that is about to be used for testing is clearly describes here in this section.

7.0 RESOURCE PLANNING.

Who has to do what is clearly described here in this section.

8.0 SCHEDULING.
The starting dates and the ending dates of each and ever task is clearly described here in this section.

9.0 STAFFING AND TRAINING.

How much staff is to be requited what kind of training is to be provided is clearly planned and mentioned here in
this section.

10.0 RISK AND CONTINGENCES.

The list of all the potential risks corresponding solution plans are listed out here in this section.
Risks
1. Unable to deliver the software with in the dead lines.
2. Employees may leave the organization in the middle of the project development.
3. Customer may impose the dead lines.
4. Unable to test all the features with in the time.
5. Lake of expatriation.

Contingences
1. Proper plan ensurance.
2. People need to be maintained on bench.
3. What not to be tested has to be planed properly.
4. Severity priority based execution.
5. Proper training needs to be provided.

11.0 ASSUMPTIONS.
The list of all the assumptions that are to be assumed by a test engineer will be listed out here in this section.

12.0 APPRUVAL INFORMATION.

Who will approve what is clearly mentioned here in this section.
2. TEST DEVELOPMENT.

TYPES OF TEST CASES

Test cases are broadly divided into two types.
1. G.U.I Test Cases.
2. Functional test cases.
Functional test cases are further divided into two types.
1. Positive Test Cases.
2. Negative Test Cases.

GUIDELINES TO PREPARE GUI TEST CASES:

1. Check for the availability of all the objects.
2. Check for the alignments of the objects if at all customer has specified the requirements.
3. Check for the consistence of the all the objects.
4. Check for the Spelling and Grammar.
Apart from these guidelines anything we test with out performing any action will fall under GUI test cases.

GUIDELINES FOR DEVELOPING POSITIVE TEST CASES.

1. A test engineer must have positive mind setup.
2. A test engineer should consider the positive flow of the application.
3. A test engineer should use the valid input from the point of functionality.

GUIDELINES FOR DEVELOPING THE NEGATIVE TEST CASES:

1. A test engineer must have negative mind setup.
2. He should consider the negative flow of the application.
3. He should use at least one invalid input for a set of data.

Test Case Template:

1. Test Objective :
2. Test Scenario :
3. Test Procedure :
4. Test Data :
5. Test Cases :

1.Test Objective:
The purpose of the document is clearly described here in this section.

2.Test Scenarios:
The list of all the situations that are to be tested, that are listed out here in this section.

3.Test Procedure:
Test procedure is a functional level term, which describe how to test the functionality. So in this section one will
describe the plan for testing the functionality.

4.Test Data:
The data that is required for testing is made available here in this section.

5.Test Cases:
The list of all the detailed test cases is- listed out here in this section.

Note:

Some companies even maintain all the above five fields individually for each and every scenario. But some
companies maintain commonly for all the scenarios.
3. TEST EXECUTION.

During the test execution phase the test engineer will do the following.

1. He will perform the action that is described in the description column.

2. He will observe the actual behavior of the application.
3. He will document the observed value under the actual value column.

4. RESULT ANALYSIS.
In this phase the test engineer will compare the expected value with actual value and mention the result as pass if
both are match other wise mentioned the result as fail.

5. BUG TRACKING.
Bug tracking is a process in which the defects are identifying, isolated and managed.
DEFECT PROFILE DOCUMENT
Defect ID:
The sequences of defect numbers are listed out here in this section.

Steps of Reproducibility:
The list of all the steps that are followed by a test engineer to identity the defect are listed out here in this section.

Submitter:
The test engineer name who submits the defect will be mentioned here in this section.

Date of Submission:
The date on which the defects submitted is mentioned here in this section.

Version Number:
The corresponding version number is mentioned here in this section.

Build Number:
Corresponding build number is mentioned here is this section.

Assigned to:
The project lead or development lead will mentioned the corresponding developers name for name the defect is
assigned.

Severity:
How serious the defect is, is described in terms of severity. It is classified in to 4 types.

1. FATAL Sev1 S1 1
2. MAJOR Sev2 S2 2
3. MINOR Sev3 S3 3
4. SUGGESION Sev4 S4 4

FATAL:
It is all the problems are related to navigational blocks or unavailability of functionality then such types of problems
are treated to be FATAL defect.

Note: It is also called as show stopper defects.

MAJOR:
It at all the problems are related to the working of the features then such types of problems are treated to be
MAJOR defects.
 MINOR:
It at all the problems are related to the look and feel of the application then such types of problems are treated to be
MINOR defects.
SUGGITIONS:
If at all the problems are related to the value of the application then such types of problems are treated to be
suggestions.
Priority:
The sequence in which the defects have to be rectified is described in terms of priority. It is classified in to 4 types.
1. CRITICAL
2. HIGH
3. MEDIUM
4. LOW

Usually the FATAL defects are given CRITICAL priority, MAJOR defects are given HIGH priority, MINOR
defects are given MEDIUM priority and SUGGITION defects are given LOW priority sent depending upon the
situation the priority may be changed by the project lead or development lead.
Ex: -
Low Severity High Priority Case:
In the case of customer visit all the look and feel defects, which are usually less savior, are given highest priority.

High Severity Low Priority Case:

If at all some part of the application is not available because it is under development still the test engineer will treat
team as FATAL defect, but the development lead will give less priority for those defects.

BUG LIFE CYCLE Hold

Testers Mistake
No
Require As Per Design
Test
really Yes
Develop Rectification
Defect

M1 BH # 1 Fixed for verification

BH # 2
TESTING

IF
New/Open Yes No Stop the Testing
DEFEC
T

Is it
Reopen No really Yes
Closed
rectified
New / Open:
When ever the defect is found for the first time the test engineer will set the status as New / Open. But some
companies will say to set the status as only new at this situation and once the developers accept the defect they will
set the status as open.

Reopen and Closed:

Once the defects are rectified by the developer and the next build is released to the testing department then the
testers will check whether the defects are rectified properly or not.

If they feel rectified they will set the status as Closed. Other wise they will set the status as Reopen

Fixed for Verification / Fixed / Rectified.

When ever the test engineer raises the defects, accepted in the developers. Rectified then they will set the status as
Fixed.
Hold:
Whenever the developer confused to accept or Reject the defect he will set the status as hold.

Testers Mistake / Testers Error / Rejected.

Whenever the developer is confused it is not at all a defect then he will set the status as reject.

As Per Design (This is a Rare case)

When ever some new changes are incorporated engineers then the test engineers will raze then as defects but the
developers will set the status as ‘As Per Design’.
Error:
It is a problem related to the program.
Defect:
If the test engineer with respect to the functionality identifies a problem then it is called defect.
Bug:
If the developer accepts the defect, that is called as Bug.

Fault / Failure:
The customer identity the problem, after delivery. It is called Fault / Failure.

6. BUG REPORTING.
1). Classical Bug Reporting Process:
Project Lead
Test Lead

Mail

TE1 TE2 TE3 Drawbacks: 1.Time consuming

2. Redundancy. Dev1 Dev2 Dev3
3. No Security.
2). Common Repository Oriented Bug Reporting Process:

TL
PL

Caman Repository

TE1 TE2 TE3

Dev1 Dev2 Dev3
Drawbacks: 1.Time consuming.
2. Redundancy.

3). Bug Tracking Tool Oriented Bug Reporting Process:

TL PL

BTT

TE1 TE2 TE3 Dev1 Dv2 Dve3

Bug Tracking Tool:

It is a software application that can be accessed only by the otherwise person and used for managing the complete
bug tracking process by providing all the facilities along with a defect profile template.

Note:

At the end of the testing process usually the test lead will prepare the test summary report which is also called as
test closure.
TEST DESIGN TECHNIQUES:

While developing the test cases if at all the test engineer feels complex in some areas to over come that complexity
usually the test engineer will use test design techniques.

Generally two types of techniques are used in most of the companies.

1. Boundary Value Analysis (BVA).
2. Equableness Class Partition (ECP).
1). Boundary Value Analysis (BVA).
When ever the engineers need to develop test cases for a range kind of input then they will go for boundary value
analysis. Which describes to concentrate on the boundary of the rang.
Usually they test with the following values.
LB-1 LB LB+1 MV UB-1 UB UB+1

2). Equableness Class Partition (ECP).

When ever the test engineer need to develop test cases for a feature which has more number of validation then one
will go for equableness class partition. Which describe first divide the class of inputs and then prepare the test cases.

Ex: Develop the test cases for E-Mail Test box whose validations are as follows.

Requirements:
1. It should accept Minimum 4 characters Maximum 20 characters.
2. It should accept only small characters.
3. It should accept @ and _ special symbols only.

Boundary Value Analysis:

LB-1 LB LB+1 MV UB-1 UB UB+1

3ch 4ch 5ch 12ch 19ch 20ch 21ch

Equableness Class Partition (ECP).

Valid Invalid

4char 3char
5char 21char
12char A–Z
19char 0–9
20char All the Special Symbols apart
a–z form @ and _.
@ Alpha Numeric.
_ Blank Space
Dismal Numbers.

Test Case Document:

Test
Case Test Case Description Expected Value
ID Type
1 +ve Enter the value as per the VIT It should accept.

2 -ve Enter the value as per the IIT It should not accept.

Valid Input Table (VIT). Invalid Input Table (IIT).

Sl NO Input Sl No Input

1 abcd 1 abc

2 ab@zx 2 ABCD

3 abcdabcd@ab_ 3 ABCD123

4 abcdabcddcbaaccd_@z 4 12345.5

5 abcdabcdabcdabcdz@_x 5 abcd abcd abcd abcd

6 abcdabcdabcdabcd_xyz 6 abcdabcd-----abc*#)

7
 TESTING-TYPES

A (return to top of page)

Acceptance Testing: Testing conducted to enable a user/customer to determine whether to accept a software
product. Normally performed to validate the software meets a set of agreed acceptance criteria.

Accessibility Testing: Verifying a product is accessible to the people having disabilities (deaf, blind, mentally
disabled etc.).

Ad Hoc Testing: Similar to exploratory testing, but often taken to mean that the testers have significant
understanding of the software before testing it.

Agile Testing: Testing practice for projects using agile methodologies, treating development as the customer of
testing and emphasizing a test-first design paradigm.

Alpha testing: Testing of an application when development is nearing completion; minor design changes may
still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.

Application Binary Interface (ABI): A specification defining requirements for portability of applications in binary
forms across different system platforms and environments.

Application Programming Interface (API): A formalized set of software calls and routines that can be
referenced by an application program in order to access supporting system or network services.

Automated Software Quality (ASQ): The use of software tools, such as automated testing tools, to improve
software quality.

Automated Testing:

 Testing employing software tools which execute tests without manual intervention. Can be applied in
GUI, performance, API, etc. testing.
 The use of software to control the execution of tests, the comparison of actual outcomes to predicted
outcomes, the setting up of test preconditions, and other test control and test reporting functions.

Click this Link for : Approaches for automated testing tools

B (return to top of page)

Backus-Naur Form: A Meta language used to formally describe the syntax of a language.

Basic Block: A sequence of one or more consecutive, executable statements containing no branches.
Basis Path Testing: A white box test case design technique that uses the algorithmic flow of the program to
design tests.

Basis Set: The set of tests derived using basis path testing.

Baseline: The point at which some deliverable produced during the software engineering process is put under
formal change control.

Beta Testing: Testing when development and testing are essentially completed and final bugs and problems
need to be found before final release. Typically done by end-users or others, not by programmers or testers.

Binary Portability Testing: Testing an executable application for portability across system platforms and
environments, usually for conformation to an ABI specification.

Black Box Testing: Testing based on an analysis of the specification of a piece of software without reference to
its internal workings. The goal is to test how well the component conforms to the published requirements for the
component.

Bottom Up Testing: An approach to integration testing where the lowest level components are tested first, then
used to facilitate the testing of higher level components. The process is repeated until the component at the top
of the hierarchy is tested.

Boundary Testing: Test which focus on the boundary or limit conditions of the software being tested. (Some of
these tests are stress tests).

Bug: A fault in a program, which causes the program to perform in an unintended or unanticipated manner.

Boundary Value Analysis: BVA is similar to Equivalence Partitioning but focuses on "corner cases" or values
that are usually out of range as defined by the specification. It means that if a function expects all values in range
of negative 100 to positive 1000, test inputs would include negative 101 and positive 1001.

Branch Testing: Testing in which all branches in the program source code are tested at least once.

Breadth Testing: A test suite that exercises the full functionality of a product but does not test features in detail.

C (return to top of page)

CAST: Computer Aided Software Testing.

Capture/Replay Tool: A test tool that records test input as it is sent to the software under test. The input cases
stored can then be used to reproduce the test at a later time. Most commonly applied to GUI test tools.

CMM: The Capability Maturity Model for Software (CMM or SW-CMM) is a model for judging the maturity of the
software processes of an organization and for identifying the key practices that are required to increase the
maturity of these processes.

Cause Effect Graph: A graphical representation of inputs and the associated outputs effects which can be used
to design test cases.

Code Complete: Phase of development where functionality is implemented in entirety; bug fixes are all that are
left. All functions found in the Functional Specifications have been implemented.
Code Coverage: An analysis method that determines which parts of the software have been executed
(covered) by the test case suite and which parts have not been executed and therefore may require additional
attention.

Code Inspection: A formal testing technique where the programmer reviews source code with a group who ask
questions analyzing the program logic, analyzing the code with respect to a checklist of historically common
programming errors, and analyzing its compliance with coding standards.

Code Walkthrough: A formal testing technique where source code is traced by a group with a small set of test
cases, while the state of program variables is manually monitored, to analyze the programmer's logic and
assumptions.

Compatibility Testing: Testing whether software is compatible with other elements of a system with which it
should operate, e.g. browsers, Operating Systems, or hardware.

Component: A minimal software item for which a separate specification is available.

Component Testing: See Unit Testing.

Concurrency Testing: Multi-user testing geared towards determining the effects of accessing the same
application code, module or database records. Identifies and measures the level of locking, deadlocking and use
of single-threaded code and locking semaphores.

Conformance Testing: The process of testing that an implementation conforms to the specification on which it
is based. Usually applied to testing conformance to a formal standard.

Context Driven Testing: The context-driven testing is flavor of Agile Testing that advocates continuous and
creative evaluation of testing opportunities in light of the potential information revealed and the value of that
information to the organization right now or it can be defined as testing driven by an understanding of the
environment, culture, and intended use of software. For example, the testing approach for life-critical medical
equipment software would be completely different than that for a low-cost computer game.

Conversion Testing: Testing of programs or procedures used to convert data from existing systems for use in
replacement systems.

Cyclomatic Complexity: A measure of the logical complexity of an algorithm, used in white-box testing.

D (return to top of page)

Data Flow Diagram: A modeling notation that represents a functional decomposition of a system.

Data Driven Testing: Testing in which the action of a test case is parameterized by externally defined data
values, maintained as a file or spreadsheet. A common technique in Automated Testing.

Dependency Testing: Examines an application's requirements for pre-existing software, initial states and
configuration in order to maintain proper functionality.

Depth Testing: A test that exercises a feature of a product in full detail.

Dynamic Testing: Testing software through executing it. See also Static Testing.

E (return to top of page)

Emulator: A device, computer program, or system that accepts the same inputs and produces the same outputs
as a given system.

Endurance Testing: Checks for memory leaks or other problems that may occur with prolonged execution.

End-to-End testing: Testing a complete application environment in a situation that mimics real-world use, such
as interacting with a database, using network communications, or interacting with other hardware, applications,
or systems if appropriate.

Equivalence Class: A portion of a component's input or output domains for which the component's behavior is
assumed to be the same from the component's specification.

Equivalence Partitioning: A test case design technique for a component in which test cases are designed to
execute representatives from equivalence classes.

Exhaustive Testing: Testing which covers all combinations of input values and preconditions for an element of
the software under test.

Exploratory testing: Often taken to mean a creative, informal software test that is not based on formal test
plans or test cases; testers may be learning the software as they test it.

F (return to top of page)

Failover Tests: Failover Tests verify of redundancy mechanisms while under load.   For example, such testing
determines what will happen if multiple web servers are being used under peak anticipate load, and one of them
dies.  Does the load balancer react quickly enough? Can the other web servers handle the sudden dumping of
extra load?  This sort of testing allows technicians to address problems in advance, in the comfort of a testing
situation, rather than in the heat of a production outage.

Functional Decomposition: A technique used during planning, analysis and design; creates a functional
hierarchy for the software.

Functional Specification: A document that describes in detail the characteristics of the product with regard to
its intended features.

Functional Testing: See also Black Box Testing.

 Testing the features and operational behavior of a product to ensure they correspond to its specifications.
 Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs
generated in response to selected inputs and execution conditions.

G (return to top of page)

Glass Box Testing: A synonym for White Box Testing.

Gorilla Testing: Testing one particular module, functionality heavily.

Gray Box Testing: A combination of Black Box and White Box testing methodologies: testing a piece of
software against its specification but using some knowledge of its internal workings.

H (return to top of page)

High Order Tests: Black-box tests conducted once the software has been integrated.

I (return to top of page)

Incremental Integration testing: Continuous testing of an application as new functionality is added; requires
that various aspects of an application's functionality be independent enough to work separately before all parts
of the program are completed, or that test drivers be developed as needed; done by programmers or by testers.

Independent Test Group (ITG): A group of people whose primary responsibility is software testing,

Inspection: A group review quality improvement process for written material. It consists of two aspects; product
(document itself) improvement and process improvement (of both document production and inspection).

Integration Testing: Testing of combined parts of an application to determine if they function together correctly.
Usually performed after unit and functional testing. This type of testing is especially relevant to client/server and
distributed systems.

Installation Testing: Confirms that the application under test recovers from expected or unexpected events
without loss of data or functionality. Events can include shortage of disk space, unexpected loss of
communication, or power out conditions.

L (return to top of page)

Load Testing: Load Tests are end to end performance tests under anticipated production load.  The primary
objective of this test is to determine the response times for various time critical transactions and business
processes and that they are within documented expectations (or Service Level Agreements - SLAs).  The test
also measures the capability of the application to function correctly under load, by measuring transaction
pass/fail/error rates. 

This is a major test, requiring substantial input from the business, so that anticipated activity can be accurately
simulated in a test situation.  If the project has a pilot in production then logs from the pilot can be used to
generate ‘usage profiles’ that can be used as part of the testing process, and can even be used to ‘drive’ large
portions of the Load Test.  

Load testing must be executed on “today’s” production size database, and optionally with a “projected”
database.  If some database tables will be much larger in some months time, then Load testing should also be
conducted against a projected database.  It is important that such tests are repeatable as they may need to be
executed several times in the first year of wide scale deployment, to ensure that new releases and changes in
database size do not push response times beyond prescribed SLAs.

See Performance Testing also.

Localization Testing: This term refers to making software specifically designed for a specific locality.

Loop Testing: A white box testing technique that exercises program loops.

M (return to top of page)

Metric: A standard of measurement. Software metrics are the statistics describing the structure or content of a
program. A metric should be a real objective measurement of something such as number of bugs per lines of
code.

Monkey Testing: Testing a system or an Application on the fly, i.e. just few tests here and there to ensure the
system or an application does not crash out.
Mutation testing: A method for determining if a set of test data or test cases is useful, by deliberately
introducing various code changes ('bugs') and retesting with the original test data/cases to determine if the 'bugs'
are detected. Proper implementation requires large computational resources.

N (return to top of page)

Network Sensitivity Tests:  Network sensitivity tests are tests that set up scenarios of varying types of network
activity (traffic, error rates...), and then measure the impact of that traffic on various applications that are
bandwidth dependant.  Very 'chatty' applications can appear to be more prone to response time degradation
under certain conditions than other applications that actually use more bandwidth.   For example, some
applications may degrade to unacceptable levels of response time when a certain pattern of network traffic uses
50% of available bandwidth, while other applications are virtually un-changed in response time even with 85% of
available bandwidth consumed elsewhere.
This is a particularly important test for deployment of a time critical application over a WAN.

Negative Testing: Testing aimed at showing software does not work. Also known as "test to fail".

N+1 Testing: A variation of Regression Testing. Testing conducted with multiple cycles in which errors found in
test cycle N are resolved and the solution is retested in test cycle N+1. The cycles are typically repeated until the
solution reaches a steady state and there are no errors. See also Regression Testing.

P (return to top of page)

Path Testing: Testing in which all paths in the program source code are tested at least once.

Performance Testing: Testing conducted to evaluate the compliance of a system or component with specified
performance requirements. Often this is performed using an automated test tool to simulate large number of
users. Also know as "Load Testing".

Performance Tests are tests that determine end to end timing (benchmarking) of various time critical business
processes and transactions, while the system is under low load, but with a production sized database.  This sets
‘best possible’ performance expectation under a given configuration of infrastructure.  It also highlights very early
in the testing process if changes need to be made before load testing should be undertaken.  For example, a
customer search may take 15 seconds in a full sized database if indexes had not been applied correctly, or if an
SQL 'hint' was incorporated in a statement that had been optimized with a much smaller database.  Such
performance testing would highlight such a slow customer search transaction, which could be remediate prior to
a full end to end load test.

Positive Testing: Testing aimed at showing software works. Also known as "test to pass".

Protocol Tests: Protocol tests involve the mechanisms used in an application, rather than the applications
themselves.  For example, a protocol test of a web server may will involve a number of HTTP interactions that
would typically occur if a web browser were to interact with a web server - but the test would not be done using a
web browser.  LoadRunner is usually used to drive load into a system using VUGen at a protocol level, so that a
small number of computers (Load Generators) can be used to simulate many thousands of users.

Q (return to top of page)

Quality Assurance: All those planned or systematic actions necessary to provide adequate confidence that a
product or service is of the type and quality needed and expected by the customer.

Quality Audit: A systematic and independent examination to determine whether quality activities and related
results comply with planned arrangements and whether these arrangements are implemented effectively and are
suitable to achieve objectives.
Quality Circle: A group of individuals with related interests that meet at regular intervals to consider problems or
other matters related to the quality of outputs of a process and to the correction of problems or to the
improvement of quality.

Quality Control: The operational techniques and the activities used to fulfill and verify requirements of quality.

Quality Management: That aspect of the overall management function that determines and implements the
quality policy.

Quality Policy: The overall intentions and direction of an organization as regards quality as formally expressed
by top management.

Quality System: The organizational structure, responsibilities, procedures, processes, and resources for
implementing quality management.

R (return to top of page)

Race Condition: A cause of concurrency problems. Multiple accesses to a shared resource, at least one of
which is a write, with no mechanism used by either to moderate simultaneous access.

Ramp Testing: Continuously raising an input signal until the system breaks down.

Recovery Testing: Confirms that the program recovers from expected or unexpected events without loss of
data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power
out conditions.

Regression Testing: Retesting a previously tested program following modification to ensure that faults have not
been introduced or uncovered as a result of the changes made.

Release Candidate: A pre-release version, which contains the desired functionality of the final version, but
which needs to be tested for bugs (which ideally should be removed before the final version is released).

S (return to top of page)

Sanity Testing: Brief test of major functional elements of a piece of software to determine if it’s basically
operational. See also Smoke Testing.

Scalability Testing: Performance testing focused on ensuring the application under test gracefully handles
increases in work load.

Security Testing: Testing which confirms that the program can restrict access to authorized personnel and that
the authorized personnel can access the functions available to their security level.

Smoke Testing: Typically an initial testing effort to determine if a new software version is performing well
enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5
minutes, bogging down systems to a crawl, or corrupting databases, the software may not be in a 'sane' enough
condition to warrant further testing in its current state.

Soak Testing: Soak testing is running a system at high levels of load for prolonged periods of time.  A soak test
would normally execute several times more transactions in an entire day (or night) than would be expected in a
busy day, to identify and performance problems that appear after a large number of transactions have been
executed.  Also, due to memory leaks and other defects, it is possible that a system may ‘stop’ working after a
certain number of transactions have been processed.  It is important to identify such situations in a test
environment.
Sociability (sensitivity) Tests: Sensitivity analysis testing can determine impact of activities in one system on
another related system.  Such testing involves a mathematical approach to determine the impact that one
system will have on another system.  For example, web enabling a customer 'order status' facility may impact on
performance of telemarketing screens that interrogate the same tables in the same database.  The issue of web
enabling can be that it is more successful than anticipated and can result in many more enquiries than originally
envisioned, which loads the IT systems with more work than had been planned.  

Static Analysis: Analysis of a program carried out without executing the program.

Static Analyzer: A tool that carries out static analysis.

Static Testing: Analysis of a program carried out without executing the program.

Storage Testing: Testing that verifies the program under test stores data files in the correct directories and that
it reserves sufficient space to prevent unexpected termination resulting from lack of space. This is external
storage as opposed to internal storage.

Stress Testing: Stress Tests determine the load under which a system fails, and how it fails.  This is in contrast
to Load Testing, which attempts to simulate anticipated load.  It is important to know in advance if a ‘stress’
situation will result in a catastrophic system failure, or if everything just “goes really slow”.  There are various
varieties of Stress Tests, including spike, stepped and gradual ramp-up tests.  Catastrophic failures require
restarting various infrastructures and contribute to downtime, a stress-full environment for support staff and
managers, as well as possible financial losses.  This test is one of the most fundamental load and performance
tests.

Structural Testing: Testing based on an analysis of internal workings and structure of a piece of software. See
also White Box Testing.

System Testing: Testing that attempts to discover defects that are properties of the entire system rather than of
its individual components. It’s a black-box type testing that is based on overall requirements specifications;
covers all combined parts of a system.

T (return to top of page)

Targeted Infrastructure Test: Targeted Infrastructure Tests are isolated tests of each layer and or component
in an end to end application configuration.   It includes communications infrastructure, Load Balancers, Web
Servers, Application Servers, Crypto cards, Citrix Servers, Database… allowing for identification of any
performance issues that would fundamentally limit the overall ability of a system to deliver at a given
performance level.

Each test can be quite simple, For example, a test ensuring that 500 concurrent (idle) sessions can be
maintained by Web Servers and related equipment should be executed prior to a full 500 user end to end
performance test, as a configuration file somewhere in the system may limit the number of users to less than
500.  It is much easier to identify such a configuration issue in a Targeted Infrastructure Test than in a full end to
end test. 

Testability: The degree to which a system or component facilitates the establishment of test criteria and the
performance of tests to determine whether those criteria have been met.

Testing:

 The process of exercising software to verify that it satisfies specified requirements and to detect errors.
 The process of analyzing a software item to detect the differences between existing and required
conditions (that is, bugs), and to evaluate the features of the software item.
  The process of operating a system or component under specified conditions, observing or recording the
results, and making an evaluation of some aspect of the system or component.

Test Automation: See Automated Testing.

Test Bed: An execution environment configured for testing. May consist of specific hardware, OS, network
topology, configuration of the product under test, other application or system software, etc. The Test Plan for a
project should enumerate the test beds(s) to be used.

Test Case:

 Test Case is a commonly used term for a specific test. This is usually the smallest unit of testing. A Test
Case will consist of information such as requirements testing, test steps, verification steps, prerequisites,
outputs, test environment, etc.
 A set of inputs, execution preconditions, and expected outcomes developed for a particular objective,
such as to exercise a particular program path or to verify compliance with a specific requirement.

Test Driven Development: Testing methodology associated with Agile Programming in which every chunk of
code is covered by unit tests, which must all pass all the time, in an effort to eliminate unit-level and regression
bugs during development. Practitioners of TDD write a lot of tests, i.e. an equal number of lines of test code to
the size of the production code.

Test Driver: A program or test tool used to execute a tests. Also known as a Test Harness.

Test Environment: The hardware and software environment in which tests will be run, and any other software
with which the software under test interacts when under test including stubs and test drivers.

Test First Design: Test-first design is one of the mandatory practices of Extreme Programming (XP).It requires
that programmers do not write any production code until they have first written a unit test.

Test Harness: A program or test tool used to execute a test. Also known as a Test Driver.

Test Plan: A document describing the scope, approach, resources, and schedule of intended testing activities. It
identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring
contingency planning.

Test Procedure: A document providing detailed instructions for the execution of one or more test cases.

Test Script: Commonly used to refer to the instructions for a particular test that will be carried out by an
automated test tool.

Test Specification: A document specifying the test approach for a software feature or combination or features
and the inputs, predicted results and execution conditions for the associated tests.

Test Suite: A collection of tests used to validate the behavior of a product. The scope of a Test Suite varies from
organization to organization. There may be several Test Suites for a particular product for example. In most
cases however a Test Suite is a high level concept, grouping together hundreds or thousands of tests related by
what they are intended to test.

Test Tools: Computer programs used in the testing of a system, a component of the system, or its
documentation.
Thread Testing: A variation of top-down testing where the progressive integration of components follows the
implementation of subsets of the requirements, as opposed to the integration of components by successively
lower levels.

Thick Client Application Tests: A Thick Client (also referred to as a fat client) is a purpose built piece of
software that has been developed to work as a client with a server.  It often has substantial business logic
embedded within it, beyond the simple validation that is able to be achieved through a web browser.  A thick
client is often able to be very efficient with the amount of data that is transferred between it and its server, but is
also often sensitive to any poor communications links.  Testing tools such as Win Runner are able to be used to
drive a Thick Client, so that response time can be measured under a variety of circumstances within a testing
regime.

Developing a load test based on thick client activity usually requires significantly more effort for the coding stage
of testing, as VUGen must be used to simulate the protocol between the client and the server.  That protocol
may be database connection based, COM/DCOM based, a proprietary communications protocol or even a
combination of protocols.

Thin Client Application Tests: An internet browser that is used to run an application is said to be a thin client. 
But even thin clients can consume substantial amounts of CPU time on the computer that they are running on. 
This is particularly the case with complex web pages that utilize many recently introduced features to liven up a
web page.  Rendering a page after hitting a SUBMIT button may take several seconds even though the server
may have responded to the request in less than one second.  Testing tools such as WinRunner are able to be
used to drive a Thin Client, so that response time can be measured from a user’s perspective, rather than from a
protocol level.

Top Down Testing: An approach to integration testing where the component at the top of the component
hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then
used to test lower level components. The process is repeated until the lowest level components have been
tested.

Traceability Matrix: A document showing the relationship between Test Requirements and Test Cases.

Tuning Cycle Tests: A series of test cycles can be executed with a primary purpose of identifying tuning
opportunities.  Tests can be refined and re-targeted 'on the fly' to allow technology support staff to make
configuration changes so that the impact of those changes can be immediately measured.

U (return to top of page)

Usability Testing: Testing the ease with which users can learn and use a product.

Use Case: The specification of tests that are conducted from the end-user perspective. Use cases tend to focus
on operating software as an end-user would conduct their day-to-day activities.

User Acceptance Testing: A formal product evaluation performed by a customer as a condition of purchase.

Unit Testing: The most 'micro' scale of testing; to test particular functions or code modules. Typically done by
the programmer and not by testers, as it requires detailed knowledge of the internal program design and code.
Not always easily done unless the application has a well-designed architecture with tight code; may require
developing test driver modules or test harnesses.

V (return to top of page)

Validation: The process of evaluating software at the end of the software development process to ensure
compliance with software requirements. The techniques for validation are testing, inspection and reviewing.

Verification: The process of determining whether of not the products of a given phase of the software
development cycle meet the implementation steps and can be traced to the incoming objectives established
during the previous phase. The techniques for verification are testing, inspection and reviewing.

Volume Testing: Testing which confirms that any values that may become large over time (such as
accumulated counts, logs, and data files), can be accommodated by the program and will not cause the program
to stop working or degrade its operation in any manner.

Volume Tests are often most appropriate to Messaging, Batch and Conversion processing type situations.  In a
Volume Test, there is often no such measure as Response time.  Instead, there is usually a concept of
Throughput. 

A key to effective volume testing is the identification of the relevant capacity drivers.  A capacity driver is
something that directly impacts on the total processing capacity.  For a messaging system, a capacity driver may
well be the size of messages being processed.  For batch processing, the type of records in the batch as well as
the size of the database that the batch process interfaces with will have an impact on the number of batch
records that can be processed per second.

W (return to top of page)

Walkthrough: A review of requirements, designs or code characterized by the author of the material under
review guiding the progression of the review.

White Box Testing: Testing based on an analysis of internal workings and structure of a piece of software.
Includes techniques such as Branch Testing and Path Testing. Also known as Structural Testing and Glass Box
Testing. Contrast with Black Box Testing.

Workflow Testing: Scripted end-to-end testing which duplicates specific workflows which are expected to be
utilized by the end-user.

Different approaches for automated testing tools

 A common type of automated tool is the 'record/playback' type. For example, a tester could click through
all combinations of menu choices, dialog box choices, buttons, etc. in an application GUI and have them
'recorded' and the results logged by a tool. The 'recording' is typically in the form of text based on a
scripting language that is interpretable by the testing tool. If new buttons are added, or some underlying
code in the application is changed, etc. the application might then be retested by just 'playing back' the
'recorded' actions, and comparing the logging results to check effects of the changes. The problem with
such tools is that if there are continual changes to the system being tested, the 'recordings' may have to
be changed so much that it becomes very time-consuming to continuously update the scripts.
Additionally, interpretation and analysis of results (screens, data, logs, etc.) can be a difficult task. Note
that there are record/playback tools for text-based interfaces also, and for all types of platforms.
 Another common type of approach for automation of functional testing is 'data-driven' or 'keyword-driven'
automated testing, in which the test drivers are separated from the data and/or actions utilized in testing
(an 'action' would be something like 'enter a value in a text box'). Test drivers can be in the form of
automated test tools or custom-written testing software. The data and actions can be more easily
maintained - such as via a spreadsheet - since they are separate from the test drivers. The test drivers
 'read' the data/action information to perform specified tests. This approach can enable more efficient
control, development, documentation, and maintenance of automated tests/test cases.

PROCESS OF DEVELOPING LOGIN SCREEN TEST CASES.

Use Case

It is a description of functionality of certain feature of an application in terms of actors, actions and response.

Preparation of use case

Input information requires to preparing the use cases.

Snap Shot:
User Name
Password
Connect To
OK Clear Cance
Functional Requirements

1. Login screen should contain user name, password connect to fields, login, clear and cancel buttons.
2. Connect to field is not a mandatory field but it should allow the user to select a database option who ever request it.
So that he can connect to the mentioned database while login in.
3. Upon entering valid username, valid password and clicking on login button corresponding page must be displayed
4. Upon entering some information into any of the fields and clicking on clear button all the fields must be cleared and
the cursor should be placed in the user name field.
5. Upon clicking on cancel button login screen must be closed.

Special Requirements / Business Rules / Validation.

1. Initially whenever the login screen is invoked (opened) the login, clear button must be disabled.
2. Cancel button must be always enabled.
3. Upon entering user name and password the login button must be enabled.
4. Upon entering some information into any of the field the clear button must be enable.
5. The tabbing must be User name, Password, Connect to, Login, Clear and Cancel.

Use case Template:

Name of the Use case :

Brief discretion of the Use case :
Actors involved :
Special Requirements :
Pre - Conditions :
Post – Conditions :
Flow of events :

Use case Document:

Name of the Use case : Login Use Case

Brief discretion of the Use case : This use case describes the functionalities of all the
 features of login screen.
Actors involved : Normal User, Admin User.
Special Requirements :
There are two types of special requirements.
1. Implicit Requirements.
2. Explicit Requirements.
Implicit Requirements:
The Requirements that are analyzed by the business analyst with out the permission of customer in order to increase
the value of the application are known as implicit req2uirments.
Explicit Requirements:
The customer specified special requirements are known as explicit requirements.
Implicit Requirements:
1. Whenever the login screen is invoked initially the cursor should be placed in the user name field.
2. Upon entering invalid user name and valid password and clicking on login button an error message should be
displayed as follows.
“ Invalid Username Please Try Again”.
3. Upon entering valid user name and invalid password and clicking on login button an error message should be
displayed as follows.
“ Invalid Password Please Try Again”.
4. Upon entering both invalid username and password and clicking on login button an error message should be
displayed as follows.
“Invalid Username and Password Please Try Again.
Explicit Requirements:
1. Login screen should contain user name, password connect to fields, login, clear and cancel buttons.
2. Connect to field is not a mandatory field but it should allow the user to select a database option who ever request it.
So that he can connect to the mentioned database while login in.
3. Upon entering valid username, valid password and clicking on login button corresponding page must be displayed
4. Upon entering some information into any of the fields and clicking on clear button all the fields must be cleared and
the cursor should be placed in the user name field.
5. Upon clicking on cancel button login screen must be closed.
Pre - Conditions:
Login screen must be available.

Post – Conditions:
Either home page or admin page for valid users and error message for invalid users.

Flow of events:
Main Flow

Action Response
Actor invokes the application. Login screen is displayed with the following felids
username, password, connect to, login, clear and
cancel.
Actor enters valid username, valid password and Authentication, either home page or admin page is
clicks on login button. displayed depending upon the actor entered.

Actor enters valid username, valid password, Authentication, either home page or admin page is
selects a database option and clicks on login button. displayed with the mentioned data base connection
depending upon the actor entered.
Actor enters invalid username, valid password and Go to alternative flow table 1.
clicks on login button.
Actor enters valid username and invalid password Go to alternative flow table 2.
and clicks on login button
Actor enters invalid username and invalid password Go to alternative flow table 3.
and clicks on login button.
Actor enters some information into any of the fields Go to alternative flow table 4.
and clicks on the clear button.
Alternative Flow Table 1. (Invalid Username)

Action Response
Actor enters invalid username, valid password and Authenticates, an error message is displayed
clicks on login button. “Invalid Username Please Try Again”.

Alternative Flow Table 2. ( Invalid Password)

Action Response
Actor enters valid username, invalid password and Authenticates, an error message is displayed “
clicks on login button. Invalid Password Please Try Again”.

Alternative Flow Table 3. (Invalid Username and Password)

Action Response
Actor enters invalid username, invalid password Authenticates, an error message is displayed “
and clicks on login button. Invalid password and username”.

Alternative Flow Table 4. (Clear Click)

Action Response
Actor enters some information into any of the fields All the fields are cleared and the cursor is placed on
the user name.

Alternative Flow table 5. (Cancel Click)

Action Response
Actor clicks on the cancel button Login screen is closed.

Guidelines to be followed by a test engineer once the use case document is give to him.

1. Identify the module to which the use case belongs.

2. Identify the functionality of the use case with respect to the total functionality.
3. Identify the functionality points and prepare the functional point document.
4. Identify the actors involved in the use case.
5. Identify the inputs required to perform testing.
6. Identify whether the use case is linked with any other use case.
7. Identify the pre – condition.
8. Identify the post – condition.
9. Understand the main flow of the use case.
10. Understand the alternative flow of the user case.
11. Understand the special requirements.
12. Document the test cases for the main flow of the application.
 13. Document the test cases for the alternative flow of application.
14. Document the test cases for special requirements.
15. Prepare the crass reference matrix (or) Tracebility matrix.

Functional points

The point where a user can perform some action is known as functional point.

The sequence of the document prepare during the test process.

FRS FPD MTCD DTCD DPD

1.User entry ……… ………

UCD 2.Passwor Vall L.C ……… ………
entry ……… ………
3.DB selection Vall C.C ……… ………
4. Login click ……… ……...
5. Clear click Vall Ca.C ……... ………
6. Cancel click

Tracebulity matrix (or) Cross-reference matrix.

It is a document which contains a table of linking information used for tracing back for the reference in any kind of
questionable or confusion situations.

UCD FPD MTCD DTCD DPD

26 6 3 38 1

32 8 4 42 3

Requirements Tracebulity Matrix. Defects Tracebulity Matrix.

UCID TCID
TCID DPD
1 2
38 1
2 4 42 2
34 3
 Quality Standards
Quality Standards are defined as a set of guidelines or help lines given to an organization to accomplish each and
every task in an effective, efficient & optimized way.

ISO (International Organization for Standards):

Example : ISO 9001 : 2000

Quality Number Year in which it is Introduced or modified

How the Quality Standards are prepared ?

BVQI ( Bureau Veritas Quality International ), Geneva ( Switzerland) is the organization which
provides guidelines to ISO organization.

The BVQI will prepare the Quality standards for ISO as mentioned below..
1. All the companies are Invited
2. All the experts are Asked to write their own procedures
3. All the experts are Requested to read all the procedures
4. Voting is Conducted
5. High voting procedure is picked-up, customize and finalize as Quality Standard

Assessment of Procedures
BVQI

ATL ATL ATL

ATM ATM ATM

Issuing Certificate External Audit

ATR
Company …….
……..
BVQI : Bureau Veritas Quality International
ATL : Assessment Team Lead ATM : Assessment Team Member
ATR : Assessment Team Report

 BVQI will appoint ATLs and ATMs, ATMs will come to the company to do External Audit and prepare a
report (ATR) and submit the same to ATL, ATL will review it and in turn sends to BVQI. After finalizing
the report, BVQI will gives the ISO certification.

Types of Quality Standards:

Departments in both Non-IT and IT companies :-

1 Plan/Design 2 Production/Development 3 Testing 4 Marketing 5 Service/Maintenance

2

ISO 9000: It is used for startup company. The company which started
newly but don't have resources can get ISO 9000.

ISO 9001: It is given for full fledged companies. The company should have its own above 5
departments, such type of companies are given this ISO 9001.They should also follow the set
of guidelines. These are the terminology given for both IT & non-IT companies.

1 2 3 4 5
2 2 2 2 2

ISO 9002: In this Certification for Planning /Designing department they will take the help of ISO 9001.

1 2 3 4 5
2 2 2 2 2

ISO 9003: It is purely meant for testing. In this only Test department is available.
The purely third party testing companies are certified

3
2
ISO 9004: Research & Development and also continual growth of the company are concentrated.
CMM:(Capability Maturity Model)

SEI : CMM: (Software Engineering Institute): Initially a five level model is developed by the PHD people
from Software engineering Istitute located in USA. That is why it is named as SEI CMM.

These 5 levels are for IT industries

CMM Level 1: INITIAL : It is used for startup companies but here one thing is considered tean should be very
strong technically strong, more experienced people so definitely the product will be quality
product. If at all the team strong they wont ask any guidelines.
( with Strong Team and well defined guidelines )

CMM Level 2: REPEATABLE: Once we entered into it two guidelines are given one is well defined
guidelines another they should focus on reusability. Team should very strong in Technical.
(with Strong Team , well defined guidelines and Focus on Reusability )

CMM Level 3: DEFINED :It means Documented. At CMM Level 3 it should focus on Documentation.
(with Strong Team , well defined guidelines ,Focus on Reusability and focus on Documents)

CMM Level 4: MANAGED Each and every work in the organization must be measured ( Metrics).
It should focus on metrics apart from level 1 + level 2 + level 3.
(with Strong Team , well defined guidelines ,Focus on Reusability, focus on Documents and focus on
Marketing )

CMM Level 5: Research and development & as well as continual growth.

level 1 + level 2 + level 3 + level 4 as well as Research and development & continual
growth. There is a great demand for CMM Level 5 . These 5 levels are for IT industries
(with Strong Team , well defined guidelines ,Focus on Reusability, focus on Documents, focus on
Marketing and focus on Research and Development)

CMM I (Integrated): It is introduced for both non IT & IT integration

CMM P 0r PCMM: P stands for People capability & maturity of people. It focus on People.
6-Sigma :

99.76%

6-Units span

6-Sigma Axis
1 2 3 4 5 6 7 8 9 10

6-Sigma companies will develop the products in multiple cycles, for each cycle they plot the graph, whenever the
graph Spans for 6-units on the 6-sigma axis , they will stop the product and check for the Quality. So that
the quality will be 99.76% and above.

sigma = xn - x where xn = sum of number of values

n X = mean / average value
n = Total number of values

 The above formula is used to plot the graph.

 Once the graph is proved by any company , then only 6-Sigma certificate will be issued.
 There are many companies are trying to get that certificate But, very few companies were got the
certificate.
Example : Motorola etc.

SSLC (Six Sigma Life Cycle) :

This life cycle contains only 5- phases ( where as other life cycles are having 6-phases)

1. Define
2. Measure
3. Analyze
4. Improve
5. Control

Every company has to Define their own production process. After production they should Measure the output
with the defined value. Analyze the result with define value and out put values, if at all is there any miss-matched
item were produced then they should Improve the production process in such way to get out put with less
deviation. In order to do the same they also have Control on the whole process. So that they could able to get the
output in such way to plot the graph with 6-units span.

* 3.4 DPMO :- 3.4 Defects per Million Opportunities

Quality Center
Introduction :
Tool name : Old version - Test Director by Mercury people.
: New Version - Quality Center by HP people
Type of the tool : Management tool
Company : Mercury Interactive Incorporation ( now by HP)
Version : 9.2 ( But we learning 9.0)
Scripting Language : No scripting language is used

 Quality center is used for just Management of whole Testing Process

 Quality center is NOT used for testing the functionality of the application

Quality Center is a management tool which provides

1. Common Repository 2. Automatic Traceability Matrix
3. Bug Tracking facility 4. Automatic Reports and Graphs generator.

A good Testing Engineer divides Testing process into 6- sections

1. Business Component*
2. Requirements
3. Test plan
4. Test Lab and
5. Defects Management
6. Dash Board * : * Not in use

1.Requirements Module: In this section, first we understand all the requirements, once we understood the
what are to be tested, listed out all the Main Requirements as well as sub-requirements (child
requirements).

=> For every Requirement we need to plan a Test. Requirement Module

* Test means Test case (in manual) or MR1
* Test means Test Script (in Automation) CR1

This module used for building the requirement string. To do the same CR2
this module has provided Two options
a). New Requirement
b). New Child Requirement
These two requirements will do the following
i). One can attach any kind of attachments to the requirement MR2
ii). It will automatically shows the author name CR3
iii). It will generate IDs automatically for each and every requirements
iv). One can give direct cover status of the requirements like CR4
 Whether the test is covered or Not
  Whether its executed or Not
 If executed, whether its passed or Failed

MR : Main Requirement
CR : Child Requirement

2.Test Plan Module : In this section,

1. We need to create test plan for corresponding requirements which were prepared in
Requirement module.
2. Using the Traceability matrix, you should cross check whether you have created test
plans for all the requirements.

Test Plan Module

This module is used for creating the tests (automatically or manually for MT1
all the requirements ) to do the same one has to create a folder, under that CT1
he needs create the desired empty test. Based on the test one has to launch
the corresponding functional tool (QTP), generate the desired test scripts CT2
and Click on the save Button in the functional tool.
The script will be saved in the empty script file which is already
created in the Quality center. In the same way one has to create all the
tests. Once all the test are created this module also provides the facility to
establish the link between the test and corresponding requirements with MT2
help of requirements coverage tab in order to establish automatic CT3
traceability and its feasibility.
Once all the test are created then one will go to next module CT4
by name Test Lab.

MT : Main Test
CT : Child Test

3.Test Lab Module : In this section, First of all we need to identify all the end-to-end scenarios , then for each
end-to-end scenarios we will create a Test Set.

This module is used for the following…

1. Building the Test set
2. Execute the Test set
3. Analyze the results.

1. To do the same one has to Build/ create the folders and create corresponding test sets with help of all the
available test sets based on the different end-to-end scenarios .

2. Once the tests are Build one can Execute them by either RUN or RUN ALL options provided in this
module.
RUN : is used for Running a single selected test in the test set
RUN ALL : is used for running all the tests in the test set

3. Once the execution is completed one can analyze the Results in the Functional tool (QTP) it self and if at
all one can identify the Defects and need to post them , he can do it from the Functional tool itself, other wise, go
to next module by name Defects Module.

4. Defects Module : This module acts like Bug Tracking tool and provides all the facilities to manage the
defects like Adding the defects, changing the status of defects etc., with complete bug tracking facility is
provided.

Once the Defects (if any) are been sent to Developers, they will re-build the application by removing such defects
and send it again for Testing.
This is called 2nd Build, doing testing on 2nd build on wards is called Re-Testing or Regression testing.
Here we do testing from 3rd module (Test Lab Module) to 4th module (Defects Module).
Till all the defects have been fixed.

So that we will have a proof for every related tasks ( above 4-modules).
Then we can say that we have done a GOOD Testing.

Architecture for Quality Center :

Requirements Module Test Plan Module Test Lab Module Defects Module
Plan a Test by Creating Creating Test Set for Bug Tracking
corresponding test each end-to-end
Creating MR plans for scenarios. Adding defects
Creating CR requirements.
Changing status..
Building Test set
etc.
Creating MT Executing Test set
Creating CT

Normal testing flow

Re-Testing / Regression testing

A Test Engineer expects from a company to work for testing.

1. Common Repository :- It’s a centralized system / server wherein authorized persons can store the data
related to testing.
2. Automatic Traceability Matrix :- if possible to company (optional )
 3. Default /Bug tracking tool :- To manage the defects easily. Some companies are maintaining their
own tool in this case.
4. Automatic Reports and Graphs generator : if possible to company (optional )

Due to cos,t most of companies are not using Quality center tool, But, maintaining their Own systems for all
above 4 operations.

Extra Components / modules in Quality Center :

5. Business Component* : It is a special feature or module provided by Quality Center in order to perform
Business Process Testing. In this type of testing usually the subject experts i.e business analysts
will develop the business components based on the business flow of the application and then
Automated test engineers will build the script in them. So that one can perform testing in an even
more effective manner.

6. Dash Board* : It’s a special component provided by quality center which is used for generating the reports
across multiple projects at a time. Usually this facility will be used by Managers.

Site Administrator
Site Administrator is a very important component provided by Quality Center which is
used for following…
1. Creating new users
2. Deleting old users
3. Modifying the information of the users
4. Creating the Domain
5. Creating the projects i.e allocating the space for new projects in the server/ common resources area
6. Assigning the users for the project and all other administrative activities.

* We write Functions in Quality center in such way that to open Test script in QTP and when we save it that will
be saved in Quality center.
* Scripts can’t be written in quality center.
* Scripts can’t be executed in quality center.

** Two ways we can test the application

1. Thru QTP : By giving the path in QTP for quality center.
2. Thru Quality Center : by opening QTP from quality center.

 Write some script in test pane ( say: msgbox “Hai”)

 Save it to hard disk or
 If thru quality center a Connection must be established….
 Open Tool -> File -> Quality Center Connection
 It will ask for Server name or url , give the name as required
 Give the username and password
 Select the domain name and project , click on Login button
 Now connection is established.
 Now click on Save the file option , so that it will be saved in quality center
 If you want you can Retrieve the saved file by selecting file -> Open option
 If you want to Logout, select File -> Quality Center -> Logout -> Change user -> Disconnect.
 AUTOMATION TESTING

There are two ways of Testing.

1. MANUAL TESTING.
2. AUTOMATION TESTING.
1). MANUAL TESTING

It is a process in which all the phases of Software Testing Life Cycle like Test Planning, Test
Development, Test Execution, Result Analysis, Bug Tracking and Reporting are accomplished
successfully manually with human efforts.

Drawbacks of Manual Testing

1. More number of people is required.

2. Time consuming.
3. No accuracy.
4. Tiredness.
5. Simultaneous actions are almost impossible.
6. Repeating the task in a same manner is not so easy manually.

2). AUTOMATION TESTING

It is a process in which all the drawbacks of manual testing are addressed (over come) properly
and provides speed and accuracy to the existing testing phase.
Note:
Automation Testing is not a replacement for manual testing it is just a continuation for a manual
testing in order to provide speed and accuracy.

Drawbacks of Automation Testing

1. Too cost.
2. Cannot automat all the areas.
3. Lake of expatriation.

AUTOMATION TOOL
Automated Tool is an Assistance of test engineers, which works based on the instructions and
information.

General foam work to learn any automated tool.

A test engineer should learn the following to work with any automated tool.
 1. How to give the instruction.
2. How to give the information.
3. How to use its recording facility.
4. How to use its play back facility.
5. How to analysis the Result.

Types of Automated Tools

Automated tools are broadly divided into 3 Types

1. Functional Tools (Q.T.P, Win Runner)

2. Management Tools (Test Directory / Quality Center)
3. Performance Tools (Load Runner)
Functional Tools (Q.T.P, Win Runner)
Q.T.P (Quick Test Professional)

Introduction

Type of the Tool : Functional Tool

Company : Mercury Interactive Incorporation.
Scripting Language : VB Script
Version : #5.5, 6.5, 7.0, 7.2, 8.0, 8.2, 9.0, 9.1, 9.2.

Anatomy of Q.T.P

Vbwindow (“Emp”). VbEdit (“Ename”).Set “Pavan”

Vbwindow (“Emp”).VbEdit (“Eage”).Set “24”
Vbwindow (“Emp”).VbEdit (“Esal”).Set “40,000”
Vbwindow (“Emp”).VbEdit (“Edesig”).Set “Test Lead”
Vbwindow (“Emp”).Vbbutton(“Submit”).Click

Add – In – Manager

Add in manager is a feature providing Q.T.P, used for making the Q.T.P compatible with the specified
environment.

By default Add-In-Manager contain 3 Add Ins.

1. Visual Basic
2. Active x.
3. Web.

Q.T.P is always compatible with standard windows environment apart from the above add ins any other
add in is required one need to purchase it by paying extra cost.

Q.T.P screen can be divided into 5 parts.

 1. Test Pane
2. Active Screen
3. Data Table
4. Debug Viewer Pane
5. Tool Options

1). Test Pane

Test pane is an area provided by Q.T.P, which is used for developing, viewing and modifying the test
script.

It represents the Test script in 2 views.

1. Expert view
2. Keyboard view
Expert view.
Expert view represents the script in VB script format.
Keyboard View
It represents the scripts using a graphical user interface, which is further divided, into 4 parts.

1. Item
2. Operation
3. Value
4. Documentation
2) Active Screen
Active Screen is a feature provided by Q.T.P which holds the snap shots related to each and every script
statement and used for understanding the script easily as well as enhancing the script easily.

3) Data Table
Data table is also called as formula1 sheet, which is developed by the third party and integrated with the
Q.T.P.
Features: -

1. It is used for holding the Test Data.

2. It provides the facility to import the test data very easily from the different data sources like Excel
files, Data bases and Flat files.
3. It allows the user directly to enter data and modify the data.
4. It isolates (Separate) the test script from the data source.

Note: Q.T.P maintains two copies of Data Table.

1. Design time data table.

2. Run time data table.

4) Debug Viewer Pane

 Debug Viewer Pane is an area provided by Q.T.P which is used for Viewing, Modifying or Setting the
current values of the variable or expressions during the execution brake with the help of three tabs by
name Watch Expression, Variable and Commands.

5) Tool Options

The options available in Manu bar, File Toolbar, and Testing Toolbar are known as Tool options.

Recording and Running

Recording and Run Settings:

Recording and Run Setting is a feature provided by Q.T.P, which is used for making the Q.T.P understand
on which applications will need to concentrate while Recording and Running. This settings has to be done
at least once for every new test.

Operational Overview of Recording.

During recording Q.T.P will be during we following

1. It will generate the corresponding test script statement for every user action.
2. It will also store the required related information in the object repository.

Operational Overview of Running.

Q.T.P will be doing the following will be running

1. It will be read the script statement.

2. It will understand what action to be perform on which object.
3. When it is realizes it need to identify that object for that it require some information for that information it
will go to the object repository and search.
4. once the information is identified using that information it will try to identify the object.
5. Once the object is identify it will perform the action

Recording Modes

There are 3 types of recording modes.

1. Contact sensitive recording mode / normal recording mode.

2. Analog recording mode.
3. Low-level recording mode.

1) Normal recording

It is used for recording the operations perform at different contacts on the standard GUI objects.

2) Analog Recording

It is used for recording the continuous operations.

3) Low-level Recording

It is special recording mode provided by Q.T.P, which is used for recording the minimum operations on
the Non-Supported environments also.

Q.T.P Life Cycle

1. Test plan
2. Generating the basic test
3. Enhancing the test
4. Debugging the test
5. Executing the test
6. Analyzing the results.
1) Test Planning
In this phase the automation test lead will do the following

1. Understand the requirements

2. Identify the areas to be automated.
3. Analyze both the positive and negative flow of those areas.
4. Based on the above analysis he will prepare the automation test plan document.
5. He will prepare the tool ready with all the pre configurational settings for further operations.

2) Generating the Basic Test

In this phase the automation test engineer will generate the basis test for both the positive and negative flow of the
test.
3) Enhancing the test
One can enhance the test in the following ways.

1. Inserting the checkpoints.

2. Synchronizing the test.
3. Parameter zings the test (Data Driven Testing).
4. Inserting the output values.
5. Measuring transactions.
6. Inserting programmatic statements.
7. Inserting comments.
8. Inserting the script statement manually.

1) Inserting the checkpoints.

Checkpoint:
 Checkpoint is defined as validation point or test point which checks the object or bitmap state or data state
during the execution at any point of time.

Operational over view of checkpoint.

The checkpoint works in two phases.

1. Pre execution phase.

2. While execution phase.

1) Pre execution phase.

 It captures the expected value

 Generates the corresponding test script statement.

2) While execution phase.

 It captures the actual value.

 Compares the expected value with the actual value.
 Displays the results.

Types of Checkpoints

1. Standard checkpoint
2. Bit map checkpoint
3. Text checkpoint
4. Text area checkpoint
5. Data base checkpoint
6. XML checkpoint
7. Page checkpoint
8. Table checkpoint
9. Image checkpoint
10. Accessibility checkpoint

1) Standard checkpoint.

It is used for checking the properties values on standard GUI values.

It can be inserted in 2 ways.

 Through application
 Through active screen
2) Bitmap checkpoint.
It is used for checking the complete bitmap or a part of a Bitmap.
It cam be inserted in 2 ways.
  Through the application.
 Through the active screen.
3) Text Checkpoint
It is used for checking the Text present on a object. It can be inserted through application as well as
through active screen.

4) Text Area Checkpoint

It is used for checking the test present in a specified area. It can be inserted only through application but
not through active screen.
5) Data Base Check Point
It is used for checking the contents of a database.
6) XML (Extended Markup Language) Checkpoint
It is used for checking the contents of an XML file.
It is a universally understandable language and used for data transformations.
Web Checkpoints
7) Page Checkpoint
It is used for checking the properties of a web page like Load time, Number of Links and number of
Images.
8) Table Checkpoint:
It is used for checking the contents of a web table.
9) Image Checkpoint
10) Accessibility Checkpoint
It is used for checking whether the page can be accessible by more number of people or not. In order to
check the same actually it checks whether the page is developed according to the WWW (world wide web
Consorted) standards or not.
Synchronizing Test
Synchronization:
It is a process of matching the speeds of both the tool and application in order to keep them in sink with
each other to obtain proper testing results.
Here the main concept is making the tool to wait that can be done in 3 ways.
1. Inserting the synchronizing point.
2. Increasing the default time.
3. Inserting the wait statement.
Syntax:
Object high rarity. Wait property “ Property name”. Property Value, Extra time in milliseconds.
Ex:
Window (“Flight Reservation”). Window Button (“Delete Order”). Wait Property “Enabled”, True,
16000.
Inserting the wait statement.
One can insert the wait statement directly in script in desired location.
Syntax: Wait (Sec).
Ex: Wait (20).

DATA DRIVEN TESTING

 It is a concept introduced in automation in order to implement Re-Testing.
Steps to be followed to Data Driven Testing.

 Collect the data in to the data table

 Generate the Basic test.
 Execute the Test.
 Analyze the Results.
Parameterization:

It is a process of replacing the constant values with the variables or parameters in order to increase the scope of the
test.

Parameterization can be driven.

1. Through Data Driven Wizard.

2. Keyword View.
3. Manually.
In the same way one can parameterized all the constant values and finally click on Ok.
In order to avoid the above navigations one can directly parameterized manually as follows.
Ex:
A = data table (“V1”,1)
Vbwindow (“form1”). Vbedit (“val1”). Set a.
Vbwindow (“form1”). Vbedit (“val2”). Set data table (“v2”, 1)
Vbwindow (“form1”). Vbbutton (“Add”). Click
4) Output Value:
It is a feature provided by Q.T.P, which is used, for capturing a value from an application or from a database or from
a XML file and stored it under a specified column in the run time data table during execution.
To do the same Q.T.P as provided 5 types of output values.
1. Standard output value.
2. Text output value.
3. Text area output value.
4. Database output value.
5. XML output value.
Operational over view of output values.
Output value feature works in 2 phases
1. Pre-Execution phase.
2. While – Execution phase.
1).Pre-Execution phase:
 Captures the field name from where the value is to be captured.
 Generates the corresponding script statement.
2) While execution phase:
 Captures the actual value form the field.
 Stores it under a specified column in the run time data table.

5) Measuring Transactions:
It is a concept provided by Q.T.P, which is used for calculating the time taken by an application to perform a specific
task or the execution time of a block of script statements.
To do the same Q.T.P has provided 2 options.
1. Start Transactions.
2. End Transactions.
Navigation through inserts Transaction points.

 Keep the cursor in the desired location.

 Activate the menu item insert.
 Select the option start Transactions
 Specify the Transaction name.
 Select one of the following options
o Before current step.
 o After current step.
 Click on Ok.

In order to avoid the above navigation one can insert the following statements directly into the script

Services. Start transaction “ Transaction Name”

-----------------------------------------------------------
-----------------------------------------------------------
-----------------------------------------------------------
Services. End transaction “Transaction Name”.
6) Inserting Programmatic Statements.
Vb script is a combination of 5 types of programmatic statements.
1. Normal statements / Objects
2. Conditional statements.
3. Looping
4. Comments
5. Utilities Statements.
Reporter utility object
It is used for reporting and user defined messages to the result window in order to understand the result better.
Syntax: Reporter. Report event status, “Report name”, “message”.
Ex: Reporter. Report event 2 / micdone, “Myrep”, “Add oper is successful”.
One can replace the status in following numbers
0 – Pass
1 – Fail
2 – Done
3 – Warning.
4) Debugging the Test.
Debugging:
It is a process of executing the script or a program in a user desired fashion with same temperare breaks in order to
identify the errors.
To do the same Q.T.P has provided 3 step commands and a break point feature.
Step Commands:
1). Step Into
It is used for executing a single step. If it is normal statement
If that statement is function or action call statement then it will step into that function or action and breaks it’s
execution.
2) Step Out
It is used for stepping out of a function or action by executing all the remaining statements from the position of the
pointer.
3) Step Over
It is used for executing a single step if it is normal statement.
If the statement is function call or action call it will execute all the statement inside the function or action once and
stops it’s execution at the next statement.
4) Break point
It is a feature provided by Q.T.P used for breaking the execution temporarily.
Ex:
Function Myfun()
Msgbox “ hai”
Msgbox “hellow”
Msgbox “h r u”
End statement
Myfun()
Myfun()
Msgbox “bye“
Myfun()
Msgbox “See U”
Debug Viewer Pane:
It is an area provided by Q.T.P which is used for viewing, modifying or setting the current values of the variables or
expressions during the execution break with the help of 3 tabs by name.
1. Watch expression
2. Variables
3. Commands
 Ex:
Dim a
A=10
B=20
Msgbox a
Msgbox a
Msgbox a
5) Executing the Test: In this phase one will execute the Test.
6) Result Analysis: In this phase one will analyze the Results.
Object Repository :
Which is defined as a Storage place where one can store the Objects
information and it also act as an Interface between the Test Script and AUT in order to Identify the
Object during the execution.

Objects ……….. …………

properties …………..
………. ……
Script………
AUT …….
Object Repository Test

 Using the value of properties in Object Repository QTP will Identify the object in AUT ,
Hence, we can’t change the value of property of that object.

 Usually we should not change the value of property of an object but when the value of Original
object’s property is changed by customer then we can change its property value.

 Rename for an object is required to easily understandable and remembrance

 We can identify an object with minimum number of properties, so, execution speed will be fast.
If those minimum properties are not sufficient to find an object in AUT then we go for some more
properties to identify that object.

 Highlight button is used for High Light the corresponding object in AUT. Some times QTP will
name objects to un-meaningful names , by using this button we can easily find that object in
AUT and re-name to a meaning full names which we can easily remember. OR
Whenever a testing engineer is not understanding any object, then he will use HighLight button ,
so that it will make the corresponding object is highlighted in AUT. Thereby, one can easily
understand which object is this.

Types of Object Repository

1. Per-Action Repository 2. Shared Repository

Per-Action Repository :- If at all this type of repository is selected , for every action a Separate
individual repository is created automatically and managed by QTP.
 For sample test we go for per-action repository
 Per-action repository can’t be Re-usable
 Space required for storage is Less
 Execution speed is fast
 Shared Repository :- If at all this type of repository is selected ,then one need to create the shared
repository manually and associate it to the corresponding test manually.
 For long run we go for shared repository even though we need to create manully.
 Shared repository can be re-usable
 Space required for storage is more
 Execution speed is slow
 Easily maintenance

Object Identification :
Object Identification concept is based on 4-types of properties and an Ordinal Identifier.
Those 4-Types of properties :-

1. Mandatory Properties (MP)

Normal Brain => stores in Object Repository
2. Assistive Properties (AP)
and Ordinal Identifier

3. Base Filter Properties (BFP)

Smart Brain => stores in secret place
4. Optional Filter Properties (OFP)

How QTP will Learns the object’s properties ?

With Normal Brain only With Smart Brain (Normal + smart brain)

BFP
MP MP
I I
OFP

AP AP
………………. ……………….
……………… II ……………… II

OI
OI
……………….
……………….
………………
……………… III III

How QTP will Identify the object’s properties ?

With Normal Brain only With Smart Brain (Normal + smart brain)

A
All
All MP + All BFP I
MP
May be/All AP
All AP I
……………
…………..
 Fresh

OI OFP
OI II ………………. II ………………. III
………………. ……………… ………………
………………

How QTP will Learns the object’s properties ?

With Normal Brain only
First of all QTP will Learn all the list of MP then it will STOP and think whether these
properties are sufficient to Identify the object Uniquely.
* If it feels satisfy then it will STOP Learning, other wise Learn the 1st AP, STOP thinks whether all
these properties are sufficient to Identify the object Uniquely.
If it feels satisfy then it will STOP Learning, other wise Learn the 2nd AP, STOP thinks whether all these
properties are sufficient to Identify the object Uniquely.
If it feels satisfy then it will STOP Learning, other wise Learn the 3rd AP, STOP thinks whether all these
properties are sufficient to Identify the object Uniquely. …..
It will continue the above process till it feels Satisfied or Up to the End of AP list.
At the end of AP list also if it feels not satisfied the Finally it will Learn the Ordinal Identifier and STOP
learning.

With Smart Brain (Normal + smart brain)

QTP will Learn all the MP at time and along with it will also Learn the BFP and OFP
completely and Stores them secretly not in the Object Repository.
* Then remaining procedure is as Same as Above.

How QTP will Identify the object’s properties ?

With Normal Brain only
While Identifying object without smart brain is also same as in case of Smart brain presence.

First of all QTP will use all the properties presented in the Object Repository Except the Ordinal
Identifier and try to identify the object. If it fails, it will check whether the Ordinal Identifier is available
or NOT. If it is available QTP will identify the Object Roughly or other wise STOPs.

With Smart Brain (Normal + smart brain)

First of All QTP will use all the Properties (All MP + May be/All AP) presented in the Object
Repository except Ordinal Identifier and try to Identify the object.
If at all it fails to identify the object, then it will FORGET all these properties and enter into the secret
place. Then considers all the BFP at a time and try to identify the object by matching these properties with
all the objects in the AUT, then it will form a list of all the objects that are matched with these properties
and check whether the list is containing only one object or more than one object.
If the list is containing more than one object , then it will consider the 1st OFP and try to match with all the
objects presented in the list and then forms a new list of objects that matched with this property. And
checks whether the list containing only one object or more than one objects.
If the list is containing more than one object it repeat the above process with 2nd OFP.
Like this it will repeat the same process till the list is Contain only one Object or Up to the end of OFP
list.
 At the end of OFP list also if the list is containing more than one object then finally it will check
whether the Ordinal Identifier is available in the Object Repository or NOT.
If it is available , it will identify the object ROUGHLY or otherwise STOPs / Hands up .

Ordinal Identifier
* Generally we should not encourage the Ordinal Identifier but when the application is Stable
then we may use it.

* Once the application is stable then only we go for Automation, till such time we do only
manual testing.

There are 3 type of Ordinal Identifiers

1. Location
2. Index
3. Creation Time

1. Location :- If at all the location is selected as an OI then the QTP will generate the Numbers from
0,1,2,3……based on the Sequence of the objects located in the Application.

2. Index :- If at all the index is selected as an OI then the QTP will generated the Numbers from
0,1,2,3…. based on the Sequence of the Programs of the objects.

3. Creation Time ( for web pages only):-

If at all the creation time is selected as an OI then the QTP will generate the Numbers from
0,1,2,3….. based on the Loading time of the web Page.

Smart Identification Mechanism

Whenever the QTP Fails to identify the object with the help of properties presented in the
Object Repository, then the Special mechanism provided by QTP to identify the same object smartly
with some other properties is called Smart Identification Mechanism.
Object Spy
It is a handy / useful feature provided by QTP which shows the complete object
information like List of Properties , List of Methods, Syntaxes of Methods and Description of
Methods then and there and Immediately on the spot of both Test Object as well as Run Time
Objects.

Runtime Object :- Run time object is he Original objects presented in the AUT .
Test Object :- Test object is the Reference object for the Runtime object created by QTP and used by QTP
to identify the Runtime object during the Execution.

Recovery Scenario

*** When you want to recover from any problem, First, face the problem manually, Find the solution
manually , Recover from that problem manually.
And in the same way you implement for Automation ( in QTP)

Recovery Scenario with Pop-Up window

( When a pop-window appears either thru +ve testing or –Ve testing of the application )

I. Pop-Up window ( Manual )

 Put tool in Recording mode

 open the AUT ( say flight Application )
 Enter User name ( kanakadri )
 *Click on OK ( wontedly for getting an error) : see the relevant script and copy that line only.
 You will get a “pop-up” window saying with some message
 Enter OK on that pop-up window
 Enter password ( mercury)
 Click OK
 Stop Recoding

------------------------------------------------------
Open a new test , Type Function () , you will get
Function
End Function
Modify the above code as below

Function popup_recovery()

* Copy that line here

End Function
------ Copy it and open a new NotePad and past it .
Save it with .vbs (VBSctipt ) Extention as library file -------

II. Pop-Up window ( thru QTP )

  Put tool under recording mode
 open the AUT ( say same flight Application )
 Enter User name ( kanakadri )
 Click on OK
 *A pop-up will appear , click on OK ( see this script code, which should be removed later)
 Enter password
 Click on OK
 Stop recording

* Remove that code and keep cursor here it self.

Now Actual Recovery scenario for pop-up window starts …..

 open the AUT ( say same flight Application )
 Enter User name ( kanakadri )
 Click on OK
 *the same pop-up will appear , DON’T’ click on it.
 Open tools -> Recovery Scenario Manager
 Select the new scenario ( wizard will appear)
 Click NEXT
 Select trigger event option as pop-up window
 Click NEXT
 With help of HAND Button select * that pop-up’s object (OK) of AUT
 Click NEXT
 Click NEXT to specify the recovery operation
 Select Function Call option
 Browse the library file which u have saved as with .vbs extention in the beginning.
 Click NEXT
 De-select the check box ( of add an other recovery operation )
 Click NEXT
 Choose Post-Recovery operation as Repeat Current Step and Continue.
 Click NEXT
 Give the name and description
 Click NEXT
 Check the check-box of Add Scenario to Current test
 Click FINISH
 Save it as with .qrs ( Quick Recovery Scenario) extension
 Click CLOSE

Run the Test which will Pass the results of course with Warnings ( may ignore it)

=================================================================
Recovery Scenario with Object State
( When the object is disabled )

I. Object State ( Manual )

 Put tool in Recording mode

 open the AUT ( say flight Application )
 Click on Open order icon
 A open order Dialog box will appear
 In which check the Order number check box
 See OK button is Disabled now
 Enter order number (say 9)
 *See the relevant script and copy that line only ie. where u entered 9
 Now OK button will be enabled
 Click on OK
 An order with that number (say 9) will be opened
 Stop recording

------------------------------------------------------
Open a new test , Type Function () , you will get
Function
End Function
Modify the above code as below

Function popup_recovery()

* Copy that line here

End Function
------ Copy it and open a new NotePad and past it .
Save it with .vbs (VBSctipt ) Extention as library file -------

II. Object State ( thru QTP )

 Put tool in Recording mode

 open the AUT ( say flight Application )
 Click on Open order icon
 A open order *Dialog box will appear
  In which check the Order number check box
 DON’T enter order number
 Stop recording

Now Actual Recovery scenario for Object state starts …..

 Open tools -> Recovery Scenario Manager
 Select the new scenario ( wizard will appear)
 Click NEXT
 Select trigger event option as Object state
 Click NEXT
 With help of HAND Button select * that disabled object (OK) in the *Dialog box of AUT
 Click NEXT
 Set object properties and values
 Click on Add/Remove button
 Edit properties window will appear
i. Check property name as Enabled and value as false
ii. Check property name as Text and value as OK
iii. Check property name as window Id and value as 1
 Click on OK
 Click NEXT to specify the recovery operation
 Select Function Call option
 Browse the library file which u have saved as with .vbs extention in the beginning.
 Click NEXT
 De-select the check box ( of add an other recovery operation )
 Click NEXT
 Choose Post-Recovery operation as Repeat Current Step and Continue.
 Click NEXT
 Give the name and description
 Click NEXT
 Check the check-box of Add Scenario to Current test
 Click FINISH
 Save it as with .qrs ( Quick Recovery Scenario) extension
 Click CLOSE

Run the Test which will Pass the results of course with Warnings ( may ignore it)

=================================================================
Recovery Scenario with Test Run Error

During execution one step may not execute properly , QTP will ignore it run next step on words .
For that we just need to call an empty function ().

Version 1.0 is released and came for testing V1.0

Chennai
1. Open the version 1.0 application Hyderabad
2. put tool in recording mode Delhi
3. select all the cities names, so that *script will be generated.
4. Stop recoding

After some time Version 2.0 is released with some changes V2.0
1. Open the version 2.0 application
2. Use the *same generated script only Chennai
But when u run this program, Delhi
It execute fist city name (Chennai)
When it comes to second city name (Hyderabad)
Test will Stops and FAIL.
Though its missed , in order to continue the execution from next step onwards
We just call an empty function which is stored in a library file
3. Keep the cursor where the city name seems to be missed
4. Activate tool menu item Tools
5. Open recovery scenario manager wizard
6. select trigger event as Test Run error
7. choose the error type from drop-down box as Item in list or menu not fund
8. Click NEXT
9. Click NEXT to specify the recovery operation
10. select operation type as Function call
11. Click NEXT
12. choose library file path where an empty function was stored
13. Click NEXT
14. De-select check box ( of add an other recovery scenario )
15. Click NEXT
16. Select post-recovery as Proceed to Next Step
17. Give name and description for this scenario
18. Click NEXT
19. Select add scenario to current test
20. click on Finish
 21. Save it with .qrs extension

Run the Test

When you Run it, it execute normally till it finds an error, when it found an error, It stops a while
(means calling an empty function ) and continue.

The test will pass with warning (which u can ignore )

Recovery Scenario with Application error

This error may comes when the application is missed.

Environment Variables :-
The variables that are commonly used across the environment in many tests by different resources are know as
Environment Variables.

There are Two types of Environment variables

1. Built-in-variables 2. User Defined Variables

1.Built-in-variables :- These variables will be by default available in every test and can be directly used
in any test with help of following syntax.
Syntax : Environment.value(“Built-in-variables”)
Example :
var=environment.Value("OS") : to display the Operating System
msgbox var

2. User Defined Variables :- The variables which are required commonly in number of test apart from
the Built-in-variables need to be created by the user which are known as User Defined Variables .
User Defined Variables are created in environment file, any body in that
environment can Associate this file and use the variables in it.

There are Two types of User Defined Variables

1. Internal User Defined Variables :- which are used in the same file
Example :
 Open the Cal application
 Put the tool under recording mode
 Capture the objects properties of Cal application to Object Repository
 Stop recording
Declaring the Environment Variables
 Activate the menu item Test
 Go to Settings
 Select the Environment tab
 Select variable type as User-defined
 Click on New button
 Add new Environment window will appear
 Give the details of Name and value ( type will be Internal )
 Click on OK
 Again Click on New button to add one more variable
 Add new Environment window will appear
 Give the details of Name and value ( type will be Internal )
 Click on OK
  Click on Apply
 Click on OK
 If you want you can Export these data to a a file with .xml extention file in the
Environment folder
Associating the Environment Variables ( by parameterizing )
 Develop the script in test pane as below
' Setting the declered environment value (a ) to value1 edit button
VbWindow("Form1").VbEdit("val1").Set environment.Value("a")
' Setting the declered environment value (b ) to value2 edit button
VbWindow("Form1").VbEdit("val2").Set environment.Value("b")
' clicking on ADD button
VbWindow("Form1").VbButton("ADD").Click
 Run the test
 Analyze the results

2. External User Defined Variables :- which are Imported from other file

Example :
 Open the Cal application
 Put the tool under recording mode
 Capture the objects properties of Cal application to Object Repository
 Stop recording
Declaring the Environment Variables
 Activate the menu item Test
 Go to Settings
 Select the Environment tab
 Select variable type as User-defined
 Select the check box of ‘load variables and values from an external file’
If you want you can make use of Exported data or you can create your own data in a file
with .xml extention file in the Environment folder
 Browse that file
 Click on Apply
 Click on OK
Associating the Environment Variables ( by parameterizing )
 Develop the script in test pane as below
' Setting the declered environment value (a ) to value1 edit button
VbWindow("Form1").VbEdit("val1").Set environment.Value("a")
' Setting the declered environment value (b ) to value2 edit button
VbWindow("Form1").VbEdit("val2").Set environment.Value("b")
' clicking on ADD button
VbWindow("Form1").VbButton("ADD").Click

 Run the test

 Analyze the results
 Automation Frame Work

Frame Work : Frame work is a Generic work designed by an expert and followed by many people to perfom a
particular task in an effective , efficient and optimized way.

Types of Frame work:-

1. Linear / Sequential Frame work

2. Modular frame work
3. Keyword Driven frame work
4. Hybrid frame work

1. Linear Frame work: This is a general and old frame work that can be used by many people.
Steps to follow ….
a). Generate the Basic Test
b). Enhance the test
c). Debug the test
d). Execute the test
e). Analyze the result

AUT
Example : Login
………
Tasks : Login ……..
Insert order Insert order
Open existing order ………
Logout ……..
Note : Here all the tasks are put together in one test pane and done the job
Open order
………
 Put the tool under recoding mode
………
 Open flight application
Logout
 Login with username and password
 Click on OK
 Insert an order by keying all the required info therein
 Click on insert order button
 That order will be inserted successfully. After inserting the order
 Open existing order by clicking on open folder icon
  A open order window will appear, check the order number check box
 Input the existing order number ( say 9)
 Click on OK
 The order will open, if necessary you may update / delete the opened order
 Logout will be done by going to menu bar of the application and select file , select
exit .
 The application will close
 Stop recording
 Run the test
 Analyze the result

2. Modular Frame work : This is also a general frame work that can be used by some people.
Steps to follow ….
a). Prepare the Individual Components for different tasks
b). Make the require compensates are as Re-Usable
c). Prepare the desired Driver based on end-to-end scenario
d). Execute the Driver
e). Analyze the results

! A script file can be called as a Driver

! Test : means a script file
! Auction : Is a set of instructions to perform a task
! Component can be called as an Action
!! Ways of action :
- Prepare complete action and Split it to each action or
- Prepare a single action and Insert each actions into it.
* One action can be spited into Two actions a time only and so on.

Example :

Tasks : Login
Insert order
Open existing order
Logout
Note 1 : After preparing complete action, split it into different individual actions and call them in a driver.
Note 2 : Other words in this frame work, we are calling the action/s ( Ex. Call login )

AUT Driver
Login login insert open logout
……… Call login
……..
Insert order Login Insert order Open order Logout Call insert
……… ……… …….. ……. ………
…….. ……… …… …… ……… Call open
Open order
……… Call logout
………
Logout Components
 Put the tool under recoding mode
 Open flight application
 Login with username and password
 Click on OK
 Insert Order by keying all the required info therein
 Click on insert order button
 That order will be inserted successfully. After inserting the order
 Open order by clicking on open folder icon
 A open order window will appear, check the order number check box
 Input the existing order number ( say 9)
 Click on OK
 The order will open, if necessary you may update / delete the opened order
 Logout will be done by closing the window/application
 Stop recording
 Save the Script (say fl_application , No extention is required)
 Split the script into 4 tasks ( login, insert_order, open_order and logout )
 Keep the cursor at the beginning of 1st line of 2nd part ( i.e starting of insert order line)
 Go to menu bar, click on Step , select Split Action
 The split action window will appear
 choose action type as independent of each other, give the 1st action name ( say
login) and leave the 2nd action name as it is ( because, again we are going to split the
2nd part )
 Click OK
 Save the changes. Next,

 Keep the cursor at the beginning of 1st line of existing 2nd part ( i.e starting of insert
order line)
 Go to menu bar, click on Step , select Split Action
 The split action window will appear
 choose action type as independent of each other, give the 1st action name ( say
insert_order) and leave the 2nd action name as it is ( because, again we are going to
split the 2nd part )
 Click OK
 Save the changes. Next,

 Keep the cursor at the beginning of 1st line of existing 2nd part ( i.e starting of open
order line)
 Go to menu bar, click on Step , select Split Action
 The split action window will appear
 choose action type as independent of each other, give the 1st action name ( say
open_order) and give the 2nd action name as logout ( because, its end of splits )
 Click OK
 Save the changes.
 So, we have splited all 4 tasks/actions successfully.
Now make them as re-usable components
 Open the just created action i.e login from drop-down box on the tool
 Go to menu bar , click on Step , select Action Properties
 Action properties window will appear
 Select General tab
  Check the Reusable action check box
 Click on OK
 Do the same for other actions too i.e insert_order, open_order and logout. Next
 Open new Test
 Re-name the action as Driver , Go to menu bar , click on Step , select Action
Properties. Action properties window will appear ,Select General tab , change the
action name as Driver.
 Click on OK
Here we can call any or all those re-usable actions
 Go to menu bar, click on Insert, select Call to Existing Action
 Select action window will appear ,

 Browse the saved application ( i.e fl_application )

 Select the one reusable action ( say login)
 Select the Location option as After the current step
 Click on OK
 An existing action related to that login action will be added to this test
 Do the same for other actions too i.e insert_order, open_order and logout.
 Now the Driver script is ready for login, inserting the order , open the order and logout.
 Run the test
 Analyze the results.
Note : in Driver test we can call any existing actions as we wish.

Type of actions : There are two types of actions

i). Normal actions
ii). Re-usable actions
 Re-usable actions called in the other test are called External Actions
 External actions are Non-Editable

Batch Testing :
Batch testing is a process of executing a group of tests at a time.
To do the same QTP has provided a separate tool by name “Test Batch Runner” and we have to
configure the tool settings as below…..
QTP -> Tools -> Options -> Run -> Check Allow other mercury products to run tests and components.

 Add the desired testAdd different script files each at a time to it

 Save it as .mtb( Mercury Test Batch file ) extension
 Whenever require open the batch file , execute and analyze the results.

* We go for batch testing when we do Regration testing.

Regration testing : Testing the functionalities of function and all its related functionalities at a time is called
Regration testing. Or its is the process of executing number of test a time.
Example : ??

3. Keyword Driven frame work: This is also a general frame work that can be used by most of people.
Steps to follow ….

1.First of all create the folder stricture as follows short form : TRL RET L

ProjectName_Automation

Test Data Associating Required files only

Script
Repository …………….
…………….
…… ………
Library ……………..

Recovery
L1
L2
Environment L4

Test
Test
Key word
Log

2. Create the required Test Data files and save them in the corresponding folder ( Test Data folder).
3. Create the required Shared Repository files and save them in corresponding folder ( Repository folder)
4. Create the required Library files and save them in corresponding folder ( Library folder)
5. Create the required Recovery files and save them in corresponding folder ( Recovery folder)
6. Create the required Environment files and save them in corresponding folder ( Environment folder)
7. Open the Main Test and associate all the Required resources like Test Data files, Repository files,
library files, recovery files and environment files.
8. Develop the script in such way that it executes based on the keyword given in the data table.
9. Save the Test in the corresponding folder ( Test folder)
10. Whenever require Open it and execute and analyze the results.
Example :

Tasks : Login
Insert order
Open existing order
Logout
Note : Here, after preparing complete action, split it into different individual Functions and call them in a Test.
Note 2 : Other words in this frame work, we are calling the Function/s ( Ex. Call login() )

AUT Test
Login login() insert() open() logout() Case “l1”
……… login()
…….. Case “l2”
Insert order Login Insert order Open order Logout insert()
……… ……… …….. ……. ……… Case “l3”
…….. ……… …… …… ……… open()
Open order Case “l4”
……… logout()
………
Logout Functions stored in Library folder

 Create a folder by any name like ProjectName_Automation ( say fl_automation)

 Create all those 7 sub-folders in it ( ie. Test Data, Repository, Library, Recovery,
Environment, Test and Log)
 Open the tool
 Open the flight application to do the following tasks
i. Login
ii. Insert order
iii. Open order
iv. Logout

So, for above 4 tasks, we need to create 4 functions and store them in a library life
under library folder. For that …
 Open a new notepad and write down the below script in it
Function login()
* Here, Past the login code from Test script
End function
Function insert_order()
* Here, Past the insert_order code from Test script
End function
Function open_order()
* Here, Past the open_order code from Test script
End function
Function logout()
* Here, Past the logout code from Test script
End function
Recording properties into object repository
 Put the tool under recoding mode
 Activate flight application
 Login with username and password
 Click on OK
 Insert Order by keying all the required info therein
 Click on insert order button
 That order will be inserted successfully. After inserting the order
 Open order by clicking on open folder icon
 A open order window will appear, check the order number check box
 Input the existing order number ( say 9)
 Click on OK
 The order will open, if necessary you may update / delete the opened order
 Logout will be done by closing the window/application
 Stop recording
Creating Shared Repository
 Open Object Repository, where in which you can see all the properties of objects
 Click on Export
 Browse to Repository folder and Save it with .tsr ( Test Script Repository )
extension.
 Click on OK
Copying and Pasting the corresponding scripts to library file from a Test Script
 Copy only login script from Test Script and past into opened notepad under
Function login() ……*…. End Function.
 Do the same for other functions too (i.e insert_order, open_order, and logout )
 Now Save that file with .vbs extension under Library folder
 With this your currently open test area will be empty.
 Now , open a new Test
 Associate the required files to new test (into Repository ) as below
Menu -> Test -> settings -> Resource Tab -> select object repository type as Shared
 Browse the saved repository file from Repository folder
 Click on Apply and OK
 In the same manner associate the required library files to new test
 Associate the required files to new test (into Repository ) as below
Menu -> Test -> settings -> Resource Tab -> click on + (add) button
 Browse the saved library file from Library folder
 Click on Apply and OK
Creating data in data table
 Activate data table of the test
 Rename the 1st column name as “keys” ( by double clicking on it and type keys).
 Enter data like l1,l2, and l3 for each row in the table ( specifying the key value in the
script so as to pick-up the relevant keyword from the data table ).
 Now Develop / write the script in test area in such way that it uses some or all
resources and execute based on key values given in the data table.
 For example : to login- insert order – open order and logout
var =datatable("keys", 1) :pick-up 1st value in data table and
assigned to var
Select Case var
Case "l1"
login()
 Case "l2"
open()

Case "l4"
logout()
End Select

 Open the flight application

 Run the test
 Analyze the results.

Note : You can invoke an application thru this function

Invokeapplication “path” : path = complete location of the file

Note : System.run “path” is also can be used for invoke the application

4. Hybrid Frame work : Hybrid frame work is a mixer of two or more frame works.

* Library file is a collection of one or more functions

Methods
Method : Method is some thing which is used by QTP to Perform any action is called a method.
Example : Click, set …. Etc

1. Capture Bit Map() : This method used for capturing a snap shot of an object during Execution and stores
in a desired location. When you want to send Defect to the developer, this captured bitmap
can also be sent in order to understand the error/defect easily.

Syntax : Object Hierarchy. captureBitmap “path of the location with a file name .bmp extension”

Example: Window("Flight Applicaiton").Dialog("Open Order").WinButton("OK").captureBitmap

(“d:\fa1.bmp”)
: captured snapshot / bit map will be stored in “D” drive with file name as fa1.bmp

 Put the tool under recording mode

 Open the flight application
 Enter username an password
  Click on OK
 After logged in , try to open an existing order by clicking on open order.
 Open order window will appears
Assume that you find some errors on that window and want to capture bitmap for that window
 Stop recording
 At the end of present script ( or next line of the error’s window script) insert the
capture method (say OH. CaptureBitmap "d:\bop.bmp" )
 Run the test
 After Test is executed successfully and that bitmap/ snap shot will be stored in the
location d:\bop.bmp
 That you can send as attachment to the developer along with defect reporting.

2. Exist () : The main purpose of this method is to check whether the object/ window is existing or NOT.
Exist method is used for checking the object’s existence. If the object is existing then it
will return TRUE and continue the execution. Otherwise , it will wait till the object exists or upto the
maximum time. Meanwhile at any point of time the object exists it will return TRUE and continue
its execution, otherwise, after the maximum time is finished it will return FALSE and continue its
execution.
* Exist method will make the QTP to wait till the default time Plus extra time (if any)

Syntax : Object Hierarchy. Exists [(Extra time in seconds]

Exaple : var = window(“flight application”).Exists (10)

Msgbox var : gives True or false
 Open the flight application and put tool in recoding mode
 Open the order by clicking on open order, it will displays the open order window
 Enter an existing order number and click on Ok. That order will be opened.
 Stop recording.
Now to check whether that window is available or not
 put this code before that window’s script
var=Window("Flight Reservation").Dialog("Open Order").Exist(10)
msgbox var : gives True or false
 If True it will continue execution else stops

3. WaitProperty () : This method is used for make the tool to wait based on the object property’s value or
up to maximum time .

Syntax : Object Hierarchy. Waitproperty “propertyName”, Property value, extra time in milliseconds

Example :
 Open the flight application and put tool in recoding mode
 Open the order by clicking on open order, it will displays the open order window
 Enter an existing order number and click on Ok. That order will be opened.
 Stop recording.
Now , if you want to wait the tool even after clicking on OK button
 take the property name ( as text),value( as OK) from object repository and put extra
time in milliseconds.
For example : OH.WaitProperty "text", OK,10000

 And put the above code after the OK button clicked statement in the script
  Run the test
 Analyze the results

4. Wait () : This method is used for making the tool to wait till the maximum time is elapsed

Syntax : Object Hierarchy. Wait (Time in seconds)

Example :

 Open the flight application and put tool in recoding mode

 Open the order by clicking on open order, it will displays the open order window
 Enter an existing order number and click on Ok. That order will be opened.
 Stop recording.
Now , if you want to wait the tool at any point of time
 Put the code any where in between the script
For example : wait (10)
 Run the test
 Analyze the results

Simple and Regular used Methods

1. Click Method : Which is used for clicking on a specified object

Syntax : Object Hierarchy. Click [ x, y [button]]

0 for Left Click
1 for Right Click
2 for Middle Click

Example : VbWindow(“Emp”).VbButton(Submit).Click Submit

2. dbl Click : which is used for double clicking on a specified object

Syntax : Object Hierarchy. Click [ x, y [button]]

0 for Left Click
1 for Right Click
2 for Middle Click
Ename :
Example : VbWindow(“Emp”).VbButton(Submit).dblClick dblClick

3. Set Method : Set method is used mainly to perform on 3 objects i.e Mstatus: Married
a). Edit box
b). Check Box Emp Un Married
c). Radio Button Location:
Hyderabad
a) Edit Box : Set method is used for entering any value into an edit box
Syntax : Object Hierarchy. Set “value” Delhi

Chennai
 Example :VbWindow(“Emp”).VbEdit(Ename).Set “ak”

b) Check Box : Set method is used for Selecting/de-selecting the check box
Syntax : Object Hierarchy. Set “ON/OFF”

Example :VbWindow(“Emp”).VbCheckBox(Mstatus).Set “ON”

c) Radio Button : Set method is used for selecting a Radio Button in a group
Syntax : Object Hierarchy. Set
Example :VbWindow(“Emp”).VbRadioButton(Location).Set

4. Select Method: Which is used for selecting an item in a ComboBox or List

Syntax : Object Hierarchy. Select “item”

Example :

5. Set Secure Method: Which is used for setting the encrypted data into the edit box.
* Encrypted string can be generated with help of a tool “password encoder”.
Navigation for password encoder : Start -> Programs -> QTP -> Tools -> Password encoder

Syntax : Object Hierarchy. SetSecure “encrypted String”

Example : *********

6. Activate Method: Which is used for activating a window or a dialog box

Syntax : Object Hierarchy. Activate

Example :

7. Close Method: Which is used for Closing a window or browser

Syntax : Object Hierarchy. Close
X
Example : XXX

8. Type Method: Which is used for performing any kind of keyboard related operations.
Syntax : Object Hierarchy. Type keyvalue

Example : ggggg

Important Methods

RO ( Runtime Object ): Runtime object is the original object that was presented in the application (AUT).
 TO ( Test Object ) : Test object the Reference of original object stored in the object repository and
used for identifying the original object in the AUT during the execution.

1. Get RO Property : This method is used for getting the Runtime Object property’s value

Syntax : var = Object Hierarchy. getROproperty(“property name”)

Text
Width etc…..

Note : By using getROproperty method we can avoid the standard checkpoint, because, the check points will
create an “internal file” which is a over burdon the execution and takes the memory to store that files.

Example : Develop the script to click on OK button if it exists.

OK

var = VbWindow(“name”).VbButton(“OK”).Exist : to find the window existence

If ( var= ture ) then
var1 = VbWindow(“name”).VbButton(“OK”).getROproperty(“enabled”)
if(var1= true) then
VbWindow(“name”).VbButton(“OK”).Click :*
else
Reporter.ReporterEvent 3, “myreporter”, “OK Button is disabled” : 3=worning
end if

Else
Reporter.ReporterEvent 3, “myreporter”, “OK Button doesn’t existing” : 3=worning
End if

* This is the only script that we generated by tool and remaining thing is the enhancement to that script
done manually by test engineer.

2. Get TO Property : This method is used for getting the Test Object’s properties value.

Syntax : var = Object Hierarchy. getTOproperty(“property name”)

Text
Width etc…..
Example :
var = VbWindow(“form1”).VbButton(“ADD”).GetTOproperty(“Text”)

Note : The properties that are learnt during the learning time are called Test Object Properties
Test Object Property = Properties presented in object Repository
+
 Properties presented in secret place (smart brain ) if any.

Test object is a Reference of runtime objects which are stored in Object Repository and in
smart brain (if smart brain is enabled).

 Whatever all the Properties Learnt during the learning time are called Test Object Properties.

When with help of Get RO properties its self we can get all the properties in an AUT ? Why Get RO and
Get TO properties?
Get RO property will be used to capture the all the properties’ present values of objects
in AUT during the Learning Time
where as Get TO property will be used to capture the all the properties’ present value of
objects in AUT during the execution time.

For example : In a application OK button is disabled by default ( This RO property) but when
entering some data therein the OK button will be enabled( This TO property).

3. Set TO Property : This method is used for Setting the Test Object’s properties value temporarily
during the execution.

Syntax : var = Object Hierarchy. SetTOproperty “property name”, “Property value”

Text OK
Width etc….. Start …..

Example : for clicking on same button for Start-Stop-Start. Assume that initially the button is named with Start
and want to be Stop when its clicked. And again if its clicked, it should be Start.

1St rename the button name as B1 in Object repository so as to don’t effect other buttons.
VbWindow(“form1”).VbButton(“B1”).Click
VbWindow(“form1”).VbButton(“B1”).SetTOproperty “text”, “stop”
VbWindow(“form1”).VbButton(“B1”).Click
VbWindow(“form1”).VbButton(“B1”).SetTOproperty “Text”, “Start”

Simple VB Script functions used for Calculation and Comparison :-

CSTR : It is used for converting a value into String

Syntax : CSTR(var1) = CSTR(var2)

CINT : It is used for converting a value into Integer

Syntax : CINT(var1) = CINT(var2)

CDBL : It is used for converting a value into Decimal value

CBOOL: It is used for converting a value into Boolean value

LTRIM: It is used for Trimming the Left side spaces

RTRIM: It is used for Trimming the Right side spaces
TRIM : It is used for Trimming the Both sides spaces

LEFT : It is used for Getting the Left substring

Syntax : var = Left(string, No. of characters )
RIGHT: It is used for Getting the Right substring
Syntax : var = Left(string, No. of characters )
MID : It is used for Getting the Middle substring
Syntax : var = Left(string, starting character number, No. of characters )

LCASE: It is used for converting a string to lowercase

UCASE: It is used for converting a string to uppercase
ROUND: It is used for Rounding a value to its nearest integer.

Script :

Action : Action is defined as a set of instructions to perform a specific task.

Test: Test is defined as one or more script files

Data Table Methods

Data Tables are two types 1. Design Time data table

2. Run Time Data Table
Data table methods are used for performing the operations on the Runtime Data table during the execution.

 All Data Table Methods are used in Runtime data table ONLY i.e we can’t do any thing with Design
time data table.
 For every action a corresponding Sheet will be created in both data tables but only one Global sheet
for each data table.
 In order to maintain test data clearly, simply and user friendly we Maintain each sheet for each
corresponding action.
 Sheet can be inserted along with action only.
 If you want to import data to Runtime data table , you need to add sheet manually in the same.
Local Sheet : In local sheet the focus will be on 1st row itself only
Global sheet : In global sheet for every iteration the focus need to change on next row and so on.

Methods :-

1. AddSheet() :- It is used for adding an extra sheet to the Run Time data table
Syntax : Datatable.AddSheet “Sheet Name”

2. DeleteSheet() :- It is used for deleting a specified sheet from the Run Time data table
Syntax : Datatable.Deletesheet “sheet name”

3. Import() :- It is used for importing the data presented in all the sheets in a xl file to the RTDT
Syntax : Datatable.import “path of the .xls file”
4. ImportSheet() :- It is used for importing the data presented in a specified sheet in the xl file to the
specified sheet in Run Time Data table.
Syntax : datatable.ImportSheet “path of the xl file”, Source sheet ID, Destination Sheet ID
5. Export() :- It is used for exporting the data presented in Run time data table to a specified laction.
 Syntax : datatable.Export “path of the location with a file name .xls extension”
6. ExprotSheet() :- It is used for exporting the data presented in a specified sheet in Run time data table
to a specified location
Syntax : datatable.ExportSheet “Path of the location with a file name .xls extension” , Sheet ID to be exported
7. SetCurrentRow() :- It is used for making the QTP focus on a specified row
Syntax : datatable.SetCurrentRow(Row number)
8. SetNextRow() :- It is used for making the QTP focus on the Next row of Currently focused row
Syntax : datatable.SetNextRow
9. SetPreRow() :- It is used for making the QTP focus on the previous row of the currently focused row.
When this method executes, the cursor will go to the last row of the table and moves
upward one by one row till it reaches to 1st row in the table.
Syntax : datatable.SetPrevRow
10. GetSheet() :- It is used for making the QTP focused on a specified sheet.
Syntax : datatable.GetSheet( Sheet Id)
11. Value() :- It is used for getting a value from a specified sheet, specified column and currently focused row.
Syntax: datatable.value(“column name”,sheet Id)

12. GetRowCount() :- It is used for getting the row count of the global sheet by default. If at all one wants
the row count of a specified sheet , then, First he needs to focus on the sheet and
then get the row count.
Syntax 1 : variable=datatable.GetRowCount
Syntax 2 : variable= datatable.GetSheet.GetRowCount

Example : For add data sheet, import data to datasheet, ADD the two values, pass the result to data sheet, export
the data sheet to log folder.

 Open the calculator application

First we need to Capture all objects properties into Object Repository
 Open the QTP
 Go to Tools
 Select opting Object Repository. An object repository will be opend
 Click on ‘Add Objects’ button, Point to calculator application main window
 ‘Object selection – Add to repository’ window will appear
 Click on OK
 Select option as ‘selected object and all its direct children’ on newly opened window
 Click on OK
 Click on OK
So that we have captured all the objects properties to Object Repository.
 Write the script ( copied from test pane )

' Create a sheet in Run time data table by name Ak

datatable.AddSheet"Ak"
' Import the data from TestData folder ( which we have created while design the Frame work)
' path, 1= global sheet in RTDT and 3= Just created Sheet i.e AK in RTDT
datatable.ImportSheet"C:\Documents and Settings\AK\Desktop\fl_application\TestData\td1.xls",1,3
' counting the number of rows and assigning to a variable
n=datatable.GetSheet(3).GetRowCount
'taking FOR loop to check with all the rows data
For i=1 to n
' focusing to 1st row
datatable.SetCurrentRow(i)
 ' parameterizing val1 and val2
' 3= Ak sheet in RTDT
VbWindow("Form1").VbEdit("val1").Set Datatable("val1",3)
VbWindow("Form1").VbEdit("val2").Set Datatable("val2",3)
VbWindow("Form1").VbButton("ADD").Click
' assigning expected value of 3 sheet in RTDT
expval = datatable.Value("ev",3)
' capturing actual value in result field of AUT
actval = vbwindow("Form1").VbEdit("res").GetROProperty("text")
' comparing the expected value and actual value
If (expval = actval ) then
' Passing the result to sheet # 3 in res column as Pass
datatable("res",3) = "Pass"
else
' Passing the result to sheet # 3 in res column as Fail
datatable("res",3) = "Fail"
End If
Next
' Exporting the result to Log folder
' This is called creating Log files
datatable.ExportSheet "C:\Documents and Settings\AK\Desktop\fl_application\TestData\td2.xls",3
' Deleting the added data sheet
datatable.DeleteSheet "Ak"

 Run
 Analyze the result

Data Base Connections

Test data may be in Database, so that we should connect our test to database and retrieve the data
and use the same in test.

We should know 3 things while we dealing with database connections viz..

1. How to Connect 2. How to Establish connection 3. How to Retrieve and use the data

 For connection , we need to provide two things

1. Driver / Provider : A third party software used for establishing the connection between front end
and back end of the application.

2. Location : Location of database

Record Set : It is a temporarily location where we can store the retrieve data from data base at time.
From that temporarily location we can use the data one by one or as per requirement in our
testing.
Connection : Connects the application and database.

* We need to create Object Instances for both Record Set and Connection.
Example : For example, test data is stored as below, do write the database connection script.
Testdata.mdb

v1 v2 res
10 20 30
30 30 60
30 20 50
90 90 180
2 8 10

For MSACCESS :

‘ Dimensioning connection (con) and recordset (rs)

Dim con, rs
‘Creating object instanced for both above con and rs
‘ adodb = ActiveX Data Object Database
Set con = CreateObject (“adodb.connection”)
Set rs = CreateObject(“adodb.recordset”) These two lines never changed
Establishing
the Connection ‘ Assigning the connection with 3rd party provider i.e with microsoft
con.provider = “Microsoft.jet.oledb.4.0”
‘ Opening the database by specifying the location *
con.open “d:/automation/testdat.mdb”

‘Retrieving the data from data table

Retrieving the data rs.open “select * from info”,con

‘ by using the retrieved data , checking all the rows

‘eof : eng of file
‘ not = if the record is not end of file then go into the loop
‘ else come out from the loop
Do while not rs.eof
‘ inserting the retrived data (v1) into val1 edit field
Vbwindow(“form1”).vbEdit(“val1”).set rs.field(“v1”)
Using the Data ‘ inserting the retrived data (v2) into val2 edit field
Vbwindow(“form1”).vbEdit(“val2”).set rs.field(“v2”)
‘ clicking on ADD button
Vbwindow(“form1”).vbButton(“ADD”).click
‘ changing the focus to next row
rs.moveNext
‘ continuing the loop till eof
Loop

=============================
* For Oracle and SQL we will write both Provider name and Connection in one line and rest is same.

For Oracle
con.open “provider=oraoledb.1;server=locahost;uid=userID;pwd=password;database=database name”

For SQL
con.open “provider=sqloledb.1;server=locahost;uid=userID;pwd=password;database=database name”

Advanced Topics

1. Regular Expressions :-
During execution some times QTP may not identify the objects due to the regular
changes in its properties values. To over come this situation one need to replace the
corresponding Constant value in the object repository with a suitable regular
expressions.
Example : To send number of orders thru fax

 Open the flight application

 Put the tool under recording mode
 Open an existing order by clicking on open order icon
 Activate the menu item file
 Select the option Fax Order
 Give dummy fax number (say 999-999-9999)
 Click on Send button
 Fax will be sent as if its sent.
 Stop recording
Now if you want to send number of orders thru FAX
 Open the data table
 Change the 1st column name as ‘order_no’
 Give the order numbers you want to send fax ( say 8,3,1)
Now change the edit box script where you enter order id in such way that QTP should enter
order ids from data table.
' this statment where recorded while trying to open order number 9
Window("Flight Reservation").Dialog("Open Order").WinEdit("Edit").Set "9"
' update above statement only in the main test script as below
' setting the datatable values into edit field of open order
' order_no is the column name of data table
' 1= global sheet in datatable
Window("Flight Reservation").Dialog("Open Order").WinEdit("Edit").Set datatable("order_no",1)

 Open the object repository

 Select the Fax order No. in object hierarchy
 Select the Text property
 Click on Constant option value button
  Constant value option window will appear
 ( To search all the files, we use *.* ) in the same way
 Change the value name with .* extension ( say Fax Order No.*)
 Select the checkbox Regular Expression
 Click on OK
 Click on No button (optional)
 Click on OK
 Run the test
 Analyze the results

2. Input & Output Parameters :-

Input parameter is a concept provided by QTP which is used for Passing some value
into the action and getting some value from the action while calling that action.
One has to declare the desired number of input and output parameters at the
action that is about to be called in order to pass and get the value.

Function :- is used for Passing and Getting value from a function.

 We need to Return the value to the function name itself.
 Function has a limitation that we can catch or get only one value at time

Example :
Function file
Function add(a,b) : function name is add
Total = a + b : adding to values to Total
add = Total : Retuning the result to the function name it self
End function

Main Test file

var = add(10,20) : passing value to function

Action :- is used to pass Two values and return One value

Example :
 Open the cal application
 Add the cal application’s object properties to Object Repository
 Activate menu item Step
 Select the option Action properties
 Select Parameters tab
 Declare the input parameters values by clicking (+) add button
 Give the name (a) , Type ( number) and some default number
 Similarly Give the name (b) , Type ( number) and some default number
 Declare the output parameters by clicking (+) add button
 Give the name (a) and Type ( number)
 Click on OK
 Write the script as below
' setting the input parameter to val1
VbWindow("Form1").VbEdit("val1").Set parameter("a")
' setting the input parameter to val2
 VbWindow("Form1").VbEdit("val2").Set parameter("b")
VbWindow("Form1").VbButton("ADD").Click
' getting the value of Result and passing to var1
var1=vbwindow("Form1").VbEdit("res").GetROProperty("text")
' passing that var1 to Output parameter c
parameter("c")=var1
Make this test as re-usable
 Activate menu item Step
 Select the option Action properties
 Select the check box Reusable action
 Click on OK
 Save it say (myTest) ( no extension is required)
 Open the new test
Call that saved re-usable action

 Activate menu item Insert

 Select the option Call to Existing action
 Browse that saved test (myTest)
 Click on OK
An external action will be added to current test
 select the action1 from actions list
 now test pane will have the following code
RunAction "Action1 [myTest]", oneIteration
Replace the above code as below
' oneIteration = one time it will execute
' 100 = passing this value into val1 thru input parameter (a)
' 200 = passing this value into val2 thru input parameter (b)
' r1= getting the output value by outputparameter ( c)
RunAction "Action1 [myTest]", oneIteration,100,200,r1
msgbox r1

 run the test

 Analyze the results
Note : RunAction "Action1 [myTest]", oneIteration, , ,r1 : used to enter the default values into val1 and val2

3. Virtual Object Configuration :-

Virtual object configuration is a process of making the QTP tool to Treat an user
defined object or a specific area as a specific object.
 Whenever QTP is not recognizing the object, then we Force QTP to
recognize that object as a specific object
 Making the QTP to understand a button on the screen.

** Once we created virtual object , it will be available to All Tests except we delete it.
Example :
 Open the virtual object application ( a window with colorbutton shape)
 Activate menu item , select Virtual Objects option
 Select the option New virtual Object
 Virtual Object wizard will appear, click on Next
 Select the standard class that nearly match to your object ( say button )
 Click Next
 Mark the object on the AUT screen, Height and width will be captured
  Click Next
 Select the option for parent of the virtual object
 Select Next
 Specify the name (button) and collection name ( Button_collections)
 Click OK
 Put the tool under recoding mode
 Click on the area you selected as button and any area on the screen
 Stop recording
 Analyze the results
Virtual Object Manager : Which is a feature provided by QTP used for creating and maintaining the virtual
objects.

QTP 9.0 - 9.1 - 9.2

QTP 9.0
There are two major Gaps in 8.2 version viz…
1. For creating a shared repository, we need to open a new test every time.
2. There must be connection between Test and shared repository.
Therefore, One test for One shared repository. * One test -> One shared repository.

Where as in 9.0, we can avoid above two gaps and create one or more shared repositories and one local
repository for a Test. No need of connection for test and shared repositories.
* One test -> more shared repositories + one local repository.
*That is the main / major change in 9.0 from 8.2

Understanding of the above Major change :

OR1
Action 1 OR2
I. …….

Action 2
……….

Action 3 OR3
………..
OR4

Test for creating shared repository

OR1 … OR4 : four different
applications Objects Repositories information.

Test
Action 1 +
II. ………….
……….... Local
………… Repository
 As shown in section-I, We can create number of Object Repositories independently for each action.
Say Action 1 is having OR1 (say Calculator Application )and OR3 (say Login Application ) shared repositories
Similarly Action 2 is having OR2(say flight Application ) and OR4 (say mindQcal Application )shared
repositories And Action 3 is having OR1 and OR2 shared repositories

In section –II, we can make use of those shared repositories as per requirement PLUS one local repository
which is created for this test.

Final word : in QTP 9.0 one can associate one or more shared repositories to an Action a part from its local
repository.

Some more changes……in QTP 9.0

 Test menu item is removed as Automation

 Setting options is moved from Test menu item to File menu item
 Quality Center connection option is moved from Tool menu item to File menu item
 Some options related to Resources like Object Repository , Recovery scenarios managers are moved from
Tools menu item to New Menu item Resources.
 New options like Object Repository and Associate Repository are introduced in Resources menu item.
 Object repository is used for creating and managing the shared repositories without having any connection
test.
 A new item Window is introduced in order to manage the windows
 Step menu item is removed and kept under Edit menu item
 A new options by name check Syntax is introduced under the Tools menu item which is used for checking
the syntax errors in the script.
 New features are introduced for the Comments and Un-comments the block of the statements.

Antinomy of QTP 9.0

QTP screen is divided into 7 parts. Viz
1. Test Pane
2. Active Screen
3. Data table As used in 8.2 version
4. Debugger view pane
5. TOOL options
6. Information pane newly added screens
7. Missing Resources Pane

Information Pane :- This pane will shows the Syntax related information during the syntax check.
Missing Resources Pane : While opening a test if at all any associated resources like Repository or Recovery
files or Library files are missing then that information will be clearly shown in
this Missing Resource area.

QTP 9.1
There are 4 changes were made to this 9.1 version from 9.0
  A new Option by name Navigate & Learn is introduced in object repository manager which is
used for learning the objects information in multiple pages or windows continuously by navigating.

 A new option is provided by name Object Repository Comparison Tool in the object repository manager
which is used for compare TWO object repositories.

 The Script Editor is made more user friendly

 QTP 9.1 is compatible with windows vista Operating system and .Net Frame work 2.0 Environment

 From QTP 9.1 onwards the company has announced that they may provide Single License for all the add-
ins also

QTP 9.2
There are 4 changes were made to this 9.2 version from 9.1

 A new feature by name Screen Recorder is introduced. Which is used for recording the complete movie of
execution which can be again viewed back / play back in the result window.

 One can handle the Object Repositories dynamically in QTP9.2 with the help of a new utility object
Repositories Collection.

 Object spy feature is enhanced with a facility that can show the objects information continuously by
pointing the Hand icon on the object

 QTP 9.2 is compatible with the following browsers

o Internet Explorer 7.0
o Mozilla FireFox
o Netscape Navigator 8.1.2

Example: for Dynamically adding ( thru script) the repository

 RepPath = “D:\ak.tsr” : Assigning the path of the file

RepositoriesCollection.RemoveAll() : Removing all repositories, if any.
RepositoriesCollection.Add(RepPath) : Adding the repository
VbWindow(“Cal”).VbEdit(“Val1”).Set “10”: Entering 10 in val1 edit box
VbWindow(“Cal”).VbEdit(“Val2”).Set “20” : Entering 20 in val2 edit box
VbWindow(“Cal”).VbButton(“ADD”).Click : Clicking on ADD button
Position = RepositoriesCollection.Find(RepPath) : Retrieving the position of current repository
Msgbox Position : displaying the position of current repository
RepositoriesCollection.Remove(Position) : Removing the that repository
 Programmatic Description

What is Programmatic Description?

Until now, the scripts that we used had the object in the object repository. QTP learns the objects and using these objects
logical names we continue scripting referencing objects with these logical names. It is also possible to access objects which
are not in the object repository. This method, of scripting by describing the object when the object is not in the object
repository is called as ‘Programmatic Description’ or ‘Descriptive Programming’.

When to use?
This method can be used when the operation has to be performed on all objects which meet the specific criteria. For
example, check all check boxes available in a table.
Also, there may be a case when certain base filter property keeps changing when hence the test fails. In that case, we can
use Programmatic Description to access the object.

How to Use?
There are two ways to Programmatic Description. They are
1. Entering the Programmatic Description directly into Test Statements
2. Create object description
The first method is relatively simpler. But creating a object description and accessing the object is more powerful.

Using Programmatic Description directly in Test Statements

The object to be referenced is described in detail as the test object description, in the test step itself. Specify the
property : = value of the object while addressing an object.

Syntax:
<TestObject>(“<PropertyName1>:= <PropertyValue1>”, …, “<PropertyNameN>:= <PropertyValueN>”)
TestObject: Test Object class.
PropertyName1: Property name which has to be matched.
PropertyValue1: Property value which has to be matched.

Example:
Dialog("text:=Remote Desktop Connection","regexpwndtitle:=Remote Desktop
Connection").WinEdit("nativeclass:=Edit","attached text:=&Computer:").Set “testMachine”
The minimum number of properties which are needed to uniquely identify the object has to be given as the
“PropertyName := PropertyValue” pair.
Also, property value can be a variable which can be the run-time property retrieved with GetROProperty.
For example, the above line can be split into two to retrieve the text value dynamically and that variable can be
substituted in the place of property value.
1. RemoteMachineName = Dialog("regexpwndtitle:=Remote Desktop Connection").GetROProperty("text")
2. Dialog("text:=" & RemoteMachineName,"regexpwndtitle:=Remote Desktop
Connection").WinEdit("nativeclass:=Edit","attached text:=&Computer:").Set “testMachine”

RemoteMachineName will get the text property at run-time. This property is used in the next line as the property
value.
For the reason of code readability, the long line of description can be replaced by a variable. In the above example,
Dialog("text:=Remote Desktop Connection","regexpwndtitle:=Remote Desktop Connection") can be replaced by a
variable, say dlgRemoteDskTop and the line of script can be rewritten as,
1. dlgRemoteDskTop = Dialog("text:=Remote Desktop Connection","regexpwndtitle:=Remote Desktop Connection")
2. dlgRemoteDskTop. WinEdit("nativeclass:=Edit","attached text:=&Computer:").Set “testMachine”

Create Object Description

Property Object: Property object is property name and property value pair.
Description Object Collection: Set of property object is called as ‘Description Object Collection’.
In short,
Description Object Collection = {(Property Name1 = Property Value1),
……
……
(Property NameN = Property ValueN)}
Creating Description Object:

A description object has to be first created. Then the object should be described with it properties and property
values in detail. Once a description object has been created, properties can be added, edited and removed. It is
also possible to retrieve the property and value contained in it.

Syntax:
Set <Description_Name> = Description.Create()

Example: This
Dialog("text:=Remote Desktop Connection","regexpwndtitle:=Remote Desktop
Connection").WinEdit("nativeclass:=Edit","attached text:=&Computer:").Set “testMachine” can be re-written using
Description Objects as…
1. Set objDesc = Description.Create()
2. objDesc(“text”).Value = “Remote Desktop Connection"
3. objDesc(“regexpwndtitle”).Value = “Remote Desktop Connection
4. Dialog(objDesc).WinEdit("nativeclass:=Edit","attached text:=&Computer:").Set “testMachine”

Note: Here again, variable can be substituted in the place of property value.

Example:
1. Set objDesc = Description.Create()
2. RemoteMachineName = Dialog("regexpwndtitle:=Remote Desktop Connection").GetROProperty("text")
3. objDesc(“text”).Value = RemoteMachineName
4. objDesc(“regexpwndtitle”).Value = “Remote Desktop Connection
5. Dialog(objDesc).WinEdit("nativeclass:=Edit","attached text:=&Computer:").Set “testMachine”
Retrieving Child Objects
Child objects contained inside a parent object can be retrieved with ChildObject method. First a description of the
child object type to be retrieved should be formed. When this description is sent as a child to the ChildObject, all
the objects which match the specified the criteria are retrieved.

Syntax:
Set <return_Value> = TestObject.ChildObject(<object_Description>)

Note:
The parameter to ChildObject() should be a description object that has been created already. It does not take direct
substitution of descriptive programming (<Property_Name> := <Property_Value>) on the same line of script.

Example:
‘Create a Description object for the parent
Set objOE6Wnd= Description.Create
objOE6Wnd("regexpwndtitle").Value = "Outlook Express"
objOE6Wnd("regexpwndclass").Value = "Outlook Express Browser Class"

‘Create a Description object for the child item

Set chkBox= Description.Create
chkBox("text").Value = "&Always perform this check when starting Outlook Express"

‘Deselect the checkbox

Set childItems = Window(objOE6Wnd).Dialog("text:=Outlook Express").ChildObjects(chkBox)
crt = childItems.Count
childItems(0).Set "OFF"

Programmatic Descriptions for WebElement Object

For web objects which are not identified by QTP, the WebElement object enables in performing methods on them.
This class of object is NOT recorded by QTP, but can be written through programmatic description. This object can
be used on any web object.
Example:
Browser("Mercury Tours").Page("Mercury Tours").WebElement("Name:=UserName", "Index:=0").Click
can be re-written as…
1. set WebObjDesc = Description.Create()
2. WebObjDesc("Name").Value = "UserName"
3. WebObjDesc("Index").Value = "0"
4. Browser("Mercury Tours").Page("Mercury Tours").WebElement(WebObjDesc).Click
 SQL QUERIES
1) Display the details of all employees
SQL>Select * from emp;

2) Display the depart information from department table

SQL>select * from dept;

3) Display the name and job for all the employees

SQL>select ename,job from emp;

4) Display the name and salary for all the employees

SQL>select ename,sal from emp;

5) Display the employee no and totalsalary for all the employees

SQL>select empno,ename,sal,comm, sal+nvl(comm,0) as"total salary" from emp

6) Display the employee name and annual salary for all employees.
SQL>select ename, 12*(sal+nvl(comm,0)) as "annual Sal" from emp

7) Display the names of all the employees who are working in depart number 10.
SQL>select emame from emp where deptno=10;

8) Display the names of all the employees who are working as clerks and a salary > 3000.
SQL>select ename from emp where job='CLERK' and sal>3000;

9) Display the employee number and name who are earning comm.
SQL>select empno,ename from emp where comm is not null;

10) Display the employee number and name who do not earn any comm.
SQL>select empno,ename from emp where comm is null;

11) Display the names of employees who are working as clerks,salesman or analyst and drawing a salary
more than 3000.
SQL>select ename from emp where job='CLERK' OR JOB='SALESMAN' OR JOB='ANALYST' AND SAL>3000;

12) Display the names of the employees who are working in the company for the past 5 years;
SQL>select ename from emp where to_char(sysdate,'YYYY')-to_char(hiredate,'YYYY')>=5;

13) Display the list of employees who have joined the company before
30-JUN-90 or after 31-DEC-90.
a)select ename from emp where hiredate < '30-JUN-1990' or hiredate > '31-DEC-90';
14) Display current Date.
SQL>select sysdate from dual;

15) Display the list of all users in your database(use catalog table).
SQL>select username from all_users;

16) Display the names of all tables from current user;

SQL>select tname from tab;

17) Display the name of the current user.

SQL>show user

18) Display the names of employees working in depart number 10 or 20 or 40 or employees working as
CLERKS,SALESMAN or ANALYST.
SQL>select ename from emp where deptno in(10,20,40) or job in ('CLERKS','SALESMAN','ANALYST');

19) Display the names of employees whose name starts with alaphabet S.
SQL>select ename from emp where ename like 'S%';

20) Display the Employee names for employees whose name ends with alaphabet S.
SQL>select ename from emp where ename like '%S';

21) Display the names of employees whose names have second alphabet A in their names.
SQL>select ename from emp where ename like '_A%';

22) select the names of the employee whose names is exactly five characters in length.
SQL>select ename from emp where length(ename)=5;

23) Display the names of the employee who are not working as MANAGERS.
SQL>select ename from emp where job not in('MANAGER');

24) Display the names of the employee who are not working as SALESMAN OR CLERK OR ANALYST.
SQL>select ename from emp where job not in('SALESMAN','CLERK','ANALYST');

25) Display all rows from emp table.The system should wait after every screen full of informaction.
SQL>set pause on

26) Display the total number of employee working in the company.

SQL>select count(*) from emp;

27) Display the total salary beiging paid to all employees.

SQL>select sum(sal) from emp;

28) Display the maximum salary from emp table.

SQL>select max(sal) from emp;

29) Display the minimum salary from emp table.

SQL>select min(sal) from emp;

30) Display the average salary from emp table.

SQL>select avg(sal) from emp;

31) Display the maximum salary being paid to CLERK.

SQL>select max(sal) from emp where job='CLERK';

32) Display the maximum salary being paid to depart number 20.
SQL>select max(sal) from emp where deptno=20;

33) Display the minimum salary being paid to any SALESMAN.

SQL>select min(sal) from emp where job='SALESMAN';

34) Display the average salary drawn by MANAGERS.

SQL>select avg(sal) from emp where job='MANAGER';

35) Display the total salary drawn by ANALYST working in depart number 40.
SQL>select sum(sal) from emp where job='ANALYST' and deptno=40;

36) Display the names of the employee in order of salary i.e the name of the employee earning lowest
salary should salary appear first.
SQL>select ename from emp order by sal;

37) Display the names of the employee in descending order of salary.

a)select ename from emp order by sal desc;

38) Display the names of the employee in order of employee name.

a)select ename from emp order by ename;

39) Display empno,ename,deptno,sal sort the output first base on name and within name by deptno and
with in deptno by sal.
SQL>select empno,ename,deptno,sal from emp order by

40) Display the name of the employee along with their annual salary(sal*12).The name of the employee
earning highest annual salary should apper first.
SQL>select ename,sal*12 from emp order by sal desc;

41) Display name,salary,hra,pf,da,total salary for each employee. The output should be in the order of total
salary,hra 15% of salary,da 10% of salary,pf 5% salary,total salary will be(salary+hra+da)-pf.
SQL>select ename,sal,sal/100*15 as hra,sal/100*5 as pf,sal/100*10 as
da, sal+sal/100*15+sal/100*10-sal/100*5 as total from emp;

42) Display depart numbers and total number of employees working in each department.
SQL>select deptno,count(deptno)from emp group by deptno;

43) Display the various jobs and total number of employees within each job group.
SQL>select job,count(job)from emp group by job;

44) Display the depart numbers and total salary for each department.
SQL>select deptno,sum(sal) from emp group by deptno;

45) Display the depart numbers and max salary for each department.
SQL>select deptno,max(sal) from emp group by deptno;

46) Display the various jobs and total salary for each job
SQL>select job,sum(sal) from emp group by job;

47) Display the various jobs and total salary for each job
SQL>select job,min(sal) from emp group by job;

48) Display the depart numbers with more than three employees in each dept.
SQL>select deptno,count(deptno) from emp group by deptno having count(*)>3;

49) Display the various jobs along with total salary for each of the jobs
where total salary is greater than 40000.
SQL>select job,sum(sal) from emp group by job having sum(sal)>40000;

50) Display the various jobs along with total number of employees in each
job.The output should contain only those jobs with more than three employees.
SQL>select job,count(empno) from emp group by job having count(job)>3
51) Display the name of the empployee who earns highest salary.
SQL>select ename from emp where sal=(select max(sal) from emp);

52) Display the employee number and name for employee working as clerk and
earning highest salary among clerks.
SQL>select empno,ename from emp where where job='CLERK'
and sal=(select max(sal) from emp where job='CLERK');

53) Display the names of salesman who earns a salary more than the highest
salary of any clerk.
SQL>select ename,sal from emp where job='SALESMAN' and sal>(select
max(sal) from emp where job='CLERK');

54) Display the names of clerks who earn a salary more than the lowest
salary of any salesman.
SQL>select ename from emp where job='CLERK' and sal>(select min(sal)
from emp where job='SALESMAN');

Display the names of employees who earn a salary more than that of
Jones or that of salary grether than that of scott.
SQL>select ename,sal from emp where sal> (select sal from emp where ename='JONES')and sal> (select
sal from emp where ename='SCOTT');

55) Display the names of the employees who earn highest salary in their respective departments.
SQL>select ename,sal,deptno from emp where sal in(select max(sal) from emp group by deptno);

56) Display the names of the employees who earn highest salaries in their respective job groups.
SQL>select ename,sal,job from emp where sal in(select max(sal) from emp group by job)

57) Display the employee names who are working in accounting department.
SQL>select ename from emp where deptno=(select deptno from dept where
dname='ACCOUNTING')

58) Display the employee names who are working in Chicago.

SQL>select ename from emp where deptno=(select deptno from dept where
LOC='CHICAGO')

59) Display the Job groups having total salary greater than the maximum
salary for managers.
SQL>SELECT JOB,SUM(SAL) FROM EMP GROUP BY JOB HAVING SUM(SAL)>(SELECT
MAX(SAL) FROM EMP WHERE JOB='MANAGER');

60) Display the names of employees from department number 10 with salary
grether than that of any employee working in other department.
SQL>select ename from emp where deptno=10 and sal>any(select sal from
emp where deptno not in 10).

61) Display the names of the employees from department number 10 with
salary greater than that of all employee working in other departments.
SQL>select ename from emp where deptno=10 and sal>all(select sal from
emp where deptno not in 10).

62) Display the names of the employees in Uppercase.

SQL>select upper(ename)from emp

63) Display the names of the employees in Lowecase.

SQL>select lower(ename)from emp
64) Display the names of the employees in Propercase.
SQL>select initcap(ename)from emp;

65) Display the length of Your name using appropriate function.

SQL>select length('name') from dual

66) Display the length of all the employee names.

SQL>select length(ename) from emp;

67) select name of the employee concatenate with employee number.

SQL>select ename||empno from emp;

68) User appropriate function and extract 3 characters starting from 2

characters from the following string 'Oracle'. i.e the out put should be 'ac'.
SQL>select substr('oracle',3,2) from dual

69) Find the First occurance of character 'a' from the following string i.e
'Computer Maintenance Corporation'.
SQL>SELECT INSTR('Computer Maintenance Corporation','a',1) FROM DUAL

70) Replace every occurance of alphabhet A with B in the string Allens(use

translate function)
SQL>select translate('Allens','A','B') from dual

71) Display the informaction from emp table.Where job manager is found it
should be displayed as boos(Use replace function).
SQL>select replace(JOB,'MANAGER','BOSS') FROM EMP;

72) Display empno,ename,deptno from emp table.Instead of display department

numbers display the related department name(Use decode function).
SQL>select empno,ename,decode(deptno,10,'ACCOUNTING',20,'RESEARCH',30,'SALES',40,'OPRATIONS')
from emp;

73) Display your age in days.

SQL>select to_date(sysdate)-to_date('10-sep-77')from dual

74) Display your age in months.

SQL>select months_between(sysdate,'10-sep-77') from dual

75) Display the current date as 15th Augest Friday Nineteen Ninety Saven.
SQL>select to_char(sysdate,'ddth Month day year') from dual

76) Display the following output for each row from emp table.
scott has joined the company on wednesday 13th August ninten nintey.
SQL>select ENAME||' HAS JOINED THE COMPANY ON '||to_char(HIREDATE,'day
ddth Month year') from EMP;

77) Find the date for nearest saturday after current date.
SQL>SELECT NEXT_DAY(SYSDATE,'SATURDAY')FROM DUAL;

78) Display current time.

SQL>select to_char(sysdate,'hh:MM:ss') from dual.

79) Display the date three months Before the current date.
SQL>select add_months(sysdate,3) from dual;

80) Display the common jobs from department number 10 and 20.
SQL>select job from emp where deptno=10 and job in(select job from emp
where deptno=20);
81) Display the jobs found in department 10 and 20 Eliminate duplicate jobs.
SQL>select distinct(job) from emp where deptno=10 or deptno=20
(or)
SQL>select distinct(job) from emp where deptno in(10,20);

82) Display the jobs which are unique to department 10.

SQL>select distinct(job) from emp where deptno=10

83) Display the details of those who do not have any person working under them.
SQL>select e.ename from emp,emp e where emp.mgr=e.empno group by
e.ename having count(*)=1;

84) Display the details of those employees who are in sales department and
grade is 3.
SQL>select * from emp where deptno=(select deptno from dept where
dname='SALES')and sal between(select losal from salgrade where grade=3)and
(select hisal from salgrade where grade=3);

85) Display those who are not managers and who are managers any one.
i)display the managers names
SQL>select distinct(m.ename) from emp e,emp m where m.empno=e.mgr;

ii)display the who are not managers

SQL>select ename from emp where ename not in(select distinct(m.ename)
from emp e,emp m where m.empno=e.mgr);

86) Display those employee whose name contains not less than 4 characters.
SQL>select ename from emp where length(ename)>4;

87) Display those department whose name start with "S" while the location
name ends with "K".
SQL>select dname from dept where dname like 'S%' and loc like '%K';

88) Display those employees whose manager name is JONES.

SQL>select p.ename from emp e,emp p where e.empno=p.mgr and
e.ename='JONES';

89) Display those employees whose salary is more than 3000 after giving 20%
increment.
SQL>select ename,sal from emp where (sal+sal*.2)>3000;

90) Display all employees while their dept names;

SQL>select ename,dname from emp,dept where emp.deptno=dept.deptno

91) Display ename who are working in sales dept.

SQL>select ename from emp where deptno=(select deptno from dept where
dname='SALES');

92) Display employee name,deptname,salary and comm for those sal in between
2000 to 5000 while location is chicago.
SQL>select ename,dname,sal,comm from emp,dept where sal between 2000
and 5000 and loc='CHICAGO' and emp.deptno=dept.deptno;

93)Display those employees whose salary greter than his manager salary.
SQL>select p.ename from emp e,emp p where e.empno=p.mgr and p.sal>e.sal

94) Display those employees who are working in the same dept where his
manager is work.
SQL>select p.ename from emp e,emp p where e.empno=p.mgr and
p.deptno=e.deptno;

95) Display those employees who are not working under any manager.
SQL>select ename from emp where mgr is null

96) Display grade and employees name for the dept no 10 or 30 but grade is
not 4 while joined the company before 31-dec-82.
SQL>select ename,grade from emp,salgrade where sal between losal and
hisal and deptno in(10,30) and grade<>4 and hiredate<'31-DEC-82';

97) Update the salary of each employee by 10% increment who are not
eligiblw for commission.
SQL>update emp set sal=sal+sal*10/100 where comm is null;

98) SELECT those employee who joined the company before 31-dec-82 while
their dept location is newyork or Chicago.
SQL>SELECT EMPNO,ENAME,HIREDATE,DNAME,LOC FROM EMP,DEPT
WHERE (EMP.DEPTNO=DEPT.DEPTNO) AND HIREDATE <'31-DEC-82' AND DEPT.LOC IN('CHICAGO','NEW
YORK');

99) DISPLAY EMPLOYEE NAME,JOB,DEPARTMENT,LOCATION FOR ALL WHO ARE WORKING

AS MANAGER?
SQL>select ename,JOB,DNAME,LOCATION from emp,DEPT where mgr is not null;

100) DISPLAY THOSE EMPLOYEES WHOSE MANAGER NAME IS JONES? --

[AND ALSO DISPLAY THEIR MANAGER NAME]?
SQL> SELECT P.ENAME FROM EMP E, EMP P WHERE E.EMPNO=P.MGR AND
E.ENAME='JONES';

101) Display name and salary of ford if his salary is equal to hisal of his grade
a)select ename,sal,grade from emp,salgrade where sal between losal and hisal
and ename ='FORD' AND HISAL=SAL;

102) Display employee name,job,depart name ,manager name,his grade and make
out an under department wise?
SQL>SELECT E.ENAME,E.JOB,DNAME,EMP.ENAME,GRADE FROM EMP,EMP
E,SALGRADE,DEPT
WHERE EMP.SAL BETWEEN LOSAL AND HISAL AND EMP.EMPNO=E.MGR
AND EMP.DEPTNO=DEPT.DEPTNO ORDER BY DNAME

103) List out all employees name,job,salary,grade and depart name for every
one in the company except 'CLERK'.Sort on salary display the highest salary?
SQL>SELECT ENAME,JOB,DNAME,SAL,GRADE FROM EMP,SALGRADE,DEPT WHERE
SAL BETWEEN LOSAL AND HISAL AND EMP.DEPTNO=DEPT.DEPTNO AND JOB
NOT IN('CLERK')ORDER BY SAL ASC;

104) Display the employee name,job and his manager.Display also employee who
are without manager?
SQL>select e.ename,e.job,eMP.ename AS Manager from emp,emp e where
emp.empno(+)=e.mgr

105) Find out the top 5 earners of company?

SQL>SELECT DISTINCT SAL FROM EMP E WHERE 5>=(SELECT COUNT(DISTINCT SAL)
FROM EMP A WHERE A.SAL>=E.SAL)ORDER BY SAL DESC;

106) Display name of those employee who are getting the highest salary?
SQL>select ename from emp where sal=(select max(sal) from emp);
107) Display those employee whose salary is equal to average of maximum and
minimum?
SQL>select ename from emp where sal=(select max(sal)+min(sal)/2 from emp);

108) Select count of employee in each department where count greater than 3?
SQL>select count(*) from emp group by deptno having count(deptno)>3

109) Display dname where at least 3 are working and display only department name?
SQL>select distinct d.dname from dept d,emp e where d.deptno=e.deptno
and 3>any (select count(deptno) from emp group by deptno)

110) Display name of those managers name whose salary is more than average
salary of his company?
SQL>SELECT E.ENAME,EMP.ENAME FROM EMP,EMP E
WHERE EMP.EMPNO=E.MGR AND E.SAL>(SELECT AVG(SAL) FROM EMP);
111)Display those managers name whose salary is more than average salary of
his employee?
SQL>SELECT DISTINCT EMP.ENAME FROM EMP,EMP E WHERE
E.SAL <(SELECT AVG(EMP.SAL) FROM EMP
WHERE EMP.EMPNO=E.MGR GROUP BY EMP.ENAME) AND EMP.EMPNO=E.MGR;

112) Display employee name,sal,comm and net pay for those employee whose net pay is greter than or
equal to any other employee salary of the company?
SQL>select ename,sal,comm,sal+nvl(comm,0) as NetPay from emp
where sal+nvl(comm,0) >any (select sal from emp)

113) Display all employees names with total sal of company with each
employee name?
SQL>SELECT ENAME,(SELECT SUM(SAL) FROM EMP) FROM EMP;

114) Find out last 5(least)earners of the company.?

SQL>SELECT DISTINCT SAL FROM EMP E WHERE 5>=(SELECT COUNT(DISTINCT SAL) FROM EMP A WHERE
A.SAL<=E.SAL) ORDER BY SAL DESC;

115) Find out the number of employees whose salary is greater than their manager salary?
SQL>SELECT E.ENAME FROM EMP ,EMP E WHERE EMP.EMPNO=E.MGR
AND EMP.SAL<E.SAL;

116) Display those department where no employee working?

SQL>select dname from emp,dept where emp.deptno not in(emp.deptno)

117) Display those employee whose salary is ODD value?

SQL>select * from emp where sal<0;

118) Display those employee whose salary contains alleast 3 digits?

SQL>select * from emp where length(sal)>=3;

119) Display those employee who joined in the company in the month of Dec?
SQL>select ename from emp where to_char(hiredate,'MON')='DEC';

120) Display those employees whose name contains "A"?

SQL>select ename from emp where instr(ename,'A')>0;
or
SQL>select ename from emp where ename like('%A%');

121) Display those employee whose deptno is available in salary?

SQL>select emp.ename from emp, emp e where emp.sal=e.deptno;
122) Display those employee whose first 2 characters from hiredate -last 2
characters of salary?
SQL>select ename,SUBSTR(hiredate,1,2)||ENAME||substr(sal,-2,2) from emp

123) Display those employee whose 10% of salary is equal to the year of joining?
SQL>select ename from emp where to_char(hiredate,'YY')=sal*0.1;

124) Display those employee who are working in sales or research?

SQL>SELECT ENAME FROM EMP WHERE DEPTNO IN(SELECT DEPTNO FROM DEPT WHERE
DNAME IN('SALES','RESEARCH'));
125) Display the grade of jones?
SQL>SELECT ENAME,GRADE FROM EMP,SALGRADE
WHERE SAL BETWEEN LOSAL AND HISAL AND Ename='JONES';

126) Display those employees who joined the company before 15 of the month?
a)select ename from emp where to_char(hiredate,'DD')<15;

127) Display those employee who has joined before 15th of the month.
a)select ename from emp where to_char(hiredate,'DD')<15;

128) Delete those records where no of employees in a particular department

is less than 3.
SQL>delete from emp where deptno=(select deptno from emp
group by deptno having count(deptno)<3);

129) Display the name of the department where no employee working.

SQL> SELECT E.ENAME,E.JOB,M.ENAME,M.JOB FROM EMP E,EMP M
WHERE E.MGR=M.EMPNO

130) Display those employees who are working as manager.

SQL>SELECT M.ENAME MANAGER FROM EMP M ,EMP E
WHERE E.MGR=M.EMPNO GROUP BY M.ENAME

131) Display those employees whose grade is equal to any number of sal but
not equal to first number of sal?
SQL> SELECT ENAME,GRADE FROM EMP,SALGRADE
WHERE GRADE NOT IN(SELECT SUBSTR(SAL,0,1)FROM EMP)

132) Print the details of all the employees who are Sub-ordinate to BLAKE?
SQL>select emp.ename from emp, emp e where emp.mgr=e.empno and
e.ename='BLAKE';

133) Display employee name and his salary whose salary is greater than
highest average of department number?
SQL>SELECT SAL FROM EMP WHERE SAL>(SELECT MAX(AVG(SAL)) FROM EMP
GROUP BY DEPTNO);

134) Display the 10th record of emp table(without using rowid)

SQL>SELECT * FROM EMP WHERE ROWNUM<11
MINUS
SELECT * FROM EMP WHERE ROWNUM<10

135) Display the half of the ename's in upper case and remaining lowercase?
SQL>SELECT
SUBSTR(LOWER(ENAME),1,3)||SUBSTR(UPPER(ENAME),3,LENGTH(ENAME)) FROM EMP;

136) Display the 10th record of emp table without using group by and rowid?
SQL>SELECT * FROM EMP WHERE ROWNUM<11
MINUS
SELECT * FROM EMP WHERE ROWNUM<10

Delete the 10th record of emp table.

SQL>DELETE FROM EMP WHERE EMPNO=(SELECT EMPNO FROM EMP WHERE ROWNUM<11
MINUS SELECT EMPNO FROM EMP WHERE ROWNUM<10)

137) Create a copy of emp table;

SQL>create table new_table as select * from emp where 1=2;

138) Select ename if ename exists more than once.

SQL>select ename from emp e group by ename having count(*)>1;

139) Display all enames in reverse order?(SMITH:HTIMS).

SQL>SELECT REVERSE(ENAME)FROM EMP;

140) Display those employee whose joining of month and grade is equal.
SQL>SELECT ENAME FROM EMP WHERE SAL BETWEEN
(SELECT LOSAL FROM SALGRADE WHERE
GRADE=TO_CHAR(HIREDATE,'MM')) AND
(SELECT HISAL FROM SALGRADE WHERE
GRADE=TO_CHAR(HIREDATE,'MM'));

141) Display those employee whose joining DATE is available in deptno.

SQL>SELECT ENAME FROM EMP WHERE TO_CHAR(HIREDATE,'DD')=DEPTNO

142) Display those employees name as follows

A ALLEN
B BLAKE
SQL> SELECT SUBSTR(ENAME,1,1),ENAME FROM EMP;

143) List out the employees ename,sal,PF(20% OF SAL) from emp;

SQL>SELECT ENAME,SAL,SAL*.2 AS PF FROM EMP;

144) Create table emp with only one column empno;

SQL>Create table emp as select empno from emp where 1=2;

145) Add this column to emp table ename vrachar2(20).

SQL>alter table emp add(ename varchar2(20));

146) Oops I forgot give the primary key constraint. Add in now.
SQL>alter table emp add primary key(empno);

147) Now increase the length of ename column to 30 characters.

SQL>alter table emp modify(ename varchar2(30));

148) Add salary column to emp table.

SQL>alter table emp add(sal number(10));

149) I want to give a validation saying that salary cannot be greater 10,000
(note give a name to this constraint)
SQL>alter table emp add constraint chk_001 check(sal<=10000)
150) For the time being I have decided that I will not impose this validation.My boss has agreed to pay
more than 10,000.
SQL>again alter the table or drop constraint with alter table emp drop constraint chk_001 (or)Disable the
constraint by using alter table emp modify constraint chk_001 disable;

151) My boss has changed his mind. Now he doesn't want to pay more than
10,000.so revoke that salary constraint.
SQL>alter table emp modify constraint chk_001 enable;

152) Add column called as mgr to your emp table;

SQL>alter table emp add(mgr number(5));

153) Oh! This column should be related to empno. Give a command to add this constraint.
SQL>ALTER TABLE EMP ADD CONSTRAINT MGR_DEPT FOREIGN KEY(MGR) REFERENCES
EMP(EMPNO)

154) Add deptno column to your emp table;

SQL>alter table emp add(deptno number(5));

155) This deptno column should be related to deptno column of dept table;
SQL>alter table emp add constraint dept_001 foreign key(deptno)
reference dept(deptno) [deptno should be primary key]

156) Give the command to add the constraint.

SQL>alter table <table_name) add constraint <constraint_name> <constraint type>

157) Create table called as newemp. Using single command create this table
as well as get data into this table(use create table as);
SQL>create table newemp as select * from emp;

SQL>Create table called as newemp. This table should contain only

empno,ename,dname.
SQL>create table newemp as select empno,ename,dname from emp,dept where 1=2;

158) Delete the rows of employees who are working in the company for more
than 2 years.
SQL>delete from emp where (sysdate-hiredate)/365>2;

159) Provide a commission(10% Comm Of Sal) to employees who are not earning
any commission.
SQL>select sal*0.1 from emp where comm is null

160) If any employee has commission his commission should be incremented by

10% of his salary.
SQL>update emp set comm=sal*.1 where comm is not null;

161) Display employee name and department name for each employee.
SQL>select empno,dname from emp,dept where emp.deptno=dept.deptno

162)Display employee number,name and location of the department in which he

is working.
SQL>select empno,ename,loc,dname from emp,dept where
emp.deptno=dept.deptno;

163) Display ename,dname even if there are no employees working in a

particular department(use outer join).
SQL>select ename,dname from emp,dept where emp.deptno=dept.deptno(+)

164) Display employee name and his manager name.

SQL>select p.ename,e.ename from emp e,emp p where e.empno=p.mgr;

165) Display the department name and total number of employees in each
department.
SQL>select dname,count(ename) from emp,dept where
emp.deptno=dept.deptno group by dname;

166)Display the department name along with total salary in each department.
SQL>select dname,sum(sal) from emp,dept where emp.deptno=dept.deptno group by dname;

167) Display itemname and total sales amount for each item.
SQL>select itemname,sum(amount) from item group by itemname;

168) Write a Query To Delete The Repeted Rows from emp table;
SQL>Delete from emp where rowid not in(select min(rowid)from emp group
by ename)

169) TO DISPLAY 5 TO 7 ROWS FROM A TABLE

SQL>select ename from emp
where rowid in(select rowid from emp where rownum<=7
minus
select rowid from empi where rownum<5)
170) DISPLAY TOP N ROWS FROM TABLE?
SQL>SELECT * FROM
(SELECT * FROM EMP ORDER BY ENAME DESC)
WHERE ROWNUM <10;

171) DISPLAY TOP 3 SALARIES FROM EMP;

SQL>SELECT SAL FROM ( SELECT * FROM EMP ORDER BY SAL DESC )
WHERE ROWNUM <4

172) DISPLAY 9th FROM THE EMP TABLE?

SQL>SELECT ENAME FROM EMP
WHERE ROWID=(SELECT ROWID FROM EMP WHERE ROWNUM<=10
MINUS
SELECT ROWID FROM EMP WHERE ROWNUM <10)
select second max salary from emp;
select max(sal) fromemp where sal<(select max(sal) from emp);

------******------

Guidelines to use the VSS

1.Check if you can login to the VSS.

2. Check if you are able to access and view all the documents from VSS.
Every TE must be able to perform the following operations with VSS.

Create a working folder in the local machine using the following steps:---

i) Select the root folder ($/) and right click on it and click on “Set working folder” option.
ii) Select ‘E’ drive and enter the folder name as E:\VSS.
iii) Click on create folder button and click on OK.

3. Check if you are able to copy any one of the documents (say BDD) to
your local software structure.

4. Check if your are able to check-in, the sample Document with the following
naming convention.

Steps to Check-in:
i) Go to FileAdd FilesSelect drive in which the document is presentSelect the file and click on
Add button.
ii) Add the comment (Optional)Click on OK.

5.Check if you can check-out the same TC document.

Steps for Checkout:

i) Select the folder in the VSS tree and select the document to be checked out.
ii) Right click on document and select the option checkout.
iii) Enter the comment items of the need to be checked out and click on OK.

6. Check if your are able to observe the red icon for the checked out document.

7. Check if your are able to Edit the checked out document with VSS.

Steps for edit :

i) Select the document and right click on it.

ii) Select Edit  click on OK.
iii) Write the comment click on OK to open the document for modification.
8. Check if you can pin the document.
Steps to pin the document :

i) Select the document and right click on it.

ii) Select show history and click on OK.
iii) Click on pin and click on close.
iv) Observe the pin icon before the document.
9. Check if you can unpin the document

Steps to unpin the document :

i) Select the document and right click on it.

ii) Select show history and click on OK.
iii) Click on unpin and click on close.
iv) Observe the unpin the document.

10. Check if you can Rollback the document to a specific Version.

Steps to Rollback the document :

i) Select the document and right click on it.
ii) Select show history and click on OK.
iii) Click on Rollback and click on close.

11.Select the document, right click on it and click on the delete button.