QTP Certification Practice Questions – Set 1

QTP Questions 1

1) ‘Browser navigation timeout’ is in which tab of Test Settings
(File Settings) window.

A) Properties
B) Resources
C) Web
D) Web Settings

2) How many tabs are there in Test Settings (File->Settings) window

A) 7
B) 6
C) 5
D) 8

3) Identify the tabs in the Test Settings (File->Settings) window

A) Properties, Run, Resources, Parameters, Environment, Web, Recovery
B) Properties, Run, Resources, Parameters, Environment, Web
Settings,Recovery
C) Properties, Run Options, Resources, Parameters, Environment, Web,
Recovery
D) Properties, Run, Resources, Input Parameters, Environment, Web, Recovery

4) ‘Generate Script’ is in which tab of Test Settings (File->Settings)

window

A) Properties
B) Web
C) Resources
D) Recovery

5) The following are the four main columns in the Keyword view

A) Item, Operation, Value, Comments
B) Item, Operation, Value, Documentation
C) Item, Operation, Property, Documentation
D) Number, Operation, Value, Documentation

6) For each object and method in an Expert View statement, a
corresponding row exists in the Keyword View.

A) True
B) False
C) There is a problem with the statement.
D) None of above

7) You can work on one or several function libraries at the same time.

A) True
B) False

8) You can insert additional steps on the test objects captured in the
Active screen after the recording session.

A) True
B) False

9) The Active Screen enables you to parameterize object values and
insert checkpoints

A) True
B) False

10) A QTP user can increase or decrease the active screen information
saved with the test.

A) True
B) False

Answers

1) C, 2) A, 3) A, 4) A, 5) b, 6) A, 7) A, 8) A, 9) A, 10) A

When to Stop Testing | Testing Completion Criteria

.. Continuing the Beginners Guide to Software Testing series

Testing should be stopped when it meets the completion criteria. Now how to find the completion criteria? Completion criteria can be derived from test plan and test strategy document. Also, re-check your test coverage.
Completion criteria should be based on Risks. Testing should be stopped when –

  • Test cases completed with certain percentage passed and test coverage is achieved.
  • There are no known critical bugs
  • Coverage of code, functionality, or requirements reaches a specified point;
  • Bug rate falls below a certain level, now testers are not getting any priority 1, 2, or 3 bugs.

As testing is a never ending process we can never assume that 100 % testing has been done, we can only minimize the risk of shipping the product to client with X testing done. The risk can be measured by Risk analysis but for small duration / low budget / low resources project, risk can be deduced by simply: –

  • Measuring Test Coverage.
  • Number of test cycles.
  • Number of high priority bugs.

Game Testing Tips and Considerations

Author – unknown. [If you know the author, or if you are the author please contact us, we will update the  post]


Video games are also considered as software that needs sufficient testing before releasing in the market. In fact, many software developers want to become game developers.
Game testing is the process of verifying game environment and behaviour. Its occurrence in game development depends on its budget. High-budgeted projects test their products when the draft version is finished. On the other hand, low-budgeted games might only support testing of the probable final version. Other types like public betas and stress tests are also used in actual game industry, but it less systematic and scientific because testing is being done by simply playing the game from the start to finish and reporting random bugs that occur and detected accidentally. Scientific and methodological approaches in testing have the following purposes:
Game Functionality
This includes gaming environment, textures, and elements. Issues like stability and game messages are also included in this purpose. The exciting part about functional testing is verifying the correctness of game elements, because for example, checking if weapons like swords can really incur damage to enemies and of course, the most practical way to do it is to play the actual game.
Game Compliance
Most games are not stand-alone system. They need to interact with hardware devices and this is especially true for console games. Protocol compatibility and hardware pin assignments should be compatible for both software and hardware side. This is often seen as an area outside the scope of game testers because it now deals with issues beyond the gaming environment.
Game Localization
It is  the common knowledge that most RPGs and other story-based games came from Japan. Thus, scripts may have inconsistencies when translated from one language to another. Unlike functional testers who need to play the actual game, localization testers often face a spreadsheet-like interface where all game scripts and its translation are listed.
Game Soaking
Soaking simply means exposing the game for an exaggerated long period of execution. This is to test if the game will exhibit unreleased segments of memory and mathematical rounding discrepancies. Rounding errors can be problematic for games because it can affect its pointing system, health value consumption, and other game parameters that involve numerical computation.
Games need thorough evaluation to deliver maximum playing experience. For this reason, its testing focuses on some crucial part and breakdown to achieve realistic game behaviour. Listed below are some game testing components:
    * Menus, sub menus, and its functions
    * Graphics, texture, and animation
    * Character audio, sound effects, and special effect
    * Game difficulty level
    * World, dungeons, and map settings
    * Player, action, and inanimate attributes
    * Artificial intelligence for the defence and offense mode
    * Game flow, logic, and sequencing
    * Life points, magic points, and player points
    * Game pad vibration, analog stick, and other hardware issues

Game testing tips and considerations are greatly focused in game graphics. For example, testers should verify a realistic behaviour when multiple objects overlapped with each other. Collision effects between two objects should also be realistic. This is especially true for games involved in sports. In terms of considerations, testers should be aware of the so-called crack bugs and placeholder. This often appears in the development period. Crack bugs are also called false bugs because it is just the result of misjudgement by the tester, while placeholders are shapes used to cover temporarily some part of the game screen while the real image is not yet finished.

Author – unknown. [If you know the author, or if you are the author please contact us, we will update the  post]

QTP Descriptive Programming – How to get number of objects

QTP Descriptive Programming – How to get number of objects

In this article, Dmitri Motevich explains QTP Descriptive Programming (DP) through Google Sets site:
The goal of the present QTP tutorial is to describe:
How to get number of controls (Links, Edits, Images, etc) with QTP DP.

Let’s investigate Descriptive Programming on examples.First of all, we should understand what Descriptive Programming means:

Answer:
QTP DP is a run-time processing of objects which are not located in QTP Object Repository.
I’ve created new QTP script which starts with http://labs.google.com/sets page.

This QTP script is simple enough:

Set Desc = Description.Create()
Desc(“micclass”).Value = “WebEdit”
Set Edits = Browser(“Google Sets”).Page(“Google Sets”).ChildObjects(Desc)

MsgBox “Number of Edits: ” & Edits.Count

And its result is:As you can see, it works correctly and returns correct number of Edits on a page.
I’m going to explain this QTP script and answer the following question:

How does QTP Descriptive Programming work?

First of all, I’ve created new Description object:

Set Desc = Description.Create()

Description object contains collection of properties, which identify any UI object such as a browser, a page, a dialog, a list, a button etc.

To specify that we want identify all Edits on browser’s page I use “micclass” property:

Desc(“micclass”).Value = “WebEdit”

Note: the “mic” prefix in “micclass” stands for “Mercury Interactive Constant”.

How do you know the class name (“micclass”) of object?

Use Spy for that:QTP Object Spy
Open QTP object Spy and check recorded properties of object.
For example, these are properties of Edit:QTP Object Spy - recorded properties
As you can see, there is “Class Name” property and its value – “WebEdit”. So, “WebEdit” is a value of Class Name of all Edits located on Web page.
Note: “Class Name” is a synonym of “micclass”.

I gathered Class Names of Web objects in this table:

# Type of Web object Class Name(micclass)
1 Web Browser Browser
2 Page Page
3 Edit box WebEdit
4 Image Image
5 Link Link
6 Web Element WebElement
7 Button WebButton
8 Checkbox WebCheckBox
9 Combobox (DropDownList) WebList
10 Table WebTable

Since we created Description object for all edit boxes, we can use this description to get all specified objects ( = edit boxes).
The next step returns the collection of all child objects (i.e. edit boxes) contained within the page:

Set Links = Browser(“Google Sets”).Page(“Google Sets”).ChildObjects(Desc)

To get the number of found objects in a returned collection, we use Count property:

MsgBox “Number of Edits: ” & Links.Count

And the result is 5 found Edits on Google Sets page:Number of Edits
So, this is a mechanism of QuickTest Professional Descriptive Programming.

Also, we can use the same code to get number of others objects – Links, Images, Buttons, etc.
For that I modified QTP script:

Function GetAllSpecificControls(Page, MicClass)    Set Desc = Description.Create()
    Desc(“micclass”).Value = MicClass
    Set GetAllSpecificControls = Page.ChildObjects(Desc)
End Function

Function GetAllEdits(Page)
    Set GetAllEdits = GetAllSpecificControls(Page, “WebEdit”)
End Function

Function GetAllButtons(Page)
    Set GetAllButtons = GetAllSpecificControls(Page, “WebButton”)
End Function

Function GetAllLinks(Page)
    Set GetAllLinks = GetAllSpecificControls(Page, “Link”)
End Function

Function GetAllImages(Page)
    Set GetAllImages = GetAllSpecificControls(Page, “Image”)
End Function

Set oPage = Browser(“Google Sets”).Page(“Google Sets”)

MsgBox “Number of Edits: ” & GetAllEdits(oPage).Count
MsgBox “Number of Buttons: ” & GetAllButtons(oPage).Count
MsgBox “Number of Links: ” & GetAllLinks(oPage).Count
MsgBox “Number of Images: ” & GetAllImages(oPage).Count

The result of this QTP script is the following:
Results of QTP script
You can compare the result with the initial web page (see first image in the present article) and verify that QTP Descriptive programming works correctly – it returns correct numbers of objects.

Summary:

I hope, that this article has helped you to understand QTP DP.
The future QTP tutorials will cover others questions on QTP Descriptive Programming.

Concept of Complete Testing | Exhaustive testing is impossible

.. Continuing the Beginners Guide to Software Testing series

It is not unusual to find people making claims such as “I have exhaustively tested the program.” Complete, or exhaustive, testing means there are no undiscovered faults at the end of the test phase. All problems must be known at the end of complete testing. For most of the systems, complete testing is near impossible because of the following reasons:

  • The domain of possible inputs of a program is too large to be completely used in testing a system. There are both valid inputs and invalid inputs.
    The program may have a large number of states. There may be timing constraints on the inputs, that is, an input may be valid at a certain time and invalid at other times. An input value which is valid but is not properly timed is called an inopportune input. The input domain of a system can be very large to be completely used in testing a program.
  • The design issues may be too complex to completely test. The design may have included implicit design decisions and assumptions. For example, a programmer may use a global variable or a static variable to control program execution.
  • It may not be possible to create all possible execution environments of the system. This becomes more significant when the behaviour of the software system depends on the real, outside world, such as weather, temperature, altitude, pressure, and so on.

[From book – Software testing and quality assurance: theory and practice By Kshirasagar Naik, Priyadarshi Tripathy]

Must Read: Testing Limitations
The Impossibility of Complete Testing by Dr. Cem Kaner

Testing Limitations

.. Continuing the Beginners Guide to Software Testing series

Testing Limitations

  • You cannot test a program completely
  • We can only test against system requirements

– May not detect errors in the requirements.
– Incomplete or ambiguous requirements may lead to inadequate or incorrect testing.

  • Exhaustive (total) testing is impossible in present scenario.
  • Time and budget constraints normally require very careful planning of the testing effort.
  • Compromise between thoroughness and budget.
  • Test results are used to make business decisions for release dates.
  • Even if you do find the last bug, you’ll never know it
  • You will run out of time before you run out of test cases
  • You cannot test every path
  • You cannot test every valid input
  • You cannot test every invalid input

Must ReadThe Impossibility of Complete Testing by Dr. Cem Kaner