Testing Interview Questions

Interview Question Part 1
1.What is the testing process?

2.Verifying that an input data produce the expected output.
3.What is the difference between testing and debugging?
4.What is the difference between structural and functional testing?
5.What is a bug? What types of bugs do you know?
6.Bug is a error during execution of the program.
7.What is the difference between testing and quality assurance (QA)?
8.What kinds of testing do you know? What is it system testing? What is it integration testing? What is a unit testing?
What is a regression testing?
9.Tell me about ur self?
10.Process in ur company?
11.Responsibilities in the project?
12.Manual and automation exp?
13.How many test cases u have written in ur model?
14.Why u have automated ur project?
15.For exmp out of 100 test cases if I ask you to automate how many you can automate?
16.What features you have frequently used in wr?
17.In your cv you have mention few types of testing tell me about that?
18.Role ur self in wr?
19.You know about trasability matrix if so tell me the fields of that?
20.Few tsl functions in wr?
21.What do u mean by regression testing have u done ?
22.You have any idea about back end testing?
23.Tell me about u r project?
24.Who is the client of ur company?
25.What is the concept of your project and which domain?
26.How many modules are there in your project and which module you have worked?
27.Can u tell me the data flow in the module?
28.What do u mean mean by integration testing?
29.Can u differ data flow and control flow?
30.Tell me about your way of written scripting?
31. You said one more generic what do u mean by that?
32. Can u done database testing tell me some quries?
33.Tell me about parameterizing data?
34.Why we need to go for testing?
35. What is CM Plan?
36. What is the back-end you are using for the Current Project? (SQL-SERVER)
37.Tell me difference between Oracle and SQL?
38.How much you are strong with SQL?
39.Tell about CMM?
40.Have you ever interacted with the client?
41.Tell about your company background?
42.What are your day- by-day activities?
43.In testing which are you are strong?
44.Tell me about the Testing life cycle?
45.Do you ever worked with the Win Runner?
46.What is the current and expected Package?
47.Explain Test Case Template?
48.Explain your project & what is your role in that Project?
49.What is White Box Testing and Black Box Testing?
50.How will you prepare the Test Plan?
51.What are the severity levels in your project?
52.What version you are using in Win Runner?
53.What is load and Stress Testing?
54.How will you check the database?
55.What is GUI Testing and Functionality Testing?56.How will you report the bug?
57.Write a query to fetch the data is the table such as Employee Table and Dept Table.
Employee Department
EmpNo DeptNo
Name Dept Name
Sal DeptNo
58. To fetch the data who is in the Department Number = 10
59. How will you maintain the project?
60. How many members are there in your team? To whom you will report the bug?
61. Why do you want to join in this Company?
62. Can you test DB using WR? What are the Databases that WR can support?
63. How do you set a query to fetch data from the database?
64. Rate your self in WR?
65. Once a new build comes to Quality Team, what they will do?
66.What is database testing?
Manual Testing Q & A Part 1
1. What is the testing process?
Verifying that an input data produce the expected output.
2. What is the difference between testing and debugging?
Big difference is that debugging is conducted by a programmer and the programmer fix the errors during debugging
phase. Tester never fixes the errors, but rather find them and return to programmer.
3. What is the difference between structural and functional testing?
Structural is a "white box" testing and based on the algorithm or code. Functional testing is a "black box" (behavioral)
testing where the tester verifies the functional specification.
4. What is a bug? What types of bugs do you know?
Bug is a error during execution of the program. There are two types of bugs: syntax and logical.
5. What is the difference between testing and quality assurance (QA)?
This question is surprisingly popular. However, the answer is quite simple. The goals of both are different: The goal of
testing is to find the errors. The goal of QA is to prevent the errors in the program.
6. What kinds of testing do you know? What is it system testing? What is it integration testing? What is a unit testing?
You theoretical background and home work may shine in this question. System testing is a testing of the entire system as
a whole. This is what user see and feels about the product you provide. Integration testing is the testing of integration of
different modules of the system. Usually, the integration process is quite painful and this testing is the most serious one of
all. Integration testing comes before system testing. Unit testing is a testing of a single unit (module) of within system. It's
conducted before integration testing. Regression testing is a "backward check" testing. The idea to ensure that new
functionality added to the system did not break old, checked, functionality of the system.
7.What are all the major processes will involve in testing?
The major processes include:
1.Planning (test strategy, test objectives, risk management)
2.Design (functions to be tested, test scenario, test cases)
3Development (test procedures, test scripts, test environment)
4.Execution (execute test)
5.Evaluation (evaluate test results, compare actual results with expected results)
8.Could you test a program 100%? 90%? Why?
Definitely not! The major problem with testing that you cannot calculate how many error are in the code, functioning etc.
There are many factors involved such as experience of programmer, complexity of the system etc.
9.How would you test a mug (chair/table/gas station etc.)?
First of all you must demand requirements and functional specification and design document of the mug. There will find
requirements like ability to hold hot water, waterproof, stability, break ability and so on. Then you should test the mug
according to all documents.
10.How would you conduct your test?
Each test is based on the technical requirements of the software product.
11.What is the other name for white box testing?
Clear box testing
12.What is other name for water fall model?
Linear sequential model
13.What is considered a good test?
It should cover most of the object's functionality
14.What is 'Software Quality Assurance'?
Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure
that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with.
15.What is 'Software Testing'?
Testing involves operation of a system or application under controlled conditions and evaluating the results (eg, 'if the user
is in interface A of the application while using hardware B, and does C, then D should happen'). The controlled conditions
should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to
determine if things happen when they shouldn't or things don't happen when they should.
16.What are some recent major computer system failures caused by software bugs?
· In March of 2002 it was reported that software bugs in Britain's national tax system resulted in more than 100,000
erroneous tax overcharges. The problem was partly attibuted to the difficulty of testing the integration of multiple systems.
· A newspaper columnist reported in July 2001 that a serious flaw was found in off-the-shelf software that had long been
used in systems for tracking certain U.S. nuclear materials. The same software had been recently donated to another
country to be used in tracking their own nuclear materials, and it was not until scientists in that country discovered the
problem, and shared the information, that U.S. officials became aware of the problems.
· According to newspaper stories in mid-2001, a major systems development contractor was fired and sued over problems
with a large retirement plan management system. According to the reports, the client claimed that system deliveries were
late, the software had excessive defects, and it caused other systems to crash.
· In January of 2001 newspapers reported that a major European railroad was hit by the aftereffects of the Y2K bug. The
company found that many of their newer trains would not run due to their inability to recognize the date '31/12/2000'; the
trains were started by altering the control system's date settings.
· News reports in September of 2000 told of a software vendor settling a lawsuit with a large mortgage lender; the vendor
had reportedly delivered an online mortgage processing system that did not meet specifications, was delivered late, and
didn't work.
· In early 2000, major problems were reported with a new computer system in a large suburban U.S. public school district
with 100,000+ students; problems included 10,000 erroneous report cards and students left stranded by failed class
registration systems; the district's CIO was fired. The school district decided to reinstate it's original 25-year old system for
at least a year until the bugs were worked out of the new system by the software vendors.
· In October of 1999 the $125 million NASA Mars Climate Orbiter spacecraft was believed to be lost in space due to a
simple data conversion error. It was determined that spacecraft software used certain data in English units that should
have been in metric units. Among other tasks, the orbiter was to serve as a communications relay for the Mars Polar
Lander mission, which failed for unknown reasons in December 1999. Several investigating panels were convened to
determine the process failures that allowed the error to go undetected.
· Bugs in software supporting a large commercial high-speed data network affected 70,000 business customers over a
period of 8 days in August of 1999. Among those affected was the electronic trading system of the largest U.S. futures
exchange, which was shut down for most of a week as a result of the outages.
· In April of 1999 a software bug caused the failure of a $1.2 billion military satellite launch, the costliest unmanned
accident in the history of Cape Canaveral launches. The failure was the latest in a string of launch failures, triggering a
complete military and industry review of U.S. space launch programs, including software integration and testing
processes. Congressional oversight hearings were requested.
· A small town in Illinois received an unusually large monthly electric bill of $7 million in March of 1999. This was about 700
times larger than its normal bill. It turned out to be due to bugs in new software that had been purchased by the local
power company to deal with Y2K software issues.
· In early 1999 a major computer game company recalled all copies of a popular new product due to software problems.
The company made a public apology for releasing a product before it was ready.
· The computer system of a major online U.S. stock trading service failed during trading hours several times over a period
of days in February of 1999 according to nationwide news reports. The problem was reportedly due to bugs in a software
upgrade intended to speed online trade confirmations.
· In April of 1998 a major U.S. data communications network failed for 24 hours, crippling a large part of some U.S. credit
card transaction authorization systems as well as other large U.S. bank, retail, and government data systems. The cause
was eventually traced to a software bug.
· January 1998 news reports told of software problems at a major U.S. telecommunications company that resulted in no
charges for long distance calls for a month for 400,000 customers. The problem went undetected until customers called
up with questions about their bills.
· In November of 1997 the stock of a major health industry company dropped 60% due to reports of failures in computer
billing systems, problems with a large database conversion, and inadequate software testing. It was reported that more
than $100,000,000 in receivables had to be written off and that multi-million dollar fines were levied on the company by
government agencies.
· A retail store chain filed suit in August of 1997 against a transaction processing system vendor (not a credit card
company) due to the software's inability to handle credit cards with year 2000 expiration dates.
· In August of 1997 one of the leading consumer credit reporting companies reportedly shut down their new public web
site after less than two days of operation due to software problems. The new site allowed web site visitors instant access,
for a small fee, to their personal credit reports. However, a number of initial users ended up viewing each others' reports
instead of their own, resulting in irate customers and nationwide publicity. The problem was attributed to "...unexpectedly
high demand from consumers and faulty software that routed the files to the wrong computers."
· In November of 1996, newspapers reported that software bugs caused the 411 telephone information system of one of
the U.S. RBOC's to fail for most of a day. Most of the 2000 operators had to search through phone books instead of using
their 13,000,000-listing database. The bugs were introduced by new software modifications and the problem software had
been installed on both the production and backup systems. A spokesman for the software vendor reportedly stated that 'It
had nothing to do with the integrity of the software. It was human error.'
· On June 4 1996 the first flight of the European Space Agency's new Ariane 5 rocket failed shortly after launching,
resulting in an estimated uninsured loss of a half billion dollars. It was reportedly due to the lack of exception handling of a
floating-point error in a conversion from a 64-bit integer to a 16-bit signed integer.
· Software bugs caused the bank accounts of 823 customers of a major U.S. bank to be credited with $924,844,208.32
each in May of 1996, according to newspaper reports. The American Bankers Association claimed it was the largest such
error in banking history. A bank spokesman said the programming errors were corrected and all funds were recovered.
· Software bugs in a Soviet early-warning monitoring system nearly brought on nuclear war in 1983, according to news
reports in early 1999. The software was supposed to filter out false missile detections caused by Soviet satellites picking
up sunlight reflections off cloud-tops, but failed to do so. Disaster was averted when a Soviet commander, based on a
what he said was a '...funny feeling in my gut', decided the apparent missile attack was a false alarm. The filtering
software code was rewritten.
17.Why is it often hard for management to get serious about quality assurance?
Solving problems is a high-visibility process; preventing problems is low-visibility. This is illustrated by an old parable:
In ancient China there was a family of healers, one of whom was known throughout the land and employed as a physician
to a great lord. The physician was asked which of his family was the most skillful healer. He replied,
"I tend to the sick and dying with drastic and dramatic treatments, and on occasion someone is cured and my name gets
out among the lords."
"My elder brother cures sickness when it just begins to take root, and his skills are known among the local peasants and
neighbors."
"My eldest brother is able to sense the spirit of sickness and eradicate it before it takes form. His name is unknown
outside our home."
18.Why does software have bugs?
·miscommunication or no communication - as to specifics of what an application should or shouldn't do (the application's
requirements).
·software complexity - the complexity of current software applications can be difficult to comprehend for anyone without
experience in modern-day software development. Windows-type interfaces, client-server and distributed applications, data
communications, enormous relational databases, and sheer size of applications have all contributed to the exponential
growth in software/system complexity. And the use of object-oriented techniques can complicate instead of simplify a
project unless it is well-engineered.
·programming errors - programmers, like anyone else, can make mistakes.
· changing requirements - the customer may not understand the effects of changes, or may understand and request them
anyway - redesign, rescheduling of engineers, effects on other projects, work already completed that may have to be
redone or thrown out, hardware requirements that may be affected, etc. If there are many minor changes or any major
changes, known and unknown dependencies among parts of the project are likely to interact and cause problems, and the
complexity of keeping track of changes may result in errors. Enthusiasm of engineering staff may be affected. In some
fast-changing business environments, continuously modified requirements may be a fact of life. In this case, management
must understand the resulting risks, and QA and test engineers must adapt and plan for continuous extensive testing to
keep the inevitable bugs from running out of control .
· time pressures - scheduling of software projects is difficult at best, often requiring a lot of guesswork. When deadlines
loom and the crunch comes, mistakes will be made.
· egos - people prefer to say things like:
'no problem' 'piece of cake'
'I can whip that out in a few hours'
'it should be easy to update that old code'
instead of:'that adds a lot of complexity and we could end up
making a lot of mistakes'
'we have no idea if we can do that; we'll wing it'
'I can't estimate how long it will take, until I
take a close look at it'
'we can't figure out what that old spaghetti code
did in the first place'
If there are too many unrealistic 'no problem's', the
result is bugs.
· poorly documented code - it's tough to maintain and modify code that is badly written or poorly documented; the result is
bugs. In many organizations management provides no incentive for programmers to document their code or write clear,
understandable code. In fact, it's usually the opposite: they get points mostly for quickly turning out code, and there's job
security if nobody else can understand it ('if it was hard to write, it should be hard to read').
·software development tools - visual tools, class libraries, compilers, scripting tools, etc. often introduce their own bugs or
are poorly documented, resulting in added bugs.
19.How can new Software QA processes be introduced in an existing organization?
·A lot depends on the size of the organization and the risks involved. For large organizations with high-risk (in terms of
lives or property) projects, serious management buy-in is required and a formalized QA process is necessary.
·Where the risk is lower, management and organizational buy-in and QA implementation may be a slower, step-at-a-time
process. QA processes should be balanced with productivity so as to keep bureaucracy from getting out of hand.
·For small groups or projects, a more ad-hoc process may be appropriate, depending on the type of customers and
projects. A lot will depend on team leads or managers, feedback to developers, and ensuring adequate communications
among customers, managers, developers, and testers.
·In all cases the most value for effort will be in requirements management processes, with a goal of clear, complete,
testable requirement specifications or expectations.
20.What is verification? validation?
Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications.
This can be done with checklists, issues lists, walkthroughs, and inspection meetings. Validation typically involves actual
testing and takes place after verifications are completed. The term 'IV & V' refers to Independent Verification and
Validation.
21.What is a 'walkthrough'?
A 'walkthrough' is an informal meeting for evaluation or informational purposes. Little or no preparation is usually required.
22.What's an 'inspection'?
An inspection is more formalized than a 'walkthrough', typically with 3-8 people including a moderator, reader, and a
recorder to take notes. The subject of the inspection is typically a document such as a requirements spec or a test plan,
and the purpose is to find problems and see what's missing, not to fix anything. Attendees should prepare for this type of
meeting by reading thru the document; most problems will be found during this preparation. The result of the inspection
meeting should be a written report. Thorough preparation for inspections is difficult, painstaking work, but is one of the
most cost effective methods of ensuring quality. Employees who are most skilled at inspections are like the 'eldest brother'
in the parable in Their skill may have low visibility but they are extremely valuable to any software development
organization, since bug prevention is far more cost-effective than bug detection.
23.What kinds of testing should be considered?
·Black box testing - not based on any knowledge of internal design or code. Tests are based on requirements and
functionality.
·White box testing - based on knowledge of the internal logic of an application's code. Tests are based on coverage of
code statements, branches, paths, conditions.
·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.
·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.
·integration testing - testing of combined parts of an application to determine if they function together correctly. The 'parts'
can be code modules, individual applications, client and server applications on a network, etc. This type of testing is
especially relevant to client/server and distributed systems.
·functional testing - black-box type testing geared to functional requirements of an application; this type of testing should
be done by testers. This doesn't mean that the programmers shouldn't check that their code works before releasing it
(which of course applies to any stage of testing.)
·system testing - black-box type testing that is based on overall requirements specifications; covers all combined parts of
a system.
·end-to-end testing - similar to system testing; the 'macro' end of the test scale; involves testing of 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.
·sanity 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 destroying databases, the software may not be in a 'sane' enough condition to
warrant further testing in its current state.
·regression testing - re-testing after fixes or modifications of the software or its environment. It can be difficult to determine
how much re-testing is needed, especially near the end of the development cycle. Automated testing tools can be
especially useful for this type of testing.
·acceptance testing - final testing based on specifications of the end-user or customer, or based on use by end-
users/customers over some limited period of time.
·load testing - testing an application under heavy loads, such as testing of a web site under a range of loads to determine
at what point the system's response time degrades or fails.
·stress testing - term often used interchangeably with 'load' and 'performance' testing. Also used to describe such tests as
system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large
numerical values, large complex queries to a database system, etc.
·performance testing - term often used interchangeably with 'stress' and 'load' testing. Ideally 'performance' testing (and
any other 'type' of testing) is defined in requirements documentation or QA or Test Plans.
·usability testing - testing for 'user-friendliness'. Clearly this is subjective, and will depend on the targeted end-user or
customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers
and testers are usually not appropriate as usability testers.
·install/uninstall testing - testing of full, partial, or upgrade install/uninstall processes.
·recovery testing - testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
·security testing - testing how well the system protects against unauthorized internal or external access, willful damage,
etc; may require sophisticated testing techniques.
·compatability testing - testing how well software performs in a particular hardware/software/operating system/network/etc.
environment.
·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.
·ad-hoc testing - similar to exploratory testing, but often taken to mean that the testers have significant understanding of
the software before testing it.
·user acceptance testing - determining if software is satisfactory to an end-user or customer.
·comparison testing - comparing software weaknesses and strengths to competing products.
·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.
·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.
·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.
24.What are 5 common problems in the software development process?
·poor requirements - if requirements are unclear, incomplete, too general, or not testable, there will be problems.
·unrealistic schedule - if too much work is crammed in too little time, problems are inevitable.
·inadequate testing - no one will know whether or not the program is any good until the customer complains or systems
crash.
·featuritis - requests to pile on new features after development is underway; extremely common.
·miscommunication - if developers don't know what's needed or customer's have erroneous expectations, problems are
guaranteed.
25.What are 5 common solutions to software development problems?
·solid requirements - clear, complete, detailed, cohesive, attainable, testable requirements that are agreed to by all
players. Use prototypes to help nail down requirements.
·realistic schedules - allow adequate time for planning, design, testing, bug fixing, re-testing, changes, and documentation;
personnel should be able to complete the project without burning out.
·adequate testing - start testing early on, re-test after fixes or changes, plan for adequate time for testing and bug-fixing.
·stick to initial requirements as much as possible - be prepared to defend against changes and additions once
development has begun, and be prepared to explain consequences. If changes are necessary, they should be adequately
reflected in related schedule changes. If possible, use rapid prototyping during the design phase so that customers can
see what to expect. This will provide them a higher comfort level with their requirements decisions and minimize changes
later on.
·communication - require walkthroughs and inspections when appropriate; make extensive use of group communication
tools - e-mail, groupware, networked bug- tracking tools and change management tools, intranet capabilities, etc.; insure
that documentation is available and up-to-date - preferably electronic, not paper; promote teamwork and cooperation; use
protoypes early on so that customers' expectations are clarified.
26.What is software 'quality'?
Quality software is reasonably bug-free, delivered on time and within budget, meets requirements and/or expectations,
and is maintainable. However, quality is obviously a subjective term. It will depend on who the 'customer' is and their
overall influence in the scheme of things. A wide-angle view of the 'customers' of a software development project might
include end-users, customer acceptance testers, customer contract officers, customer management, the development
organization's management/accountants/testers/salespeople, future software maintenance engineers, stockholders,
magazine columnists, etc. Each type of 'customer' will have their own slant on 'quality' - the accounting department might
define quality in terms of profits while an end-user might define quality as user-friendly and bug-free.
27.What is 'good code'?
'Good code' is code that works, is bug free, and is readable and maintainable. Some organizations have coding
'standards' that all developers are supposed to adhere to, but everyone has different ideas about what's best, or what is
too many or too few rules. There are also various theories and metrics, such as McCabe Complexity metrics. It should be
kept in mind that excessive use of standards and rules can stifle productivity and creativity. 'Peer reviews', 'buddy checks'
code analysis tools, etc. can be used to check for problems and enforce standards.
For C and C++ coding, here are some typical ideas to consider in setting rules/standards; these may or may not apply to a
particular situation:
·minimize or eliminate use of global variables.
·use descriptive function and method names - use both upper and lower case, avoid abbreviations, use as many
characters as necessary to be adequately descriptive (use of more than 20 characters is not out of line); be consistent in
naming conventions.
·use descriptive variable names - use both upper and lower case, avoid abbreviations, use as many characters as
necessary to be adequately descriptive (use of more than 20 characters is not out of line); be consistent in naming
conventions.
·function and method sizes should be minimized; less than 100 lines of code is good, less than 50 lines is preferable.
·function descriptions should be clearly spelled out in comments preceding a function's code.
·organize code for readability.
·use whitespace generously - vertically and horizontally
·each line of code should contain 70 characters max.
·one code statement per line.
·coding style should be consistent throught a program (eg, use of brackets, indentations, naming conventions, etc.)
·in adding comments, err on the side of too many rather than too few comments; a common rule of thumb is that there
should be at least as many lines of comments (including header blocks) as lines of code.
·no matter how small, an application should include documentaion of the overall program function and flow (even a few
paragraphs is better than nothing); or if possible a separate flow chart and detailed program documentation.
·make extensive use of error handling procedures and status and error logging.
·for C++, to minimize complexity and increase maintainability, avoid too many levels of inheritance in class heirarchies
(relative to the size and complexity of the application). Minimize use of multiple inheritance, and minimize use of operator
overloading (note that the Java programming language eliminates multiple inheritance and operator overloading.)
· for C++, keep class methods small, less than 50 lines of code per method is preferable.
· for C++, make liberal use of exception handlers
28.What is 'good design'?
'Design' could refer to many things, but often refers to 'functional design' or 'internal design'. Good internal design is
indicated by software code whose overall structure is clear, understandable, easily modifiable, and maintainable; is robust
with sufficient error-handling and status logging capability; and works correctly when implemented. Good functional design
is indicated by an application whose functionality can be traced back to customer and end-user requirements.For
programs that have a user interface, it's often a good idea to assume that the end user will have little computer knowledge
and may not read a user manual or even the on-line help; some common rules-of-thumb include:
· the program should act in a way that least surprises the user
· it should always be evident to the user what can be done next and how to exit
· the program shouldn't let the users do something stupid without warning them.
29.What is SEI? CMM? ISO? IEEE? ANSI? Will it help?
·SEI = 'Software Engineering Institute' at Carnegie-Mellon University; initiated by the U.S. Defense Department to help
improve software development processes.
·CMM = 'Capability Maturity Model', developed by the SEI. It's a model of 5 levels of organizational 'maturity' that
determine effectiveness in delivering quality software. It is geared to large organizations such as large U.S. Defense
Department contractors. However, many of the QA processes involved are appropriate to any organization, and if
reasonably applied can be helpful. Organizations can receive CMM ratings by undergoing assessments by qualified
auditors.
Level 1 - characterized by chaos, periodic panics, and heroic
efforts required by individuals to successfully
complete projects. Few if any processes in place;
successes may not be repeatable.
Level 2 - software project tracking, requirements management,

realistic planning, and configuration management
processes are in place; successful practices can
be repeated.
Level 3 - standard software development and maintenance processes
are integrated throughout an organization; a Software
Engineering Process Group is is in place to oversee
software processes, and training programs are used to
ensure understanding and compliance.
Level 4 - metrics are used to track productivity, processes,
and products. Project performance is predictable,
and quality is consistently high.
Level 5 - the focus is on continouous process improvement. The
impact of new processes and technologies can be
predicted and effectively implemented when required.
Perspective on CMM ratings: During 1997-2001, 1018 organizations
were assessed. Of those, 27% were rated at Level 1, 39% at 2,
23% at 3, 6% at 4, and 5% at 5. (For ratings during the period
1992-96, 62% were at Level 1, 23% at 2, 13% at 3, 2% at 4, and
0.4% at 5.) The median size of organizations was 100 software
engineering/maintenance personnel; 32% of organizations were
U.S. federal contractors or agencies. For those rated at
Level 1, the most problematical key process area was in
Software Quality Assurance.
· ISO = 'International Organisation for Standardization' - The ISO 9001:2000 standard (which replaces the previous
standard of 1994) concerns quality systems that are assessed by outside auditors, and it applies to many kinds of
production and manufacturing organizations, not just software. It covers documentation, design, development, production,
testing, installation, servicing, and other processes. The full set of standards consists of: (a)Q9001-2000 - Quality
Management Systems: Requirements; (b)Q9000-2000 - Quality Management Systems: Fundamentals and Vocabulary;
(c)Q9004-2000 - Quality Management Systems: Guidelines for Performance Improvements. To be ISO 9001 certified, a
third-party auditor assesses an organization, and certification is typically good for about 3 years, after which a complete
reassessment is required. Note that ISO certification does not necessarily indicate quality products - it indicates only that
documented processes are followed.
· IEEE = 'Institute of Electrical and Electronics Engineers' - among other things, creates standards such as 'IEEE Standard
for Software Test Documentation' (IEEE/ANSI Standard 829), 'IEEE Standard of Software Unit Testing (IEEE/ANSI
Standard 1008), 'IEEE Standard for Software Quality Assurance Plans' (IEEE/ANSI Standard 730), and others.
· ANSI = 'American National Standards Institute', the primary industrial standards body in the U.S.; publishes some
software-related standards in conjunction with the IEEE and ASQ (American Society for Quality).
· Other software development process assessment methods besides CMM and ISO 9000 include SPICE, Trillium, TickIT.
and Bootstrap.
30. What is the 'software life cycle'?
The life cycle begins when an application is first conceived and ends when it is no longer in use. It includes aspects such
as initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding,
document preparation, integration, testing, maintenance, updates, retesting, phase-out, and other aspects.

31.Will automated testing tools make testing easier?
·Possibly. For small projects, the time needed to learn and implement them may not be worth it. For larger projects, or on-
going long-term projects they can be valuable.
·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 can 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
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.
·Other automated tools can include:
code analyzers - monitor code complexity, adherence to
standards, etc.
coverage analyzers - these tools check which parts of the
code have been exercised by a test, and may
be oriented to code statement coverage,
condition coverage, path coverage, etc.
memory analyzers - such as bounds-checkers and leak detectors.
load/performance test tools - for testing client/server
and web applications under various load
levels.
web test tools - to check that links are valid, HTML code
usage is correct, client-side and
server-side programs work, a web site's
interactions are secure.
other tools - for test case management, documentation

management, bug reporting, and configuration
management.
32.What makes a good test engineer?
A good test engineer has a 'test to break' attitude, an ability to take the point of view of the customer, a strong desire for
quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers,
and an ability to communicate with both technical (developers) and non-technical (customers, management) people is
useful. Previous software development experience can be helpful as it provides a deeper understanding of the software
development process, gives the tester an appreciation for the developers' point of view, and reduce the learning curve in
automated test tool programming. Judgement skills are needed to assess high-risk areas of an application on which to
focus testing efforts when time is limited.
33.What makes a good Software QA engineer?
The same qualities a good tester has are useful for a QA engineer. Additionally, they must be able to understand the entire
software development process and how it can fit into the business approach and goals of the organization.
Communication skills and the ability to understand various sides of issues are important. In organizations in the early
stages of implementing QA processes, patience and diplomacy are especially needed. An ability to find problems as well
as to see 'what's missing' is important for inspections and reviews.
34.What makes a good QA or Test manager?
A good QA, test, or QA/Test(combined) manager should:
· be familiar with the software development process
· be able to maintain enthusiasm of their team and promote a positive atmosphere, despite what is a somewhat 'negative'
process (e.g., looking for or preventing problems)
· be able to promote teamwork to increase productivity
· be able to promote cooperation between software, test, and QA engineers
· have the diplomatic skills needed to promote improvements in QA processes
· have the ability to withstand pressures and say 'no' to other managers when quality is insufficient or QA processes are
not being adhered to
· have people judgement skills for hiring and keeping skilled personnel
· be able to communicate with technical and non-technical people, engineers, managers, and customers.
· be able to run meetings and keep them focused
35.What's the role of documentation in QA?
Critical. (Note that documentation can be electronic, not necessarily paper.) QA practices should be documented such that
they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans,
test cases, bug reports, user manuals, etc. should all be documented. There should ideally be a system for easily finding
and obtaining documents and determining what documentation will have a particular piece of information. Change
management for documentation should be used if possible.
36.What's the big deal about 'requirements'?
One of the most reliable methods of insuring problems, or failure, in a complex software project is to have poorly
documented requirements specifications. Requirements are the details describing an application's externally-perceived
functionality and properties. Requirements should be clear, complete, reasonably detailed, cohesive, attainable, and
testable. A non-testable requirement would be, for example, 'user-friendly' (too subjective). A testable requirement would
be something like 'the user must enter their previously-assigned password to access the application'. Determining and
organizing requirements details in a useful and efficient way can be a difficult effort; different methods are available
depending on the particular project. Many books are available that describe various approaches to this task.
Care should be taken to involve ALL of a project's significant 'customers' in the requirements process. 'Customers' could
be in-house personnel or out, and could include end-users, customer acceptance testers, customer contract officers,
customer management, future software maintenance engineers, salespeople, etc. Anyone who could later derail the
project if their expectations aren't met should be included if possible.
Organizations vary considerably in their handling of requirements specifications. Ideally, the requirements are spelled out
in a document with statements such as 'The product shall.....'. 'Design' specifications should not be confused with
'requirements'; design specifications should be traceable back to the requirements.
In some organizations requirements may end up in high level project plans, functional specification documents, in design
documents, or in other documents at various levels of detail. No matter what they are called, some type of documentation
with detailed requirements will be needed by testers in order to properly plan and execute tests. Without such
documentation, there will be no clear-cut way to determine if a software application is performing correctly.
37.What steps are needed to develop and run software tests?
The following are some of the steps to consider:
·Obtain requirements, functional design, and internal design specifications and other necessary documents
·Obtain budget and schedule requirements
·Determine project-related personnel and their responsibilities, reporting requirements, required standards and processes
(such as release processes, change processes, etc.)
·Identify application's higher-risk aspects, set priorities, and determine scope and limitations of tests
·Determine test approaches and methods - unit, integration, functional, system, load, usability tests, etc.
·Determine test environment requirements (hardware, software, communications, etc.)
·Determine testware requirements (record/playback tools, coverage analyzers, test tracking, problem/bug tracking, etc.)
·Determine test input data requirements
·Identify tasks, those responsible for tasks, and labor requirements
·Set schedule estimates, timelines, milestones
·Determine input equivalence classes, boundary value analyses, error classes
·Prepare test plan document and have needed reviews/approvals
·Write test cases
·Have needed reviews/inspections/approvals of test cases
·Prepare test environment and testware, obtain needed user manuals/reference documents/configuration
guides/installation guides, set up test tracking processes, set up logging and archiving processes, set up or obtain test
input data
·Obtain and install software releases
·Perform tests
·Evaluate and report results
·Track problems/bugs and fixes
·Retest as needed
·Maintain and update test plans, test cases, test environment, and testware through life cycle
38.What's a 'test plan'?
A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing
effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability
of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of
product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will
read it. The following are some of the items that might be included in a test plan, depending on the particular project:
·Title
·Identification of software including version/release numbers
·Revision history of document including authors, dates, approvals
·Table of Contents
·Purpose of document, intended audience
·Objective of testing effort
·Software product overview
·Relevant related document list, such as requirements, design documents, other test plans, etc.
·Relevant standards or legal requirements
·Traceability requirements
·Relevant naming conventions and identifier conventions
·Overall software project organization and personnel/contact-info/responsibilties
·Test organization and personnel/contact-info/responsibilities
·Assumptions and dependencies
·Project risk analysis
·Testing priorities and focus
·Scope and limitations of testing
·Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as
applicable
·Outline of data input equivalence classes, boundary value analysis, error classes
·Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems
·Test environment validity analysis - differences between the test and production systems and their impact on test validity.
·Test environment setup and configuration issues
·Software migration processes
·Software CM processes
·Test data setup requirements
·Database setup requirements
·Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to
help describe and report bugs
·Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of
bugs
·Test automation - justification and overview
·Test tools to be used, including versions, patches, etc.
·Test script/test code maintenance processes and version control
·Problem tracking and resolution - tools and processes
·Project test metrics to be used
·Reporting requirements and testing deliverables
·Software entrance and exit criteria
·Initial sanity testing period and criteria
·Test suspension and restart criteria
·Personnel allocation
·Personnel pre-training needs
·Test site/location
·Outside test organizations to be utilized and their purpose, responsibilties, deliverables, contact persons, and
coordination issues
·Relevant proprietary, classified, security, and licensing issues.
·Open issues
39.What's a 'test case'?

·A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of
an application is working correctly. A test case should contain particulars such as test case identifier, test case name,
objective, test conditions/setup, input data requirements, steps, and expected results.
·Note that the process of developing test cases can help find problems in the requirements or design of an application,
since it requires completely thinking through the operation of the application. For this reason, it's useful to prepare test
cases early in the development cycle if possible.
40.What should be done after a bug is found?
The bug needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should
be re-tested, and determinations made regarding requirements for regression testing to check that fixes didn't create
problems elsewhere. If a problem-tracking system is in place, it should encapsulate these processes. A variety of
commercial problem-tracking/management software tools are available
The following are items to consider in the tracking process:
·Complete information such that developers can understand the bug, get an idea of it's severity, and reproduce it if
necessary.
·Bug identifier (number, ID, etc.)
·Current bug status (e.g., 'Released for Retest', 'New', etc.)
·The application name or identifier and version
·The function, module, feature, object, screen, etc. where the bug occurred
·Environment specifics, system, platform, relevant hardware specifics
·Test case name/number/identifier
·One-line bug description
·Full bug description
·Description of steps needed to reproduce the bug if not covered by a test case or if the developer doesn't have easy
access to the test case/test script/test tool
·Names and/or descriptions of file/data/messages/etc. used in test
·File excerpts/error messages/log file excerpts/screen shots/test tool logs that would be helpful in finding the cause of the
problem
·Severity estimate (a 5-level range such as 1-5 or 'critical'-to-'low' is common)
·Was the bug reproducible?
·Tester name
·Test date
·Bug reporting date
·Name of developer/group/organization the problem is assigned to
·Description of problem cause
·Description of fix
·Code section/file/module/class/method that was fixed
·Date of fix
·Application version that contains the fix
·Tester responsible for retest
·Retest date
·Retest results
·Regression testing requirements
·Tester responsible for regression tests
·Regression testing results
A reporting or tracking process should enable notification of appropriate personnel at various stages. For instance, testers
need to know when retesting is needed, developers need to know when bugs are found and how to get the needed
information, and reporting/summary capabilities are needed for managers.
41.What is 'configuration management'?
Configuration management covers the processes used to control, coordinate, and track: code, requirements,
documentation, problems, change requests, designs, tools/compilers/libraries/patches, changes made to them, and who
makes the changes.
42.What if the software is so buggy it can't really be tested at all?
The best bet in this situation is for the testers to go through the process of reporting whatever bugs or blocking-type
problems initially show up, with the focus being on critical bugs. Since this type of problem can severely affect schedules,
and indicates deeper problems in the software development process (such as insufficient unit testing or insufficient
integration testing, poor design, improper build or release procedures, etc.) managers should be notified, and provided
with some documentation as evidence of the problem.
43.How can it be known when to stop testing?
This can be difficult to determine. Many modern software applications are so complex, and run in such an interdependent
environment, that complete testing can never be done. Common factors in deciding when to stop are:
·Deadlines (release deadlines, testing deadlines, etc.)
·Test cases completed with certain percentage passed
·Test budget depleted
·Coverage of code/functionality/requirements reaches a specified point
·Bug rate falls below a certain level
· Beta or alpha testing period ends
44.What if there isn't enough time for thorough testing?
Use risk analysis to determine where testing should be focused.
Since it's rarely possible to test every possible aspect of an application, every possible combination of events, every
dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. This
requires judgement skills, common sense, and experience. (If warranted, formal methods are also available.)
Considerations can include:
·Which functionality is most important to the project's intended purpose?
·Which functionality is most visible to the user?
·Which functionality has the largest safety impact?
·Which functionality has the largest financial impact on users?
·Which aspects of the application are most important to the customer?
·Which aspects of the application can be tested early in the development cycle?
·Which parts of the code are most complex, and thus most subject to errors?
·Which parts of the application were developed in rush or panic mode?
·Which aspects of similar/related previous projects caused problems?
·Which aspects of similar/related previous projects had large maintenance expenses?
·Which parts of the requirements and design are unclear or poorly thought out?
·What do the developers think are the highest-risk aspects of the application?
·What kinds of problems would cause the worst publicity?
·What kinds of problems would cause the most customer service complaints?
·What kinds of tests could easily cover multiple functionalities?
·Which tests will have the best high-risk-coverage to time-required ratio?
45.What if the project isn't big enough to justify extensive testing?
Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk
analysis is again needed and the same considerations as described previously in 'What if there isn't enough time for
thorough testing?' apply. The tester might then do ad hoc testing, or write up a limited test plan based on the risk analysis.
46.What can be done if requirements are changing continuously?
A common problem and a major headache.
·Work with the project's stakeholders early on to understand how requirements might change so that alternate test plans
and strategies can be worked out in advance, if possible.
·It's helpful if the application's initial design allows for some adaptability so that later changes do not require redoing the
application from scratch.
·If the code is well-commented and well-documented this makes changes easier for the developers.
·Use rapid prototyping whenever possible to help customers feel sure of their requirements and minimize changes.
·The project's initial schedule should allow for some extra time commensurate with the possibility of changes.
·Try to move new requirements to a 'Phase 2' version of an application, while using the original requirements for the
'Phase 1' version.
·Negotiate to allow only easily-implemented new requirements into the project, while moving more difficult new
requirements into future versions of the application.
·Be sure that customers and management understand the scheduling impacts, inherent risks, and costs of significant
requirements changes. Then let management or the customers (not the developers or testers) decide if the changes are
warranted - after all, that's their job.
·Balance the effort put into setting up automated testing with the expected effort required to re-do them to deal with
changes.
·Try to design some flexibility into automated test scripts.
·Focus initial automated testing on application aspects that are most likely to remain unchanged.
·Devote appropriate effort to risk analysis of changes to minimize regression testing needs.
·Design some flexibility into test cases (this is not easily done; the best bet might be to minimize the detail in the test
cases, or set up only higher-level generic-type test plans)
· Focus less on detailed test plans and test cases and more on ad hoc testing (with an understanding of the added risk
that this entails).
47.What if the application has functionality that wasn't in the requirements?
It may take serious effort to determine if an application has significant unexpected or hidden functionality, and it would
indicate deeper problems in the software development process. If the functionality isn't necessary to the purpose of the
application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by
the designer or the customer. If not removed, design information will be needed to determine added testing needs or
regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected
functionality. If the functionality only effects areas such as minor improvements in the user interface, for example, it may
not be a significant risk.
48.How can Software QA processes be implemented without stifling productivity?
By implementing QA processes slowly over time, using consensus to reach agreement on processes, and adjusting and
experimenting as an organization grows and matures, productivity will be improved instead of stifled. Problem prevention
will lessen the need for problem detection, panics and burn-out will decrease, and there will be improved focus and less
wasted effort. At the same time, attempts should be made to keep processes simple and efficient, minimize paperwork,
promote computer-based processes and automated tracking and reporting, minimize time required in meetings, and
promote training as part of the QA process. However, no one - especially talented technical types - likes rules or
bureacracy, and in the short run things may slow down a bit. A typical scenario would be that more days of planning and
development will be needed, but less time will be required for late-night bug-fixing and calming of irate customers.
49.What if an organization is growing so fast that fixed QA processes are impossible?
This is a common problem in the software industry, especially in new technology areas. There is no easy solution in this
situation, other than:
· Hire good people
· Management should 'ruthlessly prioritize' quality issues and maintain focus on the customer
· Everyone in the organization should be clear on what 'quality' means to the customer
50.How does a client/server environment affect testing?
Client/server applications can be quite complex due to the multiple dependencies among clients, data communications,
hardware, and servers. Thus testing requirements can be extensive. When time is limited (as it usually is) the focus
should be on integration and system testing. Additionally, load/stress/performance testing may be useful in determining
client/server application limitations and capabilities. There are commercial tools to assist with such testing.
51.How can World Wide Web sites be tested?
Web sites are essentially client/server applications - with web servers and 'browser' clients. Consideration should be given
to the interactions between html pages, TCP/IP communications, Internet connections, firewalls, applications that run in
web pages (such as applets, javascript, plug-in applications), and applications that run on the server side (such as cgi
scripts, database interfaces, logging applications, dynamic page generators, asp, etc.). Additionally, there are a wide
variety of servers and browsers, various versions of each, small but sometimes significant differences between them,
variations in connection speeds, rapidly changing technologies, and multiple standards and protocols. The end result is
that testing for web sites can become a major ongoing effort. Other considerations might include:
·What are the expected loads on the server (e.g., number of hits per unit time?), and what kind of performance is required
under such loads (such as web server response time, database query response times). What kinds of tools will be needed
for performance testing (such as web load testing tools, other tools already in house that can be adapted, web robot
downloading tools, etc.)?
·Who is the target audience? What kind of browsers will they be using? What kind of connection speeds will they by
using? Are they intra- organization (thus with likely high connection speeds and similar browsers) or Internet-wide (thus
with a wide variety of connection speeds and browser types)?
·What kind of performance is expected on the client side (e.g., how fast should pages appear, how fast should animations,
applets, etc. load and run)?
·Will down time for server and content maintenance/upgrades be allowed? how much?
·What kinds of security (firewalls, encryptions, passwords, etc.) will be required and what is it expected to do? How can it
be tested?
·How reliable are the site's Internet connections required to be? And how does that affect backup system or redundant
connection requirements and testing?
·What processes will be required to manage updates to the web site's content, and what are the requirements for
maintaining, tracking, and controlling page content, graphics, links, etc.?
·Which HTML specification will be adhered to? How strictly? What variations will be allowed for targeted browsers?
·Will there be any standards or requirements for page appearance and/or graphics throughout a site or parts of a site??
·How will internal and external links be validated and updated? how often?
·Can testing be done on the production system, or will a separate test system be required? How are browser caching,
variations in browser option settings, dial-up connection variabilities, and real-world internet 'traffic congestion' problems
to be accounted for in testing?
·How extensive or customized are the server logging and reporting requirements; are they considered an integral part of
the system and do they require testing?
· How are cgi programs, applets, javascripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested?
site security information include the Usenet newsgroup 'comp.security.announce' and links concerning web site security
Some usability guidelines to consider - these are subjective and may or may not apply to a given situation
·Pages should be 3-5 screens max unless content is tightly focused on a single topic. If larger, provide internal links within
the page.
·The page layouts and design elements should be consistent throughout a site, so that it's clear to the user that they're still
within a site.
·Pages should be as browser-independent as possible, or pages should be provided or generated based on the browser-
type.
·All pages should have links external to the page; there should be no dead-end pages.
· The page owner, revision date, and a link to a contact person or organization should be included on each page.
52.How is testing affected by object-oriented designs?
Well-engineered object-oriented design can make it easier to trace from code to internal design to functional design to
requirements. While there will be little affect on black box testing (where an understanding of the internal design of the
application is unnecessary), white-box testing can be oriented to the application's objects. If the application was well-
designed this can simplify test design.
53.What is Extreme Programming and what's it got to do with testing?
Extreme Programming (XP) is a software development approach for small teams on risk-prone projects with unstable
requirements. It was created by Kent Beck who described the approach in his book 'Extreme Programming Explained
.Testing ('extreme testing') is a core aspect of Extreme Programming. Programmers are expected to write unit and
functional test code first - before the application is developed. Test code is under source control along with the rest of the
code. Customers are expected to be an integral part of the project team and to help develope scenarios for
acceptance/black box testing. Acceptance tests are preferably automated, and are modified and rerun for each of the
frequent development iterations. QA and test personnel are also required to be an integral part of the project team.
Detailed requirements documentation is not used, and frequent re-scheduling, re-estimating, and re-prioritizing is
expected.
54.What are all the basic strategies for dealing with new code?
? Start with obvious and simple test
? Test each function sympathetically
? Test broadly before deeply
? Look for more powerful tests
? Expand your scope
? Do some freestyle exploratory testing
55.What is acceptance testing?
Its a formal testing conducted to determine whether a system satisfies its acceptance criteria -enables an end user to
determine whether or not to accept the system
56.What is functionality testing?
Its a mandatory part in black box testing and is also known as requirement testing. During this testing testing team will
validates the correctness of every functionality in terms of behavioral coverage,calculation coverage,input domain
coverage and back end coverage.
57.What is GUI testing?
This testing is done against the windows compliance standards such as each windows present in the application,text
boxes,options(radio buttons),check boxes,command buttons,drop down list boxes.
58.What is Retesting?
Testing of a particular test cases to check whether the bug is fixed or not.
59.What is the difference between functional testing and functionality testing?
Functional testing is a mandatory part in black box testing.
Functionality testing is also known as requirement testing,during this test testing validates the correctness of every
functionality in terms of behavioural coverage,calculation coverage,input domain coverage,back end coverage
60.How to log defects in manual testing?
When you find a bug u have to post it in your company's issue tracker(as discovery or open status).While post the bug do
not forget to mention the summary,description,build version,screen shot,step to reproduce,severity and reproducibility of
the bug.
61.When to use regression testing and retesting?
Retesting:In retesting we are going to check whether the bug is fixed or not.
Regression: It means after getting conformation the bug is fixed,we are going to check the fixation is going to create any
problems in the application or not.
62.What are all the main actions which will be taken by the project manager for testing a product?
1) Assess risks for the project as a whole
2) Assess the risk associated with the testing sub-project
3) Lay out criteria for important milestones and stick to them
4) Develop a project plan for the testing sub project
5) Track testing progress against the plan
63.What are all the important factors want to be trade-off when building a product?
1. Time to market
2. Cost to market
3. Reliability of delivered product
4. Feature set
64.What are all the favorite risks will be arised during the project plan?
? Are there fixed dates that must be met for milestones or components of the product?
? How likely is it that the test group will get the software on schedule?
? What technical areas of the product do the current members of the test group not understand?
? Which areas of the program must be well tested?
? Are there regulatory or legal requirements that the product must meet?
65.What is Guerilla testing?
It involves ad hoc testing done by some one who is skilled at finding errors on the fly. It is one person's best shot at finding
bugs. This approach is typically time limited.
66.What is combinatorial testing?
The most comprehensive approach to testing program-input combinations is referred to as combinatorial testing. In this
testing all possible combinations of the test data values selected for the program inputs are tested
Win Runner Q & A Part 1

1) Explain WinRunner testing process?
a) WinRunner testing process involves six main stages
i.Create GUI Map File so that WinRunner can recognize the GUI objects in the application being tested
ii.Create test scripts by recording, programming, or a combination of both. While recording tests, insert checkpoints where
you want to check the response of the application being tested.
iii.Debug Test: run tests in Debug mode to make sure they run smoothly
iv.Run Tests: run tests in Verify mode to test your application.
v.View Results: determines the success or failure of the tests.
vi.Report Defects: If a test run fails due to a defect in the application being tested, you can report information about the
defect directly from the Test Results window.
2) What is contained in the GUI map?
a) WinRunner stores information it learns about a window or object in a GUI Map. When WinRunner runs a test, it uses
the GUI map to locate objects. It reads an object’s description in the GUI map and then looks for an object with the same
properties in the application being tested. Each of these objects in the GUI Map file will be having a logical name and a
physical description.
b) There are 2 types of GUI Map files.
i.Global GUI Map file: a single GUI Map file for the entire application
ii.GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created.
3) How does WinRunner recognize objects on the application?
a) WinRunner uses the GUI Map file to recognize objects on the application. When WinRunner runs a test, it uses the GUI
map to locate objects. It reads an object’s description in the GUI map and then looks for an object with the same
properties in the application being tested.
4) Have you created test scripts and what is contained in the test scripts?
a) Yes I have created test scripts. It contains the statement in Mercury Interactive’s Test Script Language (TSL). These
statements appear as a test script in a test window. You can then enhance your recorded test script, either by typing in
additional TSL functions and programming elements or by using WinRunner’s visual programming tool, the Function
Generator.
5) How does WinRunner evaluates test results?
a) Following each test run, WinRunner displays the results in a report. The report details all the major events that occurred
during the run, such as checkpoints, error messages, system messages, or user messages. If mismatches are detected at
checkpoints during the test run, you can view the expected results and the actual results from the Test Results window.
6) Have you performed debugging of the scripts?

a) Yes, I have performed debugging of scripts. We can debug the script by executing the script in the debug mode. We
can also debug script using the Step, Step Into, Step out functionalities provided by the WinRunner.
7) How do you run your test scripts?
a) We run tests in Verify mode to test your application. Each time WinRunner encounters a checkpoint in the test script, it
compares the current data of the application being tested to the expected data captured earlier. If any mismatches are
found, WinRunner captures them as actual results.
8) How do you analyze results and report the defects?
checkpoints during the test run, you can view the expected results and the actual results from the Test Results window. If
a test run fails due to a defect in the application being tested, you can report information about the defect directly from the
Test Results window. This information is sent via e-mail to the quality assurance manager, who tracks the defect until it is
fixed.
9) What are the different modes of recording?
a) There are two type of recording in WinRunner.
i.Context Sensitive recording records the operations you perform on your application by identifying Graphical User
Interface (GUI) objects.
ii.Analog recording records keyboard input, mouse clicks, and the precise x- and y-coordinates traveled by the mouse
pointer across the screen.
10) What is the purpose of loading WinRunner Add-Ins?
a) Add-Ins are used in WinRunner to load functions specific to the particular add-in to the memory. While creating a script
only those functions in the add-in selected will be listed in the function generator and while executing the script only those
functions in the loaded add-in will be executed else WinRunner will give an error message saying it does not recognize
the function.

11.How to modify the logical name or physical description of the object?
Using GUI editor
12.How Winrunner handles varying window labels?
Using regular expressions
13.How do you write messages to the report?
report_msg
14. How you used WinRunner in your project?
Yes, I have been WinRunner for creating automates scripts for GUI, functional and regression testing of the AUT.
15. Explain WinRunner testing process?
WinRunner testing process involves six main stages
i.Create GUI Map File so that WinRunner can recognize the GUI objects in the application being tested
ii.Create test scripts by recording, programming, or a combination of both. While recording tests, insert checkpoints where
you want to check the response of the application being tested.
iiiDebug Test: run tests in Debug mode to make sure they run smoothly
iv.Run Tests: run tests in Verify mode to test your application.
v.View Results: determines the success or failure of the tests.
vi.Report Defects: If a test run fails due to a defect in the application being tested, you can report information about the
defect directly from the Test Results window.
16. What in contained in the GUI map?
a) WinRunner stores information it learns about a window or object in a GUI Map. When WinRunner runs a test, it uses
the GUI map to locate objects. It reads an object’s description in the GUI map and then looks for an object with the same
properties in the application being tested. Each of these objects in the GUI Map file will be having a logical name and a
physical description.
b) There are 2 types of GUI Map files.
i.Global GUI Map file: a single GUI Map file for the entire application
ii.GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created.
17. How does WinRunner recognize objects on the application?
a)WinRunner uses the GUI Map file to recognize objects on the application. When WinRunner runs a test, it uses the GUI
map to locate objects. It reads anobject’sdescription in the GUI map and then looks for an object with the same properties
in the application being tested.
18. Have you created test scripts and what is contained in the test scripts?
a) Yes I have created test scripts. It contains the statement in Mercury Interactive’s Test Script Language (TSL). These
statements appear as a test script in a test window. You can then enhance your recorded test script, either by typing in
additional TSL functions and programming elements or by using WinRunner’s visual programming tool, the Function
Generator.
19. How does WinRunner evaluates test results?
checkpoints during the test run, you can view the expected results and the actual results from the Test Results window.
20. Have you performed debugging of the scripts?
a) Yes, I have performed debugging of scripts. We can debug the script by executing the script in the debug mode. We
can also debug script using the Step, Step Into, Step out functionalities provided by the WinRunner.
1.What is the testing process?
2.Verifying that an input data produce the expected output.
3.What is the difference between testing and debugging?
4.What is the difference between structural and functional testing?
5.What is a bug? What types of bugs do you know?
6.Bug is a error during execution of the program.
7.What is the difference between testing and quality assurance (QA)?
8.What kinds of testing do you know? What is it system testing? What is it integration testing? What is a unit testing?
9.Tell me about ur self?
10.Process in ur company?
11.Responsibilities in the project?
12.Manual and automation exp?
13.How many test cases u have written in ur model?
14.Why u have automated ur project?
15.For exmp out of 100 test cases if I ask you to automate how many you can automate?
16.What features you have frequently used in wr?
17.In your cv you have mention few types of testing tell me about that?
18.Role ur self in wr?
19.You know about trasability matrix if so tell me the fields of that?
20.Few tsl functions in wr?
21.What do u mean by regression testing have u done ?
22.You have any idea about back end testing?
23.Tell me about u r project?
24.Who is the client of ur company?
25.What is the concept of your project and which domain?
26.How many modules are there in your project and which module you have worked?
27.Can u tell me the data flow in the module?
28.What do u mean mean by integration testing?
29.Can u differ data flow and control flow?
30.Tell me about your way of written scripting?
31. How do you view the contents of the GUI map?
a) GUI Map editor displays the content of a GUI Map. We can invoke GUI Map Editor from the Tools Menu in WinRunner.
The GUI Map Editor displays the various GUI Map files created and the windows and objects learned in to them with their
logical name and physical description.
32. When you create GUI map do you record all the objects of specific objects?
a) If we are learning a window then WinRunner automatically learns all the objects in the window else we will we
identifying those object, which are to be learned in a window, since we will be working with only those objects while
creating scripts.
33. What is the purpose of set_window command?
a) Set_Window command sets the focus to the specified window. We use this command to set the focus to the required
window before executing tests on a particular window.
Syntax: set_window(<logical name>, time);
The logical name is the logical name of the window and time is the time the execution has to wait till it gets the given
window into focus.
34. How do you load GUI map?
a) We can load a GUI Map by using the GUI_load command.
Syntax: GUI_load(<file_name>);
35. What is the disadvantage of loading the GUI maps through start up scripts?
a) If we are using a single GUI Map file for the entire AUT then the memory used by the GUI Map may be much high.
b) If there is any change in the object being learned then WinRunner will not be able to recognize the object, as it is not in
the GUI Map file loaded in the memory. So we will have to learn the object again and update the GUI File and reload it.
36. How do you unload the GUI map?
a) We can use GUI_close to unload a specific GUI Map file or else we call use GUI_close_all command to unload all the
GUI Map files loaded in the memory.
Syntax: GUI_close(<file_name>); or GUI_close_all;
37. What actually happens when you load GUI map?
a) When we load a GUI Map file, the information about the windows and the objects with their logical names and physical
description are loaded into memory. So when the WinRunner executes a script on a particular window, it can identify the
objects using this information loaded in the memory.
38. What is the purpose of the temp GUI map file?
a) While recording a script, WinRunner learns objects and windows by itself. This is actually stored into the temporary GUI
Map file. We can specify whether we have to load this temporary GUI Map file should be loaded each time in the General
Options.
39. What is the extension of gui map file?
a) The extension for a GUI Map file is “.gui”.
40. How do you find an object in an GUI map.
a) The GUI Map Editor is been provided with a Find and Show Buttons.
i To find a particular object in the GUI Map file in the application, select the object and click the Show window. This blinks
the selected object.
ii.To find a particular object in a GUI Map file click the Find button, which gives the option to select the object. When the
object is selected, if the object has been learned to the GUI Map file it will be focused in the GUI Map file.
41. What different actions are performed by find and show button?
a) To find a particular object in the GUI Map file in the application, select the object and click the Show window. This blinks
the selected object.
b) To find a particular object in a GUI Map file click the Find button, which gives the option to select the object. When the
object is selected, if the object has been learned to the GUI Map file it will be focused in the GUI Map file.
42. How do you identify which files are loaded in the GUI map?
a) The GUI Map Editor has a drop down “GUI File” displaying all the GUI Map files loaded into the memory.
43. How do you modify the logical name or the physical description of the objects in GUI map?
a) You can modify the logical name or the physical description of an object in a GUI map file using the GUI Map Editor.
44. When do you feel you need to modify the logical name?
a) Changing the logical name of an object is useful when the assigned logical name is not sufficiently descriptive or is too
long.
45. When it is appropriate to change physical description?
a) Changing the physical description is necessary when the property value of an object changes.
46. How WinRunner handles varying window labels?
a) We can handle varying window labels using regular expressions. WinRunner uses two “hidden” properties in order to
use regular expression in an object’s physical description. These properties are regexp_label and regexp_MSW_class.
i.The regexp_label property is used for windows only. It operates “behind the scenes” to insert a regular expression into a
window’s label description.
ii.The regexp_MSW_class property inserts a regular expression into an object’s MSW_class. It is obligatory for all types of
windows and for the object class object.
[
47. What is the purpose of regexp_label property and regexp_MSW_class property?
a) The regexp_label property is used for windows only. It operates “behind the scenes” to insert a regular expression into
a window’s label description.
b) The regexp_MSW_class property inserts a regular expression into an object’s MSW_class. It is obligatory for all types
of windows and for the object class object.
48. How do you suppress a regular expression?
a) We can suppress the regular expression of a window by replacing the regexp_label property with label property.
49. How do you copy and move objects between different GUI map files?
a) We can copy and move objects between different GUI Map files using the GUI Map Editor. The steps to be followed
are:
i Choose Tools > GUI Map Editor to open the GUI Map Editor.
ii.Choose View > GUI Files.
iii.Click Expand in the GUI Map Editor. The dialog box expands to display two GUI map files simultaneously.
iv. View a different GUI map file on each side of the dialog box by clicking the file names in the GUI File lists.
v.In one file, select the objects you want to copy or move. Use the Shift key and/or Control key to select multiple objects.
To select all objects in a GUI map file, choose Edit > Select All.
vi.Click Copy or Move.
vii.To restore the GUI Map Editor to its original size, click Collapse.
50. How do you select multiple objects during merging the files?
a) Use the Shift key and/or Control key to select multiple objects. To select all objects in a GUI map file, choose Edit >
Select All.
51. How do you clear a GUI map files?
a) We can clear a GUI Map file using the “Clear All” option in the GUI Map Editor.
52. How do you filter the objects in the GUI map?
a) GUI Map Editor has a Filter option. This provides for filtering with 3 different types of options.
i. Logical name displays only objects with the specified logical name.
ii. Physical description displays only objects matching the specified physical description. Use any substring belonging to
the physical description.
iii. Class displays only objects of the specified class, such as all the push buttons.
53.How do you configure gui map?
a) When WinRunner learns the description of a GUI object, it does not learn all its properties. Instead, it learns the
minimum number of properties to provide a unique identification of the object.
b) Many applications also contain custom GUI objects. A custom object is any object not belonging to one of the standard
classes used by WinRunner. These objects are therefore assigned to the generic “object” class. When WinRunner records
an operation on a custom object, it generates obj_mouse_ statements in the test script.
c) If a custom object is similar to a standard object, you can map it to one of the standard classes. You can also configure
the properties WinRunner uses to identify a custom object during Context Sensitive testing. The mapping and the
configuration you set are valid only for the current WinRunner session. To make the mapping and the configuration
permanent, you must add configuration statements to your startup test script.
54.W hat is the purpose of GUI map configuration?
a) GUI Map configuration is used to map a custom object to a standard object.
55. How do you make the configuration and mappings permanent?
a) The mapping and the configuration you set are valid only for the current WinRunner session. To make the mapping and
the configuration permanent, you must add configuration statements to your startup test script.
56. What is the purpose of GUI spy?
a) Using the GUI Spy, you can view the properties of any GUI object on your desktop. You use the Spy pointer to point to
an object, and the GUI Spy displays the properties and their values in the GUI Spy dialog box. You can choose to view all
the properties of an object, or only the selected set of properties that WinRunner learns.
57. What is the purpose of obligatory and optional properties of the objects?
a) For each class, WinRunner learns a set of default properties. Each default property is classified “obligatory” or
“optional”.
i. An obligatory property is always learned (if it exists).
ii.An optional property is used only if the obligatory properties do not provide unique identification of an object. These
optional properties are stored in a list. WinRunner selects the minimum number of properties from this list that are
necessary to identify the object. It begins with the first property in the list, and continues, if necessary, to add properties to
the description until it obtains unique identification for the object.
58. When the optional properties are learned?
a) An optional property is used only if the obligatory properties do not provide unique identification of an object.
59. What is the purpose of location indicator and index indicator in GUI map configuration?
a) In cases where the obligatory and optional properties do not uniquely identify an object, WinRunner uses a selector to
differentiate between them. Two types of selectors are available:
i. A location selector uses the spatial position of objects.
1. The location selector uses the spatial order of objects within the window, from the top left to the bottom right corners, to
differentiate among objects with the same description.
ii. An index selector uses a unique number to identify the object in a window.
1. The index selector uses numbers assigned at the time of creation of objects to identify the object in a window. Use this
selector if the location of objects with the same description may change within a window.
60. How do you handle custom objects?
a) A custom object is any GUI object not belonging to one of the standard classes used by WinRunner. WinRunner learns
such objects under the generic “object” class. WinRunner records operations on custom objects using obj_mouse_
statements.
b) If a custom object is similar to a standard object, you can map it to one of the standard classes. You can also configure
the properties WinRunner uses to identify a custom object during Context Sensitive testing.
61. What is the name of custom class in WinRunner and what methods it applies on the custom
objects?
a) WinRunner learns custom class objects under the generic “object” class. WinRunner records
operations on custom objects using obj_ statements.
62. In a situation when obligatory and optional both the properties cannot uniquely identify an object
what method WinRunner applies?
a) In cases where the obligatory and optional properties do not uniquely identify an object,
WinRunner uses a selector to differentiate between them. Two types of selectors are available:
i. A location selector uses the spatial position of objects.
ii. An index selector uses a unique number to identify the object in a window.
63 What is the purpose of different record methods 1) Record 2) Pass up 3) As Object 4) Ignore.
a) Record instructs WinRunner to record all operations performed on a GUI object. This is the default
record method for all classes. (The only exception is the static class (static text), for which the default
is Pass Up.)
b) Pass Up instructs WinRunner to record an operation performed on this class as an operation
performed on the element containing the object. Usually this element is a window, and the operation
is recorded as win_mouse_click.
c) As Object instructs WinRunner to record all operations performed on a GUI object as though its
class were “object” class.
d) Ignore instructs WinRunner to disregard all operations performed on the class.
64. How do you find out which is the start up file in WinRunner?
a) The test script name in the Startup Test box in the Environment tab in the General Options dialog
box is the start up file in WinRunner.
65. What are the virtual objects and how do you learn them?
a) Applications may contain bitmaps that look and behave like GUI objects. WinRunner records
operations on these bitmaps using win_mouse_click statements. By defining a bitmap as a virtual
object, you can instruct WinRunner to treat it like a GUI object such as a push button, when you
record and run tests.
b) Using the Virtual Object wizard, you can assign a bitmap to a standard object class, define the
coordinates of that object, and assign it a logical name.
To define a virtual object using the Virtual Object wizard:
i. Choose Tools > Virtual Object Wizard. The Virtual Object wizard opens. Click Next.
ii. In the Class list, select a class for the new virtual object. If rows that are displayed in the window.
For a table class, select the number of visible rows and columns. Click Next.
iii. Click Mark Object. Use the crosshairs pointer to select the area of the virtual object. You can use
the arrow keys to make precise adjustments to the area you define with the crosshairs. Press Enter or
click the right mouse button to display the virtual object’s coordinates in the wizard. If the object
marked is visible on the screen, you can click the Highlight button to view it. Click Next.
iv.Assign a logical name to the virtual object. This is the name that appears in the test script when you
record on the virtual object. If the object contains text that WinRunner can read, the wizard suggests
using this text for the logical name. Otherwise, WinRunner suggests virtual_object,
virtual_push_button, virtual_list, etc.
v. You can accept the wizard’s suggestion or type in a different name. WinRunner checks that there
are no other objects in the GUI map with the same name before confirming your choice. Click Next.
66.H ow you created you test scripts 1) by recording or 2) programming?
a) Programming. I have done complete programming only, absolutely no recording.
67. What are the two modes of recording?
a) There are 2 modes of recording in WinRunner
i.Context Sensitive recording records the operations you perform on your application by identifying
Graphical User Interface (GUI) objects.
ii.Analog recording records keyboard input, mouse clicks, and the precise x- and y-coordinates
traveled by the mouse pointer across the screen.
68. What is a checkpoint and what are different types of checkpoints?
a) Checkpoints allow you to compare the current behavior of the application being tested to its
behavior in an earlier version.
You can add four types of checkpoints to your test scripts:
i. GUI checkpoints verify information about GUI objects. For example, you can check that a button is
enabled or see which item is selected in a list.
ii. Bitmap checkpoints take a “snapshot” of a window or area of your application and compare this to
an image captured in an earlier version.
iii. Text checkpoints read text in GUI objects and in bitmaps and enable you to verify their contents.
iv. Database checkpoints check the contents and the number of rows and columns of a result set,
which is based on a query you create on your database.
69. What are data driven tests?
71. What is parameterizing?
a) In order for WinRunner to use data to drive the test, you must link the data to the test script which it drives. This is
called parameterizing your test. The data is stored in a data table.
72. How do you maintain the document information of the test scripts?
a) Before creating a test, you can document information about the test in the General and Description tabs of the Test
Properties dialog box. You can enter the name of the test author, the type of functionality tested, a detailed description of
the test, and a reference to the relevant functional specifications document.
73. What do you verify with the GUI checkpoint for single property and what command it generates, explain syntax?
a) You can check a single property of a GUI object. For example, you can check whether a button is enabled or disabled
or whether an item in a list is selected. To create a GUI checkpoint for a property value, use the Check Property dialog
box to add one of the following functions to the test script:
i. button_check_info
ii. scroll_check_info
iii. edit_check_info
iv. static_check_info
v. list_check_info
vi. win_check_info
vii. obj_check_info
Syntax: button_check_info (button, property, property_value );
edit_check_info ( edit, property, property_value );
74. What do you verify with the GUI checkpoint for object/window and what command it generates, explain syntax?
a) You can create a GUI checkpoint to check a single object in the application being tested. You can either check the
object with its default properties or you can specify which properties to check.
b) Creating a GUI Checkpoint using the Default Checks
i. You can create a GUI checkpoint that performs a default check on the property recommended by WinRunner. For
example, if you create a GUI checkpoint that checks a push button, the default check verifies that the push button is
enabled.
ii. To create a GUI checkpoint using default checks:
1. Choose Create > GUI Checkpoint > For Object/Window, or click the GUI Checkpoint for Object/Window button on the
User toolbar. If you are recording in Analog mode, press the CHECK GUI FOR OBJECT/WINDOW softkey in order to
avoid extraneous mouse movements. Note that you can press the CHECK GUI FOR OBJECT/WINDOW softkey in
Context Sensitive mode as well. The WinRunner window is minimized, the mouse pointer becomes a pointing hand, and a
help window opens on the screen.
2. Click an object.
3. WinRunner captures the current value of the property of the GUI object being checked and stores it in the test’s
expected results folder. The WinRunner window is restored and a GUI checkpoint is inserted in the test script as an
obj_check_gui statement
Syntax: win_check_gui ( window, checklist, expected_results_file, time );
c) Creating a GUI Checkpoint by Specifying which Properties to Check
d) You can specify which properties to check for an object. For example, if you create a checkpoint that checks a push
button, you can choose to verify that it is in focus, instead of enabled.
e) To create a GUI checkpoint by specifying which properties to check:
i. Choose Create > GUI Checkpoint > For Object/Window, or click the GUI Checkpoint for Object/Window button on the
User toolbar. If you are recording in Analog mode, press the CHECK GUI FOR OBJECT/WINDOW softkey in order to
avoid extraneous mouse movements. Note that you can press the CHECK GUI FOR OBJECT/WINDOW softkey in
Context Sensitive mode as well. The WinRunner window is minimized, the mouse pointer becomes a pointing hand, and a
help window opens on the screen.
ii. Double-click the object or window. The Check GUI dialog box opens.
iii. Click an object name in the Objects pane. The Properties pane lists all the properties for the selected object.
iv. Select the properties you want to check.
1. To edit the expected value of a property, first select it. Next, either click the Edit Expected Value button, or double-click
the value in the Expected Value column to edit it.
2. To add a check in which you specify arguments, first select the property for which you want to specify arguments. Next,
either click the Specify Arguments button, or double-click in the Arguments column. Note that if an ellipsis (three dots)
appears in the Arguments column, then you must specify arguments for a check on this property. (You do not need to
specify arguments if a default argument is specified.) When checking standard objects, you only specify arguments for
certain properties of edit and static text objects. You also specify arguments for checks on certain properties of
nonstandard objects.
3. To change the viewing options for the properties of an object, use the Show Properties buttons.
4. Click OK to close the Check GUI dialog box. WinRunner captures the GUI information and stores it in the test’s
expected results folder. The WinRunner window is restored and a GUI checkpoint is inserted in the test script as an
obj_check_gui or a win_check_gui statement.
obj_check_gui ( object, checklist, expected results file, time );
75. What do you verify with the GUI checkpoint for multiple objects and what command it generates, explain syntax?
a) To create a GUI checkpoint for two or more objects:
i. Choose Create > GUI Checkpoint > For Multiple Objects or click the GUI Checkpoint for Multiple Objects button on the
User toolbar. If you are recording in Analog mode, press the CHECK GUI FOR MULTIPLE OBJECTS softkey in order to
avoid extraneous mouse movements. The Create GUI Checkpoint dialog box opens.
ii. Click the Add button. The mouse pointer becomes a pointing hand and a help window opens.
iii. To add an object, click it once. If you click a window title bar or menu bar, a help window prompts you to check all the
objects in the window.
iv. The pointing hand remains active. You can continue to choose objects by repeating step 3 above for each object you
want to check.
v. Click the right mouse button to stop the selection process and to restore the mouse pointer to its original shape. The
Create GUI Checkpoint dialog box reopens.
vi. The Objects pane contains the name of the window and objects included in the GUI checkpoint. To specify which
objects to check, click an object name in the Objects pane. The Properties pane lists all the properties of the object. The
default properties are selected.
1. To edit the expected value of a property, first select it. Next, either click the Edit Expected Value button, or double-click
the value in the Expected Value column to edit it.
2. To add a check in which you specify arguments, first select the property for which you want to specify arguments. Next,
either click the Specify Arguments button, or double-click in the Arguments column. Note that if an ellipsis appears in the
Arguments column, then you must specify arguments for a check on this property. (You do not need to specify arguments
if a default argument is specified.) When checking standard objects, you only specify arguments for certain properties of
edit and static text objects. You also specify arguments for checks on certain properties of nonstandard objects.
3. To change the viewing options for the properties of an object, use the Show Properties buttons.
vii. To save the checklist and close the Create GUI Checkpoint dialog box, click OK. WinRunner captures the current
property values of the selected GUI objects and stores it in the expected results folder. A win_check_gui statement is
inserted in the test script.
obj_check_gui ( object, checklist, expected results file, time );
76. What information is contained in the checklist file and in which file expected results are stored?
a) The checklist file contains information about the objects and the properties of the object we are verifying.
b) The gui*.chk file contains the expected results which is stored in the exp folder
77. What do you verify with the bitmap check point for object/window and what command it generates, explain syntax?
a) You can check an object, a window, or an area of a screen in your application as a bitmap. While creating a test, you
indicate what you want to check. WinRunner captures the specified bitmap, stores it in the expected results folder (exp) of
the test, and inserts a checkpoint in the test script. When you run the test, WinRunner compares the bitmap currently
displayed in the application being tested with the expected bitmap stored earlier. In the event of a mismatch, WinRunner
captures the current actual bitmap and generates a difference bitmap. By comparing the three bitmaps (expected, actual,
and difference), you can identify the nature of the discrepancy.
b) When working in Context Sensitive mode, you can capture a bitmap of a window, object, or of a specified area of a
screen. WinRunner inserts a checkpoint in the test script in the form of either a win_check_bitmap or obj_check_bitmap
statement.
c) Note that when you record a test in Analog mode, you should press the CHECK BITMAP OF WINDOW softkey or the
CHECK BITMAP OF SCREEN AREA softkey to create a bitmap checkpoint. This prevents WinRunner from recording
extraneous mouse movements. If you are programming a test, you can also use the Analog function check_window to
check a bitmap.
d) To capture a window or object as a bitmap:
i. Choose Create > Bitmap Checkpoint > For Object/Window or click the Bitmap Checkpoint for Object/Window button on
the User toolbar. Alternatively, if you are recording in Analog mode, press the CHECK BITMAP OF OBJECT/WINDOW
softkey. The WinRunner window is minimized, the mouse pointer becomes a pointing hand, and a help window opens.
ii. Point to the object or window and click it. WinRunner captures the bitmap and generates a win_check_bitmap or
obj_check_bitmap statement in the script. The TSL statement generated for a window bitmap has the following syntax:
win_check_bitmap ( object, bitmap, time );
iii. For an object bitmap, the syntax is:
obj_check_bitmap ( object, bitmap, time );
iv. For example, when you click the title bar of the main window of the Flight Reservation application, the resulting
statement might be:
win_check_bitmap ("Flight Reservation", "Img2", 1);
v. However, if you click the Date of Flight box in the same window, the statement might be:
obj_check_bitmap ("Date of Flight:", "Img1", 1);
Syntax: obj_check_bitmap ( object, bitmap, time [, x, y, width, height] );
78. What do you verify with the bitmap checkpoint for screen area and what command it generates, explain syntax?
a) You can define any rectangular area of the screen and capture it as a bitmap for comparison. The area can be any size:
it can be part of a single window, or it can intersect several windows. The rectangle is identified by the coordinates of its
upper left and lower right corners, relative to the upper left corner of the window in which the area is located. If the area
intersects several windows or is part of a window with no title (for example, a popup window), its coordinates are relative
to the entire screen (the root window).
b) To capture an area of the screen as a bitmap:
i. Choose Create > Bitmap Checkpoint > For Screen Area or click the Bitmap Checkpoint for Screen Area button.
Alternatively, if you are recording in Analog mode, press the CHECK BITMAP OF SCREEN AREA softkey. The
WinRunner window is minimized, the mouse pointer becomes a crosshairs pointer, and a help window opens.
ii. Mark the area to be captured: press the left mouse button and drag the mouse pointer until a rectangle encloses the
area; then release the mouse button.
iii. Press the right mouse button to complete the operation. WinRunner captures the area and generates a
win_check_bitmap statement in your script.
iv. The win_check_bitmap statement for an area of the screen has the following syntax:
win_check_bitmap ( window, bitmap, time, x, y, width, height );
79. What do you verify with the database checkpoint default and what command it generates, explain syntax?
a) By adding runtime database record checkpoints you can compare the information in your application during a test run
with the corresponding record in your database. By adding standard database checkpoints to your test scripts, you can
check the contents of databases in different versions of your application.
b) When you create database checkpoints, you define a query on your database, and your database checkpoint checks
the values contained in the result set. The result set is set of values retrieved from the results of the query.
c) You can create runtime database record checkpoints in order to compare the values displayed in your application
during the test run with the corresponding values in the database. If the comparison does not meet the success criteria
you
d) specify for the checkpoint, the checkpoint fails. You can define a successful runtime database record checkpoint as one
where one or more matching records were found, exactly one matching record was found, or where no matching records
are found.
e) You can create standard database checkpoints to compare the current values of the properties of the result set during
the test run to the expected values captured during recording or otherwise set before the test run. If the expected results
and the current results do not match, the database checkpoint fails. Standard database checkpoints are useful when the
expected results can be established before the test run.
Syntax: db_check(<checklist_file>, <expected_restult>);
f) You can add a runtime database record checkpoint to your test in order to compare information that appears in your
application during a test run with the current value(s) in the corresponding record(s) in your database. You add runtime
database record checkpoints by running the Runtime Record Checkpoint wizard. When you are finished, the wizard
inserts the appropriate db_record_check statement into your script.
Syntax:
db_record_check(ChecklistFileName,SuccessConditions,RecordNumber );
ChecklistFileName A file created by WinRunner and saved in the test's checklist folder. The file contains information about
the data to be captured during the test run and its corresponding field in the database. The file is created based on the
information entered in the Runtime Record Verification wizard.
Contains one of the following values:
1. DVR_ONE_OR_MORE_MATCH - The checkpoint passes if one or more matching database records are found.
2. DVR_ONE_MATCH - The checkpoint passes if exactly one matching database record is found.
3. DVR_NO_MATCH - The checkpoint passes if no matching database records are found.
RecordNumber An out parameter returning the number of records in the database.
80. How do you handle dynamically changing area of the window in the bitmap checkpoints?
a) The difference between bitmaps option in the Run Tab of the general options defines the minimum number of pixels
that constitute a bitmap mismatch
81. What do you verify with the database check point custom and what command it generates, explain syntax?
a) When you create a custom check on a database, you create a standard database checkpoint in which you can specify
which properties to check on a result set.
b) You can create a custom check on a database in order to:
i. check the contents of part or the entire result set
ii. edit the expected results of the contents of the result set
iii. count the rows in the result set
iv. count the columns in the result set
c) You can create a custom check on a database using ODBC, Microsoft Query or Data Junction.
82. What do you verify with the sync point for object/window property and what command it generates, explain syntax?
a) Synchronization compensates for inconsistencies in the performance of your application during a test run. By inserting
a synchronization point in your test script, you can instruct WinRunner to suspend the test run and wait for a cue before
continuing the test.
b) You can a synchronization point that instructs WinRunner to wait for a specified object or window to appear. For
example, you can tell WinRunner to wait for a window to open before performing an operation within that window, or you
may want WinRunner to wait for an object to appear in order to perform an operation on that object.
c) You use the obj_exists function to create an object synchronization point, and you use the win_exists function to create
a window synchronization point. These functions have the following syntax:
Syntax:
obj_exists ( object [, time ] );
win_exists ( window [, time ] );
83. What do you verify with the sync point for object/window bitmap and what command it generates, explain syntax?
a) You can create a bitmap synchronization point that waits for the bitmap of an object or a window to appear in the
application being tested.
b) During a test run, WinRunner suspends test execution until the specified bitmap is redrawn, and then compares the
current bitmap with the expected one captured earlier. If the bitmaps match, then WinRunner continues the test.
Syntax:
obj_wait_bitmap ( object, image, time );
win_wait_bitmap ( window, image, time );
84. What do you verify with the sync point for screen area and what command it generates, explain syntax?
a) For screen area verification we actually capture the screen area into a bitmap and verify the application screen area
with the bitmap file during execution
Syntax: obj_wait_bitmap(object, image, time, x, y, width, height);
85. How do you edit checklist file and when do you need to edit the checklist file?
a) WinRunner has an edit checklist file option under the create menu. Select the “Edit GUI Checklist” to modify GUI
checklist file and “Edit Database Checklist” to edit database checklist file. This brings up a dialog box that gives you option
to select the checklist file to modify. There is also an option to select the scope of the checklist file, whether it is Test
specific or a shared one. Select the checklist file, click OK which opens up the window to edit the properties of the objects.
86. How do you edit the expected value of an object?
a) We can modify the expected value of the object by executing the script in the Update mode. We can also manually edit
the gui*.chk file which contains the expected values which come under the exp folder to change the values.
87. How do you modify the expected results of a GUI checkpoint?
a) We can modify the expected results of a GUI checkpoint be running the script containing the checkpoint in the update
mode.
88. How do you handle ActiveX and Visual basic objects?
a) WinRunner provides with add-ins for ActiveX and Visual basic objects. When loading WinRunner, select those add-ins
and these add-ins provide with a set of functions to work on ActiveX and VB objects.
89. How do you create ODBC query?
a) We can create ODBC query using the database checkpoint wizard. It provides with option to create an SQL file that
uses an ODBC DSN to connect to the database. The SQL File will contain the connection string and the SQL statement.
90. How do you record a data driven test?
a) We can create a data-driven testing using data from a flat file, data table or a database.
i. Using Flat File: we actually store the data to be used in a required format in the file. We access the file using the File
manipulation commands, reads data from the file and assign the variables with data.
ii. Data Table: It is an excel file. We can store test data in these files and manipulate them. We use the ‘ddt_*’ functions to
manipulate data in the data table.
iii.Database: we store test data in the database and access these data using ‘db_*’ functions.
91. How do you convert a database file to a text file?
a) You can use Data Junction to create a conversion file which converts a database to a target text file.
92. How do you parameterize database check points?
a) When you create a standard database checkpoint using ODBC (Microsoft Query), you can add parameters to an SQL
statement to parameterize the checkpoint. This is useful if you want to create a database checkpoint with a query in which
the SQL statement defining your query changes.
93. How do you create parameterize SQL commands?
a) A parameterized query is a query in which at least one of the fields of the WHERE clause is parameterized, i.e., the
value of the field is specified by a question mark symbol ( ? ). For example, the following SQL statement is based on a
query on the database in the sample Flight Reservation application:
i. SELECT Flights.Departure, Flights.Flight_Number, Flights.Day_Of_Week FROM Flights Flights WHERE

(Flights.Departure=?) AND (Flights.Day_Of_Week=?)
SELECT defines the columns to include in the query.
FROM specifies the path of the database.
WHERE (optional) specifies the conditions, or filters to use in the query.
Departure is the parameter that represents the departure point of a flight.
Day_Of_Week is the parameter that represents the day of the week of a flight.
b) When creating a database checkpoint, you insert a db_check statement into your test script. When you parameterize
the SQL statement in your checkpoint, the db_check function has a fourth, optional, argument: the parameter_array
argument. A statement similar to the following is inserted into your test script:
db_check("list1.cdl", "dbvf1", NO_LIMIT, dbvf1_params);
The parameter_array argument will contain the values to substitute for the parameters in the parameterized checkpoint.
94. Explain the following commands:
a) db_connect
to connect to a database
db_connect(<session_name>, <connection_string>);
b) db_execute_query
to execute a query
db_execute_query ( session_name, SQL, record_number );
record_number is the out value.
c) db_get_field_value
returns the value of a single field in the specified row_index and column in the session_name database session.
db_get_field_value ( session_name, row_index, column );
d) db_get_headers
returns the number of column headers in a query and the content of the column headers, concatenated and delimited by
tabs.
db_get_headers ( session_name, header_count, header_content );
e) db_get_row
returns the content of the row, concatenated and delimited by tabs.
db_get_row ( session_name, row_index, row_content );
f) db_write_records
writes the record set into a text file delimited by tabs.
db_write_records ( session_name, output_file [ , headers [ , record_limit ] ] );
g) db_get_last_error
returns the last error message of the last ODBC or Data Junction operation in the session_name database session.
db_get_last_error ( session_name, error );
h) db_disconnect
disconnects from the database and ends the database session.
db_disconnect ( session_name );
i) db_dj_convert
runs the djs_file Data Junction export file. When you run this file, the Data Junction Engine converts data from one spoke
(source) to another (target). The optional parameters enable you to override the settings in the Data Junction export file.
db_dj_convert ( djs_file [ , output_file [ , headers [ , record_limit ] ] ] );
95. What check points you will use to read and check text on the GUI and explain its syntax?
a) You can use text checkpoints in your test scripts to read and check text in GUI objects and in areas of the screen. While
creating a test you point to an object or a window containing text. WinRunner reads the text and writes a TSL statement to
the test script. You may then add simple programming elements to your test scripts to verify the contents of the text.
b) You can use a text checkpoint to:
i.Read text from a GUI object or window in your application, using obj_get_text and win_get_text
ii.Search for text in an object or window, using win_find_text and obj_find_text
iii. Move the mouse pointer to text in an object or window, using obj_move_locator_text and win_move_locator_text
iv. Click on text in an object or window, using obj_click_on_text and win_click_on_text
96. Explain Get Text checkpoint from object/window with syntax?
a) We use obj_get_text (<logical_name>, <out_text>) function to get the text from an object
b) We use win_get_text (window, out_text [, x1, y1, x2, y2]) function to get the text from a window.
97. Explain Get Text checkpoint from screen area with syntax?
a) We use win_get_text (window, out_text [, x1, y1, x2, y2]) function to get the text from a window.
98. Explain Get Text checkpoint from selection (web only) with syntax?
a) Returns a text string from an object.
web_obj_get_text (object, table_row, table_column, out_text [, text_before, text_after, index]);
i. object The logical name of the object.
ii. table_row If the object is a table, it specifies the location of the row within a table. The string is preceded by the #
character.
iii. table_column If the object is a table, it specifies the location of the column within a table. The string is preceded by the
# character.
iv. out_text The output variable that stores the text string.
v. text_before Defines the start of the search area for a particular text string.
vi. text_after Defines the end of the search area for a particular text string.
vii. index The occurrence number to locate. (The default parameter number is numbered 1).
99. Explain Get Text checkpoint web text checkpoint with syntax?
a) We use web_obj_text_exists function for web text checkpoints.
web_obj_text_exists ( object, table_row, table_column, text_to_find [, text_before, text_after] );
a. object The logical name of the object to search.
b. table_row If the object is a table, it specifies the location of the row within a table. The string is preceded by the
character #.
c. table_column If the object is a table, it specifies the location of the column within a table. The string is preceded by the
character #.
d. text_to_find The string that is searched for.
e. text_before Defines the start of the search area for a particular text string.
f. text_after Defines the end of the search area for a particular text string.
100. Which TSL functions you will use for
a) Searching text on the window
i. find_text ( string, out_coord_array, search_area [, string_def ] );
string The string that is searched for. The string must be complete, contain no spaces, and it must be preceded and
followed by a space outside the quotation marks. To specify a literal, case-sensitive string, enclose the string in quotation
marks. Alternatively, you can specify the name of a string variable. In this case, the string variable can include a regular
expression.
out_coord_array The name of the array that stores the screen coordinates of the text (see explanation below).
search_area The area to search, specified as coordinates x1,y1,x2,y2. These define any two diagonal corners of a
rectangle. The interpreter searches for the text in the area defined by the rectangle.
string_def Defines the type of search to perform. If no value is specified, (0 or FALSE, the default), the search is for a
single complete word only. When 1, or TRUE, is specified, the search is not restricted to a single, complete word.
b) getting the location of the text string
i. win_find_text ( window, string, result_array [, search_area [, string_def ] ] );
window The logical name of the window to search.
string The text to locate. To specify a literal, case sensitive string, enclose the string in quotation marks. Alternatively, you
can specify the name of a string variable. The value of the string variable can include a regular expression. The regular
expression should not include an exclamation mark (!), however, which is treated as a literal character. For more
information regarding Regular Expressions, refer to the "Using Regular Expressions" chapter in your User's Guide.
result_array The name of the output variable that stores the location of the string as a four-element array.
search_area The region of the object to search, relative to the window. This area is defined as a pair of coordinates, with
x1,y1,x2,y2 specifying any two diagonally opposite corners of the rectangular search region. If this parameter is not
defined, then the entire window is considered the search area.
string_def Defines how the text search is performed. If no string_def is specified, (0 or FALSE, the default parameter), the
interpreter searches for a complete word only. If 1, or TRUE, is specified, the search is not restricted to a single, complete
word.
c) Moving the pointer to that text string
i. win_move_locator_text (window, string [ ,search_area [ ,string_def ] ] );
window The logical name of the window.
string The text to locate. To specify a literal, case sensitive string, enclose the string in quotation marks. Alternatively, you
can specify the name of a string variable. The value of the string variable can include a regular expression (the regular
expression need not begin with an exclamation mark).
search_area The region of the object to search, relative to the window. This area is defined as a pair of coordinates, with
x1, y1, x2, y2 specifying any two diagonally opposite corners of the rectangular search region. If this parameter is not
defined, then the entire window specified is considered the search area.
string_def Defines how the text search is performed. If no string_def is specified, (0 or FALSE, the default parameter), the
interpreter searches for a complete word only. If 1, or TRUE, is specified, the search is not restricted to a single, complete
word.
d) Comparing the text
i. compare_text (str1, str2 [, chars1, chars2]);
str1, str2 The two strings to be compared.
chars1 One or more characters in the first string.
chars2 One or more characters in the second string. These characters are substituted for those in chars1.
101. What are the steps of creating a data driven test?
a) The steps involved in data driven testing are:
i. Creating a test
ii. Converting to a data-driven test and preparing a database
iii. Running the test
iv. Analyzing the test results.
102. Record a data driven test script using data driver wizard?
a) You can use the DataDriver Wizard to convert your entire script or a part of your script into a data-driven test. For
example, your test script may include recorded operations, checkpoints, and other statements that do not need to be
repeated for multiple sets of data. You need to parameterize only the portion of your test script that you want to run in a
loop with multiple sets of data.
To create a data-driven test:
i. If you want to turn only part of your test script into a data-driven test, first select those lines in the test script.
ii. Choose Tools > DataDriver Wizard.
iii. If you want to turn only part of the test into a data-driven test, click Cancel. Select those lines in the test script and
reopen the DataDriver Wizard. If you want to turn the entire test into a data-driven test, click Next.
iv. The Use a new or existing Excel table box displays the name of the Excel file that WinRunner creates, which stores the
data for the data-driven test. Accept the default data table for this test, enter a different name for the data table, or use
v. The browse button to locate the path of an existing data table. By default, the data table is stored in the test folder.
vi. In the Assign a name to the variable box, enter a variable name with which to refer to the data table, or accept the
default name, “table.”
vii. At the beginning of a data-driven test, the Excel data table you selected is assigned as the value of the table variable.
Throughout the script, only the table variable name is used. This makes it easy for you to assign a different data table
viii. To the script at a later time without making changes throughout the script.
ix. Choose from among the following options:
1. Add statements to create a data-driven test: Automatically adds statements to run your test in a loop: sets a variable
name by which to refer to the data table; adds braces ({and}), a for statement, and a ddt_get_row_count statement to your
test script selection to run it in a loop while it reads from the data table; adds ddt_open and ddt_close statements
2. To your test script to open and close the data table, which are necessary in order to iterate rows in the table. Note that
you can also add these statements to your test script manually.
3. If you do not choose this option, you will receive a warning that your data-driven test must contain a loop and
statements to open and close your datatable.
4. Import data from a database: Imports data from a database. This option adds ddt_update_from_db, and ddt_save
statements to your test script after the ddt_open statement.
5. Note that in order to import data from a database, either Microsoft Query or Data Junction must be installed on your
machine. You can install Microsoft Query from the custom installation of Microsoft Office. Note that Data Junction is not
automatically included in your WinRunner package. To purchase Data Junction, contact your Mercury Interactive
representative. For detailed information on working with Data Junction, refer to the documentation in the Data Junction
package.
6. Parameterize the test: Replaces fixed values in selected checkpoints and in recorded statements with parameters,
using the ddt_val function, and in the data table, adds columns with variable values for the parameters. Line by line:
Opens a wizard screen for each line of the selected test script, which enables you to decide whether to parameterize a
particular line, and if so, whether to add a new column to the data table or use an existing column when parameterizing
data.
7. Automatically: Replaces all data with ddt_val statements and adds new columns to the data table. The first argument of
the function is the name of the column in the data table. The replaced data is inserted into the table.
x. The Test script line to parameterize box displays the line of the test script to parameterize. The highlighted value can be
replaced by a parameter. The Argument to be replaced box displays the argument (value) that you can replace with a
parameter. You can use the arrows to select a different argument to replace.
Choose whether and how to replace the selected data:
1. Do not replace this data: Does not parameterize this data.
2. An existing column: If parameters already exist in the data table for this test, select an existing parameter from the list.
3. A new column: Creates a new column for this parameter in the data table for this test. Adds the selected data to this
column of the data table. The default name for the new parameter is the logical name of the object in the selected. TSL
statement above. Accept this name or assign a new name.
xi. The final screen of the wizard opens.
1. If you want the data table to open after you close the wizard, select Show data table now.
2. To perform the tasks specified in previous screens and close the wizard, click Finish.
3. To close the wizard without making any changes to the test script, click Cancel.
103. What are the three modes of running the scripts?

a) WinRunner provides three modes in which to run tests—Verify, Debug, and Update. You use each mode during a
different phase of the testing process.
i. Verify
1. Use the Verify mode to check your application.
ii. Debug
1. Use the Debug mode to help you identify bugs in a test script.
iii. Update
1. Use the Update mode to update the expected results of a test or to create a new expected results folder.
104. Explain the following TSL functions:
a) Ddt_open
Creates or opens a datatable file so that WinRunner can access it.
Syntax: ddt_open ( data_table_name, mode );
data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a
tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the
parameters. This row is labeled row 0.
mode The mode for opening the data table: DDT_MODE_READ (read-only) or DDT_MODE_READWRITE (read or write).
b) Ddt_save
Saves the information into a data file.
Syntax: dt_save (data_table_name);
tabbed text file name, or the full path and file name of the table.
c) Ddt_close
Closes a data table file
Syntax: ddt_close ( data_table_name );
data_table_name The name of the data table. The data table is a Microsoft Excel file or a tabbed text file. The first row in
the file contains the names of the parameters.
d) Ddt_export
Exports the information of one data table file into a different data table file.
Syntax: ddt_export (data_table_namename1, data_table_namename2);
data_table_namename1 The source data table filename.
data_table_namename2 The destination data table filename.
e) Ddt_show
Shows or hides the table editor of a specified data table.
Syntax: ddt_show (data_table_name [, show_flag]);
tabbed text file name, or the full path and file name of the table.
show_flag The value indicating whether the editor should be shown (default=1) or hidden (0).
f) Ddt_get_row_count
Retrieves the no. of rows in a data tables
Syntax: ddt_get_row_count (data_table_name, out_rows_count);
parameters.
out_rows_count The output variable that stores the total number of rows in the data table.
g) ddt_next_row
Changes the active row in a database to the next row
Syntax: ddt_next_row (data_table_name);
parameters.
h) ddt_set_row
Sets the active row in a data table.
Syntax: ddt_set_row (data_table_name, row);
row The new active row in the data table.
i) ddt_set_val
Sets a value in the current row of the data table
Syntax: ddt_set_val (data_table_name, parameter, value);
parameter The name of the column into which the value will be inserted.
value The value to be written into the table.
j) ddt_set_val_by_row
Sets a value in a specified row of the data table.
Syntax: ddt_set_val_by_row (data_table_name, row, parameter, value);
row The row number in the table. It can be any existing row or the current row number plus 1, which will add a new row to
the data table.
parameter The name of the column into which the value will be inserted.
value The value to be written into the table.
k) ddt_get_current_row
Retrieves the active row of a data table.
Syntax: ddt_get_current_row ( data_table_name, out_row );
out_row The output variable that stores the active row in the data table.
l) ddt_is_parameter
Returns whether a parameter in a datatable is valid
Syntax: ddt_is_parameter (data_table_name, parameter);
parameters.
parameter The parameter name to check in the data table.
m) ddt_get_parameters
Returns a list of all parameters in a data table.
Syntax: ddt_get_parameters ( table, params_list, params_num );
table The pathname of the data table.
params_list This out parameter returns the list of all parameters in the data table, separated by tabs.
params_num This out parameter returns the number of parameters in params_list.
n) ddt_val
Returns the value of a parameter in the active roe in a data table.
Syntax: ddt_val (data_table_name, parameter);
parameters.
parameter The name of the parameter in the data table.
o) ddt_val_by_row
Returns the value of a parameter in the specified row in a data table.
Syntax: ddt_val_by_row ( data_table_name, row_number, parameter );
row_number The number of the row in the data table.
parameter The name of the parameter in the data table.
p) ddt_report_row
Reports the active row in a data table to the test results
Syntax: ddt_report_row (data_table_name);
q) ddt_update_from_db
imports data from a database into a data table. It is inserted into your test script when you select the Import data from a
database option in the DataDriver Wizard. When you run your test, this function updates the data table with data from the
database.
105. How do you handle unexpected events and errors?
a) WinRunner uses exception handling to detect an unexpected event when it occurs and act to recover the test run.
Define Exception Handling
Define Exception
Define Handler Function
WinRunner enables you to handle the following types of exceptions:
Pop-up exceptions: Instruct WinRunner to detect and handle the appearance of a specific window.
TSL exceptions: Instruct WinRunner to detect and handle TSL functions that return a specific error code.
Object exceptions: Instruct WinRunner to detect and handle a change in a property for a specific GUI object.
Web exceptions: When the WebTest add-in is loaded, you can instruct WinRunner to handle unexpected events and
errors that occur in your Web site during a test run.
106. How do you handle pop-up exceptions?
a) A pop-up exception Handler handles the pop-up messages that come up during the execution of the script in the AUT.
TO handle this type of exception we make WinRunner learn the window and also specify a handler to the exception. It
could be
i. Default actions: WinRunner clicks the OK or Cancel button in the pop-up window, or presses Enter on the keyboard. To
select a default handler, click the appropriate button in the dialog box.
ii. User-defined handler: If you prefer, specify the name of your own handler. Click User Defined Function Name and type
in a name in the User Defined Function Name box.
107. How do you handle TSL exceptions?
a) A TSL exception enables you to detect and respond to a specific error code returned during test execution.
b) Suppose you are running a batch test on an unstable version of your application. If your application crashes, you want
WinRunner to recover test execution. A TSL exception can instruct WinRunner to recover test execution by exiting the
current test, restarting the application, and continuing with the next test in the batch.
c) The handler function is responsible for recovering test execution. When WinRunner detects a specific error code, it
calls the handler function. You implement this function to respond to the unexpected error in the way that meets your
specific testing needs.
d) Once you have defined the exception, WinRunner activates handling and adds the exception to the list of default TSL
exceptions in the Exceptions dialog box. Default TSL exceptions are defined by the XR_EXCP_TSL configuration
parameter in the wrun.ini configuration file.
108. How do you handle object exceptions?
a) During testing, unexpected changes can occur to GUI objects in the application you are testing. These changes are
often subtle but they can disrupt the test run and distort results.
b) You could use exception handling to detect a change in property of the GUI object during the test run, and to recover
test execution by calling a handler function and continue with the test execution
109. How do you comment your script?
a) We comment a script or line of script by inserting a ‘#’ at the beginning of the line.
110. What is a compile module?
a) A compiled module is a script containing a library of user-defined functions that you want to call frequently from other
tests. When you load a compiled module, its functions are automatically compiled and remain in memory. You can call
them directly from within any test.
b) Compiled modules can improve the organization and performance of your tests. Since you debug compiled modules
before using them, your tests will require less error-checking. In addition, calling a function that is already compiled is
significantly faster than interpreting a function in a test script.
111. What is the difference between script and compile module?
a) Test script contains the executable file in WinRunner while Compiled Module is used to store reusable functions.
Complied modules are not executable.
b) WinRunner performs a pre-compilation automatically when it saves a module assigned a property value of “Compiled
Module”.
c) By default, modules containing TSL code have a property value of "main". Main modules are called for execution from
within other modules. Main modules are dynamically compiled into machine code only when WinRunner recognizes a
"call" statement. Example of a call for the "app_init" script:
call cso_init();
call( "C:\\MyAppFolder\\" & "app_init" );
d) Compiled modules are loaded into memory to be referenced from TSL code in any module. Example of a load
statement:
reload (“C:\\MyAppFolder\\" & "flt_lib");
or
load ("C:\\MyAppFolder\\" & "flt_lib");
112. Write and explain various loop command?
a) A for loop instructs WinRunner to execute one or more statements a specified number of times.
It has the following syntax:
for ( [ expression1 ]; [ expression2 ]; [ expression3 ] )statement
i. First, expression1 is executed. Next, expression2 is evaluated. If expression2 is true, statement is executed and
expression3 is executed. The cycle is repeated as long as expression2 remains true. If expression2 is false, the for
statement terminates and execution passes to the first statement immediately following.
ii. For example, the for loop below selects the file UI_TEST from the File Name list
iii. in the Open window. It selects this file five times and then stops.
set_window ("Open")
for (i=0; i<5; i++)
list_select_item("File_Name:_1","UI_TEST"); #Item Number2
b) A while loop executes a block of statements for as long as a specified condition is true.
while ( expression )
statement ;
i. While expression is true, the statement is executed. The loop ends when the expression is false. For example, the while
statement below performs the same function as the for loop above.
set_window ("Open");
i=0;
while (i<5){
i++;
list_select_item ("File Name:_1", "UI_TEST"); # Item Number 2
}
c) A do/while loop executes a block of statements for as long as a specified condition is true. Unlike the for loop and while
loop, a do/while loop tests the conditions at the end of the loop, not at the beginning.
A do/while loop has the following syntax:
do
statement
while (expression);
i. The statement is executed and then the expression is evaluated. If the expression is true, then the cycle is repeated. If
the expression is false, the cycle is not repeated.
ii. For example, the do/while statement below opens and closes the Order dialog box of Flight Reservation five times.
set_window ("Flight Reservation");
i=0;
do
{
menu_select_item ("File;Open Order...");
set_window ("Open Order");
button_press ("Cancel");
i++;
}
while (i<5);
113. Write and explain decision making command?
a) You can incorporate decision-making into your test scripts using if/else or switch statements.
i. An if/else statement executes a statement if a condition is true; otherwise, it executes another statement.
if ( expression )
statement1;
[ else
statement2; ]
expression is evaluated. If expression is true, statement1 is executed. If expression1 is false, statement2 is executed.
b) A switch statement enables WinRunner to make a decision based on an expression that can have more than two
values.
switch (expression )
{
case case_1: statements
case case_n: statements
default: statement(s)
}
The switch statement consecutively evaluates each case expression until one is found that equals the initial expression. If
no case is equal to the expression, then the default statements are executed. The default statements are optional.
114. Write and explain switch command?
a) A switch statement enables WinRunner to make a decision based on an expression that can have more than two
values.
switch (expression )
{
case case_n: statements
default: statement(s)
}
b) The switch statement consecutively evaluates each case expression until one is found that equals the initial
expression. If no case is equal to the expression, then the default statements are executed. The default statements are
optional.
115. How do you write messages to the report?
a) To write message to a report we use the report_msg statement
Syntax: report_msg (message);
116. What is a command to invoke application?
a) Invoke_application is the function used to invoke an application.
Syntax: invoke_application(file, command_option, working_dir, SHOW);
117. What is the purpose of tl_step command?
a) Used to determine whether sections of a test pass or fail.
Syntax: tl_step(step_name, status, description);
118. Which TSL function you will use to compare two files?
a) We can compare 2 files in WinRunner using the file_compare function.
Syntax: file_compare (file1, file2 [, save file]);
119. What is the use of function generator?
a) The Function Generator provides a quick, error-free way to program scripts. You can:
i. Add Context Sensitive functions that perform operations on a GUI object or get information from the application being
tested.
ii. Add Standard and Analog functions that perform non-Context Sensitive tasks such as synchronizing test execution or
sending user-defined messages to a report.
iii. Add Customization functions that enable you to modify WinRunner to suit your testing environment.
120. What is the use of putting call and call_close statements in the test script?
a) You can use two types of call statements to invoke one test from another:
i. A call statement invokes a test from within another test.
ii. A call_close statement invokes a test from within a script and closes the test when the test is completed.
iii. The call statement has the following syntax:
1. call test_name ( [ parameter1, parameter2, ...parametern ] );
iv. The call_close statement has the following syntax:
1. call_close test_name ( [ parameter1, parameter2, ... parametern ] );
v. The test_name is the name of the test to invoke. The parameters are the parameters defined for the called test.
vi. The parameters are optional. However, when one test calls another, the call statement should designate a value for
each parameter defined for the called test. If no parameters are defined for the called test, the call statement must contain
an empty set of parentheses.
121. What is the use of treturn and texit statements in the test script?
a) The treturn and texit statements are used to stop execution of called tests.
i. The treturn statement stops the current test and returns control to the calling test.
ii. The texit statement stops test execution entirely, unless tests are being called from a batch test. In this case, control is
returned to the main batch test.
b) Both functions provide a return value for the called test. If treturn or texit is not used, or if no value is specified, then the
return value of the call statement is 0.
treturn
c) The treturn statement terminates execution of the called test and returns control to the calling test.
The syntax is:
treturn [( expression )];
d) The optional expression is the value returned to the call statement used to invoke the test.
texit
e) When tests are run interactively, the texit statement discontinues test execution. However, when tests are called from a
batch test, texit ends execution of the current test only; control is then returned to the calling batch test.
The syntax is:
texit [( expression )];
122. Where do you set up the search path for a called test.
a) The search path determines the directories that WinRunner will search for a called test.
b) To set the search path, choose Settings > General Options. The General Options dialog box opens. Click the Folders
tab and choose a search path in the Search Path for Called Tests box. WinRunner searches the directories in the order in
which they are listed in the box. Note that the search paths you define remain active in future testing sessions.
123. How you create user-defined functions and explain the syntax?
a) A user-defined function has the following structure:
[class] function name ([mode] parameter...)
{
declarations;
statements;
}
b) The class of a function can be either static or public. A static function is available only to the test or module within which
the function was defined.
c) Parameters need not be explicitly declared. They can be of mode in, out, or inout. For all non-array parameters, the
default mode is in. For array parameters, the default is inout. The significance of each of these parameter types is as
follows:
in: A parameter that is assigned a value from outside the function.
out: A parameter that is assigned a value from inside the function.
inout: A parameter that can be assigned a value from outside or inside the function.
124. What does static and public class of a function means?
a) The class of a function can be either static or public.
b) A static function is available only to the test or module within which the function was defined.
c) Once you execute a public function, it is available to all tests, for as long as the test containing the function remains
open. This is convenient when you want the function to be accessible from called tests. However, if you want to create a
function that will be available to many tests, you should place it in a compiled module. The functions in a compiled module
are available for the duration of the testing session.
d) If no class is explicitly declared, the function is assigned the default class, public.
125. What does in, out and input parameters means?
a) in: A parameter that is assigned a value from outside the function.
b) out: A parameter that is assigned a value from inside the function.
c) inout: A parameter that can be assigned a value from outside or inside the function.
126. What is the purpose of return statement?
a) This statement passes control back to the calling function or test. It also returns the value of the evaluated expression
to the calling function or test. If no expression is assigned to the return statement, an empty string is returned.
Syntax: return [( expression )];
127. What does auto, static, public and extern variables means?
a) auto: An auto variable can be declared only within a function and is local to that function. It exists only for as long as the
function is running. A new copy of the variable is created each time the function is called.
b) static: A static variable is local to the function, test, or compiled module in which it is declared. The variable retains its
value until the test is terminated by an Abort command. This variable is initialized each time the definition of the function is
executed.
c) public: A public variable can be declared only within a test or module, and is available for all functions, tests, and
compiled modules.
d) extern: An extern declaration indicates a reference to a public variable declared outside of the current test or module.
128. How do you declare constants?
a) The const specifier indicates that the declared value cannot be modified. The class of a constant may be either public
or static. If no class is explicitly declared, the constant is assigned the default class public. Once a constant is defined, it
remains in existence until you exit WinRunner.
b) The syntax of this declaration is:
[class] const name [= expression];
129. How do you declare arrays?
a) The following syntax is used to define the class and the initial expression of an array. Array size need not be defined in
TSL.
b) class array_name [ ] [=init_expression]
c) The array class may be any of the classes used for variable declarations (auto, static, public, extern).
130. How do you load and unload a compile module?
a) In order to access the functions in a compiled module you need to load the module. You can load it from within any test
script using the load command; all tests will then be able to access the function until you quit WinRunner or unload the
compiled module.
b) You can load a module either as a system module or as a user module. A system module is generally a closed module
that is “invisible” to the tester. It is not displayed when it is loaded, cannot be stepped into, and is not stopped by a pause
command. A system module is not unloaded when you execute an unload statement with no parameters (global unload).
load (module_name [,1|0] [,1|0] );
The module_name is the name of an existing compiled module.
Two additional, optional parameters indicate the type of module. The first parameter indicates whether the function
module is a system module or a user module: 1 indicates a system module; 0 indicates a user module.
(Default = 0)
The second optional parameter indicates whether a user module will remain open in the WinRunner window or will close
automatically after it is loaded: 1 indicates that the module will close automatically; 0 indicates that the module will remain
open.
(Default = 0)
c) The unload function removes a loaded module or selected functions from memory.
d) It has the following syntax:
unload ( [ module_name | test_name [ , "function_name" ] ] );

131. Why you use reload function?
a) If you make changes in a module, you should reload it. The reload function removes a loaded module from memory
and reloads it (combining the functions of unload and load).
The syntax of the reload function is:
reload ( module_name [ ,1|0 ] [ ,1|0 ] );
The module_name is the name of an existing compiled module.

Two additional optional parameters indicate the type of module. The first parameter indicates whether the module is a
system module or a user module: 1 indicates a system module; 0 indicates a user module.
(Default = 0)
The second optional parameter indicates whether a user module will remain open in the WinRunner window or will close
automatically after it is loaded. 1 indicates that the module will close automatically. 0 indicates that the module will remain
open.
(Default = 0)
132. Why does the minus sign not appear when using obj_type(), win_type(), type()?
If using any of the type() functions, minus signs actually means hold down the button for the previous character. The
solution is to put a backslash character "\\" before the minus sign. This also applies to + < >.
133. Write and explain compile module?
134. How do you call a function from external libraries (dll).
135. What is the purpose of load_dll?
136. How do you load and unload external libraries?
137. How do you declare external functions in TSL?
138. How do you call windows APIs, explain with an example?
139. Write TSL functions for the following interactive modes:
i. Creating a dialog box with any message you specify, and an edit field.
ii. Create dialog box with list of items and message.
iii. Create dialog box with edit field, check box, and execute button, and a cancel button.
iv. Creating a browse dialog box from which user selects a file.
v. Create a dialog box with two edit fields, one for login and another for password input.
140. What is the purpose of step, step into, step out, step to cursor commands for debugging your script?
141. How do you update your expected results?
142. How do you run your script with multiple sets of expected results?
143. How do you view and evaluate test results for various check points?
144. How do you view the results of file comparison?
145. What is the purpose of Wdiff utility?
146. What are batch tests and how do you create and run batch tests ?
147. How do you store and view batch test results?
148. How do you execute your tests from windows run command?
149. Explain different command line options?
150. What TSL function you will use to pause your script?
151. What is the purpose of setting a break point?
152. What is a watch list?
153. During debugging how do you monitor the value of the variables?
154.What are the reasons that WinRunner fails to identify an object on the GUI?
a) WinRunner fails to identify an object in a GUI due to various reasons.
i. The object is not a standard windows object.
ii. If the browser used is not compatible with the WinRunner version, GUI Map Editor will not be able to learn any of the
objects displayed in the browser window.
155.What do you mean by the logical name of the object.
a) An object’s logical name is determined by its class. In most cases, the logical name is the label that appears on an
object.
156.If the object does not have a name then what will be the logical name?
If the object does not have a name then the logical name could be the attached text.
157.What is the different between GUI map and GUI map files?
a) The GUI map is actually the sum of one or more GUI map files. There are two modes for organizing GUI map files.
i. Global GUI Map file: a single GUI Map file for the entire application
ii. GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created.
b) GUI Map file is a file which contains the windows and the objects learned by the WinRunner with its logical name and
their physical description.
158.How do you view the contents of the GUI map?
a) GUI Map editor displays the content of a GUI Map. We can invoke GUI Map Editor from the Tools Menu in WinRunner.
The GUI Map Editor displays the various GUI Map files created and the windows and objects learned in to them with their
logical name and physical description.
160.What is startup script in WinRunner?
It is writing a script and when WinRunner starts it automatically runs the script. If you write script like invoking some
application as soon as the script is run the application will be invoked for the purpose of testing
161.What is the purpose of loading WinRunner add-ins?
Add-ins are used in WinRunner to load functions specific to the particular add-in to the memory. While creating a script
only those functions in the add-in selected will be listed in the function generator,and while executing the script only those
functions in the loaded add-in will be executed,else WinRunner will give an error message saying it does not recognize
the function
162.What is the purpose of GUI spy?
Using the GUI spy you can view the properties of any GUI object and your desktop. You use the spy pointer to point to an
object,and the GUI spy displays the properties and their values in the GUI spy dialog box. You can choose to view all
properties of an object, or only the selected set of properties that WinRunner learns.
163.When you create GUI map do you record all the objects of specific objects?
a) If we are learning a window then WinRunner automatically learns all the objects in the window else we will we
identifying those object, which are to be learned in a window, since we will be working with only those objects while
creating scripts.
164.What is the purpose of set_window command?
b) Set_Window command sets the focus to the specified window. We use this command to set the focus to the required
window before executing tests on a particular window.
Syntax: set_window(<logical name>, time);

The logical name is the logical name of the window and time is the time the execution has to wait till it gets the given
window into focus.
165.How do you load GUI map?
c) We can load a GUI Map by using the GUI_load command.
Syntax: GUI_load(<file_name>);
166..What is the disadvantage of loading the GUI maps through start up scripts?
d) If we are using a single GUI Map file for the entire AUT then the memory used by the GUI Map may be much high.
e) If there is any change in the object being learned then WinRunner will not be able to recognize the object, as it is not in
the GUI Map file loaded in the memory. So we will have to learn the object again and update the GUI File and reload it.
167.How do you unload the GUI map?
f) We can use GUI_close to unload a specific GUI Map file or else we call use GUI_close_all command to unload all the
GUI Map files loaded in the memory.
Syntax: GUI_close(<file_name>); or GUI_close_all;
Quick Test Professional Q & A Part 1
1.What is Quick test pro?
Its a Mercury interactive's keyword driven testing tool
2.By using QTP what kind of applications we can test?
By using QTP we can test standard windows applications,Web objects,ActiveX controls,and Visual basic applications.
3.What is called as test?
Test is a collection of steps organized into one or more actions,which are used to verify that your application performs as
expected
4.What is the meaning of business component?
Its a collections of steps representing a single task in your application. Business components are combined into specific
scenario to build business process tests in Mercury Quality center with Business process testing
5.How the test will be created in QTP?
As we navigate through our application,QTP records each step we perform and generates a test or component that
graphically displays theses steps in an table-based keyword view.
6.What are all the main tasks which will be accomplished by the QTP after creating a test?
After we have finished recording,we can instruct QTP to check the properties of specific objects in our application by
means of enhancement features available in QTP. When we perform a run session,QTP performs each step in our test or
component. After the run session ends,we can view a report detailing which steps were performed,and which one
succeeded or failed.
7.What is Actions?
A test is composed of actions. The steps we add to a test are included with in the test's actions. By each test begin with a
single action. We can divide our test into multiple actions to organize our test.
8.What are all the main stages will involve in QTP while testing?
? Creating tests or business components
? Running tests or business components
? Analyzing results
9.How the creation of test will be accomplished in QTP?
We can create the test or component by either recording a session on our application or web site or building an object
repository and adding steps manually to the keyword view using keyword-driven functionality. We can then modify our test
with programming statements.
10.What is the purpose of documentation in key word view?
The documentation column of the key word view used to displays a description of each step in easy to understand
sentences.
Quick Test Professional Q & A Part 2
11.Keyword view in QTP is also termed as
Icon based view
12.What is the use of data table in QTP?
parameterizing the test
13.What is the use of working with actions?
To design a modular and efficient tests
14.What is the file extension of the code file and object repository file in QTP?
The extension for code file is .vbs and the extension for object repository is .tsr
15.What are the properties we can use for identifying a browser and page when using descriptive programming?
The name property is used to identify the browser and the title property is used to identify the page
16.What are the different scripting languages we can use when working with QTP?
VB script
17.Give the example where we can use a COM interface in our QTP project?
COM interface appears in the scenario of front end and back end.
18.Explain the keyword createobject with example
createobject is used to create and return a reference to an automation object.
For example:
Dim ExcelSheetSet
ExcelSheet=createobject(“Excel.Sheet”)
19.How to open excel sheet using QTP script?
You can open excel in QTP by using the following command
System.Util.Run”Path of the file”
20.Is it necessary to learn VB script to work with QTP?
Its not mandate that one should mastered in VB script to work with QTP. It is mostly user friendly and for good results we
need to have basic VB or concepts which will suffice
21.If WinRunner and QTP both are functional testing tools from the same company. Why a separate tool QTP came in to
picture?
QTP has some additional functionality which is not present in WinRunner. For example,you can test(Functionality and
Regression testing) an application developed in .Net technology with QTP,which is not possible to test in WinRunner
22.Explain in brief about the QTP automation object model
The test object model is a large set of object types or classes that QTP uses to represent the objects in our application.
Each test object has a list of properties that can uniquely identify objects of that class
23.What is a Run-Time data table?
The test results tree also includes the table-shaped icon that displays the run-time data table-a table that shows the
values used to run a test containing data table parameters or the data table output values retrieved from a application
under test
24.What are all the components of QTP test script?
QTP test script is a combination of VB script statements and statements that use QuickTest test objects ,methods and
properties
25. What is test object?
Its an object that QTP uses to represent an object in our application. Each test object has one or more methods and
properties that we can use to perform operations and retrieve values for that object. Each object also has a number of
identification properties that can describe the object.
26.What are all the rules and guidelines want to be followed while working in expert view?
Case-sensitivity
VB script is not case sensitive and does not differentiate between upper case and lower case spelling of words.
Text strings
When we enter value as a string, that time we must add quotation marks before and after the string
Variables
We can use variables to store strings,integers,arrays and objects. Using variables helps to make our script more readable
and flexible.
Parentheses
To achieve the desired result and to avoid the errors,it is important that we use parentheses() correctly in our statements.
Comments
We can add comments to our statements using apostrophe('),either at a beginning of the separate line or at the end of a
statement
Spaces
We can add extra blank spaces to our script to improve clarity. These spaces are ignored by the VB script
Test Director Q & A Part 1
1.What is Test Director?
Its a Mercury interactive's Test management tool. It includes all the features we need to organize and manage the testing
process.
2.What are all the main features of Test Director?
It enables us to create a database of tests,execute tests, report and track defects detected in the software.
3.How the assessment of the application will be taken place in Test Director?
As we test, Test Director allows us to continuously assess the status of our application by generating sophisticated reports
and graphs. By integrating all tasks involved in software testing Test Director helps us to ensure that our software is ready
for deployment.
4.What the planning tests will do in Test Director?
It is used to develop a test plan and create tests. This includes defining goals and strategy,designing tests,automating
tests where beneficial and analyzing the plan.
5.What the running tests will do in Test Director?
It execute the test created in the planning test phase, and analyze the test results
6.What the tracking defects will do in Test Director?
It is used to monitor the software quality. It includes reporting defects,determining repair priorities,assigning tasks,and
tracking repair progress
7.What are all the three main views available in What the running tests will do in Test Director?
? Plan tests
? Run tests
? Track defects
Each view includes all the tools we need to complete each phase of the testing process
8.What is test plan tree?
A test plan tree enables you to organize and display your test hierarchically,according to your testing requirements
9.What are all the contents of test plan tree?
Test plan tree can include several type of tests
? Manual test scripts
? Win Runner test scripts
? Batch of Win Runner test scripts
? Visual API test scripts
? Load Runner scenario scripts and Vuser scripts
10.What is test step?
A test step includes the action to perform in our application,input to enter,and its expected output
Test Director Q & A Part 2
11.TestDirector is a Test management tool
12..What are all the components of TestDirector5.0?
Plan tests,Run tests,Track defects
13.Who is having full privileges in TestDirector project?
TD Admin
12.What is test set?
A test set is a subset of tests in our database designed to achieve a specified testing objective
13.How the analyzing of test results will be accomplished in TestDirector?
Analyzing results will be accomplished by viewing run data and by generating TestDirector reports and graphs
14.What is Test set builder?
The test set builder enables us to create,edit,and delete test sets. Our test sets can include both manual and automated
tests. We can include the same test in different test sets.
15.How the running of Manual test will be accomplished in TestDirector?
When running a manual test,we perform the actions detailed in the test steps and compare them to the expected results.
The mini step window allows us to conveniently perform manual tests and record results with TestDirector minimized
16.How the running of Automated test will be accomplished in TestDirector?
We can execute automated tests on our own computer or on multiple remote hosts. The test execution window enables
us to control test execution and manage hosts. We can execute a single test, or launch an entire batch of tests.
17.How to execute test plan in testdirector?
Write testcases in test plan(Description and expected results)

To execute them go to TEST LAB . Give coverage from test plan to test lab by selecting “select tests”.
Then click on RUN of RUN TEST SET to execute the test cases.
18.What is the use of Test Director software?
TestDirector is Mercury Interactive's software test management tool. It helps quality assurance personnel plan and
organize the testing process. With TestDirector you can create database of manual and automated tests, build test cycles,
run tests, and report and track defects.
19.How you integrated your automated scripts from TestDirector?
When you work with WinRunner , you can choose to save your tests directly to your TestDirector database or while
creating a test case in the TestDirector we can specify whether the script in automated or manual.
20.Who all are having the rights to detect and report the defects?
? Software developers
? Testers
? End users
21.What are the main things want to be considered while reporting the bug?
? Description about the bug
? Software version
? Additional informations necessary to reproduce and repair the defect
22.Describe about mailing defect data
Connecting TestDirector to your e-mail system lets you routinely inform development and quality assurance personnel
about defect repair activity.
23.What is report designer?
Its a powerful and flexible tool that allows you to design your own unique reports
24.What is the use of graphs in TestDirector?
TestDirector graphs help us visualize the progress of test planning,test execution,and defect tracking for our application,so
that we can detect bottlenecks in the testing process.
Load Runner Q & A Part 1
1.Where the LoadRunner will be exactly applicable?
Its mainly applicable for testing the performance of the client and server based applications
2.How the LoadRunner will test the application?
LoadRunner enables us to test our system under controlled and peak load conditions. To generate load LoadRunner runs
thousands of virtual users that are distributed over a network. Using a minimum of hardware resources,these virtual users
provide consistent,repeatable,and measurable load to exercise our client and server system just as real users would.
3.How to evaluate the performance of a system?
LoadRunner's in-depth reports and graph provide the information that we need to evaluate the performance of our client
and server system
4.What are all the compatible platforms which will be used to execute the LoadRunner scripts?
Windows,UNIX
5.What are all the parameters LoadRunner will mainly test?
To load our client and server system, LoadRunner emulates an environment where multiple users work concurrently,while
the client and server system is under load, LoadRunner accurately measures and analyze the system performance,and its
functionality
6.What kind of applications which will be mainly focused by the performance testing?
Modern client and server architectures are complex. While they provide an unprecedented degree of power and
flexibility,these systems are difficult to test. Whereas single user testing focuses primarily on functionality and the user
interface of single application,client and server testing focuses on performance and reliability of an entire client and server
system.
7.What are the limitations of manual load testing?
? It is expensive,requiring large amount of both personnel and machinery
? It is complicated,especially coordinating and synchronizing multiple users
? It involves a high degree of organization
? The repeatability of the manual tests is limited
8.What are all the main features of LoadRunner?
? LoadRunner reduces the personnel requirements
? LoadRunner reduces the hardware requirements
? The controlling will be accomplished effectively by the controller
? Because LoadRunner tests are fully automated,we can easily repeat them as many times we need
9.What is the purpose of LoadRunner scenarios?
Using LoadRunner,we divide our client and server performance requirements into scenarios. A scenario defines
the events that occur during each testing session.
10.What sort of things will be replaced in scenarios?
In the scenario, LoadRunner replaces human users with virtual users or Vusers. When we run a scenario, Vuser emulate
the actions of human users-submitting input into the server.
Load Runner Q & A Part 2

11.What is load testing?
Testing of application for simultaneous users
12.What does vuser_init action contains?
Login procedures
13.What is the main aim of load testing?
To calculate the response time
14.What the Vuser script will do while running the scenario?
The actions that a Vuser performs during the scenario are described in a Vuser script. When we run a scenario,each
Vuser executes a Vuser script. The Vuser script include functions that measure and record the performance of the server
during the scenario.
15.What is Transaction time?
To measure the performance of the server,we define transactions. Transactions measure the time that it takes for the
server to respond to tasks submitted by Vuser.
16.What is Rendezvous points?
We can insert Rendezvous points in to Vuser scripts to emulate heavy user load on the server. Rendezvous points instruct
multiple Vuser to perform tasks at exactly the same time.
17.What is controller?
LoadRunner controller is used to manage and maintain our scenarios. Using the controller ,we can control all the Vusers
in a scenario from a single work station.
18.What is Hosts?
The host is the machine that executes the Vuser script,enabling the Vuser to emulate the actions of a human user.
19.What is mean by Rendezvous points?
A rendezvous point creates intense user load on the server and enables LoadRunner to measure server performance
under load
20.What is the need for doing load testing?
The factors are: Minimal infrastructure,Reliable,Repeatable,Programmable,Comprehensive,Reusable
21.How to create Vuser Groups in loadrunner?
A scenario consists of groups of Vusers which emulate human user interacting with your application. When you run a
scenario, the Vusers generate load on the server, and LoadRunner monitors the server and transaction performance
22.Why should we automate the performance testing?
Its a discipline that leverages products,people and processes to reduce the risk of application,upgrade or patch
deployment. It is about applying production work loads to pre-deployment systems while simultaneously measuring
system performance and end-user experience.
23.What are all the things will be considered while doing performance testing?
? Does the application respond quickly enough for the intended users?
? Will the application handle the expected user load and beyond?
? Will the application handle the number of transactions required by the business?
? Is the application stable under expected and unexpected user loads?
? Are we sure that users will have a positive experience on go-live day?
24. What are the LoadRunner components?
? Virtual User Generator
? Controller
? Load Generators
? Analysis
? Launcher
25. What is the LoadRunner testing process?
? Plan load test
? Create Vuser Scripts
? Define Scenario
? Run Scenario
? Analyze results
26.What is remote command launcher?
The remote command launcher enables the controller to start applications on the host machine

Testing Interview Questions

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Testing Interview Questions

Hochgeladen von

Copyright:

Verfügbare Formate

Interview Question Part 1

1.What is the testing process?

Level 2 - software project tracking, requirements management,

Manual Testing Q & A Part 4

other tools - for test case management, documentation

39.What's a 'test case'?

Win Runner Q & A Part 1

6) Have you performed debugging of the scripts?

Win Runner Q & A Part 2

i. SELECT Flights.Departure, Flights.Flight_Number, Flights.Day_Of_Week FROM Flights Flights WHERE

103. What are the three modes of running the scripts?

Win Runner Q & A Part 14

The module_name is the name of an existing compiled module.

Syntax: set_window(<logical name>, time);

Write testcases in test plan(Description and expected results)

Load Runner Q & A Part 2

Das könnte Ihnen auch gefallen