Attach resource to Current run of QC

Once we integrate QTP with QC, we need to upload the resources to current run of QC. Here is the code to attach the resources to current run.
-------Code----------

Dim CurrentRun, attachment

    On error resume next
    If QCUtil.IsConnected Then
        Set CurrentRun =QCUtil.CurrentRun
        Set attachment = CurrentRun.Attachments
        If Err.Number = 424 Then
            Reporter.ReportEvent micWarning, "Not running through QC so can't save results", ""
       Else
            Reporter.ReportEvent micDone, "Attachment Saved to QC curent run", strFileName
            Set Attlist = attachment.NewList("")
            Set Att = attachment.AddItem(Null) 
            att.FileName = strFileName 
            att.Type = 1
            att.Post 
            att.Save False 
        End If
    Else 
    
        Reporter.ReportEvent micWarning, "No connection", "Not connected to Quality Center" 

    End If
    
    On error goto 0

Common DOM methods and properties used in QTP

Every HTML element in a Web page is a scriptable object in the object model, with its own set of properties, methods, and events. To enable access to these objects, Internet Explorer creates a top-level document object for each HTML document it displays. When you use the .Object property on a Web page object in your test or component, you actually get a reference to this DOM object. This document object represents the entire page. From this document object, you can access the rest of the object hierarchy by using properties and collections.

Following are the most useful document properties and methods available through the Web .Object property:

Properties

• activeElement Property - Retrieves the object that has the focus when the parent document has focus.
• cookie Property - Sets or retrieves the string value of a cookie.
• documentElement Property - Retrieves a reference to the root node of the document.
• readyState Property - Retrieves a value that indicates the current state of the object.
• URL Property - Sets or retrieves the URL for the current document.
• URLUnencoded Property - Retrieves the URL for the document, stripped of any character encoding.

Collections

• all - Returns a reference to the collection of elements contained by the object.
• frames - Retrieves a collection of all window objects defined by the given document or defined by the document associated with the given window.
• images - Retrieves a collection, in source order, of img objects in the document.
• links - Retrieves a collection of all objects that specify the HREF property and all area objects in the document.

Methods

• getElementById Method - Returns a reference to the first object with the specified value of the ID attribute.
• getElementsByName Method - Retrieves a collection of objects based on the value of the NAME attribute.
• getElementsByTagName Method - Retrieves a collection of objects based on the specified element name.

Source:Sudhakar's blog

Automated script review check points

Often we review the code,but will not be sure whether we are doing it right and doing it complete.So here is a checklist for automated script code review...

1. Automation coverage--Does the script automate each step of the test case?
2. Sequence--Does the script coded each step in the correct order as per the test case flow?
3. Validation--Does the script cover each and every validation as per manual test case?
4. Logic--Does the script logic call the correct functions? Are these functions called with the correct arguments?
5. Test data--Does the script take application input values from the correct input test data file(s)?
6. Object compatibility--Does the script execute user operations against the correct objects?
7. Synchronization--Does the script give the application sufficient time to transition to the correct test state e.g. the correct page/window/screen?
8. Output values--Does the script validate application output values/system generated data against the correct output test data file(s)?
9. Object validation--Does the script validate the state of the correct objects?
10. Object used--Does the script load only the necessary objects in memory?
11. Waits--Is the script free from unnecessary delays?
12. Error handling--Does the script handle application errors as designed?
13. Naming--Does the script have a unique identifier?
14. Unknown data--Is the script free of any magic numbers or magic strings?
15. Commenting--Is the script commented at each appropriate place in it? Is each comment correct?
16. Usage--Is the script free from unnecessary or extra code?
17. Reporting--Is the reporting correct? All the details are reported?
18. Documentation--All data like Developer,Date of scripting,Functions used, etc are
documented?

I think it helps...

Pesticide Paradox !!

I came across a term called as 'Pesticide Paradox' in testing.So just thought of sharing it.

What is the meaning?:
The immunity of the application under test increases !
The same tests (test cases) run over a period of time would start losing their effectiveness to find defects. The developers fix the bugs and the application might reach the saturation in that area or module or functionality.The easy to find and fix defects are discovered and fixed but in the process more subtler bugs are introduced into the system.

What is the solution for it?
To maintain the effectiveness and efficacy of the tests being performed, they need to be revisited time and again and re-written so that the unexposed code is also tested thoroughly.
There can be many permutations and combinations to test a particular system and it is never possible to test it in its entirety. Another effective technique is not to rely solely on the structured and formal techniques but also to perform ad-hoc and exploratory testing to uncover bugs.Think out of box !

Local or Shared Repository?

While using QTP,usually we will be not able to decide whether to to use the Local object repository or shared object repositories.Well, here is a quick reference to decide..

This	In these situations...
local object repository	You are creating single-action tests. You are creating simple tests, especially under the following conditions: You have only one, or very few, tests that correspond to a given application, interface, or set of objects. You do not expect to frequently modify object properties. You are new to using QuickTest. You can record and run tests without creating, choosing, or modifying shared object repositories because all objects are automatically saved in a local object repository that can be accessed by its corresponding action.
shared object repository	You are creating tests using keyword-driven methodologies (not by recording). You have several tests that test elements of the same application, interface, or set of objects. You often work with multi-action tests and regularly use the Insert Copy of Action and Insert Call to Action options. You expect the object properties in your application to change from time to time and/or you regularly need to update or modify object properties. If you are familiar with testing, it is probably most efficient to save objects in a shared object repository. In this way, you can use the same shared object repository for multiple actions—if the actions include the same objects. Object information that applies to many actions is kept in one central location. When the objects in your application change, you can update them in one location for all the actions that use this shared object repository.

Courtesy: QTP Help

Hell World..

Hi All !!
I welcome you to my blog. I will try to write based on my experience and the readings..
Happy reading :)