By Shalini Rawal

I wanted to share my understanding of USE CASES and get valuable inputs from you. I found use case very interesting and an easy way to design test cases. The name sounds a bit awkward. Doesn’t it? So then what does it mean?

Use Case is a very effective elicitation technique which can be used throughout SDLC. It describes “who” can do “what” with the system in question. The use case technique is used to capture a system’s behavioral requirements by detailing scenario-driven threads through the functional requirements. It is very effective where multiple user classes are involved. As compared to other approach (Requirement Itemisation) of test case designing from SRS, use case has some advantages:

• Easy to write

• Expressed in language of the user

• Can be visually represented

• Can be used for validation (acceptance testing)

• Tools support

• Ideal for OO development

• Where the system is functionally oriented (different types of users, complex behavioral patterns)

We should not use a Use Case when system has few users and is dominated by Non-Functional requirement. Now let us see the various entities involved in a Use Case.

• Actor: An Actor is someone or something that interacts with the system. Example of actors are People (Users), Devices, Other Systems, Organizations. Actors live outside the boundary of the system being defined and they initiate an action. Types of actors are Primary actor and Supporting actor.

A PRIMARY ACTOR is one who calls on the system to deliver a service. i.e. it has a GOAL with respect to the system. A PRIMARY ACTOR is typically who triggers the use case

Examples: A caller initiating a telephone call, a customer withdrawing money from the ATM

(Note: Use cases help identify Primary actors early in the lifecycle)

A SUPPORTING ACTOR is an external actor that provides a service to the system under design.

Examples: A high-speed printer, a web service

(Note: We can use supporting actors to identify external interfaces and the protocols the system will use. An actor can be primary in one use case and supporting in another).

• A GOAL is:

• What an ACTOR wants to get with the help of the system

• An ACTION is

• what the ACTOR must perform to reach the GOAL

• An INTERACTION is

• a sequence of steps that must be  followed to complete the ACTION

Examples of USE CASEs are:

1. “Purchase Goods” Level: User Goal

1. Visitor enters customer information (name, address, etc.).

2. System retrieves customer’s profile information, and presents product search and selection mechanisms.

3. Visitor selects products until satisfied. After each selection, system adds the selected product to the customer’s shopping cart and presents the ongoing running total of products selected.

4. Visitor selects to purchase the selected items.

5. System presents contents of shopping cart and requests customer’s payment information.

6. Visitor enters manner of payment and other payment details.

7. System presents visitor with final sums, charges credit card, and delivers packing list to the shipping department.

2. “Book flight!” referencing “Find a flight-”

“Book flight!” Level: User Goal

1. The customer contacts the travel agency and requests a flight.

2. The customer finds a flight-.

3. The system presents the travel options to the customer.

4. The customer selects a flight.

5. The system builds and reserves flight itinerary for the customer.

7. The customer provides a credit card number.

8. The system charges the flight against it and issues the ticket.

“Find a flight-” Level: Subfunction

1. The customer requests to find a flight.

2. The travel agent captures the customer’s trip origin and destination.

3. The travel agent looks up the airport codes for the origin and destination.

4. The travel agent captures the preferred departure times for the customer.

5. The travel agent captures the customer’s preferred class of service.

6. The travel agent confirms that the customer’s preferences are correct.

7. The system gets from the airline reservation system and presents a list of the available flights that match the customer’s preferences.

To summarise, Use Cases are very helpful in deriving test cases from specification. Some of the good practices for writing Use Cases are:

• Make the use cases clear, short and easy to read: Use active voice, present tense, make sure actor and actor’s intent are visible in each step.

• Every Use case has two possible endings: Success and Failure / alternate courses. Don’t forget to gather both.

• Create a list of primary actors and their goals (actor-goal list).

• Restrict use cases to capture system behavior….use cases are not suitable for other type of requirements.

• Use a common template.

By Shalini Rawal

Correlation is a method used by performance testing tools such as LoadRunner to handle dynamic content. Dynamic content refers to page components that are dynamically created during every execution of the business process and always differ from the value generated in the previous run. For example, consider the following interaction with a web based application.

When a yahoo user successfully logs in the website, the web server returns a session id to the web browser that is being used by the user along with the page indicating that the login has succeeded. The user then clicks the Inbox link on the returned page that request the web server to open the Inbox page. The Web browser includes the session ID when sending the request. Based on the session ID, the Web server knows that the request comes from someone who is already logged on, and so open the respective Inbox page. In this case data in the second request depends on the data contained in the response to a previous request. So here the request data is substituted from the response data on which it depends. The term for this internal tagging of response and request data is data correlation (or, sometimes, dynamic data). When a test is run with multiple users and varied data, data correlation is required to ensure that the test runs correctly. Besides this correlation is also used to simplify or optimize the code and to accommodate unique data records.

To use correlation the following steps are to be followed:

1.    Determine the value to correlate: This can be done in two ways. Firstly we can scan for correlation and choose from the list, the values to correlate. Secondly we can record the same script twice and compare them. We can look up the difference file to see for the values which need to be correlated.

2.    Save the results: Save the value of a query to the variable using the appropriate correlating function. The functions are protocol specific. E.g. web_reg_save _param.

3.    Reference the saved values: Replace the constants in the query or the statement with the saved variables.

Correlation can be done manually using functions and automatically. Scripts can be automatically correlated during and after recording. The script should be recorded in HTML mode as this reduces the need for correlation. Vugen’s correlation engine automatically correlates dynamic data using Built-in Correlation or User Defined Rule during recording. The Built-in correlation detects and correlates dynamic data for supported application servers. Most servers have clear syntax rules or contexts that they use when creating links and referrals. User defined Rule correlation is used in an application which has unique rules which can be determined clearly. The new rules can be defined using the Recording Options dialog box. Vugen’s built-in web correlation mechanism correlates scripts after recording. This mechanism compares snapshots captured during record and replay to find values which need to be correlated. The web correlation mechanism has built in comparison utility that displays the text or binary differences between the snapshots. The differences can then be correlated one by one or all at once.

Manual correlation is done using the function web_reg_save_param which dynamically saves data to a parameter. When the script is executed, this function scans the subsequent HTML page for the text specified between the defined left and right boundaries. When the text is found it is assigned to a parameter. Please, note that web_reg_save_param function does not perform correlation. web_reg_save_param function just registers a request for correlation from the next server response. That’s why web_reg_save_param function should be placed before action functions, such as: web_url, web_submit_form, and others.

The function’s syntax is as follows:
Int web_reg_save_param(const char *mpszParamName, <List of Attributes>, LAST);

The available attributes are listed below. The attribute value strings are not case sensitive.

NotFound The handling method when a boundary is not found and an empty string is generated. “ERROR,” the default, indicates that VuGen should issue an error when a boundary is not found. When set to “EMPTY,” no error message is issued and script execution continues. Note that if Continue on Error is enabled for the script, then even when NOTFOUND is set to “ERROR,” the script continues when the boundary is not found, but it writes an error message to the Extended log file.

LB The left boundary of the parameter or the dynamic data. This parameter must be a non-empty, null-terminated character string. Boundary parameters are case sensitive; to ignore the case, add “/IC” after the boundary. Specify “/BIN” after the boundary to specify binary data.

RB The right boundary of the parameter or the dynamic data. This parameter must be a non-empty, null-terminated character string. Boundary parameters are case sensitive; to ignore the case, add “/IC” after the boundary. Specify “/BIN” after the boundary to specify binary data.

RelFrameID The hierarchy level of the HTML page relative to the requested URL.

Search The scope of the search—where to search for the delimited data. The possible values are Headers (search only the headers), Body (search only Body data, not headers), or ALL (search Body and headers). The default value is ALL.

ORD This optional parameter indicates the ordinal or occurrence number of the match. The default ordinal is 1. If you specify “All,” it saves the parameter values in an array.

SaveOffset The offset of a sub-string of the found value, to save to the parameter. The default is 0. The offset value must be non-negative.

Savelen The length of a sub-string of the found value, from the specified offset, to save to the parameter. The default is -1, indicating until the end of the string.

Convert The conversion method to apply to the data:

HTML_TO_URL: convert HTML-encoded data to a URL-encoded data format

HTML_TO_TEXT: convert HTML-encoded data to plain text format

Examples:
The examples below are taken from the LoadRunner tutorial to give clarity on topic. We will see more examples in the coming posts.

Sample Correlation for Web Vusers
Suppose the script contains a dynamic session ID:
web_url(”FirstTimeVisitors”,”URL=/exec/obidos/subst/help/first-time-visitors.html/002-8481703-4784428>Buy books for a penny “, “TargetFrame=”,”RecContentType=text/html”,”SupportFrames=0″,LAST);
The dynamic id here is 002-8481703-4784428
You insert a web_reg_save_param statement before the above statement:
web_req_save_param (”user_access_number”, “NOTFOUND=ERROR”,”LB=first-time-visitors.html/”,”RB=>Buy books for a penny”, “ORD=6″,LAST);
ORD=6 saves the sixth occurrence of the value in user_access_number. I think everything else is self explanatory

After implementing correlated statements, the modified script looks like this, where user_access_number is the name of the parameter representing the dynamic data.
web_url(”FirstTImeVisitors”,”URL=/exec/obidos/subst/help/first-time-”“visitors.html/{user_access_number}Buy books for a penny “,
“TargetFrame=”,”RecContentType=text/html”,”SupportFrames=0″,LAST);
Note: Each correlation function retrieves dynamic data once, for the subsequent HTTP request. If another HTTP request at a later point in the script generates new dynamic data, you must insert another correlation function.

Tips to identify the dynamic string boundaries:

•    Always analyze the location of the dynamic data within the HTML code itself, and not in the recorded script.

•    Identify the string that is immediately to the left of the dynamic data. This string defines the left boundary of the dynamic data.

•    Identify the string that is immediately to the right of the dynamic data. This string defines the right boundary of the dynamic data.

•    web_reg_save_param looks for the characters between (but not including) the specified boundaries and saves the information beginning one byte after the left boundary and ending one byte before the right boundary. web_reg_save_param does not support embedded boundary characters.
For example, if the input buffer is {a{b{c} and “{” is specified as a left boundary, and “}” as a right boundary, the first instance is c and there are no further instances—it found the right and left boundaries but it does not allow embedded boundaries, so “c” is the only valid match. By default, the maximum length of any boundary string is 256 characters.

Include a web_set_max_html_param_len function in your script to increase the maximum permitted length. For example, the following function increases the maximum length to 1024 characters: web_set_max_html_param_len(“1024”);

If you have problems handling dynamic data or you want to optimize your code , avoid nesting queries or handling unique data you know what to do. Of course correlation is the answer….

By Shalini Rawal

Metrics means measurement. Metrics are very important in the development of software as it helps to identify the errors in the software development and thus helps to ensure the quality of the software. They are a system of parameters or ways of quantitative and periodic assessment of a process that is to be measured, along with the procedures to carry out such measurement and the procedures for interpretation of assessment in the light of previous or comparable assessments. The importance of metrics is correctly emphasized in the statement:
“When you can measure what you are speaking about and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, and your knowledge is of the meager and unsatisfactory kind.” - Lord Kelvin

Why Measure

• Tracking Projects against plan
• Take timely corrective actions
• Getting early warnings
• Basis for setting benchmarks
• Basis for driving process improvements
• Tracking process performance against business objectives

Elements of test Metrics:

The elements of test metrics are depicted in the below table:
Metric                                Name of the metric
Metric Description              Description of what is measured
Measurement Procedure     How is the metric measured
Measurement Frequency     How often is the measurement taken
Thresholds Estimation         How are the thresholds calculated
Current Thresholds            Current range of values considered normal for the metric
Target Value                      Best possible value of the metric
Units                                 Units of measurement

Test metrics helps to improve the testing process by providing information such as real status, quality and productivity of the testing effort. This helps to ensure that the tested software is defect free.
We will look at the various metrics that evaluate the effectiveness of the testing process and also the other metrics that are affected due to the testing process will be discussed:

Defect Density: Defect Density is the no. of defects found in a unit. Defects are measured as found in – Reviews, Testing, Acceptance, Warranty.
•    Total Defect density = (Total number of defects including both impact and non-impact, found in all the phases + Post delivery defects)/Size
The defect impacting the functionality is direct impact defect whereas the commenting standard defect found in code review is non-impact.

Average Defect Age: The Average defect age tells us for how long the defect was in the system after it was injected.
•    Average Defect age = (Sum of ((Defect detection phase number – defect injection phase number) * No of defects detected in the defect detection phase))/(Total Number of defects till date)

Defect Removal Efficiency
•    DRE = 100 * No. of pre-delivery defects / Total No. of Defects

Review Effectiveness: It tells us how effective the review process is. If all the defects are found during the review then the effectiveness % will be 100.
•    Review Effectiveness = 100 * Total no. of defects fond in review / Total no. of defects

Cost of finding a defect in review (CFDR): This metric tells us the effort spent in finding a defect in reviews. Cost of reviews includes all the efforts spent in review briefing, defect recording etc. This includes reviewer, recorder and creators time if creator is attending the review his/her time also should be recorded.
•    Cost of finding a defect in reviews = (Total efforts spent on reviews / No. of defects found in reviews)

Cost of finding a defect in testing (CFDT): This metric computes the Cost of finding a defect in testing. Total time spent on testing includes time to create and review, run the test cases and recording the defects. This should not include the time spent in fixing the defects.
•    Cost of finding a defect in testing =  (Total efforts spent on testing / defects found in testing)

Cost of Quality: Cost of Quality consists of Prevention cost, Appraisal cost & Failure (or Rework) cost. Here, cost is the efforts measured in terms of person days. Prevention cost consists of efforts spent on preventing defects such as -
1.      Time spent in various DP meetings
2.      Time spent by DPR/PL on analysis of defect entries/discussions with team members/SQA
3.      Time spent by the team in implementing the preventive actions identified from project start date to till date.

Appraisal cost consists of effort spent on all testing & review activities, from the project start date to till date.

Failure (or Rework) cost includes internal failure cost and external failure cost.
It is the amount of efforts spent on fixing / reworking the pre-delivery and post-delivery defects, from the project start date to till date.
•    % Cost of Quality = (Total efforts spent on Prevention + Total efforts spent on Appraisal + Total efforts spent on failure or rework)*100/(Total efforts spent on project)
•    Failure cost = Efforts spent on fixing or reworking the pre-delivery defects + (3 * efforts spent on fixing or reworking the post-delivery defects)
(As the impact of post delivery defects will be high, weight-age of “3” has been attached to it)

Test Case Effectiveness: This metrics defines the effectives of the test cases which are measured in terms of the number of defects found in testing without using the test cases.
•    Test Case Effectiveness = # of defects detected using the test cases * 100/ total # of defects detected in testing
•    This metrics defines the effectives of the test cases which is measured in terms of the number of defects found in testing with using the test cases
Test Case Adequacy: This metrics defines the number of actual test cases created v/s the estimated test cases at the end of the test case preparation phase
•    Test Case Adequacy = No. of actual Test cases * 100 / No. of test cases estimated

Thus metrics play an important role in IT services by measuring the effectiveness of the testing processes at delivering services to customers. So data can be gathered from different organisations against an agreed set of metrics, to from a benchmark, which would allow organizations to evaluate their performance against industry sectors to establish, objectively, how well they are performing.