1. Descriptive Programming concept or OR-free scripting ::Recording model for script creation heavily relies on use of Object Repositories (or GUI Maps as they are known in WinRunner). Object Repository is nothing more than a database of physical descriptions of known objects. By utilizing Mercury recommended scripting approach an engineer makes a valid choice in most of the cases. However, there are those cases where object detailed information is not known in advance and requires capturing of that information during script run-time. To script for such situations, engineer must utilize object physical descriptions and refer to them directly from scripts. Since in some cases we have to allow for the use of physical descriptions, one may ask - why not fully rely on them rather than on standard Object Repositories? Object Repository is simply a placeholder for object definitions. Through making these definitions accessible by other means, we can make script creation and maintainability a much easier process then it currently is, or can be made by using any of the other approaches available on the market. Automatically building physical descriptions during script run-time is the essence of Descriptive Programming. Thus, QA Team will create a sub-language in QTP that will enable such operations. This sub-language then will be used to create test automation scripts.
Benefits of such an approach include hiding QTP specific functionality from the test engineer. This requires less QTP specific skills. Now all an engineer needs to know is test automation theory, some VBScript combined with generic programming skills and have solid understanding of the tested application. Other benefits include ability to enable script execution in foreign languages/locales, measuring response times for page loads, ability to perform some generic and yet global error verifications, and many other tasks by overloading library functions with additional code (this also allows for an expansion of test script creation from just QA group to entire Development organization), as well as rapid script creation - since there is no QTP specifics to worry about, engineers can concentrate on the application itself.
There are several valid concerns in over-using Descriptive Programming. Most serious concern is related to the very concept itself - hiding automation tool functionality from the end user, which means that any new features directed to ease use of OR-based approach could potentially be ignored. However, it should be understood that Descriptive Programming concept does not prevent an engineer from using standard approaches in scripts.2. What is keyword view and Expert view in QTP?QuickTest's Keyword Driven approach, test automation experts have full access to the underlying test and object properties, via an integrated scripting and debugging environment that is round-trip synchronized with the Keyword View. Advanced testers can view and edit their tests in the Expert View, which reveals the underlying industry-standard VBScript that QuickTest Professional automatically generates. Any changes made in the Expert View are automatically synchronized with the Keyword View.3. What is the Diff between Image check-point and Bit map Check point?Image checkpoints enable you to check the properties of a Web image. You can check an area of a Web page or application as a bitmap. While creating a test or component, you specify the area you want to check by selecting an object. You can check an entire object or any area within an object. Quick Test captures the specified object as a bitmap, and inserts a checkpoint in the test or component. You can also choose to save only the selected area of the object with your test or component in order to save disk Space. For example, suppose you have a Web site that can display a map of a city the user specifies. The map has control keys for zooming. You can record the new map that is displayed after one click on the control key that zooms in the map. Using the bitmap checkpoint, you can check that the map zooms in correctly. You can create bitmap checkpoints for all supported testing environments (as long as the appropriate add-ins are loaded). Note: The results of bitmap checkpoints may be affected by factors such as operating system, screen resolution, and color settings.| Myth | Reality |
1. Descriptive programming solves many object recognition and maintenance problems that are otherwise going to stay (if we use Object Repository). So, we can rely on Descriptive Programming, ignoring Object Repository. | Here are some of the consequences of ignoring Object Repository: All the properties you use in Descriptive Programming will be treated as Mandatory properties. You are loosing the power of Assistive properties in the object recognition mechanism of QTP QTP identifies an object using test object description stored in Object Repository. This description is made up of two sets of properties: 1. Mandatory Properties 2. Assistive Properties For any object you can dictate QTP what properties to consider as mandatory and what properties as Assistive properties in a facility called "Object Identification". Quick Test learns all mandatory properties by default. If it can't create a unique description for the object using mandatory properties alone, it starts learning one assistive property at a time until it creates a unique description for the object in question. So, what it means is that just because you told QTP to use several Assistive Properties, it does not mean that it learns them all. It learns only to the extent needed i.e. until a unique object description is created Also, in Descriptive Programming, you can't make use of the modern technology available in QTP - Smart Identification. You can use this only if have Object Repository. If an object is not learned into Object Repository, there will be no logical name, no assistive properties, nor there do any base and optional properties to use for smart identification. |
2. Descriptive Programming is better than Object Repository in cases where objects in the application are dynamic in nature and need special handling to identify the object. | Objects whose properties change dynamically for each run or depending on input data can be handled equally well by Object Repository. In both cases you can use global or local sheet parameters, environment parameters as well as regular expressions to parameterize object properties. |
3. If the size of Object repository increases too much then it decreases the performance of QTP while recognizing an object. Descriptive Programming is better in such situations. | Size of the Object Repository has very little or nothing to do with performance of QTP. It is rather the nature and number of objects in a given page that impact the performance of QTP. For example if there is one web button on a web page, QTP needs only one property (class name) to uniquely recognize that object right away. If you have, say 100 web buttons in a web page, then QTP has to use additional properties to recognize the object (may be "Value" property). Like this, QTP keeps on using more and more properties until it recognizes the object uniquely and this is what causes performance degradation not the size of Object Repository. |
4. Descriptive Programming makes maintenance easy! | No. It is as bad/good as maintaining Object Repository. |
5. QTP cannot take action on an object until unless its object description is in the Object Repository. But descriptive programming provides a way to perform action on objects which are not in Object repository | If an object is not in the object repository, you will have to create your own description of that object so that QTP can recognize and act on it. You will have to create the description very carefully otherwise you will get run error. In Descriptive Programming, creating a workable description for some objects can prove to be very tedious and time consuming some times. Properties that work are not always consistent. Some times you have to dig through several combinations of properties to find one that works correctly. You will be better off adding object to the Object Repository with just click of a button rather than creating a time consuming buggy description all by yourself. |
6. Using Descriptive Programming, automation scripts can be created even if the application has not been developed. | If you build object descriptions (and scripts based on those descriptions) without ever spying on the objects, the chances are that, in more than 50% of the cases, the description might fail. Scripts you create with out having the application developed will hardly serve you any purpose. This is because, without having the application developed, you can't have active screens captured, can't insert checkpoints, can't output values. |
| Advantages of Descriptive programming | |
Descriptive Programming Solves redundancy problem. If you have same objects on many pages, you don't need to add them to Object Repository under each page. You can handle it with Descriptive Programming and avoid redundancy. Descriptive Programming solves the problem of dealing with large number of objects of same type. For example, you can't anticipate search results and put them in Object Repository in advance. You can create descriptions for such objects and make QTP act on them based on, for example, ordinal identifier. | |
| Conclusion | |
Descriptive programming helps us handle special circumstances which otherwise can't be handled with Object Repository alone. However, in the final analyses, Descriptive Programming should NOT be treated as replacement for Object Repository for it is far from being a viable alternative to object Repository. Descriptive Programming is a necessary exception rather than a norm. But, at the same time, we can't live without Descriptive Programming. I would like to conclude that Object Repository and Descriptive Programming compliment each other rather than act as mutually exclusive entities and using only one of them means sacrificing the power of the other. | |
