How to update and mail defects in Test Director?

Normal tracking of the defects requires too much efforts but tracking the repair of defects in a project just requires the periodic updates of the defects.

This can be done directly using either of the two:

1. Defects grid and
2. Defect details dialog box

However, the ability of both the methods to update some fields of the defects depends pretty much on the permission settings given by user. 

In this article we shall discuss how you can update the information of the defects by assigning different defects to different members of the development team, adding a comment and by changing the severity of the defects.

Steps for Updating Defects in test Director

1. Make sure that you have the defects module on display and if it is not do so by clicking on the defects tab.
2. Now, to update the defects directly using the defects grid, go to the defects grid and select the concerned defect that you also added using the ‘add new defects” dialog box. In order to assign the defect to a member, select the name of concerned member from the list by clicking on the ‘assigned to’ box in the defect  records.
3. Next click on the defect details tab and it will open up defect details dialog box for you.
4. In this defect details dialog box, do the following tasks:

a) Select the required severity from the severity box to change the severity level of the defect.

b)  Add a comment to explain the change in severity level if you wish so by clicking on the add comment button in the description menu.

5. To view all the attachments click on the attachments button in the left menu and you will see the list of URL attachments.
6. For viewing the history of the changes made to the defect click on the history button in the left menu. For every change made to the defect the date of the change, new value and name of the person who made the change is displayed by the test director.
7. When you are done with everything click OK to exit this dialog box and save the changes.

Steps to mail defects in Test Director

- The details about a defect can be shared with another user via e – mail. 

- With this, a routine of the inform development  and quality assurance can be developed regarding the defect repair activity.

- A ‘go to defect’ link is included in the test director using which the user can go directly to the concerned defect. 

- Follow the below mentioned steps to mail a defect to the concerned person:

1. First of all display the defects module by clicking on the defects tab.
2. Next select the defect you want to mail and click on the mail defects button. This will open up another dialog box called ‘send mail’ dialog box.
3. In this box you need to enter a valid e – mail address in the ‘To’ field.
4. For including any attachments or history of the defects select attachments and history option from the include box.
5. You can add your own comments under the additional comments.
6. When you are done composing the e – mail click on the send button. You will get a message box. Click ok.
7. The person to whom you have sent the mail can view it from his/ her mail box.

Even a test in the test plan can be associated with a specific defect in the defects grid. Whenever an association is created it can be determined whether the test is to be executed based up on the status of the defect. 

How to add and match defects in Test Director?

Location of the defects and their effective repair forms an inseparable part of the application development and indeed of the test director testing process. Defects can be submitted by almost everyone involved with the development process such as the developers, end users and of course testers. The test director eases all the testing processes and thus defects can be submitted through it and can be tracked until they are appropriately repaired. 

In this article we shall discuss the following two things:

1. Adding defects in the test director and
2. Matching defects in test director

Steps in adding defects in Test Director

Whenever a defect is submitted to the test director it is processed through the following  four stages:

1. New
2. Open
3. Fixed
4. Closed

Addition of the defects to the test director can be carried out at almost any stage of the test process. Below we state the steps that you need to follow in order to add the defects in test director:

1. Open the test director project with which you are concerned and log on to it.
2. Next step involves displaying the defects module by clicking on the defects tab. The defect data will be displayed by the defects grid in a grid where each row is a representation of an individual defect record.
3. Clicking on the add defect button will open up the ‘add defect’ dialog box. The fields displayed in red color are mandatory to be filled up.
4. Fourth step involves describing the defect by providing the following details:

a) Summary: i.e., what problem the defect actually caused.

b) Category

c)  Severity

d) Subject

e) Detected in version

f) Description:

It includes the part of the code where the defect was discovered and 

what problem was actually encountered.

5. Now you need to attach the URL address for the page where the defect was found by clicking on the Attach URL button. Clicking on that button will open up a attach URL dialog box. There type the address of the page and click OK. This URL will be displayed above the description box by the test director.
6. Next run a spell check for the text in the description box. If any errors are found follow the replacement suggestions.
7. Click on the submit button to submit the defect to the test director project.
8. Finally, close the add defect dialog box by clicking on the close button. The defect will be added to the defect grid.

How to match defects in Test Director

- The purpose of matching the defects is to find similar defects so that the duplicate ones can be eliminated from the project. 

-  Every time a new defect is added the list of keywords is stored by the test director from the description and summary fields. 

-  The stored keywords are then used for matching the defects. 

- Articles, coordinate conjunctions, wildcards and Boolean operators are ignored by the test director while matching the two tests. 

- Below mentioned steps are for matching defects in test director:

1. Like for adding the defects this also requires displaying the defects module. Do this by clicking on the defects tab.
2. From the defects grid select the one you want to match. If in case you cannot find the required test search it using the clear filter/ sort button.
3. Now click on the find similar defects button to find similar defects. The results will be displayed in the similar defects dialog box by the test director.The defects are searched based up on percentage of the similarity detected.
4. Finally, click on the close button to close the similar defects dialog box. 

What issues should be considered when deciding whether to automate a test? How to generate an automated test script?est Scripts, Scripts

Execution of the test sets lies at the center of any testing process. As the software system or application encounters changes, the defects are located by running both manual as well as automated tests in the project. Also, the quality of the tests is assessed by running the tests itself. 

Issues considered when deciding to go for automation?

- Deciding which all tests have to be automated is a part of the test planning process. 

- Two options namely manual and automated are available for the execution of the tests. 

- If you go with the manual execution of the tests, you can begin with the execution just after you finish defining the test steps. 

- If you go for automating the tests, the test scripts need to be generated and completed. 

- Below we state the issues that should be considered when deciding to go for automation:

1. Do Automate: Only the tests which are data driven or which make use of multiple data values for the same operation, which run with every new version of the application as a measure to check its functionality i.e., regression testing, which are for stress testing i.e., run many times and tests that facilitate the checking of a server system or multi-user client system (load testing) must always be automated.
2. Do not automate: The tests which are meant for a single execution, need to be executed immediately, check for the usability of the tests and whose result cannot be predicted should not be automated.

Steps for generating Automated Test Scripts

Below mentioned steps can be followed for the generation of the automated test scripts:

1. First, click on the test plan tab in order to enable the display of the test plan module.
2. Locate the manual test that you want to automate by selecting the subject folder available at the root of the test plan tree. There click on the find button and the find folder/ test dialog box will open up.
3. Type the name of the test to be searched for in the ‘value to find’ field of the box. Check the ‘include tests’ check box so that the test director can be instructed to look for folders and tests. Finally click on find option. ‘Search results’ dialog box will pop up thus displaying all the possible matches. Click on go to button and the test will be highlighted in the test plan tree. Close this dialog box.
4. Click on the design steps tab in order to display the design steps tab.
5. For generating a test script click on the generate script button. You can choose either of the following options:

a) QUICKTEST_ TEST: For generating an astra quicktest test or quick test professional test.

b)   WR – AUTOMATED: For generating a winrunner test.

The above two options will be available if the corresponding add ins have been installed. Once the test has been automated, the manual test symbol ‘M’ will be replaced by automated test icon.

6. For viewing the test script click on the test script lab. Click on the launch button for displaying and modifying the test script in the testing tool where it was created.

Whenever an automated test is run, the testing tool selected by the tester is opened by the test director automatically and the test is run on either the remote hosts or local machines. The tests can be run either from the execution flow tab or the execution grid tab.

How do you modify and convert requirements in Test Director?

There is no doubt in the fact that one kicks off a testing process by inputting the specification of the requirements employing the requirements module of the test director. Requirements are a necessity in the testing process. Also, the foundation on which a testing team carries out the testing process is laid down by the requirements itself. The definition of the requirements is represented in the form of what is called a requirements tree. This is actually a graphical representation of the requirements as stated in the document view with the only difference being of hierarchical display. 

The requirements can be grouped as well as sorted out in a requirements tree. The following tasks can also be carried out:

1. Task allocation monitoring.
2. Monitoring the progress of the requirements.
3. Generation of the detailed graphs and reports.

Once the tests have been created in the test plan module they have to be linked to the corresponding requirements. 

Here in this article, we talk about the modification and conversion of the requirements in the test director. 

One can modify the requirements by following the below mentioned step sequence:

1. First, make sure that the requirements module is available on display. If in case it is not you need to open it using the requirements tab. Both the requirements tree as well as the document view will be displayed.
2. Your next step is to copy that particular requirement to which you want to make modifications from the requirements tree by clicking on the copy option. Next clicking on the paste option and you will get a warning saying that you are duplicating the requirement. Click OK and the requirement will be pasted in the same hierarchy level as that of the original requirement. Suffix _copy_ is added to the name of the requirement.
3. Next step, is to rename the requirement by following the usual procedure for renaming an object.
4. Next, move this requirement to a different location but in the same requirements tree. But the requirements should be pasted as child requirement. Click OK for confirmation and drag the requirement to any location you want in the requirements tree.
5. For deleting this requirement as well its child requirement use the delete option.

Once all the requirements have been created and defined, they can be used as a basis for providing definition of the test plan tree module. The conversion to test wizards can be used to get assistance for designing the test plan tree. Using this wizard you can convert the selected requirements from the requirement tree in to subjects or tests for the test plan tree.

Steps for conversion of Requirements

Now the below mentioned steps can be followed for the conversion of the requirements:

1. For the modification procedure make sure that the requirements is up for display and if it is not there do so by clicking on the requirements tab.
2. From the various requirements in the requirements tree select the one which you want to be converted.
3. Now launch the convert to tests wizard from the tool menu and from that click on ‘convert selected’ option.
4. You can go for the automatic conversion method by taking second option i.e., ‘convert lowest child requirements to tests’ for the conversion of the selected requirements in to tests.
5. Now clicking on the next button will start the conversion process and after the conversion the results will be displayed in the step 2 dialog box. 

What are the types of Exception available in Win Runner? How do you handle an Exception in WinRunner?

In this article, we talk about the various kinds of exceptions available in winrunner and how to handle them. Basically 4 types of exceptions are available in winrunner and they have been mentioned below:

1. Pop up exceptions
2. Object exceptions
3. TSL exceptions and lastly
4. Web exceptions

Web exceptions are available only if you have installed the web add- ins.

How are different types of exceptions are handled in WinRunner?

- A pop up exception handler is provided in the wirunner package for handling the pop up exceptions that often show up during the execution of the test scripts during the running of acceptance user test.  

- Winrunner can be made to handle pop ups by making it learn the window and by specifying a handler for the exception. 

- These handlers can be:

1. User defined handlers: The names of these handlers can be specified by clicking on the user defined function name and changing it according to your own will.
2. Default actions: Winrunner makes its own choice whether to press ok or cancel option. The desired default handler can be selected in the dialog box.

What if your batch test is executing up on a highly unstable version of the software system or application? 

- Obviously it will crash and you would want to recover the test execution. 

- This is possible only through the TSL exceptions which help in the test recovery by instructing the winrunner to exit the current test and restart the application.

- The winrunner can be easily instructed upon how an unexpected event or error can be handled that may occur in the testing environment while you test your web site. 

Here now we explain how to handle such exceptions. 

- Whenever you load some web test add in, the winrunner can be very well instructed up on how a particular exception can be handled that occurred during a test run in your web site. 

- The simplest example that can be given is of the security alert dialog box that some times appears during the test run. 

- The user can resume the normal testing by clicking on the yes button of the security alert dialog box. 

- All the exceptions that are supported by the winrunner are mentioned in a list and can be viewed in the web exception editor.

- This list can be modified and additional exceptions that you want the winrunner to support can be configured and added to the list. 

- All the new exceptions are to be added to the list of exceptions stored in the web exception editor. 

- You need to go down to the tools menu and select the option of web exception handling.

- This opens the web exception editor. 

- There is a pointing hand, clicking on that adds a new exception to the list. 

- For categorizing the exception you need to select a category in the type list. 

- The MSW_class, message and title of the exception are displayed by the editor.

- There is an action list available which provides you the options for carrying out the following execution:

1. Web_ exception_ handler_ dialog_ click_ default: For activating the default button.
2. Web_ exception_ handler_ fall_ retry: For reloading the web page as well as activating the default button.
3. Web_ exception_ enter_ user name_ password: For using the given user id and password.
4. Web_ exception_ handler_ dialog_ click_ yes: For activating the yes button.
5. Web_ exception_ handler_ dialog_ click_ no: For activating the no button.

- The other operations that can be carried out in winrunner up on exceptions are defining, modifying, activating and deactivating them. 

What causes browser display differences?

Most of the time while browsing the same over many browsers you might have noticed considerable differences between the displays across the various browsers. These differences cause a lot of annoyance to the users.

There are various reasons why there occur differences across the different browsers. This article is focussed up on such browser display differences and errors as well as suggestions to avoid them.

ABOUT WEB BROWSER DISPLAY DIFFERENCES

- Earlier it was quite difficult and time consuming task to compare the web sites displays under many different browsers but nowadays several tools have been developed that have proven to be quite effective in testing the appearance of a web site on various browsers.

- These tools help in checking out the differences by taking the snap shots of the web site across the various browsers and then comparing them.

- You can even have the snap shots of your web page under different computers and screen resolutions.

- An HTML tool box is incorporated in these tools which tell whether the differences have occurred due to the incompatibility of the HTML code used in the web site or are they because of the browser incompatibility.

- The HTML tool box in some of the tools has also the capability for repairing off the code errors in just a few clicks.

Some of the most common factors that causes browser display differences are:
1. Browser bugs
2. Browser incompatibility
3. HTML errors
4. Different font sizes
5. Different computer types
6. Different screen sizes
7. Different versions of the browsers

RARE CASES
- In some very rare cases, the problem of differences might also occur due to certain features of a web site that have been exclusively designed for certain browsers and are not meant for others.

- Usually a web site is developed so that all of its features are accessible by all the web sites.

- For example, the web site for downloading Google chrome extensions and tools has been designed exclusively for the Google chrome browser.

- Though this web site can be viewed in any other browser but, one cannot download extensions through that browser.

STEPS FOR ELIMINATING DISPLAY DIFFERENCES ARE:

There are several steps that one can take for eliminating such differences:
1. Avoiding using cutting edge HTML as far as possible.
2. Set some goals for your web site.
3. Always check for the browsers incompatibilities.
4. Follow the trial and error debugging method.
5. Never forget to validate your web pages.

WHAT WEB BROWSERS ACTUALLY DO?

- They translate the web site code in to the formatted web pages.

- Every individual web browser has its own way of translating the web pages.

- This can be compared to the following example: you give a sentence written in German to a few people and ask them to translate it in to English. Checking the results, you will observe that all of them though have translated the sentence but their ways of translation are different i.e., the have used different words and grammar composition.

- Though the rules and standards for using HTML have been stated by the World Wide Web consortium, web site designers have their own way of implementing it.

- There is a fact that you should know which is that there is no such an effective browser that supports the hundred percent of the HTML, though there are certain browsers that come a little far away than their counterparts.

- If your browser does not supports a part of the code, it is sure to affect the display of your web site.

- This problem is further exaggerated by the HTML extensions that are specific to certain browsers.

- Such problems have forced the designers to put a label on their web site stating on which browser their web site can be viewed.

Interface Analysis - Analysis of Display Content and Work Environment

ANALYSIS OF DISPLAY CONTENT

User tasks lead to the presentation of variety of content.Content can be character based reports, graphical displays, specialized information. Analysis modeling techniques identify the output data objects. During this step, the format and aesthetics of content are considered.
To determine format and aesthetics of content, steps that are followed are:
- can user customize screen location for content?
- is proper on-screen identification assigned to all content?
- how is color used to enhance understanding?
- how will error messages and warnings presented to user?
- how is report partitioned for ease of understanding?
- are different types of data assigned to consistent geographic locations on screen?

ANALYSIS OF WORK ENVIRONMENT

People do not work in isolation. They are always influenced by the activity around them. In some applications, the user interface is placed in a user-friendly location but in others lighting and noise may be a factor, a keyboard or mouse may not be an option. in addition to physical environment factors, the work place culture also is important.Can system interaction be measured? Will two or more people share information before input is provided? Many such questions should be answered before interface design commences.