How to design and copy test cases in test director?

Application testing process is not the one that can be completed in a jiffy. It demands constant input in form of efforts, organization and maintenance. Well, all this becomes easy when you are assisted by mercury interactive’s test management tool.
Test director saves you a great deal of efforts for tasks such as requirements analysis, test planning, test execution, defect tracking etc. here in this article we are going to tell you how you can design as well as copy the test cases in test director. After the tests created for all the subjects have been added to the test plan tree and the basic test information has been defined, the test cases or the test steps are defined.
By defining them we mean that more details or step by step instructions are provided for how that particular test case is to be executed. Each step of a test case consists of two things namely:
1. Actions to be performed on the application under testing or AUT and
2. The expected results.

Test steps can be created either for manual tests or automated tests using test director. For manual testing it is said to be complete when you are done with the designing of the tests.
Then, the test execution can be straightaway be started by using the test plan tree. But in the case of the automated testing, an addition step is to create automated test scripts using any other mercury interactive tool such as Winrunner or some other third party tool.

Steps for designing test cases

Below mentioned are the steps that one can follow for designing a test case:
1. It has to be made sure that the test plan module is on display and if it is not click on the test plan tab to turn it on.
2. The test case for which you are about to design the test steps also needs to be displayed. You can do this by simply clicking on the name of that particular test.
3. Next you need to launch the design step editor by clicking on the ‘design steps lab’.
4. In the design step editor dialog box clicking on the new step button you will get a new step dialog box which will ask you enter a step name which is by default a sequential number.
5. Now for defining that step you require to fill up the following fields and click OK:
         a) Step name
         b) Description
         c) Expected result
6. Last step is to click OK which will close the design step editor and display the design steps.

How to copy the test cases?

In test director you get the option of copying the test cases either from the same project or from some other. Follow the below mentioned steps:
1. You need to turn on the design steps tab and select that particular test case from the test plan tree which you want to be copied.
2. Next step involves selecting the steps of the test cases which you want to be copied. You will observe a gray sidebar, position the mouse pointer there and you will see that the pointer changes to  ->. Now hold down the shift and select the steps you want to be copied.
3. By using the copy steps copy down all the selected steps.
4. Next paste the steps where you want them to be copied in the test plan tree by using the paste steps button in the design steps tab.

How do you define and view requirements in Test Director?

Test director is currently available as a plug in or add – on as a support for HP quality center and works like a test management tool. The earlier versions of the test director i.e., version 6 and below worked as stand-alone desk top applications.

However, the next version i.e., the test director 7 was a standalone web application and was known to work on any of the browsers that happened to be supporting active technology. For all the testers world wide it has been easy to integrate with the other mercury interactive tools via test director.

Three facts regarding test director:

1. This tool is not going to work out for the collection of the requirements of a software system or application.
2. It is not an automated testing tool.
3. It cannot be integrated with the products save mercury interactive products.

Test director comes with four specific modules namely:

1. Requirements module
2. Test plan module
3. Test lab module and
4. Defects module

How can we define and view requirements in the test director?

- This is done using the requirements module. 

- In every test management process, specification of the requirements is the first important step. 

- It involves analyzation of the software system or application under test and determination of the requirements of testing that application.

- Requirements analysis somewhat helps in carrying out the coverage analysis. - The following tasks are involved:

1. Addition of new requirements or editing of the previously added ones.
2. Addition and editing of the child requirements.
3. Linking of the requirements to the associated defects.
4. Analyzation of the coverage.

- The requirements analyzation phase follows through the below mentioned steps:

1. Defining the scope: The scope of the requirements includes test goals and objectives and can be determined using the requirements documentation.
2. Creation of the requirements: A requirements tree needs to be built so that all of the testing requirements can be defined.
3. Providing details for the requirements: Detailing involves adding attachments, assigning priority levels to all the requirements if required for testing.
4. Analyzation of the requirements: This phase involves generation of the reports consisting of the graphs to provide an assistance in the analyzation of the testing requirements.

Steps for Defining Requirements

Follow the below mentioned steps for defining the requirements:

1. Launch the test director demo project. You will require to log on to the project if in case the project is not open.
2. Now clicking on the requirements tab will display the requirements module or the requirements tree.
3. One thing that you need to be sure of is that the document view of the requirements is also displayed.
4. Click on the new requirement option which will open the new requirement dialog box. Fill in the details and hit OK.
5. Click new child requirement button for adding a requirement as a lower level of hierarchy.

Steps for Viewing Requirements

For viewing the requirements follow the below mentioned steps:

1. First step is making sure that the requirements module is displayed and if not click on the requirements and turn on the document view of the requirements tree.
2. You can zoom in as well as zoom out of the requirements tree using the zoom in and zoom out buttons.
3. In some cases you may require to view the numeration of requirements. 
4. To view numerations go to view menu and click on the numeration option. If you make any changes in the requirements the same is updated by the test director and numerations are renumbered. 

What is a Silk Test Test plan? What are the types of text lines in a test plan file?

A silk test plan consists of large amounts of data as well as information based on which are the details of the plan which in turn will be used in the organization and the development of the software system or application. 

It has three basic qualities as mentioned below:

1. Well structured
2. Hierarchical
3. Ideal model

A silk test test plan constitutes of two parts which are entirely different:

1. First part consists of an outline which gives a detailed description of the all the requirements of the testing process.
2. Second part consists of a statement which establishes a relationship between the outline of the first part and 4test scripts as well as test cases which are bound to implement the requirements defined above.

What is a Silk Test Plan?

- Test plan helps in achieving a guided way for the creation as well as execution of the test cases. 

- A new test plan can be created by following the below mentioned steps:

1. Go to the file menu and then click on new option.
2. From the drop down list that follows select test plan and hit OK. You will get a test plan window. Fill in the required fields and click OK.

- This is a known fact that silk test specializes in the field of functionality as well as regression testing and has been a known product when it comes to web, java or windows based applications. 

- Silk test provides you with two ways for defining or creating the automated tests:

1. By using the record test case command for recording the actions and the verification of steps.
2. Using visual 4test scripting language by writing the test cases manually.

- Test plans in silk test are stored as ‘test plan (.pln)’ file type. 

- This file type is sometimes used for making combinations of the test scripts. 

- The basic purpose of a silk test test plan is to provide a frame work for the testing process and also for the organization and maintenance of the testing requirements. 

Benefits of using a Test Plan

Using a test plan has following benefits:

1. With test plan you have a chance to implement top down approach for defining the testing requirements, developing thoughts and refining the requirements.
2. Attributes can be assigned to individual tests or group of tests.
3. Redundancy is reduced single only actually implementing statements are allowed.
4. Can be used as a comprehensive inventory of requirements consisting of most general as well as specific requirements.

What kind of text lines are there in a test plan file?

Test plan file consists of 5 types of text lines that we have described below:

1. First type of text lines are the comments which are usually marked in green color.These types of text lines provide commentary type of information regarding the test code.
2. Group Description: This type of text lines are represented in bold black color. Furthermore, they are included so as to provide a description of a group of tests rather than describing individual tests. Usually, a test plan consists of many tests which are then grouped in to multiple levels of various groups.
3. Test Description: This type of text lines are written in blue color and are meant for showcasing the description of the individual tests only.
4. Test plan statement: This type of text lines in a test plan file provide information regarding the relations to the following elements:

a)   Test cases

b)   Link scripts

c)   Test data

d)   Closed sub test plans

e)   Include files to a test plan.

These are marked in red color.

5. Open sub plan file marker: These text lines are marked in magenta color and thus providing info regarding relations to link sub test plans with the master plan.

How to start with Test Director?

Application testing is not an easy task, rather it is a very complex process but made easy with the test director. With the test director it has been possible to organize as well as manage all of the phases of the test director testing process. You can also specify the requirements of the testing process, plan the tests, execute them and keep an eye on the defects and so on.

Test director actually forms an organized frame work for the testing of the software systems or application before they are put under deployment. A central data repository is needed for the organization and management of the application testing process since the test plans have a way of evolving with any changes in the existing requirements or the new requirements. 

The following are the processes where you get a plenty of guidance from the test director:

1. Requirements specification
2. Test planning
3. Test execution
4. Defect tracking etc.

Basically the application testing process via test director consists of the following four phases:

1. Specifying requirements
2. Planning tests
3. Running tests
4. Tracking defects

First phase involves:

1. Define the testing scope
2. Create requirements
3. Detail requirements
4. Analyze requirements specification

Second phase involves:

1. Defining testing strategy
2. Define test subjects
3. Define tests
4. Creating the requirements coverage
5. Designing the test steps
6. Automating the tests
7. Analyzation of the test plan

3^rd phase involves:

1. Creating test sets
2. Scheduling the test runs
3. Running the tests
4. Analyzation of the test results

4^th phase involves:

1. Adding the defects
2. Reviewing the defects
3. Repairing the open defects
4. Testing new builds
5. Analyzing the defect data

How to start with Test Director?

- To start with the test director you need to go to your web browser and enter the URL of the test director in the test director options window. 

- When you press enter you will get a test director window.  

- If in case you are having some problem with opening the test director you can check whether or not the test director has been installed of the web server of your company.

- If it’s the very first time that you are running the test director, you will have to wait for a while so that the test director downloads and installs itself on your system. 

- If it had been a long since you last ran the test director the test director will update your version with the latest version. 

- Next, you will get a test director log-in window from where you have to log-in as a quality assurance tester. 

- While logging in you will asked to enter the domain and project name. 

- When you will be logged in you will get a test director window comprising of the following test director modules:

1. Requirements module
2. Test plan module
3. Test lab module
4. Defects module

All of the above mentioned test director modules possess some common elements namely:

1. Test director tool bar
2. Menu bar
3. Module tool bar
4. Tools button
5. Help button
6. Log out button

- One can start off straightaway giving the specifications for testing requirements in the requirements module in detail so as to provide a foundation for the rest of the application testing process. 

- All these requirements will be stated in the form of a requirements tree i.e., in a graphical form. 

- Once specified, the requirements need to be linked to the tests. 

- If the defects are found they are also be linked to the requirements which are responsible for those defects. 

What is Silk Test Architecture?

Whenever the graphical user interface of any software system or application is tested, a manipulation is done to the windows, menus, buttons and so on via input sources such as key board and mouse clicks etc. 

These windows, menus, buttons and so on are nothing but the GUI objects which are interpreted by the silk test. 

Later, in the test automation process the silk test recognizes these GUI objects based up on two things that uniquely identify them namely:

1. Object class properties and
2. Object methods

The operations that are performed on that particular application software by the users are usually in terms of input from keyboard and mouse clicks. 

These events are simulated by the silk test and the results thus obtained are subjected to automatic verification. 

This whole process is carried out by two very distinct components of the silk test mentioned below:

1. Silk host software and
2. Silk agent software

Both of these components are installed on different machines: the host machine and the target machine. 

- Host machine is for the silk host software whereas target machine is for the second component of the silk test. 

- The host component plays an important role in the development of the test scripts as well as the test plan.

- Using the components the following operations can be carried out on the test scripts:

1. Creating
2. Editing
3. Deleting
4. Compiling
5. Running
6. Debugging etc.

- The latter component of the silk test i.e., the agent is configured to interact with the graphical user interface of the AUT or application under test. 

- The agent is responsible for monitoring as well as driving the application under test. 

- The commands in test scripts are written in the 4test language. 

- These need to be translated in to specific equivalent GUI commands. 

- This task is also achieved by the silk agent software. 

- One thing that should be taken care of is that the application under test should be installed on the same machine as of the agent and on no machine else. 

- Matching objects to that of the GUI objects are created in the 4test and each one is unique. 

- Silk test completes test automation in a period of 4 steps:

1. Creation of a test plan
2. Recording of the test frame
3. Creation of the test cases
4. Execution of the test cases and interpretation of the test results.

- The interaction between the GUI of the application and the silk test is necessary since the operations need to be submitted to the application for simulation. 

- During the simulation, the silk test is said to be the simulated user whose work is to drive the application under test. 

- Since the AUT does not recognize the difference between the simulated user and the actual user, it behaves exactly in the same way as it reacts to an actual user. 

- In addition, you can have an agent as a local agent installed on the host machine. 

- Machines other than the host machine on which agent is installed in a network are called target machines. 

- The application under test is driven by the silk test and in turn drives the server like always. 

- Silk test is quite a powerful tool and can be used to drive the GUI of a server directly by running the scripts which will send equivalent SQL scripts to the data base of the server. 

- In such a way the server application is manipulated directly thus supporting the testing involving a server being driven by a client.

List out the advantages and limitations of Silk Test?

Silk test over the years has always been successful in delivering the test automation and that too in an agile development. 

It is considered by most of us that the quality management is just a discrete discipline when it comes to the agile projects, which is wrong. The fact is that the quality management forms an integral part of the code production process in agile projects. 

The rate of flexibility and change associated with the development of agile projects is increasing day by day and thus it is required that the testing should be made automated as and when and as much as possible. 

The traditional tools for test automation and management have very less capability for accommodating the required changes that are made to skills, processes, responsibility, and attitude and so on. 

Therefore, the whole software world is now shifting to the agile management practices. 

- Agile development goals at delivering the code at the end of the sprints which is ready for the production process. 

- There is no other go for the agile development projects except to undergo a rigorous testing routine in each and every sprint and to automate the testing. 

- If it is not done, the agile projects are sure to fall short of quality. 

- With every iteration a customer value is delivered by the agile project. 

- More testing is permitted in test automation process. 

- This also aids in cutting down the costs of the software since the time lag between the introduction and identification of the defect is slashed. 

- There is a need to regularly check about the changes which lead to development of frequent builds involving the test automation runs. 

- The earlier the test automation runs are run the sooner the defects are identified. 

- Another advantage of silk test is that it supports continuous test automation. 

- Test automation results are what is demanded by the agile teams and that too on a per build basis. 

- Silk test makes sure about this and delivers the UI automation at the fastest play back speed possible. 

- The play back speed offered by the silk test is the fastest that is available in the current market. 

- This in turn has another advantage which is that it reduces the duration of testing which helps in submitting timely test results as required by the agile teams. 

- The saved time thus can be utilized for further testing activities. 

- Agile teams exhibit a strong and flexible collaboration among the testers and developers and thus the test-ability of the applications can be further improved up on. 

- Here, we should not miss out mentioning that the tool which provides the strongest support for custom UI properties in the industry is none other than the silk test automation tool. 

- Stable and reliable identifiers are required for the UI controls and this is also catered by the silk test automation tool. 

- Silk test is quite different from the other tools in the sense that it does not rely on a small subset of properties for identifying the objects. 

- Silk test provides very detailed test results thus minimizing the efforts that you will have to spend on the analyzation of the test failures. 

- The test failures related to the issues of test script synchronization are minimized by the reliable test execution of the silk test.

Limitations of SilkTest

1. Recognition of some objects in some page is not possible due to some technical reasons.
2. Some window frames may not be recognized.
3. Frequent change in tag value is observed.
4. Difficulty in activating some window is experienced.
5. In some of the web applications and web pages the links are taken as simple text. 

What is keyword driven testing framework and methodology?

Keyword driven testing is one of the testing methodologies which is gaining popularity in the area of the test automation. Well, in this article, we are going to discuss regarding the frame work and methodology of the keyword driven testing. 

What is Keyword Driven Testing?

- The key word driven testing methodology is actually dependent on frame work. 

- It depends on such a frame work that calls for the development of the key words and data tables.

- But there is one condition which is that it should be independent of the test automation tool which is to be used for their execution. 

- Another condition is that it should also be independent of the test script code which is used to drive the application under test or AUT as well as the data. 

- In this testing methodology, the functionality of the application under test or AUT need to be documented in a table. 

- Also, the functionality needs to be stated as in step by step instructions for each and every test. 

- This then actually becomes a frame work approach for creating automated regression tests. 

- The frame work approach thus obtained proves to be successful in achieving many benefits of the automated testing when compared to the traditional methodology for capture and playback of the custom scripts. 

- Whenever automated testing is required, two sets of requirements come in to existence namely:

1. Business Requirements: This category included the following requirements:

a) Maintainability: The maintenance of the tests should be easy as well as there should be a minimum need for updating scripts with changes made to the application and newer versions.

b) Selective testing: Less requirement of in depth testing. Also it should be easy to select test scenarios for a much targeted regression.

c) Recovery: It should be possible for the test suite to resume testing from the point where it failed or crashed at a later point of time. The need for re- testing the functionality should be eliminated.

d) Scalability: For gaining the time efficiency the execution of the tests from different machines at the same time should be possible.

e) Inter environment portability: All the environments must support the test scripts without making nay changes to them.

f)   Usability: Minimal amount of training must be required by employees to learn to execute the automated suite. There should be no manual intervention in the execution of the scripts.

g) Reporting: The status of each test script must be known easily.

2. Technical requirements: This category includes:

a) Data abstraction: There should complete isolation of the test data for the execution of the scripts from the actual script code.

b) Separation of concerns: Concerns at each layer must be addressed by the distinct layers of the architecture.

c)  Portability

Methodology of the keyword driven testing lies in two different phases namely:

1. Planning phase and
2. The implementation phase

The planning phase involves the analyzation of the application and determination of operations and objects to be used in the business processes. The requirement of customized keywords is determined for the following purpose:

1. Additional functionality
2. Business level clarity
3. Maximizing efficiency
4. Maintainability

The second phase i.e., the implementation phase operates around a collection of objects or references usually known as repository which saves the info for unique identification of the objects. This phase also involves the development and documentation of the keywords of the business level in function libraries. Development of customized functions is required for the creation of the functional libraries. This is all done for the application under test or AUT.

The methodology of the keyword driven testing calls for more advance planning and time investment.

What are file types used in Silk Test?

Silk test consists of many file types which have been discussed in this article. There are various types of files that are used by the silk test in the process of automation testing. 

Each of the files is used for a specific purpose or we can say function such as certain files are required by the silk test for the creation and execution of the tests. 

Now we shall discuss the different file types available one by one:

1. Test plan (.pln): This file type in silk test facilitates the creation of the test suites. But the test suites can be created lonely if this file type is combined with the test scripts.

Testone

          Script: test.t

          Test case: one

Testtwo

          Script: test.t

          Test case: second

Here in the above example the main test script file is test. t. on the other hand the ‘one’ and the ‘second’ are the names of the test cases in the main script file test.t. Whenever this file type is run the test cases one and second are automatically picked up by the main script file and executed.

2. Test script (.t): This file type in the silk test is used while writing the actual test scripts. Whenever such a file is in run session the test one and test two test cases are executed by it in a predefined order and at the end the note pad application is closed.
3. Frame file (.inc): The windows and the controls present in the AUT or application under test are defined by an abstraction layer. These windows as well as the controls are referenced later in .t files.
4. Result file (.res): This file type consists of all the test run results which have the names of all the passed as well as failed tests along with their suitable descriptions. These file types may or may not contain log messages.

Leaving out the result file (.res) type, almost all the other file types are based up on text. Therefore, the editing of all those files can be edited either using the silk test IDE or by using a text editor.

In the silk test version that was released in the year of 2006, the files can be saved in either of the two formats namely:

1. ANSI format or
2. The UTF – 8 format

5. Project (.vtp): This file type is saved with an extension of 'verify test project' and is used as storage for the locations as well as the names of the files that are currently in use by some project. With this file type there is another associated file type .ini extension since it is an initialization file.
6. Data driven script (.g.t): This file type stores the data driven test cases which are use to pull out data from the data bases.
7. Suite (.s): With the help of this file type the sequential execution of several test scripts is possible.  
8. Text file (.txt): This is an ascii file type and can be used for the following purposes:

a)   For storing a data that can be used for driving a test.

b)   For printing a file in some another document.

c)   The test automation file is accompanied by this file type as a read me file.

d)   For transformation of a tab delimited plan in to a silk test plan.

Entire above discussed source files are compiled and stored as the ‘pseudo code object files’ at either of the times:

1. When the files are loaded or
2. When any change has occurred in the file types. 

How will you call from one action to another action in QTP?

In the test scripts produced with the help of quick test professional, one action can be called from another action. In this article we are going to discuss the same i.e., how this can be done? 

How to call from one action to another action?

- A call to a reusable action can be inserted easily that might be stored in some local test (current test) or in some external test (external test). 

- Calling one action from some other action is just like inserting an action call in an existing action or just linking it to it.

- The steps involved in this whole process can be viewed using the action view tool but they cannot be modified. 

- The local object repository of the action that has been called is read only. 

- It is not necessary that each and every calling and called action must have a local object repository. 

- It may or may not have a repository.

- If the external action that has been called has some data in the data table, you get two options:

1. Either you take the data from the data sheet of the action and import it as a editable or local copy,
2. Or you take the data from the original action but here the data is read only type.

- The data obtained from the global data sheet of the action that has been called is imported to the test as an editable and local copy of data.

- In order to modify an existing external action you need to open the particular test where you have the action stored and make modifications there itself. 

- These modifications will be visible in all the tests that will call that particular function. 

- If you choose to go for the second option as mentioned above then the changes that you will make will apply to original data as well. 

Step by step procedure of how a call to an action can be inserted?

1. Go to insert menu, the select the “call to existing action” option and you will be provided with a list of actions. From that select “insert call to existing action” or you can also right click on any of the steps. The go for the action button and then click on “insert call to existing” option. Now a action properties dialog box pops up.
2. There is a browse button called “from test” and can be used to find the test that holds the action to be called. All the reusable actions in the test that you select are displayed in this action box.
3. From the action that is displayed select the action that is to be called and its type as well as description both are displayed if available. This type and description help you further in proper identification of the action that you wish to be called.  You can even set other properties of the actions by going to the “setting general action properties”.
4. Now you are done with setting the properties, decide on where the function has to be inserted. For inserting the function you are provided with two options namely:

a)   After the current step or

b)   At the end of the test

There is one thing to be noted which is that if the step that is in current selection is a reusable action from some another test, then the action call is added at the end of the test automatically.

5. Now the last step is to just clock on the OK button and you have your action inserted. This action can be moved to any other desired location by just dragging it to that position.