How does Winrunner identify GUI Objects?

We all are familiar with the functional testing tool that has been developed by the mercury interactive known by the name of winrunner. In this article we are going to discuss one of the important aspects of the winrunner i.e., how the GUI objects are identified by the winrunner. 

How does WinRunner identify GUI objects?

- The software testing conducted by the winrunner is based up on the identification of the graphical user interfaces objects present in the software system or application under testing.

- The identification of the GUI objects takes place in the context sensitive recording mode. 

- In such recording, the application can be tested by the point of view of the user i.e., in the terms of the graphical user interface objects like buttons, windows, menus, lists and so on. 

- Each of these GUI objects have their own individual properties that are known to define their appearance as well as behavior.

- These properties are learnt by the GUI and are used in identification and location of the GUI objects while a test is in execution. 

- In this mode there is no need for the winrunner to know the physical location of a GUI object for its identification. 

- There is a tool called GUI spy which you can install on your system and properties of any of the GUI objects present in your software system or application that is to be tested can be known very quickly and easily. 

- All the information recorded by the winrunner regarding the behavior of the GUI objects is stored in the GUI map.

- While a test is in execution, this GUI map provides a lot of help in locating a particular object. 

- Actually, the information or the object description is read by the winrunner from the GUI map and then it searches for an object with same properties in the software system or application that is being tested.

- The tester can even have a view of the GUI map in order to know the scenario of the GUI objects that are present in their software system or application.

- The GUI map is actually many small GUI map files added together. 

- Two modes have defined for the organization of the GUI map files:

1. Default mode: A GUI map file is created for the whole application software or separately for each window in the application software. A common GUI map file can be referred by multiple tests. This mode holds good for the users who are quite experienced with the winrunner.
2. Global GUI map file mode: In this mode the GUI map files are automatically created by the winrunner for every test that is created by the user. This mode holds good for the users who are new to the winrunner since it is quite simple.

- In many cases what happens is that the interface of the software system or application under testing changes  but this is not a reason to worry since the winrunner provides solution for this also. 

- The tests that you created for the previous interface can be used for the next interface also. 

- You just need to delete, add or edit the object descriptions in the GUI map so that the same can be located by the winrunner in the modified software system or application. 

- The tests are created by the scripts that have been either recorded or programmed. 

- These test scripts are constituted of the TSL (test script language by mercury) statements. 

- A logical name is given by the winrunner for every object to help in the identification process which is actually a nick name or an alias for the description of the GUI object. 

Document Restructuring - an activity involved in software re-engineering process model.

Software re- engineering process model is a generic one and consists of 6 major steps:

1. Inventory analysis
2. Documentation reconstruction
3. Reverse engineering
4. Code re- structuring
5. Data re- structuring
6. Forward Engineering

This article is dedicated to the discussion regarding the second step of the software re- engineering process model i.e., the documentation reconstruction. 

Why Documentation Reconstruction is important?

It has been observed from the inventory analysis of many organizations that most of the documentation attached with the software systems or applications is either outdated or does not pertain to the documentation standards or refers to the earlier versions of the particular software system or application. 

In such cases, reconstructing the entire software documentation becomes very necessary. The need for re- engineering is felt in three typical situations:

1. When the changes made to a system are confined only to the sub system, there is a need to re- engineering the sub system.

2. When the software as well as the hardware support becomes obsolete.

3. When the tools required for supporting the re- structuring are available.

When it comes to restructuring the documentation the below mentioned options are available to the developers:

1. Keep the weak documentation itself.
2. Update those parts of the documentation that are needed.
3. Rewrite the whole documentation on the “essential minimum requirements” for the critical systems.

- Any existing documentation of the software under re- engineering process is gathered and copies of any required third party software are obtained. 

- All the associated data files and the source code files that are required for the execution of the software system or application are documented and this documentation forms the baseline for the existing version of the software system or application. 

Why Documentation is necessary?

- Documentation forms a very important part of the entire re- engineering process since like other resources it is also a primary resource of information regarding the software system or application. 

- Documentation serves as a potential support for the future maintenance of the software system or application. 

- Documentation should be self sufficient enough to the extent that any developer having knowledge of that programming language must be able to speed up the work with the code in a short period of time using the documentation. 

What is to be contained in the documentation depends pretty much up on the type of the software system or application that is being re- engineered and also on the contents of the previously existing documentation. 

- However, the documentation must contain description of the changes that were introduced during the process of re- engineering. 

- The documentation must also highlight the details of the configuration plan and baselines of the software system or application that were created for the re- engineering process. 

- Other aspects to be included are mentioned below:

1. Steps to verify which version of the software system or application is installed.
2. How to install/ uninstall the software application.
3. How to use the software system or application (a quick guide).
4. Overview of the design of the software system or application.
5. How to build the application software ready for the release.

- After re- engineering process is complete the same documentation must be update and if no documentation exists, one should be created. 

- After the re- engineering the re- engineered software system or application is baselined along with this documentation and the project log and is now considered to be ready for the release. 

Inventory Analysis - an activity involved in software re-engineering process model.

The software re- engineering process model over the years has proved to be a very effective process in bringing the poorly maintained and controlled code to an acceptable standard. This model consists of the below mentioned 5 steps:

1. Inventory analysis
2. Document reconstruction
3. Reverse engineering
4. Code re- structuring
5. Data re- structuring
6. Forward Engineering

In this article we have discussed about the first step of the process i.e., inventory analysis in detail. 

Characteristics of Inventory Analysis

- It is obvious for every organization to maintain an inventory of all the software systems or applications it has developed whether they are active or not.

- An inventory is like a spreadsheet containing details of the software system or application against its name. 

- In inventory analysis, the software systems and applications are sorted out on the basis of the following criteria:

1. Business criticality
2. Longevity
3. Current maintainability and
4. Local criteria

- This step of the software re engineering process model helps the team to identify what all the software systems or applications require to be re- engineered.  

- Firstly, a table is build that lists all the software applications.

- After this a list of criteria is established on the basis of the criteria like few of which have been mentioned below:

1. Name of the software system or application.
2. Year of its creation.
3. Number of changes or modifications it had gone through since its creation.
4. Effort applied in making those modifications.
5. Effort applied in making the last of the modifications.
6. Date on which the last modification was made.
7. The systems in which the application now resides.
8. Other applications with which this application shares the interface.

- The primary purposes of this step is prioritizing all of them and analyze them so as to select the candidates for re- engineering. 

- The steps for the creation of an effective inventory are:

1. Preparing for data collection
2. Collecting the data
3. Deciding the criteria
4. Allocation

- It has not been wrongly said that “well begun is half done” since the organization may have to suffer a huge set back if it chose wrong candidates for re- engineering. 

- So selecting the candidates for re- engineering during the stage of inventory analysis holds importance. 

- The inventory analysis is a very generic process.

- The inventory analysis looks up with the details of all small and big aspects of the software systems and applications and therefore it becomes easy to select which candidates really need re- engineering.

- Usually the software systems or applications which have not been updated since a long time and are no more accepted and are undocumented are given the first priority.

- Such software systems and applications often have documentation associated with them that is either not updated or relates to the previous versions of the particular software system or application. 

- Problems with the selected candidates are identified and they are carried forward to the next step of the software re- engineering process model. 

- Before you start the restructuring of the code it is necessary that the objectives of the re- engineering are defined. 

- Re- engineering actually consists of 11 steps but they are shortened down to 5 major steps. - The detailed steps are:

1. Identifying the existing documentation
2. Verifying the identified code
3. Familiarising with the existing software
4. Identifying the re- engineering requirements
5. Drawing up the re- engineering plan
6. Producing a test plan, test script and test data.
7. Producing test results for original software and the ported version.
8. Restructuring the code
9. Testing the code
10. Updating the documentation

Project Scheduling - Different ways for tracking the schedule.

A proper project schedule is very important for a successful project delivery. The project schedule is a road map for a software project manager. A project schedule needs to be properly developed. A proper project schedule defines the tasks and milestones that are tracked and controlled as project proceeds. This tracking needs to be accomplished nicely and there are different methods and ways to do so...

- Timely project meetings regarding the status of the project are held and it should be ensured that each team member should report the progress achieved and the problems that are faced.
- There are different reviews that are conducted throughout the software engineering process. It becomes necessary to evaluate the results of all these reviews in order to accomplish proper tracking.
- To accomplish proper tracking, for each task of the project, the actual start date and the planned start date should be compared.
- To accomplish tracking, one should determine whether the formal project milestones are achieved by the scheduled date.
- To accomplish tracking, progress should be assessed quantitatively.

The best indication of progress is the completion and successful review of a defined software work product.
The control administers the project resources, cope with problems and direct the project staff. Control is light if the project is on schedule and within budget. The control is exercised to reconcile the problems if they occur.

In case the problem is identified and diagnosed:
- staff is redeployed
- additional resources should be focused on problem area.

A severe deadline can be managed by time-boxing technique. It chooses an incremental software paradigm and a schedule is derived for each incremental delivery. This technique is done when the product may not be deliverable by a pre-defined deadline.

What is meant by Relationship-Navigation Analysis (RNA)?

Relationship navigation analysis (RNA) is a series of analysis steps to identify relationships among the elements that are left uncovered during the creation of the analysis model. There are five steps that constitutes the RNA approach:
- Stakeholder analysis establishes stakeholder hierarchy and identifies various user categories.
- Element analysis identifies content objects and functional elements that are in interest to end uses.
- Relationship analysis identifies the relationship among web application elements.
- Navigation analysis identifies the accessibility of elements by users.
- Evaluation analysis identifies the cost and benefit included.

RELATIONSHIP ANALYSIS
To assess analysis model elements to understand relationships among them, some guidelines are:
- the attributes identified for element.
- whether description about element exists and where?
- is element composed of other smaller elements?
- is element a member of larger collection of elements?
- does analysis class describe the element?
- in using the element, what are the pre and post conditions.
- is the element used in specific ordering of other elements?
- does the element appear in the same place?

The answers to above questions helps the web engineer to position the element in question within the web application and to establish relationships among elements.

NAVIGATION ANALYSIS
After relationship are identified among elements, the web engineer defines how the user category navigates from one element to another. The questions that would clear the navigation requirements are:
- how are navigation errors handled?
- should certain elements be easier to reach?
- should group element navigation be given priority over specific element navigation?
- should links be used for navigation?
- should there be a navigation log for users?
- should a navigation map or menu be established?
- for which user category an optimal navigation be designed?

Introduction to Class-Responsibility-Collaborator (CRC) Modeling

Class-responsibility-collaborator (CRC) modeling is a means to identify and organize classes relevant to system requirements. CRC model is a collection of index cards and it consists of three parts:

Classes : It is a collection of similar objects.
- Entity classes or business classes are obtained directly from statement of the problem. The information contained in these classes are important to users but they do not display themselves.
- Boundary classes are used to create interface which user sees and interacts with as software is used.
- Controller classes are designed to manage creation or update of entity objects, instantiation of boundary objects, communication between objects and validation of data.

Responsibility : something that a class knows or does. Some guidelines that can be applied for allocating responsibilities to classes are:
- System intelligence should be distributed across classes to best address the needs of the problem.
- Each responsibility should be stated as generally as possible.
- Information and the behavior related to it should reside within the same class.
- Information about one thing should be localized with a single class not distributed across multiple classes.
- Responsibilities should be shared among related classes when appropriate.

Collaborator : another class that the class interacts with to fulfill the responsibilities.
- It takes one of two forms : a request for information or a request to do something.
- If a class cannot fulfill all of its obligations itself, then a collaboration is required.
- Collaboration identifies relationship between classes.

What are different steps while conducting component level designing?

The following steps represent a typical task set for component level design, when it is applied for an object oriented system. If you are working in a non object oriented environment, the first three steps focus on the refinement of data objects and processing functions identified as part of analysis model.

STEP 1: Identify all design classes that correspond to the problem domain.
STEP 2: Identify all design classes that correspond to the infrastructure domain.
STEP 3: Elaborate all design classes that are not acquired as reusable components.
In addition to all interfaces, attributes, operations, design heuristics i.e cohesion and coupling should be considered during elaboration.
- Specify message details when classes or components collaborate.
Structure of messages that are passed between objects within a system are shown as component level design proceeds.
- Identify appropriate interfaces for each component.
Interface is an abstract class that provides a controlled connection between design classes. So interfaces should be identified appropriately.
- Elaborate attributes and define data types and data structures required to implement them.
The programming language that is to be used in the project typically is a factor in the definition of the data structure and types used to describe attributes. When the component level design process is started, the name of attributes is used; as the design proceeds the UML attribute format is increasingly used.
- Describe processing flow within each operation in detail.
There are two ways to do this; through a UML activity diagram or a programming language based pseudocode. The elaboration of each software component is by doing a number of iterations and in each iteration a step-wise refinement concept is used.
STEP 4: Describe persistent data sources and identify the classes required to manage them.
As the design elaboration proceeds, an additional data should be provided about the structure and organization of these data sources which are initially specified as part of architectural design.
STEP 5: Develop and elaborate behavioral representations for a class or component.
In order to depict the externally observable behavior of the system as well as that of individual analysis classes, UML state diagrams are used. As a part of component level design, modeling the behavior of a design class may be sometimes required. The instantiation of a design class a s program executes is also known as the dynamic behavior of the object. This behavior is impacted by the current state of object as well as external events.
STEP 6: Elaborate deployment diagrams to provide additional implementation detail.
When component level design is being done, in order to make deployment diagrams simple to read and comprehend, the location of components(individual components) are generally not depicted.
STEP 7: Factor every component level design representation and always consider alternatives.
The first component level model that is created will not be consistent, complete and accurate as compared to the nth iteration that is applied to the model. It is necessary to re-factor as design work is conducted.