Articles On Testing

Wecome to !!!

Articles On Testing

Wecome to !!!

Articles On Testing

Wecome to !!!

Articles On Testing

Wecome to !!!

Articles On Testing

Wecome to !!!

Showing posts with label Checkpoint. Show all posts
Showing posts with label Checkpoint. Show all posts

Accessibility Checkpoint In QTP

What is accessibility checkpoint in QTP :

Checkpoints is one of the most important of the many features QTP has in it.  Among the many well known checkpoints we have one lesser known and less frequently used checkpoint called Accessibility checkpoint. It is one of the most sought after query in any Automation testing interview rounds during QTP technical questions. In very broad sense we can conclude that accessibility checkpoint is nothing but a 508 standard compliance of any website in terms of its standardization usage of various tags. However let us explore in details as to what this 508 compliance refers to.

HTML 508 Compliance :
(a)    A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).
(b)   Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.
      (c)     Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.
      d)    Documents shall be organized so they are readable without requiring an associated style sheet.
      e)    Redundant text links shall be provided for each active region of a server-side image map.
      f)     Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
      g) Row and column headers shall be identified for data tables.
      h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
      i) Frames shall be titled with text that facilitates frame identification and navigation.
      j)     Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.
      k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.
      l)     When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
      m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).
      n)   When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
      o)    A method shall be provided that permits users to skip repetitive navigation links.
      p)    When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.
      q)    When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.
      r)     Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer.
      (s)    A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.
      (t)     Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text.
      (u)   When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application's performance.
      (v)    Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes.
      (w)  Applications shall not override user selected contrast and color selections and other individual display attributes.
      (x)    When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user.
      (y)    Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
      (z)    When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided.
       a)Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz.
(      b)                       When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

Log on to below url for more on the same :

For more on QTP automation testing log on to QTP Testing

Checkpoint & Test Reporting in QTP

Checkpoint & Test Reporting in QTP

Test Reporting Enhancements :

86. Ability to create reports in different format. Excel, Word, HTML etc…

87. Reporting of errors or failure in different categories and priority. E.g. – Reporting a error with severity, priority and category (Application, Script, Validation, Checkpoint).

88. Exact location of the error in the script. This should include the line of code, error number, error statement.

89. Direct ability to send report to a specified list of email addresses when the test end.

90. Currently the reports can only be viewed through QTP reporter viewer and cannot be viewed on machines without this tool. Report should be made completely Web compatible so that I can be viewed in any browser in the same way it is displayed in report viewer.

91. Ability to view status of current Action. Currently Reporter.RunStatus only provides the status of whole test and not for current action.

92. Ability to enumerate the current status from within a Test i.e. Actions executed with details, checkpoints executed with details, recovery scenarios executed with details.

93. Hosting web server to capture and display script status in batch.

94. Ability to report to a existing result file.

95. Ability to override the Action Name in reports.

96. Ability to specify the time zone to be used in reports.

97. Ability to specify the results path during the run

Checkpoint Enhancements :

98. Ability to alter properties of all checkpoints during run-time. E.g. Expected bitmap of a bitmap checkpoint, expected values of a Table/DB checkpoint etc.

99. Ability to create checkpoints at run-time.

100. Ability to load checkpoints from a external file at run-time.

101. Ability to enumerate all checkpoints present in current script.

Checkpoints In QTP

Checkpoints are verification points in the test which allow us to compare expected to observed values. Checkpoints can be added while recording the test or afterwards when editing the test. In general, it’s easier to add a checkpoint after the test has been recorded.

Checkpoint information is stored in the Local Object Repository. In the expert view, on any blank line type Checkpoint and put "(". As soon as we put the starting bracket it will show all the checkpoints we have used in the test.

We can add a checkpoint in the keyword view by selecting a row, right clicking and selecting Insert Standard Checkpoint. This will open a dialog that looks like this:


We can then choose which property of the control we wish to verify, whether or not we want to use a constant or a parameter, the number of seconds QTP has to verify the checkpoint  and whether we want the verification to take place before or after the currently highlighted step.

Checkpoint property’s values can be either validated with the constants or they can be parameterized. In case of parameterization, values (which are expected to be property value) are passed through Data sheet and property is validated against those values during run time.

To add checkpoints while recording or editing:

Ø  Use the commands in the Insert > Checkpoint menu, or click the Insert Checkpoint button on the toolbar. This displays a menu of checkpoint options that are relevant to the selected step.

Ø  Right-click the step where we need to add the checkpoint and choose Insert Standard Checkpoint.
Ø  Select the step where we need to add the checkpoint and choose Insert > Checkpoint > Standard Checkpoint.
Ø  Right-click any object in the Active Screen and choose the relevant checkpoint option:
·         Insert Standard Checkpoint
·         Insert Bitmap Checkpoint
·         Insert Accessibility Checkpoint

These options can be used to create checkpoints for any object in the Active Screen (even if the object is not part of any step in the Keyword View).

Different Types of Checkpoints :

*      Standard Checkpoint checks the property value of an object in the application or Web page. The standard checkpoint checks a variety of objects such as buttons, radio buttons, combo boxes, lists, and so forth. For example, we can check that a radio button is activated after it is selected or can check the value of an edit box.

*      Image Checkpoint checks the value of an image in the application or Web page. For example, we can check that a selected image’s source file is correct. We can create an image checkpoint by inserting a standard checkpoint on an image object.

*      Bitmap Checkpoint checks an area of the Web page or application as a bitmap. For example, suppose we have a Web site that can display a map of a city the user specifies. The map has control keys for zooming. We can record the new map that is displayed after one click on the control key that zooms in the map. Using the bitmap checkpoint, we can check that the map zooms in correctly.

*      Table Checkpoint checks information within a table. For example, in our application we have WMPs displayed as a Table in the Plan Setup page, so here we can add Table Checkpoint and can pick the WMP Owner name for the first WMP in the table. This can be inserted by Standard checkpoint on the table object.

*      Text Checkpoint checks that a text string is displayed in the appropriate place on a Web page or application. For example, in our application we can create a text checkpoint that checks that the word “Project Space” is displayed between “Process Space” and “Work Space”.

*      Text Area Checkpoint checks that a text string is displayed within a defined area in a Windows application, according to specified criteria. For example,
suppose Visual Basic application has a button that says View Doc , where is replaced by the four digit code entered in a form
elsewhere in the application. We can create a text area checkpoint to confirm that the number displayed on the button is the same as the number
entered in the form. Text area checkpoints are also supported for some external add-in environments, such as Java.

*      Accessibility Checkpoint identifies areas of the Web site that may not conform to the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines. We should provide a text equivalent for every non-text element. We can add an Alt property check to check whether objects that require the Alt property under this guideline, do in fact have this tag.

*      Page Checkpoint checks the characteristics of a Web page. For example, we can check how long a Web page takes to load or whether a Web page contains broken links. We can create Page checkpoint by inserting a standard checkpoint on a page object.

*      Database Checkpoint checks the contents of a database accessed by your application. For example, we can use a database checkpoint to check the
details of a database containing Project information for our application.

*      XML Checkpoint checks the data content of XML documents in XML files or XML documents in Web pages and frames.

Checkpoints are also differentiated as Normal QTP Checkpoints (as listed above), and Custom Checkpoints. Following are the Custom checkpoints which are normally inserted within some conditions and can be viewed in the Test Results window.

Ø  Reporter.ReportEvent micDone
Ø  Reporter.ReportEvent micPass
Ø  Reporter.ReportEvent micFail
Ø  Reporter.ReportEvent micWarning